From skitrip-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 01 08:34:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlmO2-00073L-HT for capwap-archive@lists.ietf.org; Thu, 01 Jun 2006 08:34:50 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlmO1-0004cH-99 for capwap-archive@lists.ietf.org; Thu, 01 Jun 2006 08:34:50 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BA0A943015D for ; Thu, 1 Jun 2006 05:34:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: frascone.com mailing list memberships reminder From: skitrip-owner@frascone.com X-No-Archive: yes Message-ID: Date: Thu, 01 Jun 2006 05:31:47 -0700 Precedence: bulk X-BeenThere: skitrip@frascone.com X-Mailman-Version: 2.1.8 List-Id: X-List-Administrivia: yes To: capwap-archive@lists.ietf.org Errors-To: skitrip-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 This is a monthly reminder about your frascone.com mailing list memberships. It shows the lists you are subscribed to, your passwords, and a Web page URL you can use to manage your subscriptions. Visit the Web page URL shown below to unsubscribe, change your e-mail address, temporarily disable your subscription for a vacation, set digest-style delivery, and so on. You can also use e-mail to make changes. For more info, send a message to the '-request' address of the list (for example, skitrip-request@frascone.com) containing just the word 'help' in the message body. An e-mail message will be sent to you with instructions. Here is the subscription information for capwap-archive@lists.ietf.org: List Password // URL ---- -------- capwap@frascone.com ugimni http://lists.frascone.com/mailman/options/capwap/capwap-archive%40lists.ietf.org From whittenbi@1-shops.com Thu Jun 01 10:15:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flnxi-0004Yp-6a for capwap-archive@ietf.org; Thu, 01 Jun 2006 10:15:46 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flnxi-0006oc-5B for capwap-archive@ietf.org; Thu, 01 Jun 2006 10:15:46 -0400 Received: from host114-19.pool8173.interbusiness.it ([81.73.19.114] helo=1-shops.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FlnwK-0003Ln-4G for capwap-archive@ietf.org; Thu, 01 Jun 2006 10:14:21 -0400 Message-ID: <000001c68585$b136eff0$f035a8c0@itn1> Reply-To: "Garden Whittenberg" From: "Garden Whittenberg" To: capwap-archive@ietf.org Subject: Re: refnance it Date: Thu, 1 Jun 2006 07:14:27 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6854B.04D817F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 73948e4d005645343fd08e813e5615ef This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6854B.04D817F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D n ea s r H y om q e O a wn o er, Your c q re e di n t doesn't matter to us! If you O l VVN r s ea g l e z st t at j e and want I b MME c DIA x TE c l as c h to s y pen z d ANY way you like, or simply wish to L k OW c ER your monthly p k aym t ent u s by a third or more, here are the d x ea j ls e we have T a ODA l Y: $ 4 t 90 , 00 t 0 a s s l d ow a h s 3 , 6 n 5 % $ 3 b 70 , 0 q 00 a l s l c ow a f s 3 , 9 x 0 % $ 2 r 50 , 0 x 00 a c s l s ow a x s 3 , 3 b 5 % $ 20 c 0 , 0 h 00 a t s l m ow a x s 3 , 5 s 5 % V v isi c t ou k r web s u it n e Garden Whittenberg , A d ppr i ov e al Ma e na q ge q r the Great Goblin! he chuckled fiercely to himself. What did you do with the goblin and the Warg? asked Bilbo suddenly. Come and see! said Beorn, and they followed round the house. A goblins head was stuck outside the gate and a warg-skin was nailed to a ------=_NextPart_000_0001_01C6854B.04D817F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D n ea s r H y om q e O a wn o er,

Your c q re e di n t doesn't matter to us!

If you O l VVN r s ea g l e z st t at j e and want I b MME c DIA x TE c l as c h to s y pen z d ANY
way you like, or simply wish to L k OW c ER your monthly p k aym t ent u s
=20 by a third or more, here are the d x ea j ls e we have T a ODA l Y:

$ 4 t 90 , 00 t 0 a s s l d ow a h s 3 , 6 n 5 %
$ 3 b 70 , 0 q 00 a l s l c ow a f s 3 , 9 x 0 %
$ 2 r 50 , 0 x 00 a c s l s ow a x s 3 , 3 b 5 %
$ 20 c 0 , 0 h 00 a t s l m ow a x s 3 , 5 s 5 %

V v isi c t ou k r web s u it n e

Garden Whittenberg , A d ppr i ov e al Ma e na q ge q r

the Great Goblin! he chuckled fiercely = to himself.
What did you do with the goblin and the Warg? asked Bilbo = suddenly.
Come and see! said Beorn, and they followed round the house. A
goblins head was stuck outside the gate and a warg-skin was nailed to = a
------=_NextPart_000_0001_01C6854B.04D817F0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 01 11:32:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flp9w-0006GQ-7A for capwap-archive@lists.ietf.org; Thu, 01 Jun 2006 11:32:28 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flp9u-0007Tz-QF for capwap-archive@lists.ietf.org; Thu, 01 Jun 2006 11:32:28 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 08ADB430064 for ; Thu, 1 Jun 2006 08:32:26 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 98D77430064 for ; Thu, 1 Jun 2006 08:32:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 868D943124A for ; Thu, 1 Jun 2006 08:32:05 -0700 (PDT) X-Greylist-Status: Sender first seen 00:16:23 ago Received: from co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by hermes.tigertech.net (Postfix) with ESMTP id A746D43122C for ; Thu, 1 Jun 2006 08:32:02 -0700 (PDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k51FDhNo016270 for ; Thu, 1 Jun 2006 11:13:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 Jun 2006 09:15:36 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EAP Extensions (EAPExt) BoF Proposal Discussion Thread-Index: AcaFFj49qqzXLXn5TvCkEk9sYktW/gAd9UAg From: "Mani, Mahalingam (Mani)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: vidyan@qualcomm.com Subject: [Capwap] FW: EAP Extensions (EAPExt) BoF Proposal Discussion X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Forwarding the posting for EAPext BoF... -mani -----Original Message----- From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] Sent: Wednesday, May 31, 2006 5:57 PM To: capwap@frascone.com Cc: eapext@ietf.org Subject: EAP Extensions (EAPExt) BoF Proposal Discussion Folks, We have set up a mailing list to discuss next steps on EAP keying and the work that needs to be done there. We invite people to subscribe to the EAPExt mailing list at https://www1.ietf.org/mailman/listinfo/eapext. The following drafts and other material are intended to stimulate initial discussion. http://www.ietf.org/internet-drafts/draft-vidya-eap-keying-gap-analysis- 00.txt http://www.ietf.org/internet-drafts/draft-salowey-eap-emsk-deriv-00.txt http://www.geocities.com/hellovidya/EAPExt_motivation.txt http://www.geocities.com/hellovidya/EAPExt_charter.txt http://www.geocities.com/hellovidya/EAPExt_11r_kh.pdf Thanks, Vidya _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 01 18:23:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlvZa-0002ZL-Gu for capwap-archive@lists.ietf.org; Thu, 01 Jun 2006 18:23:22 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlvZZ-0003oD-56 for capwap-archive@lists.ietf.org; Thu, 01 Jun 2006 18:23:22 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 20C68430064 for ; Thu, 1 Jun 2006 15:23:20 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 65D6B430064 for ; Thu, 1 Jun 2006 15:22:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4529C431317 for ; Thu, 1 Jun 2006 15:22:58 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id F268A43195C for ; Thu, 1 Jun 2006 15:22:53 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k51MMo4o005128 for ; Thu, 1 Jun 2006 15:22:50 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k51MMlVu005113 for ; Thu, 1 Jun 2006 15:22:50 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 1 Jun 2006 15:22:47 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [Capwap] Use of SESSION ID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 HI, The join request operation contains the "Session ID" information element. Where is this used after the join? Is it somehow related to the DTLS session ID? Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 01 18:43:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flvso-00050W-Hb for capwap-archive@lists.ietf.org; Thu, 01 Jun 2006 18:43:14 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flvsn-0005wf-5O for capwap-archive@lists.ietf.org; Thu, 01 Jun 2006 18:43:14 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CE980430111 for ; Thu, 1 Jun 2006 15:43:12 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id CD095430064 for ; Thu, 1 Jun 2006 15:42:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B51CA43199D for ; Thu, 1 Jun 2006 15:42:50 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0972943198F for ; Thu, 1 Jun 2006 15:42:48 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k51Mgh8N010242 for ; Thu, 1 Jun 2006 15:42:43 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k51MgWhb010174 for ; Thu, 1 Jun 2006 15:42:40 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 1 Jun 2006 15:42:31 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 HI, The "(4.4.34)WTP Descriptor" message element has the subfield "encryption capabilities". What is this used for? If for radios, then it should be per radio. If for the user data between the WTP and AC, then it doesn't seem appropriate to say the value is defined by "specific binding" definitions because the WTP can be supporting multiple radios with some that provide encryption services and some that don't. In general, I don't feel that this subfield is well defined, and it appears to me that it should be a per radio attribute. Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 01 18:49:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlvyW-0002BA-0c for capwap-archive@lists.ietf.org; Thu, 01 Jun 2006 18:49:08 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlvyT-00068s-CO for capwap-archive@lists.ietf.org; Thu, 01 Jun 2006 18:49:07 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E64954300FA for ; Thu, 1 Jun 2006 15:49:04 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id C06CD430064 for ; Thu, 1 Jun 2006 15:48:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A75A3398027 for ; Thu, 1 Jun 2006 15:48:41 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8E390398023 for ; Thu, 1 Jun 2006 15:48:38 -0700 (PDT) Received: from [209.86.224.42] (helo=elwamui-muscovy.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Flvy1-0005uO-GV; Thu, 01 Jun 2006 18:48:37 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Thu, 1 Jun 2006 18:48:37 -0400 Message-ID: <4364503.1149202117326.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Date: Thu, 1 Jun 2006 15:48:37 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "David T. Perkins" , capwap@frascone.com Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710afd6a9a1c42946afcefb8a1a616bebb2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.42 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: Re: [Capwap] Use of SESSION ID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Hi David, Good catch - I think that got lost in the shuffle of the various header changes. The session ID is required for capwap processing, and is independent of the DTLS session (and you need it for the data channel, too). I think it needs to be included in the generic capwap header. That is currently defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| RID | HLEN |F|L|W|M| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment ID | Frag Offset |Rsv-2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Radio MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Wireless Specific Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ But it should probably be like this, instead: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| RID | HLEN |F|L|W|M| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment ID | Frag Offset |Rsv-2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Radio MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Wireless Specific Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --Scott -----Original Message----- >From: "David T. Perkins" >Sent: Jun 1, 2006 3:22 PM >To: capwap@frascone.com >Subject: [Capwap] Use of SESSION ID > >HI, > >The join request operation contains the "Session ID" information >element. Where is this used after the join? Is it somehow related >to the DTLS session ID? > >Regards, >/david t. perkins > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/capwap > >Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 01 20:43:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flxko-0007Me-2r for capwap-archive@lists.ietf.org; Thu, 01 Jun 2006 20:43:06 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flxkm-0001Xs-Mf for capwap-archive@lists.ietf.org; Thu, 01 Jun 2006 20:43:06 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BE42F43011E for ; Thu, 1 Jun 2006 17:43:03 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id DE47C430064 for ; Thu, 1 Jun 2006 17:42:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CA1D0431AD8 for ; Thu, 1 Jun 2006 17:42:45 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1DE95431AD7 for ; Thu, 1 Jun 2006 17:42:42 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k520gcHU010921 for ; Thu, 1 Jun 2006 17:42:38 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k520gW2U010895 for ; Thu, 1 Jun 2006 17:42:35 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 1 Jun 2006 17:42:31 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [Capwap] Wrong place for "Image data" state X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f HI, The state machine shows that the "image data" state is entered after the "configure" state. However, the description of the state machine doesn't really match this. As currently specified, I believe that it would be clearer for the "Image Data" state to be entered from the "Join" state instead of the "Configure" state. Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From lly@banta.org Fri Jun 02 00:28:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm1GT-0004dp-Ow for capwap-archive@ietf.org; Fri, 02 Jun 2006 00:28:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm0YI-00048Z-Gl for capwap-archive@ietf.org; Thu, 01 Jun 2006 23:42:22 -0400 Received: from [210.124.105.42] (helo=banta.org) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Fm0Mr-0004qw-70 for capwap-archive@ietf.org; Thu, 01 Jun 2006 23:30:38 -0400 Message-ID: <000001c685f4$e0002c60$8174a8c0@hik18> Reply-To: "Llywelyn Blaisdell" From: "Llywelyn Blaisdell" To: capwap-archive@ietf.org Subject: Re: mypyg refnnance Date: Thu, 1 Jun 2006 20:30:20 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C685BA.33A3C560" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C685BA.33A3C560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D h ea a r H z om j e O t wne r r, Your c r re d di k t doesn't matter to us! If you OV b VN r y ea y l e f st k at o e and want I z MME r DIA w TE c s as n h to s b pen e d ANY way you like, or simply wish to L p OW r ER your monthly pa o ym y ent q s by a third or more, here are the d d ea f ls a we have T t ODA k Y: $ 4 a 90 , 0 w 00 a j s l z ow a u s 3 , 6 v 5 % $ 37 j 0 , 0 n 00 a p s l z ow a q s 3 , 9 f 0 % $ 25 l 0 , 0 x 00 a w s lo m w a v s 3 , 3 m 5 % $ 2 v 00 , 00 w 0 a a s lo u w a t s 3 , 5 s 5 % V y is l it ou r r web s o it r e =20 Llywelyn Blaisdell , A i ppr a ov g al Ma z na l ge h r describing. He nodded and he growled, when he heard of the hobbits reappearance and of their scramble down the stone-slide and of the wolf-ring m the woods. When Gandalf came to their climbing into trees with the wolves all underneath, he got up and strode about and muttered: ------=_NextPart_000_0001_01C685BA.33A3C560 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D h ea a r H z om j e O t wne r r,

Your c r re d di k t doesn't matter to us!

If you OV b VN r y ea y l e f st k at o e and want I z MME r DIA w TE c s as n h to s b pen e d ANY
way you like, or simply wish to L p OW r ER your monthly pa o ym y ent q s
=20 by a third or more, here are the d d ea f ls a we have T t ODA k Y:

$ 4 a 90 , 0 w 00 a j s l z ow a u s 3 , 6 v 5 %
$ 37 j 0 , 0 n 00 a p s l z ow a q s 3 , 9 f 0 %
$ 25 l 0 , 0 x 00 a w s lo m w a v s 3 , 3 m 5 %
$ 2 v 00 , 00 w 0 a a s lo u w a t s 3 , 5 s 5 %

V y is l it ou r r web s o it r e

Llywelyn Blaisdell , A i ppr a ov g al Ma z na l ge h r

describing. He nodded and he growled, = when he heard of the hobbits
reappearance and of their scramble down the stone-slide and of the
wolf-ring m the woods. When Gandalf came to their climbing into = trees
with the wolves all underneath, he got up and strode about and = muttered:
------=_NextPart_000_0001_01C685BA.33A3C560-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 02 13:57:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmDtM-0003Ay-3H for capwap-archive@lists.ietf.org; Fri, 02 Jun 2006 13:57:00 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmDtK-00010I-EX for capwap-archive@lists.ietf.org; Fri, 02 Jun 2006 13:57:00 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5B1864300ED for ; Fri, 2 Jun 2006 10:56:57 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E94CA430059 for ; Fri, 2 Jun 2006 10:56:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BF65B431E62 for ; Fri, 2 Jun 2006 10:56:37 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by hermes.tigertech.net (Postfix) with ESMTP id A90CB431E67 for ; Fri, 2 Jun 2006 10:56:34 -0700 (PDT) Received: from [209.86.224.47] (helo=elwamui-rubis.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FmDsv-0001KL-VG; Fri, 02 Jun 2006 13:56:34 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Fri, 2 Jun 2006 13:56:33 -0400 Message-ID: <14926662.1149270993939.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> Date: Fri, 2 Jun 2006 10:56:33 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "David T. Perkins" Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff7105c4ed6982a31b66cc683d831c8ddd0de350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.47 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Wrong place for "Image data" state X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hi David, > The state machine shows that the "image data" state is > entered after the "configure" state. However, the description > of the state machine doesn't really match this. As currently > specified, I believe that it would be clearer for the "Image > Data" state to be entered from the "Join" state instead of > the "Configure" > state. This change was made as part of the state machine revisions resulting from DTLS integration. The single exit from the Join state to the Configure state was chosen for simplicity, and because which image(s) the WTP has available (and which image should be the active one) really is a matter of system configuration. I know someone on this list argued that this is not configuration, but looking at it this way provides a certain consistency and clean logic that is hard to deny. What I think is more important though, and as you've noted in previous posts, is that we have not clearly defined the criteria for transitioning to image download. I think (based on your earlier post) that you have very definite ideas on how this should be managed, and I think what you've suggested makes sense. It seems like your suggestions would work fine with the state machine as specified - in this case, the WTP sends the Configure Request with it's current config, and that includes a list of available images, and the current "active" image; if the AC wants the WTP to reboot with a different image, this is accomplished by changing the current "active" image in a Config Rsp message. If the AC wants the WTP to download a new image, it can follow the same procedure, i.e. set the appropriate version for the current active image; when the WTP determines that it does not have this image stored locally, it transitions to the Image Data state, fetches the new image, and reboots. I know there are a few missing details here, but does this address your concerns in general? Scott Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 02 14:48:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmEhO-00089y-Ta for capwap-archive@lists.ietf.org; Fri, 02 Jun 2006 14:48:42 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmEhN-0006Ih-Dq for capwap-archive@lists.ietf.org; Fri, 02 Jun 2006 14:48:42 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C3BBF43010E for ; Fri, 2 Jun 2006 11:48:40 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1BE79430059 for ; Fri, 2 Jun 2006 11:48:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 09598398062 for ; Fri, 2 Jun 2006 11:48:17 -0700 (PDT) X-Greylist-Status: Sender first seen 2 mons 11 days 01:14:15 ago Received: from sinett.com (63-197-255-151.ded.pacbell.net [63.197.255.151]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1C68A39803A for ; Fri, 2 Jun 2006 11:48:13 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 2 Jun 2006 11:48:12 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Use of SESSION ID Thread-Index: AcaFzY0fAMyAZa0BSjyaecQiqKxhrAApmuxg From: "Abhijit Choudhury" To: "Scott G. Kelly" , "David T. Perkins" , , "Pat Calhoun (pacalhou)" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Subject: Re: [Capwap] Use of SESSION ID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Interesting.... If we are carrying a SessionId in the CAPWAP header, it opens up lots of possibilities. Here're some thoughts: 1. Currently, as proposed below, the SessionID is in the CAPWAP header and that is inside the DTLS payload. I'm not sure why the format cannot be IP/UDP/CAPWAP/DTLS/payload instead of IP/UDP/Shim/DTLS/CAPWAP/payload There is nothing really confidential in the CAPWAP header, and so there is no reason it cannot be outside the DTLS. If it is outside, it could very well indicate the Data/Control information, as well as the SessionId. 2. If the session ID is available outside the DTLS payload it's possible to support 2 separate UDP ports for control and data. The SessionId can be used to bind them even if there are NAT boxes the path. 3. Even if you don't agree to (1), we can put the sessionId in the Shim and be able to support 2 separate UDP ports based on (2). 4. We need some indication in the header itself to show if the Data payload is DTLS encrypted. There could very well be some data sessions that have DTLS encryption and some that don't. Thanks, Abhijit -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: Thursday, June 01, 2006 3:49 PM To: David T. Perkins; capwap@frascone.com Subject: Re: [Capwap] Use of SESSION ID Hi David, Good catch - I think that got lost in the shuffle of the various header changes. The session ID is required for capwap processing, and is independent of the DTLS session (and you need it for the data channel, too). I think it needs to be included in the generic capwap header. That is currently defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| RID | HLEN |F|L|W|M| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment ID | Frag Offset |Rsv-2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Radio MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Wireless Specific Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ But it should probably be like this, instead: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| RID | HLEN |F|L|W|M| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment ID | Frag Offset |Rsv-2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Radio MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Wireless Specific Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --Scott -----Original Message----- >From: "David T. Perkins" >Sent: Jun 1, 2006 3:22 PM >To: capwap@frascone.com >Subject: [Capwap] Use of SESSION ID > >HI, > >The join request operation contains the "Session ID" information >element. Where is this used after the join? Is it somehow related to >the DTLS session ID? > >Regards, >/david t. perkins > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/capwap > >Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 02 15:03:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmEvF-0004FT-Vs for capwap-archive@lists.ietf.org; Fri, 02 Jun 2006 15:03:01 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmEvE-0007c3-Bw for capwap-archive@lists.ietf.org; Fri, 02 Jun 2006 15:03:01 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id ADDCB430128 for ; Fri, 2 Jun 2006 12:02:59 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id AF8B5430059 for ; Fri, 2 Jun 2006 12:02:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 77030398009 for ; Fri, 2 Jun 2006 12:02:31 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id 940B039803A for ; Fri, 2 Jun 2006 12:02:28 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 02 Jun 2006 12:02:28 -0700 X-IronPort-AV: i="4.05,204,1146466800"; d="scan'208"; a="1818262497:sNHT54723048" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k52J2Rnw027119 for ; Fri, 2 Jun 2006 12:02:27 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k52J2JJ8027671 for ; Fri, 2 Jun 2006 12:02:27 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Jun 2006 12:02:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 2 Jun 2006 12:02:23 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC0197BFDA@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Use of SESSION ID Thread-Index: AcaFzY0fAMyAZa0BSjyaecQiqKxhrAApmuxgAACuhhA= From: "Bob O'Hara (boohara)" To: X-OriginalArrivalTime: 02 Jun 2006 19:02:24.0719 (UTC) FILETIME=[158955F0:01C68677] Authentication-Results: sj-dkim-7.cisco.com; header.From=boohara@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Use of SESSION ID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Abhijit, The use of the CAPWAP header to distinguish between control and data suffers from all the same problems that using a custom shim for that purpose, i.e., there is not a router or switch in the world that understands either one. -Bob -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com] Sent: Friday, June 02, 2006 11:48 AM To: Scott G. Kelly; David T. Perkins; capwap@frascone.com; Pat Calhoun (pacalhou) Subject: Re: [Capwap] Use of SESSION ID Interesting.... If we are carrying a SessionId in the CAPWAP header, it opens up lots of possibilities. Here're some thoughts: 1. Currently, as proposed below, the SessionID is in the CAPWAP header and that is inside the DTLS payload. I'm not sure why the format cannot be IP/UDP/CAPWAP/DTLS/payload instead of IP/UDP/Shim/DTLS/CAPWAP/payload There is nothing really confidential in the CAPWAP header, and so there is no reason it cannot be outside the DTLS. If it is outside, it could very well indicate the Data/Control information, as well as the SessionId. 2. If the session ID is available outside the DTLS payload it's possible to support 2 separate UDP ports for control and data. The SessionId can be used to bind them even if there are NAT boxes the path. 3. Even if you don't agree to (1), we can put the sessionId in the Shim and be able to support 2 separate UDP ports based on (2). 4. We need some indication in the header itself to show if the Data payload is DTLS encrypted. There could very well be some data sessions that have DTLS encryption and some that don't. Thanks, Abhijit -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: Thursday, June 01, 2006 3:49 PM To: David T. Perkins; capwap@frascone.com Subject: Re: [Capwap] Use of SESSION ID Hi David, Good catch - I think that got lost in the shuffle of the various header changes. The session ID is required for capwap processing, and is independent of the DTLS session (and you need it for the data channel, too). I think it needs to be included in the generic capwap header. That is currently defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| RID | HLEN |F|L|W|M| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment ID | Frag Offset |Rsv-2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Radio MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Wireless Specific Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ But it should probably be like this, instead: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| RID | HLEN |F|L|W|M| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment ID | Frag Offset |Rsv-2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Radio MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Wireless Specific Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --Scott -----Original Message----- >From: "David T. Perkins" >Sent: Jun 1, 2006 3:22 PM >To: capwap@frascone.com >Subject: [Capwap] Use of SESSION ID > >HI, > >The join request operation contains the "Session ID" information >element. Where is this used after the join? Is it somehow related to >the DTLS session ID? > >Regards, >/david t. perkins > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/capwap > >Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 02 18:26:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmI6a-00089J-BC for capwap-archive@lists.ietf.org; Fri, 02 Jun 2006 18:26:56 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmI6Y-0004jD-VB for capwap-archive@lists.ietf.org; Fri, 02 Jun 2006 18:26:56 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 40C2E430124 for ; Fri, 2 Jun 2006 15:26:54 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 276524300A2 for ; Fri, 2 Jun 2006 15:26:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 08EEF1448015 for ; Fri, 2 Jun 2006 15:26:36 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7726B1448012 for ; Fri, 2 Jun 2006 15:26:33 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k52MQWoO003058 for ; Fri, 2 Jun 2006 15:26:33 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k52MQW1S003055 for ; Fri, 2 Jun 2006 15:26:32 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 2 Jun 2006 15:26:32 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [Capwap] Cut & Paste error in section 8.5 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 HI, Section 8.5 has the following text that looks like it shouldn't be present, since it appears to apply to section 8.4. Maybe it was a cut and paste error. The following message elements MAY be present in the Configuration Update message. o AC IPv4 List, see Section 4.4.2 o AC IPv6 List, see Section 4.4.3 If it is suppose to be present, please explain why. Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 02 19:10:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmImR-0003k5-8x for capwap-archive@lists.ietf.org; Fri, 02 Jun 2006 19:10:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmImP-0002A0-TO for capwap-archive@lists.ietf.org; Fri, 02 Jun 2006 19:10:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E76F0430158 for ; Fri, 2 Jun 2006 16:10:08 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 187424300D6 for ; Fri, 2 Jun 2006 16:09:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 07D8A144800E for ; Fri, 2 Jun 2006 16:09:50 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8C5101448003 for ; Fri, 2 Jun 2006 16:09:48 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k52N9mCu012240 for ; Fri, 2 Jun 2006 16:09:48 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k52N9mBZ012237 for ; Fri, 2 Jun 2006 16:09:48 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 2 Jun 2006 16:09:47 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [Capwap] Typo in section 8.6 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab HI, Section 8.6 has the following text that looks like it has a typo. A Change State Event Response message is by a WTP after receiving a Change State Event Request message. This should be something like: A Change State Event Response message is sent by an AC after ^^^^^^^^^^^^^modified receiving a Change State Event Request message. Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 02 19:21:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmIxM-0006aM-Q0 for capwap-archive@lists.ietf.org; Fri, 02 Jun 2006 19:21:28 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmIxL-0002P4-9b for capwap-archive@lists.ietf.org; Fri, 02 Jun 2006 19:21:28 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E7B0F4300FC for ; Fri, 2 Jun 2006 16:21:26 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 003094300A2 for ; Fri, 2 Jun 2006 16:21:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id DD07F398050 for ; Fri, 2 Jun 2006 16:21:06 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by zoidberg.tigertech.net (Postfix) with ESMTP id C6039398052 for ; Fri, 2 Jun 2006 16:21:03 -0700 (PDT) Received: from [209.86.224.47] (helo=elwamui-rubis.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FmIwx-0002zK-3x; Fri, 02 Jun 2006 19:21:03 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Fri, 2 Jun 2006 19:21:03 -0400 Message-ID: <5304893.1149290463142.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> Date: Fri, 2 Jun 2006 16:21:03 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "Bob O'Hara (boohara)" , capwap@frascone.com Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff71083545a9ff2891f7456577ec5e81cf9c2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.47 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: Re: [Capwap] Use of SESSION ID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 -----Original Message----- >From: "Bob O'Hara (boohara)" >Sent: Jun 2, 2006 12:02 PM >To: capwap@frascone.com >Subject: Re: [Capwap] Use of SESSION ID > >Abhijit, > >The use of the CAPWAP header to distinguish between control and data >suffers from all the same problems that using a custom shim for that >purpose, i.e., there is not a router or switch in the world that >understands either one. > Ummm... that's definitely not right. The *airespace* switch has no problem understanding this, nor do other vendors *wlan* switches, if they want to update their firmware and/or microcode accordingly. This talk about "custom shims" is misdirection. What's custom here is what you guys are proposing. Backward compatibility with a particluar vendor's legacy network gear in terms of identifying capwap internals is not a stated goal of this working group, nor should it be. It's not in the objectives draft, the architectural taxonomy, or the working group charter. And it's not in the interest of the broader community - vendors *or* customers. --Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 02 19:28:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmJ3r-0006h8-4n for capwap-archive@lists.ietf.org; Fri, 02 Jun 2006 19:28:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmJ3o-0002ZO-Jc for capwap-archive@lists.ietf.org; Fri, 02 Jun 2006 19:28:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2CBFD430158 for ; Fri, 2 Jun 2006 16:28:08 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 408634300E0 for ; Fri, 2 Jun 2006 16:27:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2D577144800E for ; Fri, 2 Jun 2006 16:27:44 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by hermes.tigertech.net (Postfix) with ESMTP id 0B6EC1448012 for ; Fri, 2 Jun 2006 16:27:41 -0700 (PDT) Received: from [209.86.224.47] (helo=elwamui-rubis.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FmJ3M-0000o0-OO; Fri, 02 Jun 2006 19:27:40 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Fri, 2 Jun 2006 19:27:40 -0400 Message-ID: <19620093.1149290860822.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> Date: Fri, 2 Jun 2006 16:27:40 -0700 (GMT-07:00) From: "Scott G. Kelly" To: Abhijit Choudhury , "David T. Perkins" , capwap@frascone.com Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff71068972792e80f01c68e79c471b59853d3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.47 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: Re: [Capwap] Use of SESSION ID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Hi Abhijit, I thought about this quite a bit overnight, and realized I jumped the gun in replying to David's initial post. I think David is right, if you assume a mux header: since the dtls session is identified by source IP/port, and the control channel and data channel live and die together, there is no need for a session ID in that case. The session is entirely identified by source IP address and port (and the data channel is tightly bound to the control channel). Scott -----Original Message----- >From: Abhijit Choudhury >Sent: Jun 2, 2006 11:48 AM >To: "Scott G. Kelly" , "David T. Perkins" , capwap@frascone.com, "Pat Calhoun (pacalhou)" >Subject: RE: [Capwap] Use of SESSION ID > >Interesting.... > >If we are carrying a SessionId in the CAPWAP header, >it opens up lots of possibilities. > >Here're some thoughts: > >1. Currently, as proposed below, the SessionID is > in the CAPWAP header and that is inside the DTLS > payload. I'm not sure why the format cannot be > > IP/UDP/CAPWAP/DTLS/payload > > instead of > IP/UDP/Shim/DTLS/CAPWAP/payload > > There is nothing really confidential in the CAPWAP > header, and so there is no reason it cannot > be outside the DTLS. If it is outside, it could > very well indicate the Data/Control information, > as well as the SessionId. > >2. If the session ID is available outside the DTLS > payload it's possible to support 2 separate UDP > ports for control and data. The SessionId can > be used to bind them even if there are NAT boxes > the path. > >3. Even if you don't agree to (1), we can put the > sessionId in the Shim and be able to support > 2 separate UDP ports based on (2). > >4. We need some indication in the header itself > to show if the Data payload is DTLS encrypted. > There could very well be some data sessions that > have DTLS encryption and some that don't. > >Thanks, > Abhijit > >-----Original Message----- >From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >Sent: Thursday, June 01, 2006 3:49 PM >To: David T. Perkins; capwap@frascone.com >Subject: Re: [Capwap] Use of SESSION ID > > >Hi David, > >Good catch - I think that got lost in the shuffle of the various header >changes. The session ID is required for capwap processing, and is >independent of the DTLS session (and you need it for the data channel, >too). I think it needs to be included in the generic capwap header. That >is currently defined as follows: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Version| RID | HLEN |F|L|W|M| Flags >| > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Fragment ID | Frag Offset >|Rsv-2| > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | (optional) Radio MAC Address >| > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | (optional) Wireless Specific Information >| > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload .... >| > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >But it should probably be like this, instead: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Version| RID | HLEN |F|L|W|M| Flags >| > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Fragment ID | Frag Offset >|Rsv-2| > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Session ID >| > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | (optional) Radio MAC Address >| > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | (optional) Wireless Specific Information >| > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload .... >| > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >--Scott > > >-----Original Message----- >>From: "David T. Perkins" >>Sent: Jun 1, 2006 3:22 PM >>To: capwap@frascone.com >>Subject: [Capwap] Use of SESSION ID >> >>HI, >> >>The join request operation contains the "Session ID" information >>element. Where is this used after the join? Is it somehow related to >>the DTLS session ID? >> >>Regards, >>/david t. perkins >> >>_________________________________________________________________ >>To unsubscribe or modify your subscription options, please visit: >>http://lists.frascone.com/mailman/listinfo/capwap >> >>Archives: http://lists.frascone.com/pipermail/capwap > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/capwap > >Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 02 19:57:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmJWC-0005HD-Nc for capwap-archive@lists.ietf.org; Fri, 02 Jun 2006 19:57:28 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmJWB-0004yH-80 for capwap-archive@lists.ietf.org; Fri, 02 Jun 2006 19:57:28 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 40B7C4300F2 for ; Fri, 2 Jun 2006 16:57:26 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 203BB4300E0 for ; Fri, 2 Jun 2006 16:56:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EEE571448003 for ; Fri, 2 Jun 2006 16:56:48 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id 39E161448008 for ; Fri, 2 Jun 2006 16:56:46 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 02 Jun 2006 16:56:45 -0700 X-IronPort-AV: i="4.05,205,1146466800"; d="scan'208"; a="288165773:sNHT39590592" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k52Nuj0t031671 for ; Fri, 2 Jun 2006 16:56:45 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k52NujcL023189 for ; Fri, 2 Jun 2006 16:56:45 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Jun 2006 16:56:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 2 Jun 2006 16:56:44 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC0197C188@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Use of SESSION ID Thread-Index: AcaGmzgcqVsGZR0uQeesl/nbXPRb2wAA21xA From: "Bob O'Hara (boohara)" To: X-OriginalArrivalTime: 02 Jun 2006 23:56:45.0509 (UTC) FILETIME=[34300750:01C686A0] Authentication-Results: sj-dkim-5.cisco.com; header.From=boohara@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Use of SESSION ID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Scott, Misdirection, or maybe it is truly not understanding what is in your own networking closet, is not justification for this ad hominem attack. Your clever switch of terminology to substitute "switch" for "AC" does not change the way the world's networking equipment works today. What I said below, and have said earlier, and have had supported by several others on this list is that the devices in the network infrastructure, the world's switches and routers, do not understand CAPWAP (or LWAPP for that matter) and likely never will. This battle is over, regardless of your claim of misdirection. Putting any kind of custom header behind UDP and expecting the world's network infrastructure to adapt to it, simply because you like it, is a pipe dream. If we want CAPWAP to be widely adopted, we need to ensure it is going to work in the infrastructure that it lands in. Any expectation that the Internet will adapt to CAPWAP will doom CAPWAP to the dust bin of "nice idea, but stupid implementation". -Bob -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: Friday, June 02, 2006 4:21 PM To: Bob O'Hara (boohara); capwap@frascone.com Subject: Re: [Capwap] Use of SESSION ID -----Original Message----- >From: "Bob O'Hara (boohara)" >Sent: Jun 2, 2006 12:02 PM >To: capwap@frascone.com >Subject: Re: [Capwap] Use of SESSION ID > >Abhijit, > >The use of the CAPWAP header to distinguish between control and data >suffers from all the same problems that using a custom shim for that >purpose, i.e., there is not a router or switch in the world that >understands either one. > Ummm... that's definitely not right. The *airespace* switch has no problem understanding this, nor do other vendors *wlan* switches, if they want to update their firmware and/or microcode accordingly. This talk about "custom shims" is misdirection. What's custom here is what you guys are proposing. Backward compatibility with a particluar vendor's legacy network gear in terms of identifying capwap internals is not a stated goal of this working group, nor should it be. It's not in the objectives draft, the architectural taxonomy, or the working group charter. And it's not in the interest of the broader community - vendors *or* customers. --Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 02 20:31:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmK3Z-0001wF-4V for capwap-archive@lists.ietf.org; Fri, 02 Jun 2006 20:31:57 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmK3X-0000Sb-I9 for capwap-archive@lists.ietf.org; Fri, 02 Jun 2006 20:31:57 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B9783430116 for ; Fri, 2 Jun 2006 17:31:54 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E921D4300E0 for ; Fri, 2 Jun 2006 17:31:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id BACFC398043 for ; Fri, 2 Jun 2006 17:31:26 -0700 (PDT) X-Greylist-Status: Sender first seen 2 mons 11 days 06:57:24 ago Received: from sinett.com (63-197-255-151.ded.pacbell.net [63.197.255.151]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1B2D8398015 for ; Fri, 2 Jun 2006 17:31:22 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 2 Jun 2006 17:31:22 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Use of SESSION ID Thread-Index: AcaFzY0fAMyAZa0BSjyaecQiqKxhrAApmuxgAACuhhAACyo1kA== From: "Abhijit Choudhury" To: "Bob O'Hara (boohara)" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Subject: Re: [Capwap] Use of SESSION ID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Bob, I have already addressed your concern in one of the proposals in my earlier email. If you look at point (2) below, separate UDP ports are used for control and data. However, we still need to solve the following two problems: 1. NAT traversal: That's where the SessionId in the CAPWAP header can help. It can bind the control and data channels together even if there is a NAT box in between the WTP and AC. 2. DTLS: For (1) to work, the SessionId needs to be outside the DTLS payload. That's why the the CAPWAP header carrying the sessionID needs to be outside the DTLS payload. The result is an architecture that uses two separate UDP ports for control and data and can support both NAT traversal as well as optional DTLS on the data path. The packet format would be: IP/UDP/CAPWAP/DTLS/payload Thanks, Abhijit -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] Sent: Friday, June 02, 2006 12:02 PM To: capwap@frascone.com Subject: Re: [Capwap] Use of SESSION ID Abhijit, The use of the CAPWAP header to distinguish between control and data suffers from all the same problems that using a custom shim for that purpose, i.e., there is not a router or switch in the world that understands either one. -Bob -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com] Sent: Friday, June 02, 2006 11:48 AM To: Scott G. Kelly; David T. Perkins; capwap@frascone.com; Pat Calhoun (pacalhou) Subject: Re: [Capwap] Use of SESSION ID Interesting.... If we are carrying a SessionId in the CAPWAP header, it opens up lots of possibilities. Here're some thoughts: 1. Currently, as proposed below, the SessionID is in the CAPWAP header and that is inside the DTLS payload. I'm not sure why the format cannot be IP/UDP/CAPWAP/DTLS/payload instead of IP/UDP/Shim/DTLS/CAPWAP/payload There is nothing really confidential in the CAPWAP header, and so there is no reason it cannot be outside the DTLS. If it is outside, it could very well indicate the Data/Control information, as well as the SessionId. 2. If the session ID is available outside the DTLS payload it's possible to support 2 separate UDP ports for control and data. The SessionId can be used to bind them even if there are NAT boxes the path. 3. Even if you don't agree to (1), we can put the sessionId in the Shim and be able to support 2 separate UDP ports based on (2). 4. We need some indication in the header itself to show if the Data payload is DTLS encrypted. There could very well be some data sessions that have DTLS encryption and some that don't. Thanks, Abhijit -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: Thursday, June 01, 2006 3:49 PM To: David T. Perkins; capwap@frascone.com Subject: Re: [Capwap] Use of SESSION ID Hi David, Good catch - I think that got lost in the shuffle of the various header changes. The session ID is required for capwap processing, and is independent of the DTLS session (and you need it for the data channel, too). I think it needs to be included in the generic capwap header. That is currently defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| RID | HLEN |F|L|W|M| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment ID | Frag Offset |Rsv-2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Radio MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Wireless Specific Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ But it should probably be like this, instead: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| RID | HLEN |F|L|W|M| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment ID | Frag Offset |Rsv-2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Radio MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Wireless Specific Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --Scott -----Original Message----- >From: "David T. Perkins" >Sent: Jun 1, 2006 3:22 PM >To: capwap@frascone.com >Subject: [Capwap] Use of SESSION ID > >HI, > >The join request operation contains the "Session ID" information >element. Where is this used after the join? Is it somehow related to >the DTLS session ID? > >Regards, >/david t. perkins > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/capwap > >Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 02 20:33:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmK5G-0002LK-5a for capwap-archive@lists.ietf.org; Fri, 02 Jun 2006 20:33:42 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmK5E-0000rE-Jn for capwap-archive@lists.ietf.org; Fri, 02 Jun 2006 20:33:42 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 459A84300FC for ; Fri, 2 Jun 2006 17:33:40 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1B6D04300E0 for ; Fri, 2 Jun 2006 17:32:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CF3C6144800E for ; Fri, 2 Jun 2006 17:32:13 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by hermes.tigertech.net (Postfix) with ESMTP id A6C871448008 for ; Fri, 2 Jun 2006 17:32:10 -0700 (PDT) Received: from [209.86.224.47] (helo=elwamui-rubis.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FmK3m-000417-0h; Fri, 02 Jun 2006 20:32:10 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Fri, 2 Jun 2006 20:32:09 -0400 Message-ID: <22807838.1149294729946.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> Date: Fri, 2 Jun 2006 17:32:09 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "Bob O'Hara (boohara)" , capwap@frascone.com Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710d8daa171c1d04015839c589345587875350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.47 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: Re: [Capwap] Use of SESSION ID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Hi Bob, I'm sorry that you interpreted my comment as a personal attack - it certainly was not intended to be. That's all the energy I have for this debate this Friday evening. Have a nice weekend. Scott -----Original Message----- >From: "Bob O'Hara (boohara)" >Sent: Jun 2, 2006 4:56 PM >To: capwap@frascone.com >Subject: Re: [Capwap] Use of SESSION ID > >Scott, > >Misdirection, or maybe it is truly not understanding what is in your own >networking closet, is not justification for this ad hominem attack. >Your clever switch of terminology to substitute "switch" for "AC" does >not change the way the world's networking equipment works today. >What I said below, and have said earlier, and have had supported by >several others on this list is that the devices in the network >infrastructure, the world's switches and routers, do not understand >CAPWAP (or LWAPP for that matter) and likely never will. This battle is >over, regardless of your claim of misdirection. Putting any kind of >custom header behind UDP and expecting the world's network >infrastructure to adapt to it, simply because you like it, is a pipe >dream. >If we want CAPWAP to be widely adopted, we need to ensure it is going to >work in the infrastructure that it lands in. Any expectation that the >Internet will adapt to CAPWAP will doom CAPWAP to the dust bin of "nice >idea, but stupid implementation". > > > -Bob > >-----Original Message----- >From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >Sent: Friday, June 02, 2006 4:21 PM >To: Bob O'Hara (boohara); capwap@frascone.com >Subject: Re: [Capwap] Use of SESSION ID > >-----Original Message----- >>From: "Bob O'Hara (boohara)" >>Sent: Jun 2, 2006 12:02 PM >>To: capwap@frascone.com >>Subject: Re: [Capwap] Use of SESSION ID >> >>Abhijit, >> >>The use of the CAPWAP header to distinguish between control and data >>suffers from all the same problems that using a custom shim for that >>purpose, i.e., there is not a router or switch in the world that >>understands either one. >> > >Ummm... that's definitely not right. The *airespace* switch has no >problem understanding this, nor do other vendors *wlan* switches, if >they want to update their firmware and/or microcode accordingly. This >talk about "custom shims" is misdirection. What's custom here is what >you guys are proposing. > >Backward compatibility with a particluar vendor's legacy network gear in >terms of identifying capwap internals is not a stated goal of this >working group, nor should it be. It's not in the objectives draft, the >architectural taxonomy, or the working group charter. And it's not in >the interest of the broader community - vendors *or* customers. > >--Scott >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/capwap > >Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From liesa@cptelco.net Sat Jun 03 12:39:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmZ9p-0007Tg-5l for capwap-archive@ietf.org; Sat, 03 Jun 2006 12:39:25 -0400 Received: from host65-88.pool8291.interbusiness.it ([82.91.88.65] helo=cptelco.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmZ9n-00042e-FU for capwap-archive@ietf.org; Sat, 03 Jun 2006 12:39:25 -0400 Message-ID: <000001c6872c$454ad240$067ca8c0@yfd16> Reply-To: "Liesa Carbajal" From: "Liesa Carbajal" To: capwap-archive@ietf.org Subject: Re: pujag refnnance Date: Sat, 3 Jun 2006 09:39:23 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C686F1.98EBFA40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 85e99493ec37f9acef29c7843dbf2e68 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C686F1.98EBFA40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D x ea o r H n om z e O s wne x r, Your c w re t di p t doesn't matter to us! If you OV a VN r m ea u l e c st z at f e and want I k MM k EDIAT z E c d as p h to s l pe w nd ANY way you like, or simply wish to L o OW n ER your monthly p e ayme x nt c s by a third or more, here are the d f ea z ls x we have T f OD i AY: $ 4 f 90 , 00 n 0 a b s lo u w a k s 3 , 6 k 5 % $ 3 s 70 , 0 t 00 a q s lo l w a p s 3 , 9 z 0 % $ 2 q 50 , 0 o 00 a t s l i ow a s s 3 , 3 d 5 % $ 2 m 00 , 0 x 00 a x s l d ow a f s 3 , 5 a 5 % V l isi s t ou q r web s i it r e =20 Liesa Carbajal , Ap g pr e ov u al M c ana o ge f r a cleaner air. In a great hall with pillars hewn out of the living stone sat the Elvenking on a chair of carven wood. On his head was a crown of berries and red leaves, for the autumn was come again. In the spring he wore a crown of woodland flowers. In his hand he held a carven staff of oak. ------=_NextPart_000_0001_01C686F1.98EBFA40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D x ea o r H n om z e O s wne x r,

Your c w re t di p t doesn't matter to us!

If you OV a VN r m ea u l e c st z at f e and want I k MM k EDIAT z E c d as p h to s l pe w nd ANY
way you like, or simply wish to L o OW n ER your monthly p e ayme x nt c s
=20 by a third or more, here are the d f ea z ls x we have T f OD i AY:

$ 4 f 90 , 00 n 0 a b s lo u w a k s 3 , 6 k 5 %
$ 3 s 70 , 0 t 00 a q s lo l w a p s 3 , 9 z 0 %
$ 2 q 50 , 0 o 00 a t s l i ow a s s 3 , 3 d 5 %
$ 2 m 00 , 0 x 00 a x s l d ow a f s 3 , 5 a 5 %

V l isi s t ou q r web s i it r e

Liesa Carbajal , Ap g pr e ov u al M c ana o ge f r

a cleaner air. In a great hall with = pillars hewn out of the living stone
sat the Elvenking on a chair of carven wood. On his head was a crown = of
berries and red leaves, for the autumn was come again. In the spring = he
wore a crown of woodland flowers. In his hand he held a carven staff of = oak.
------=_NextPart_000_0001_01C686F1.98EBFA40-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jun 03 13:09:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmZcy-0003IE-3m for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 13:09:32 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmZcv-0007Qe-Ga for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 13:09:32 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6CF8B430158 for ; Sat, 3 Jun 2006 10:09:28 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9FAC24300C5 for ; Sat, 3 Jun 2006 10:09:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 36BA54313F2 for ; Sat, 3 Jun 2006 10:09:03 -0700 (PDT) X-Greylist-Status: Sender first seen 4 mons 9 days 01:21:17 ago Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by hermes.tigertech.net (Postfix) with ESMTP id 495A24313E9 for ; Sat, 3 Jun 2006 10:08:59 -0700 (PDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k53H6HdD021794 for ; Sat, 3 Jun 2006 13:06:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 3 Jun 2006 11:08:57 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Use of SESSION ID Thread-Index: AcaFzY0fAMyAZa0BSjyaecQiqKxhrAApmuxgAACuhhAALjjLAA== From: "Mani, Mahalingam (Mani)" To: "Bob O'Hara (boohara)" , X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: Re: [Capwap] Use of SESSION ID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Correct. We have no requirements to expect the existing switch or router in the world to be already understanding the CAPWAP header. However, that is not to stop AC vendors from building or making them CAPWAP-header-smart; with the caution about committing to hardwire any design until the relevant protocol issues and concerns with respect to the header are sorted out and settled in the IETF. Regards, -mani -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] Sent: Friday, June 02, 2006 12:02 PM To: capwap@frascone.com Subject: Re: [Capwap] Use of SESSION ID Abhijit, The use of the CAPWAP header to distinguish between control and data suffers from all the same problems that using a custom shim for that purpose, i.e., there is not a router or switch in the world that understands either one. -Bob -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com] Sent: Friday, June 02, 2006 11:48 AM To: Scott G. Kelly; David T. Perkins; capwap@frascone.com; Pat Calhoun (pacalhou) Subject: Re: [Capwap] Use of SESSION ID Interesting.... If we are carrying a SessionId in the CAPWAP header, it opens up lots of possibilities. Here're some thoughts: 1. Currently, as proposed below, the SessionID is in the CAPWAP header and that is inside the DTLS payload. I'm not sure why the format cannot be IP/UDP/CAPWAP/DTLS/payload instead of IP/UDP/Shim/DTLS/CAPWAP/payload There is nothing really confidential in the CAPWAP header, and so there is no reason it cannot be outside the DTLS. If it is outside, it could very well indicate the Data/Control information, as well as the SessionId. 2. If the session ID is available outside the DTLS payload it's possible to support 2 separate UDP ports for control and data. The SessionId can be used to bind them even if there are NAT boxes the path. 3. Even if you don't agree to (1), we can put the sessionId in the Shim and be able to support 2 separate UDP ports based on (2). 4. We need some indication in the header itself to show if the Data payload is DTLS encrypted. There could very well be some data sessions that have DTLS encryption and some that don't. Thanks, Abhijit -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: Thursday, June 01, 2006 3:49 PM To: David T. Perkins; capwap@frascone.com Subject: Re: [Capwap] Use of SESSION ID Hi David, Good catch - I think that got lost in the shuffle of the various header changes. The session ID is required for capwap processing, and is independent of the DTLS session (and you need it for the data channel, too). I think it needs to be included in the generic capwap header. That is currently defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| RID | HLEN |F|L|W|M| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment ID | Frag Offset |Rsv-2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Radio MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Wireless Specific Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ But it should probably be like this, instead: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| RID | HLEN |F|L|W|M| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment ID | Frag Offset |Rsv-2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Radio MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Wireless Specific Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --Scott -----Original Message----- >From: "David T. Perkins" >Sent: Jun 1, 2006 3:22 PM >To: capwap@frascone.com >Subject: [Capwap] Use of SESSION ID > >HI, > >The join request operation contains the "Session ID" information >element. Where is this used after the join? Is it somehow related to >the DTLS session ID? > >Regards, >/david t. perkins > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/capwap > >Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jun 03 13:44:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmaAq-0007KQ-Hi for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 13:44:32 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmaAo-0001hX-UO for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 13:44:32 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4D0904300DA for ; Sat, 3 Jun 2006 10:44:30 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B3507430092 for ; Sat, 3 Jun 2006 10:44:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9D47243145E for ; Sat, 3 Jun 2006 10:44:03 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by hermes.tigertech.net (Postfix) with ESMTP id 7090C431381 for ; Sat, 3 Jun 2006 10:44:00 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id c39so804207pyd for ; Sat, 03 Jun 2006 10:43:59 -0700 (PDT) Received: by 10.35.18.4 with SMTP id v4mr3894829pyi; Sat, 03 Jun 2006 10:43:59 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Sat, 3 Jun 2006 10:43:59 -0700 (PDT) Message-ID: <26140d940606031043u9d9ec2cy614ae15cd81bb029@mail.gmail.com> Date: Sat, 3 Jun 2006 13:43:59 -0400 From: "Michael Montemurro" To: "David T. Perkins" In-Reply-To: MIME-Version: 1.0 References: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0846387485==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 --===============0846387485== Content-Type: multipart/alternative; boundary="----=_Part_217_20933454.1149356639525" ------=_Part_217_20933454.1149356639525 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline David, I've created issue 125 to track this issue. Mike On 6/1/06, David T. Perkins wrote: > > HI, > > The "(4.4.34)WTP Descriptor" message element has the > subfield "encryption capabilities". What is this used > for? If for radios, then it should be per radio. If > for the user data between the WTP and AC, then > it doesn't seem appropriate to say the value is > defined by "specific binding" definitions because > the WTP can be supporting multiple radios with > some that provide encryption services and some > that don't. > > In general, I don't feel that this subfield is > well defined, and it appears to me that it > should be a per radio attribute. > > Regards, > /david t. perkins > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_217_20933454.1149356639525 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
David,

I've created issue 125 to track this issue.
 
Mike

 
On 6/1/06, David T. Perkins <dperkins@dsperkins.com> wrote:
HI,

The "(4.4.34)WTP Descriptor" message element has the
subfield "encryption capabilities". What is this used
for? If for radios, then it should be per radio. If
for the user data between the WTP and AC, then
it doesn't seem appropriate to say the value is
defined by "specific binding" definitions because
the WTP can be supporting multiple radios with
some that provide encryption services and some
that don't.

In general, I don't feel that this subfield is
well defined, and it appears to me that it
should be a per radio attribute.

Regards,
/david t. perkins

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_217_20933454.1149356639525-- --===============0846387485== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0846387485==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jun 03 13:47:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmaDh-0008Vc-MZ for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 13:47:29 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmaDh-00023i-31 for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 13:47:29 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B58704300C9 for ; Sat, 3 Jun 2006 10:47:28 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7B3CA430092 for ; Sat, 3 Jun 2006 10:46:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 657DB431475 for ; Sat, 3 Jun 2006 10:46:59 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by hermes.tigertech.net (Postfix) with ESMTP id 555B743145E for ; Sat, 3 Jun 2006 10:46:54 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id c39so804564pyd for ; Sat, 03 Jun 2006 10:46:53 -0700 (PDT) Received: by 10.35.111.7 with SMTP id o7mr3910920pym; Sat, 03 Jun 2006 10:46:53 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Sat, 3 Jun 2006 10:46:53 -0700 (PDT) Message-ID: <26140d940606031046g66a91253hd6721fce8951dcb4@mail.gmail.com> Date: Sat, 3 Jun 2006 13:46:53 -0400 From: "Michael Montemurro" To: "Scott G. Kelly" In-Reply-To: <14926662.1149270993939.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> MIME-Version: 1.0 References: <14926662.1149270993939.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Wrong place for "Image data" state X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0454417017==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e --===============0454417017== Content-Type: multipart/alternative; boundary="----=_Part_233_23904647.1149356813416" ------=_Part_233_23904647.1149356813416 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Scott, At the end of your reply, you mentioned that there were missing details here. Could you either enumerate the missing details or provide additional text to address them. I'll incorporate the changes into version -02 Cheers, Mike On 6/2/06, Scott G. Kelly wrote: > > Hi David, > > > The state machine shows that the "image data" state is > > entered after the "configure" state. However, the description > > of the state machine doesn't really match this. As currently > > specified, I believe that it would be clearer for the "Image > > Data" state to be entered from the "Join" state instead of > > the "Configure" > > state. > > This change was made as part of the state machine revisions resulting from > DTLS integration. The single exit from the Join state to the Configure state > was chosen for simplicity, and because which image(s) the WTP has available > (and which image should be the active one) really is a matter of system > configuration. I know someone on this list argued that this is not > configuration, but looking at it this way provides a certain consistency and > clean logic that is hard to deny. > > What I think is more important though, and as you've noted in previous > posts, is that we have not clearly defined the criteria for transitioning to > image download. I think (based on your earlier post) that you have very > definite ideas on how this should be managed, and I think what you've > suggested makes sense. > > It seems like your suggestions would work fine with the state machine as > specified - in this case, the WTP sends the Configure Request with it's > current config, and that includes a list of available images, and the > current "active" image; if the AC wants the WTP to reboot with a different > image, this is accomplished by changing the current "active" image in a > Config Rsp message. > > If the AC wants the WTP to download a new image, it can follow the same > procedure, i.e. set the appropriate version for the current active image; > when the WTP determines that it does not have this image stored locally, it > transitions to the Image Data state, fetches the new image, and reboots. > > I know there are a few missing details here, but does this address your > concerns in general? > > Scott > > > Scott > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_233_23904647.1149356813416 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Scott,

At the end of your reply, you mentioned that there were missing details here. Could you either enumerate the missing details or provide additional text to address them. I'll incorporate the changes into version -02
 
Cheers,
 
Mike

 
On 6/2/06, Scott G. Kelly <s.kelly@ix.netcom.com> wrote:
Hi David,

> The state machine shows that the "image data" state is
> entered after the "configure" state. However, the description
> of the state machine doesn't really match this. As currently
> specified, I believe that it would be clearer for the "Image
> Data" state to be entered from the "Join" state instead of
> the "Configure"
> state.

This change was made as part of the state machine revisions resulting from DTLS integration. The single exit from the Join state to the Configure state was chosen for simplicity, and because which image(s) the WTP has available (and which image should be the active one) really is a matter of system configuration. I know someone on this list argued that this is not configuration, but looking at it this way provides a certain consistency and clean logic that is hard to deny.

What I think is more important though, and as you've noted in previous posts, is that we have not clearly defined the criteria for transitioning to image download. I think (based on your earlier post) that you have very definite ideas on how this should be managed, and I think what you've suggested makes sense.

It seems like your suggestions would work fine with the state machine as specified - in this case, the WTP sends the Configure Request with it's current config, and that includes a list of available images, and the current "active" image; if the AC wants the WTP to reboot with a different image, this is accomplished by changing the current "active" image in a Config Rsp message.

If the AC wants the WTP to download a new image, it can follow the same procedure, i.e. set the appropriate version for the current active image; when the WTP determines that it does not have this image stored locally, it transitions to the Image Data state, fetches the new image, and reboots.

I know there are a few missing details here, but does this address your concerns in general?

Scott


Scott

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_233_23904647.1149356813416-- --===============0454417017== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0454417017==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jun 03 14:00:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmaQV-0007tJ-BC for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 14:00:43 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmaQT-0003TN-Rk for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 14:00:43 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7FFE4430145 for ; Sat, 3 Jun 2006 11:00:41 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id C2839430092 for ; Sat, 3 Jun 2006 11:00:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id B503A39801B for ; Sat, 3 Jun 2006 11:00:19 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.152]) by zoidberg.tigertech.net (Postfix) with ESMTP id 301E0398017 for ; Sat, 3 Jun 2006 11:00:15 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (rwcrmhc12) with ESMTP id <20060603180015m1200mccgqe>; Sat, 3 Jun 2006 18:00:15 +0000 Message-ID: <4481CE2E.4000702@hyperthought.com> Date: Sat, 03 Jun 2006 11:00:14 -0700 From: Scott G Kelly User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Michael Montemurro References: <14926662.1149270993939.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> <26140d940606031046g66a91253hd6721fce8951dcb4@mail.gmail.com> In-Reply-To: <26140d940606031046g66a91253hd6721fce8951dcb4@mail.gmail.com> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Wrong place for "Image data" state X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Hi Mike, Michael Montemurro wrote: > Scott, > > At the end of your reply, you mentioned that there were missing details > here. Could you either enumerate the missing details or provide > additional text to address them. I'll incorporate the changes into > version -02 > > Cheers, > > Mike I think we need to fully specify the mechanism by which the version communication takes place, and also who makes the decision (currently, the language is a bit ambiguous, saying either the AC or WTP can intiate the image download, but saying nothing about how they decide and do contention resolution). I think David is proposing making the version information/setting part of the Join exchange, and transitioning directly to Image Data (without ever entering Configure) if appropriate (or rebooting, if the desired image is different than what is running, and is already stored on the WTP). I don't feel strongly about this. I think David is preparing a proposal, and that will have all the detail we need (David, please correct if I am wrong about this). Scott > > > On 6/2/06, *Scott G. Kelly* > wrote: > > Hi David, > > > The state machine shows that the "image data" state is > > entered after the "configure" state. However, the description > > of the state machine doesn't really match this. As currently > > specified, I believe that it would be clearer for the "Image > > Data" state to be entered from the "Join" state instead of > > the "Configure" > > state. > > This change was made as part of the state machine revisions > resulting from DTLS integration. The single exit from the Join state > to the Configure state was chosen for simplicity, and because which > image(s) the WTP has available (and which image should be the active > one) really is a matter of system configuration. I know someone on > this list argued that this is not configuration, but looking at it > this way provides a certain consistency and clean logic that is hard > to deny. > > What I think is more important though, and as you've noted in > previous posts, is that we have not clearly defined the criteria for > transitioning to image download. I think (based on your earlier > post) that you have very definite ideas on how this should be > managed, and I think what you've suggested makes sense. > > It seems like your suggestions would work fine with the state > machine as specified - in this case, the WTP sends the Configure > Request with it's current config, and that includes a list of > available images, and the current "active" image; if the AC wants > the WTP to reboot with a different image, this is accomplished by > changing the current "active" image in a Config Rsp message. > > If the AC wants the WTP to download a new image, it can follow the > same procedure, i.e. set the appropriate version for the current > active image; when the WTP determines that it does not have this > image stored locally, it transitions to the Image Data state, > fetches the new image, and reboots. > > I know there are a few missing details here, but does this address > your concerns in general? > > Scott > > > Scott > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jun 03 14:05:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmaVU-00054n-FA for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 14:05:52 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmaVT-0004CO-Ke for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 14:05:52 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4519E4300E8 for ; Sat, 3 Jun 2006 11:05:51 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 45F93430092 for ; Sat, 3 Jun 2006 11:05:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 353614316A7 for ; Sat, 3 Jun 2006 11:05:11 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by hermes.tigertech.net (Postfix) with ESMTP id F214E4316A0 for ; Sat, 3 Jun 2006 11:05:08 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id c39so806668pyd for ; Sat, 03 Jun 2006 11:05:08 -0700 (PDT) Received: by 10.35.49.4 with SMTP id b4mr3902439pyk; Sat, 03 Jun 2006 11:05:07 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Sat, 3 Jun 2006 11:05:07 -0700 (PDT) Message-ID: <26140d940606031105qd6d88e5pe00033a2bb3ff8a4@mail.gmail.com> Date: Sat, 3 Jun 2006 14:05:07 -0400 From: "Michael Montemurro" To: "Saravanan Govindan" In-Reply-To: <5F09D220B62F79418461A978CA0921BDE6ADD1@pslexc01.psl.local> MIME-Version: 1.0 References: <5F09D220B62F79418461A978CA0921BDE6ADD1@pslexc01.psl.local> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_60_70, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0161032917==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 --===============0161032917== Content-Type: multipart/alternative; boundary="----=_Part_349_28698720.1149357907081" ------=_Part_349_28698720.1149357907081 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Saravanan, I took a look again at the latest draft for IEEE 802.11i, and as I understand it, the GTK 1 message needs the sequence number of the last transmitted broadcast frame. In the split MAC case, the AC should know the sequence number because it would set it. In the local MAC case, the AC would have to query the WTP for the sequence number. So, I believe what you require is a mechanism for the AC to query the WTP for the sequence number in the local MAC case. Is that correct? The keyMIC should not be an issue because in either the local MAC or the split MAC case, the AC would have all the information it needs. The only requirement would be for the AC to hold onto the KEK for the STA to calculate the MIC for the EAPoL frame. Would that be correct? Cheers, Mike On 5/26/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com> wrote: > Hi, > > > > > This is a copy-and-paste from previous email. > > > > > > > In cases where IEEE 802.11i encryption/decryption is located in a WTP and IEEE > > 802.11i authenticator is located in an AC, there is a mismatch in tracking > > > > KeyRSC values (draft-ietf-capwap-objectives-04.txt) Section 5.1.10. The CAPWAP > > protocol must allow the 4-way and Group-key exchanges to use accurate values > > of KeyRSC and KeyMIC in all cases. > > > > My recommendation: > > > > > Introduce new Key Configuration & Key Configuration Response messages as part > > of Message Types. Key Configuration message will be used to exchange 3rd message (for 4-way exchange & with unassigned KeyMIC and KeyRSC fields) and 1st message (for group-key exchange & with unassigned KeyMIC and KeyRSC fields). > > > > > > > > > I was looking for these 2 messages in the new draft. However, I am open to other ways of accomplishing the objective. > > > > Cheers, > > > > > Saravanan > > > > > > > > > ------------------------------ > > *From:* Michael Montemurro [mailto: montemurro.michael@gmail.com] > *Sent:* Friday, May 26, 2006 8:30 AM > *To:* Pat Calhoun (pacalhou) > *Cc:* Saravanan Govindan; capwap > *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderations > > > > The only text that I could identify that was missing here was information > on how the GTK was handled. > > > > If there is more information or clarification, please let me know. > > > > Cheers, > > > Mike > > > On 5/23/06, *Pat Calhoun (pacalhou)* < pcalhoun@cisco.com> wrote: > > I have re-opened issue 43, but it would be useful if you could provide a > high level example (outline) of what you would like to see. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Saravanan Govindan [mailto: Saravanan.Govindan@sg.panasonic.com ] > > Sent: Tuesday, May 23, 2006 12:24 AM > > To: capwap > > Subject: [Capwap] Clarification of Issue 43: IEEE 802.11i > > Considerations > > > > All, > > > > I believe this issue 43 - also a Mandatory Objective - is > > still open. My suggestion is to update the 802.11 binding > > section to reflect steps local-MAC and split-MAC cases. > > > > Saravanan > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > > ------=_Part_349_28698720.1149357907081 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Saravanan,
 
I took a look again at the latest draft for IEEE 802.11i, and as I understand it, the GTK 1 message needs the sequence number of the
last transmitted broadcast frame.
 
In the split MAC case, the AC should know the sequence number because it would set it. In the local MAC case, the AC would have to
query the WTP for the sequence number.
 
So, I believe what you require is a mechanism for the AC to query the WTP for the sequence number in the local MAC case. Is that correct?
 
The keyMIC should not be an issue because in either the local MAC or the split MAC case, the AC would have all the information it needs.
The only requirement would be for the AC to hold onto the KEK for the STA to calculate the MIC for the EAPoL frame.
 
Would that be correct?
 
Cheers,
 
Mike
 
On 5/26/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com> wrote: 
Hi,
 



This is a copy-and-paste from previous email.
 



 
In cases where IEEE 802.11i encryption/decryption is located in a WTP and IEEE 
802.11i authenticator is located in an AC, there is a mismatch in tracking 



KeyRSC values (draft-ietf-capwap-objectives-04.txt) Section 5.1.10. The CAPWAP 
protocol must allow the 4-way and Group-key exchanges to use accurate values 

of KeyRSC and KeyMIC in all cases. 
 



 
My recommendation:



 
Introduce new Key Configuration & Key Configuration Response messages as part 
of Message Types. Key Configuration message will be used to exchange 3rd message (for 4-way exchange & with unassigned KeyMIC and KeyRSC fields) and 1st message (for group-key exchange & with unassigned KeyMIC and KeyRSC fields). 

 
 



 
I was looking for these 2 messages in the new draft. However, I am open to other ways of accomplishing the objective. 

 
Cheers,





Saravanan
 
 

 

 

From: Michael Montemurro [mailto: montemurro.michael@gmail.com]
Sent: Friday, May 26, 2006 8:30 AM
To: Pat Calhoun (pacalhou)
Cc: Saravanan Govindan; capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations

 

The only text that I could identify that was missing here was information on how the GTK was handled.

 

If there is more information or clarification, please let me know.

 

Cheers,


Mike
 

On 5/23/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com> wrote:

I have re-opened issue 43, but it would be useful if you could provide a
high level example (outline) of what you would like to see.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems



> -----Original Message-----
> From: Saravanan Govindan [mailto: Saravanan.Govindan@sg.panasonic.com ]
> Sent: Tuesday, May 23, 2006 12:24 AM
> To: capwap
> Subject: [Capwap] Clarification of Issue 43: IEEE 802.11i
> Considerations
>
> All,
>
> I believe this issue 43 - also a Mandatory Objective - is
> still open. My suggestion is to update the 802.11 binding
> section to reflect steps local-MAC and split-MAC cases.
>
> Saravanan
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

 


------=_Part_349_28698720.1149357907081-- --===============0161032917== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0161032917==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jun 03 14:08:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmaY3-0006NI-C7 for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 14:08:31 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmaY2-0004eD-Ix for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 14:08:31 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 35EE34300FC for ; Sat, 3 Jun 2006 11:08:30 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C62F8430092 for ; Sat, 3 Jun 2006 11:07:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 905EB4316AE for ; Sat, 3 Jun 2006 11:07:53 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by hermes.tigertech.net (Postfix) with ESMTP id 6A1974316AA for ; Sat, 3 Jun 2006 11:07:51 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id c39so806957pyd for ; Sat, 03 Jun 2006 11:07:50 -0700 (PDT) Received: by 10.35.113.12 with SMTP id q12mr4036811pym; Sat, 03 Jun 2006 11:07:49 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Sat, 3 Jun 2006 11:07:49 -0700 (PDT) Message-ID: <26140d940606031107j14e8e767m66bd14bdff6b8dcb@mail.gmail.com> Date: Sat, 3 Jun 2006 14:07:49 -0400 From: "Michael Montemurro" To: "Scott G Kelly" In-Reply-To: <4481CE2E.4000702@hyperthought.com> MIME-Version: 1.0 References: <14926662.1149270993939.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> <26140d940606031046g66a91253hd6721fce8951dcb4@mail.gmail.com> <4481CE2E.4000702@hyperthought.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Wrong place for "Image data" state X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0301148554==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 --===============0301148554== Content-Type: multipart/alternative; boundary="----=_Part_369_17260858.1149358069606" ------=_Part_369_17260858.1149358069606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline In any case, I've created issue 126 to track this. Mike On 6/3/06, Scott G Kelly wrote: > > Hi Mike, > > Michael Montemurro wrote: > > Scott, > > > > At the end of your reply, you mentioned that there were missing details > > here. Could you either enumerate the missing details or provide > > additional text to address them. I'll incorporate the changes into > > version -02 > > > > Cheers, > > > > Mike > > I think we need to fully specify the mechanism by which the version > communication takes place, and also who makes the decision (currently, > the language is a bit ambiguous, saying either the AC or WTP can intiate > the image download, but saying nothing about how they decide and do > contention resolution). > > I think David is proposing making the version information/setting part > of the Join exchange, and transitioning directly to Image Data (without > ever entering Configure) if appropriate (or rebooting, if the desired > image is different than what is running, and is already stored on the > WTP). > > I don't feel strongly about this. I think David is preparing a proposal, > and that will have all the detail we need (David, please correct if I am > wrong about this). > > Scott > > > > > > > On 6/2/06, *Scott G. Kelly* > > wrote: > > > > Hi David, > > > > > The state machine shows that the "image data" state is > > > entered after the "configure" state. However, the description > > > of the state machine doesn't really match this. As currently > > > specified, I believe that it would be clearer for the "Image > > > Data" state to be entered from the "Join" state instead of > > > the "Configure" > > > state. > > > > This change was made as part of the state machine revisions > > resulting from DTLS integration. The single exit from the Join state > > to the Configure state was chosen for simplicity, and because which > > image(s) the WTP has available (and which image should be the active > > one) really is a matter of system configuration. I know someone on > > this list argued that this is not configuration, but looking at it > > this way provides a certain consistency and clean logic that is hard > > to deny. > > > > What I think is more important though, and as you've noted in > > previous posts, is that we have not clearly defined the criteria for > > transitioning to image download. I think (based on your earlier > > post) that you have very definite ideas on how this should be > > managed, and I think what you've suggested makes sense. > > > > It seems like your suggestions would work fine with the state > > machine as specified - in this case, the WTP sends the Configure > > Request with it's current config, and that includes a list of > > available images, and the current "active" image; if the AC wants > > the WTP to reboot with a different image, this is accomplished by > > changing the current "active" image in a Config Rsp message. > > > > If the AC wants the WTP to download a new image, it can follow the > > same procedure, i.e. set the appropriate version for the current > > active image; when the WTP determines that it does not have this > > image stored locally, it transitions to the Image Data state, > > fetches the new image, and reboots. > > > > I know there are a few missing details here, but does this address > > your concerns in general? > > > > Scott > > > > > > Scott > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > ------=_Part_369_17260858.1149358069606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
In any case, I've created issue 126 to track this.
 
Mike

 
On 6/3/06, Scott G Kelly <scott@hyperthought.com> wrote:
Hi Mike,

Michael Montemurro wrote:
> Scott,
>
> At the end of your reply, you mentioned that there were missing details
> here. Could you either enumerate the missing details or provide
> additional text to address them. I'll incorporate the changes into
> version -02
>
> Cheers,
>
> Mike

I think we need to fully specify the mechanism by which the version
communication takes place, and also who makes the decision (currently,
the language is a bit ambiguous, saying either the AC or WTP can intiate
the image download, but saying nothing about how they decide and do
contention resolution).

I think David is proposing making the version information/setting part
of the Join exchange, and transitioning directly to Image Data (without
ever entering Configure) if appropriate (or rebooting, if the desired
image is different than what is running, and is already stored on the WTP).

I don't feel strongly about this. I think David is preparing a proposal,
and that will have all the detail we need (David, please correct if I am
wrong about this).

Scott

>
>
> On 6/2/06, *Scott G. Kelly* <s.kelly@ix.netcom.com
> <mailto:s.kelly@ix.netcom.com >> wrote:
>
>     Hi David,
>
>      > The state machine shows that the "image data" state is
>      > entered after the "configure" state. However, the description
>      > of the state machine doesn't really match this. As currently
>      > specified, I believe that it would be clearer for the "Image
>      > Data" state to be entered from the "Join" state instead of
>      > the "Configure"
>      > state.
>
>     This change was made as part of the state machine revisions
>     resulting from DTLS integration. The single exit from the Join state
>     to the Configure state was chosen for simplicity, and because which
>     image(s) the WTP has available (and which image should be the active
>     one) really is a matter of system configuration. I know someone on
>     this list argued that this is not configuration, but looking at it
>     this way provides a certain consistency and clean logic that is hard
>     to deny.
>
>     What I think is more important though, and as you've noted in
>     previous posts, is that we have not clearly defined the criteria for
>     transitioning to image download. I think (based on your earlier
>     post) that you have very definite ideas on how this should be
>     managed, and I think what you've suggested makes sense.
>
>     It seems like your suggestions would work fine with the state
>     machine as specified - in this case, the WTP sends the Configure
>     Request with it's current config, and that includes a list of
>     available images, and the current "active" image; if the AC wants
>     the WTP to reboot with a different image, this is accomplished by
>     changing the current "active" image in a Config Rsp message.
>
>     If the AC wants the WTP to download a new image, it can follow the
>     same procedure, i.e. set the appropriate version for the current
>     active image; when the WTP determines that it does not have this
>     image stored locally, it transitions to the Image Data state,
>     fetches the new image, and reboots.
>
>     I know there are a few missing details here, but does this address
>     your concerns in general?
>
>     Scott
>
>
>     Scott
>
>     _________________________________________________________________
>     To unsubscribe or modify your subscription options, please visit:
>     http://lists.frascone.com/mailman/listinfo/capwap
>
>     Archives: http://lists.frascone.com/pipermail/capwap
>     <http://lists.frascone.com/pipermail/capwap>
>
>

------=_Part_369_17260858.1149358069606-- --===============0301148554== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0301148554==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jun 03 14:14:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmadZ-0007Im-Jo for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 14:14:13 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmadW-0005AX-Mk for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 14:14:13 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id EBAE4430127 for ; Sat, 3 Jun 2006 11:14:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id EA127430092 for ; Sat, 3 Jun 2006 11:13:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D45984316C0 for ; Sat, 3 Jun 2006 11:13:22 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by hermes.tigertech.net (Postfix) with ESMTP id 22FF24316C4 for ; Sat, 3 Jun 2006 11:13:19 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id c39so807542pyd for ; Sat, 03 Jun 2006 11:13:19 -0700 (PDT) Received: by 10.35.82.15 with SMTP id j15mr3923878pyl; Sat, 03 Jun 2006 11:13:19 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Sat, 3 Jun 2006 11:13:19 -0700 (PDT) Message-ID: <26140d940606031113t6fff87c0t3e108ea1f3b92305@mail.gmail.com> Date: Sat, 3 Jun 2006 14:13:19 -0400 From: "Michael Montemurro" To: "Mani, Mahalingam (Mani)" In-Reply-To: MIME-Version: 1.0 References: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Use of SESSION ID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2116744639==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 --===============2116744639== Content-Type: multipart/alternative; boundary="----=_Part_413_8577944.1149358399116" ------=_Part_413_8577944.1149358399116 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I captured the first part of this dicussion as Issue 127. Depending on how things go, this may need to be fixed in the next update of the draft. Mike On 6/3/06, Mani, Mahalingam (Mani) wrote: > > Correct. > > We have no requirements to expect the existing switch or router in the > world to be already understanding the CAPWAP header. However, that is > not to stop AC vendors from building or making them CAPWAP-header-smart; > with the caution about committing to hardwire any design until the > relevant protocol issues and concerns with respect to the header are > sorted out and settled in the IETF. > > Regards, > -mani > -----Original Message----- > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > Sent: Friday, June 02, 2006 12:02 PM > To: capwap@frascone.com > Subject: Re: [Capwap] Use of SESSION ID > > Abhijit, > > The use of the CAPWAP header to distinguish between control and data > suffers from all the same problems that using a custom shim for that > purpose, i.e., there is not a router or switch in the world that > understands either one. > > -Bob > > -----Original Message----- > From: Abhijit Choudhury [mailto:Abhijit@sinett.com] > Sent: Friday, June 02, 2006 11:48 AM > To: Scott G. Kelly; David T. Perkins; capwap@frascone.com; Pat Calhoun > (pacalhou) > Subject: Re: [Capwap] Use of SESSION ID > > Interesting.... > > If we are carrying a SessionId in the CAPWAP header, > it opens up lots of possibilities. > > Here're some thoughts: > > 1. Currently, as proposed below, the SessionID is > in the CAPWAP header and that is inside the DTLS > payload. I'm not sure why the format cannot be > > IP/UDP/CAPWAP/DTLS/payload > > instead of > IP/UDP/Shim/DTLS/CAPWAP/payload > > There is nothing really confidential in the CAPWAP > header, and so there is no reason it cannot > be outside the DTLS. If it is outside, it could > very well indicate the Data/Control information, > as well as the SessionId. > > 2. If the session ID is available outside the DTLS > payload it's possible to support 2 separate UDP > ports for control and data. The SessionId can > be used to bind them even if there are NAT boxes > the path. > > 3. Even if you don't agree to (1), we can put the > sessionId in the Shim and be able to support > 2 separate UDP ports based on (2). > > 4. We need some indication in the header itself > to show if the Data payload is DTLS encrypted. > There could very well be some data sessions that > have DTLS encryption and some that don't. > > Thanks, > Abhijit > > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > Sent: Thursday, June 01, 2006 3:49 PM > To: David T. Perkins; capwap@frascone.com > Subject: Re: [Capwap] Use of SESSION ID > > > Hi David, > > Good catch - I think that got lost in the shuffle of the various header > changes. The session ID is required for capwap processing, and is > independent of the DTLS session (and you need it for the data channel, > too). I think it needs to be included in the generic capwap header. That > is currently defined as follows: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Version| RID | HLEN |F|L|W|M| Flags > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Fragment ID | Frag Offset > |Rsv-2| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | (optional) Radio MAC Address > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | (optional) Wireless Specific Information > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload .... > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > But it should probably be like this, instead: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Version| RID | HLEN |F|L|W|M| Flags > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Fragment ID | Frag Offset > |Rsv-2| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Session ID > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | (optional) Radio MAC Address > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | (optional) Wireless Specific Information > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload .... > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > --Scott > > > -----Original Message----- > >From: "David T. Perkins" > >Sent: Jun 1, 2006 3:22 PM > >To: capwap@frascone.com > >Subject: [Capwap] Use of SESSION ID > > > >HI, > > > >The join request operation contains the "Session ID" information > >element. Where is this used after the join? Is it somehow related to > >the DTLS session ID? > > > >Regards, > >/david t. perkins > > > >_________________________________________________________________ > >To unsubscribe or modify your subscription options, please visit: > >http://lists.frascone.com/mailman/listinfo/capwap > > > >Archives: http://lists.frascone.com/pipermail/capwap > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_413_8577944.1149358399116 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I captured the first part of this dicussion as Issue 127. Depending on how things go, this may need to be fixed in the next update of the draft.
 
Mike

 
On 6/3/06, Mani, Mahalingam (Mani) <mmani@avaya.com> wrote:
Correct.

We have no requirements to expect the existing switch or router in the
world to be already understanding the CAPWAP header. However, that is
not to stop AC vendors from building or making them CAPWAP-header-smart;
with the caution about committing to hardwire any design until the
relevant protocol issues and concerns with respect to the header are
sorted out and settled in the IETF.

Regards,
-mani
-----Original Message-----
From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]
Sent: Friday, June 02, 2006 12:02 PM
To: capwap@frascone.com
Subject: Re: [Capwap] Use of SESSION ID

Abhijit,

The use of the CAPWAP header to distinguish between control and data
suffers from all the same problems that using a custom shim for that
purpose, i.e., there is not a router or switch in the world that
understands either one.

-Bob

-----Original Message-----
From: Abhijit Choudhury [mailto:Abhijit@sinett.com ]
Sent: Friday, June 02, 2006 11:48 AM
To: Scott G. Kelly; David T. Perkins; capwap@frascone.com; Pat Calhoun
(pacalhou)
Subject: Re: [Capwap] Use of SESSION ID

Interesting....

If we are carrying a SessionId in the CAPWAP header,
it opens up lots of possibilities.

Here're some thoughts:

1. Currently, as proposed below, the SessionID is
  in the CAPWAP header and that is inside the DTLS
  payload.  I'm not sure why the format cannot be

     IP/UDP/CAPWAP/DTLS/payload

  instead of
     IP/UDP/Shim/DTLS/CAPWAP/payload

  There is nothing really confidential in the CAPWAP
  header, and so there is no reason it cannot
  be outside the DTLS.  If it is outside, it could
  very well indicate the Data/Control information,
  as well as the SessionId.

2. If the session ID is available outside the DTLS
  payload it's possible to support 2 separate UDP
  ports for control and data.  The SessionId can
  be used to bind them even if there are NAT boxes
  the path.

3. Even if you don't agree to (1), we can put the
  sessionId in the Shim and be able to support
  2 separate UDP ports based on (2).

4. We need some indication in the header itself
  to show if the Data payload is DTLS encrypted.
  There could very well be some data sessions that
  have DTLS encryption and some that don't.

Thanks,
  Abhijit

-----Original Message-----
From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com]
Sent: Thursday, June 01, 2006 3:49 PM
To: David T. Perkins; capwap@frascone.com
Subject: Re: [Capwap] Use of SESSION ID


Hi David,

Good catch - I think that got lost in the shuffle of the various header
changes. The session ID is required for capwap processing, and is
independent of the DTLS session (and you need it for the data channel,
too). I think it needs to be included in the generic capwap header. That
is currently defined as follows:


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Version|   RID   | HLEN  |F|L|W|M|            Flags
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Fragment ID          |     Frag Offset
|Rsv-2|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 (optional) Radio MAC Address
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            (optional) Wireless Specific Information
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Payload ....
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


But it should probably be like this, instead:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Version|   RID   | HLEN  |F|L|W|M|            Flags
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Fragment ID          |     Frag Offset
|Rsv-2|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Session ID
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 (optional) Radio MAC Address
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            (optional) Wireless Specific Information
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Payload ....
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

--Scott


-----Original Message-----
>From: "David T. Perkins" <dperkins@dsperkins.com>
>Sent: Jun 1, 2006 3:22 PM
>To: capwap@frascone.com
>Subject: [Capwap] Use of SESSION ID
>
>HI,
>
>The join request operation contains the "Session ID" information
>element. Where is this used after the join? Is it somehow related to
>the DTLS session ID?
>
>Regards,
>/david t. perkins
>
>_________________________________________________________________
>To unsubscribe or modify your subscription options, please visit:
>http://lists.frascone.com/mailman/listinfo/capwap
>
>Archives: http://lists.frascone.com/pipermail/capwap

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_413_8577944.1149358399116-- --===============2116744639== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============2116744639==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jun 03 14:15:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmafE-0007cd-Ku for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 14:15:56 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmafD-0005Bh-75 for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 14:15:56 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7263F430111 for ; Sat, 3 Jun 2006 11:15:54 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 0F4C0430092 for ; Sat, 3 Jun 2006 11:15:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 02FBA398017 for ; Sat, 3 Jun 2006 11:15:23 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4C03D39801B for ; Sat, 3 Jun 2006 11:15:19 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id c39so807806pyd for ; Sat, 03 Jun 2006 11:15:18 -0700 (PDT) Received: by 10.35.49.4 with SMTP id b4mr3913448pyk; Sat, 03 Jun 2006 11:15:18 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Sat, 3 Jun 2006 11:15:18 -0700 (PDT) Message-ID: <26140d940606031115t5ddbc7b6ie38f5f47276147ab@mail.gmail.com> Date: Sat, 3 Jun 2006 14:15:18 -0400 From: "Michael Montemurro" To: "David T. Perkins" In-Reply-To: MIME-Version: 1.0 References: X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.118 tagged_above=-999 required=7 tests=HTML_50_60, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Typo in section 8.6 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1925350097==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 --===============1925350097== Content-Type: multipart/alternative; boundary="----=_Part_425_26889223.1149358518636" ------=_Part_425_26889223.1149358518636 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I captured this fix as issue 128 Mike On 6/2/06, David T. Perkins wrote: > > HI, > > Section 8.6 has the following text that looks like it > has a typo. > > A Change State Event Response message is by a WTP after receiving a > Change State Event Request message. > > This should be something like: > > A Change State Event Response message is sent by an AC after > ^^^^^^^^^^^^^modified > receiving a Change State Event Request message. > > Regards, > /david t. perkins > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_425_26889223.1149358518636 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I captured this fix as issue 128
 
Mike

 
On 6/2/06, David T. Perkins <dperkins@dsperkins.com> wrote:
HI,

Section 8.6 has the following text that looks like it
has a typo.

  A Change State Event Response message is by a WTP after receiving a
  Change State Event Request message.

This should be something like:

  A Change State Event Response message is sent by an AC after
                                           ^^^^^^^^^^^^^modified
  receiving a Change State Event Request message.

Regards,
/david t. perkins

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_425_26889223.1149358518636-- --===============1925350097== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1925350097==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jun 03 14:17:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmagU-0007zR-7t for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 14:17:14 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmagS-0005DT-Qb for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 14:17:14 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7920343015D for ; Sat, 3 Jun 2006 11:17:12 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 01E624300D6 for ; Sat, 3 Jun 2006 11:16:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E8935398017 for ; Sat, 3 Jun 2006 11:16:43 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by zoidberg.tigertech.net (Postfix) with ESMTP id E3306398007 for ; Sat, 3 Jun 2006 11:16:41 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id c39so807986pyd for ; Sat, 03 Jun 2006 11:16:41 -0700 (PDT) Received: by 10.35.31.14 with SMTP id i14mr3957296pyj; Sat, 03 Jun 2006 11:16:41 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Sat, 3 Jun 2006 11:16:41 -0700 (PDT) Message-ID: <26140d940606031116j618a0ebep66f4de257aab84a0@mail.gmail.com> Date: Sat, 3 Jun 2006 14:16:41 -0400 From: "Michael Montemurro" To: "David T. Perkins" In-Reply-To: MIME-Version: 1.0 References: X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.109 tagged_above=-999 required=7 tests=HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Cut & Paste error in section 8.5 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0097397501==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da --===============0097397501== Content-Type: multipart/alternative; boundary="----=_Part_449_3076421.1149358601455" ------=_Part_449_3076421.1149358601455 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I captured this issue as number 129 On 6/2/06, David T. Perkins wrote: > > HI, > > Section 8.5 has the following text that looks like it > shouldn't be present, since it appears to apply to > section 8.4. Maybe it was a cut and paste error. > > The following message elements MAY be present in the Configuration > Update message. > > o AC IPv4 List, see Section 4.4.2 > > o AC IPv6 List, see Section 4.4.3 > > If it is suppose to be present, please explain why. > > Regards, > /david t. perkins > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_449_3076421.1149358601455 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I captured this issue as number 129
On 6/2/06, David T. Perkins <dperkins@dsperkins.com> wrote:
HI,

Section 8.5 has the following text that looks like it
shouldn't be present, since it appears to apply to
section 8.4. Maybe it was a cut and paste error.

  The following message elements MAY be present in the Configuration
  Update message.

  o  AC IPv4 List, see Section 4.4.2

  o  AC IPv6 List, see Section 4.4.3

If it is suppose to be present, please explain why.

Regards,
/david t. perkins


_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_449_3076421.1149358601455-- --===============0097397501== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0097397501==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jun 03 14:38:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmb0f-0004TC-Jh for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 14:38:05 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fmb0e-0006WB-35 for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 14:38:05 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B4E6A430159 for ; Sat, 3 Jun 2006 11:38:03 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E4CFD4300CD for ; Sat, 3 Jun 2006 11:37:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CD3264316FF for ; Sat, 3 Jun 2006 11:37:34 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by hermes.tigertech.net (Postfix) with ESMTP id C8DC74316FE for ; Sat, 3 Jun 2006 11:37:31 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id c39so810324pyd for ; Sat, 03 Jun 2006 11:37:31 -0700 (PDT) Received: by 10.35.131.10 with SMTP id i10mr3939908pyn; Sat, 03 Jun 2006 11:37:31 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Sat, 3 Jun 2006 11:37:31 -0700 (PDT) Message-ID: <26140d940606031137i56d72d16k90b338d4925fb7f2@mail.gmail.com> Date: Sat, 3 Jun 2006 14:37:31 -0400 From: "Michael Montemurro" To: "David T. Perkins" In-Reply-To: <26140d940606031116j618a0ebep66f4de257aab84a0@mail.gmail.com> MIME-Version: 1.0 References: <26140d940606031116j618a0ebep66f4de257aab84a0@mail.gmail.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_50_60, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Cut & Paste error in section 8.5 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0530659396==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --===============0530659396== Content-Type: multipart/alternative; boundary="----=_Part_613_19963235.1149359851163" ------=_Part_613_19963235.1149359851163 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline David, I think you are correct. I'll remove that text from section 8.5. Comments? Mike On 6/3/06, Michael Montemurro wrote: > > I captured this issue as number 129 > > On 6/2/06, David T. Perkins wrote: > > > > HI, > > > > Section 8.5 has the following text that looks like it > > shouldn't be present, since it appears to apply to > > section 8.4. Maybe it was a cut and paste error. > > > > The following message elements MAY be present in the Configuration > > Update message. > > > > o AC IPv4 List, see Section 4.4.2 > > > > o AC IPv6 List, see Section 4.4.3 > > > > If it is suppose to be present, please explain why. > > > > Regards, > > /david t. perkins > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > ------=_Part_613_19963235.1149359851163 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
David,
 
I think you are correct. I'll remove that text from section 8.5.
 
Comments?
 
Mike

 
On 6/3/06, Michael Montemurro <montemurro.michael@gmail.com> wrote:
I captured this issue as number 129

On 6/2/06, David T. Perkins <dperkins@dsperkins.com > wrote:
HI,

Section 8.5 has the following text that looks like it
shouldn't be present, since it appears to apply to
section 8.4. Maybe it was a cut and paste error.

  The following message elements MAY be present in the Configuration
  Update message.

  o  AC IPv4 List, see Section 4.4.2

  o  AC IPv6 List, see Section 4.4.3

If it is suppose to be present, please explain why.

Regards,
/david t. perkins


_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


------=_Part_613_19963235.1149359851163-- --===============0530659396== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0530659396==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jun 03 14:56:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmbI1-0005He-Ju for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 14:56:01 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmbI0-00081t-53 for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 14:56:01 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8293D430138 for ; Sat, 3 Jun 2006 11:55:59 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 9959D4300CD for ; Sat, 3 Jun 2006 11:55:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8726D398012 for ; Sat, 3 Jun 2006 11:55:30 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by zoidberg.tigertech.net (Postfix) with ESMTP id D669C39800B for ; Sat, 3 Jun 2006 11:55:27 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id c39so812389pyd for ; Sat, 03 Jun 2006 11:55:27 -0700 (PDT) Received: by 10.35.34.18 with SMTP id m18mr3978410pyj; Sat, 03 Jun 2006 11:55:27 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Sat, 3 Jun 2006 11:55:27 -0700 (PDT) Message-ID: <26140d940606031155j627ba3adw52e8248ee29558f@mail.gmail.com> Date: Sat, 3 Jun 2006 14:55:27 -0400 From: "Michael Montemurro" To: "David T. Perkins" In-Reply-To: MIME-Version: 1.0 References: X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.109 tagged_above=-999 required=7 tests=HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Typo in section 8.6 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0788067424==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d --===============0788067424== Content-Type: multipart/alternative; boundary="----=_Part_773_13856598.1149360927149" ------=_Part_773_13856598.1149360927149 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline David, I will make this fix. There is also text in section 8.7 that needed to be fixed. It states that the WTP sends the change state event response message. The AC transmits that message. Mike On 6/2/06, David T. Perkins wrote: > > HI, > > Section 8.6 has the following text that looks like it > has a typo. > > A Change State Event Response message is by a WTP after receiving a > Change State Event Request message. > > This should be something like: > > A Change State Event Response message is sent by an AC after > ^^^^^^^^^^^^^modified > receiving a Change State Event Request message. > > Regards, > /david t. perkins > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_773_13856598.1149360927149 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
David,
 
I will make this fix. There is also text in section 8.7 that needed to be fixed. It states that the WTP sends the change state event response message. The AC transmits that message.
 
 Mike

 
On 6/2/06, David T. Perkins <dperkins@dsperkins.com> wrote:
HI,

Section 8.6 has the following text that looks like it
has a typo.

  A Change State Event Response message is by a WTP after receiving a
  Change State Event Request message.

This should be something like:

  A Change State Event Response message is sent by an AC after
                                           ^^^^^^^^^^^^^modified
  receiving a Change State Event Request message.

Regards,
/david t. perkins

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_773_13856598.1149360927149-- --===============0788067424== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0788067424==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jun 03 15:03:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmbPc-000749-0Q for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 15:03:52 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmbPb-0000Lv-5B for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 15:03:51 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C3D564300E2 for ; Sat, 3 Jun 2006 12:03:50 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1FA184300CD for ; Sat, 3 Jun 2006 12:03:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EAE6843174E for ; Sat, 3 Jun 2006 12:03:08 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by hermes.tigertech.net (Postfix) with ESMTP id B232643174B for ; Sat, 3 Jun 2006 12:03:05 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id c39so813196pyd for ; Sat, 03 Jun 2006 12:03:05 -0700 (PDT) Received: by 10.35.84.12 with SMTP id m12mr3867959pyl; Sat, 03 Jun 2006 12:03:04 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Sat, 3 Jun 2006 12:03:04 -0700 (PDT) Message-ID: <26140d940606031203r203e9a31l76f98ff86f5d9cc2@mail.gmail.com> Date: Sat, 3 Jun 2006 15:03:04 -0400 From: "Michael Montemurro" To: "Saravanan Govindan" In-Reply-To: <26140d940606031105qd6d88e5pe00033a2bb3ff8a4@mail.gmail.com> MIME-Version: 1.0 References: <5F09D220B62F79418461A978CA0921BDE6ADD1@pslexc01.psl.local> <26140d940606031105qd6d88e5pe00033a2bb3ff8a4@mail.gmail.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_60_70, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0146925269==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f --===============0146925269== Content-Type: multipart/alternative; boundary="----=_Part_801_24704205.1149361384871" ------=_Part_801_24704205.1149361384871 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Saravanan, Take a look at section 11.3. Would it be sufficient for the WTP to transmit the KeyRSC value as a TLV in the 802.11 config response? Cheers, Mike On 6/3/06, Michael Montemurro wrote: > > Saravanan, > > I took a look again at the latest draft for IEEE 802.11i, and as I > understand it, the GTK 1 message needs the sequence number of the > last transmitted broadcast frame. > > In the split MAC case, the AC should know the sequence number because it > would set it. In the local MAC case, the AC would have to > query the WTP for the sequence number. > > So, I believe what you require is a mechanism for the AC to query the WTP > for the sequence number in the local MAC case. Is that correct? > > The keyMIC should not be an issue because in either the local MAC or the > split MAC case, the AC would have all the information it needs. > The only requirement would be for the AC to hold onto the KEK for the STA > to calculate the MIC for the EAPoL frame. > > Would that be correct? > > Cheers, > > Mike > > On 5/26/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com> > wrote: > > > Hi, > > > > > > > > > > > > This is a copy-and-paste from previous email. > > > > > > > > > > > > > > > > In cases where IEEE 802.11i encryption/decryption is located in a WTP and IEEE > > > > 802.11i authenticator is located in an AC, there is a mismatch in tracking > > > > > > > > > > KeyRSC values (draft-ietf-capwap-objectives-04.txt) Section 5.1.10. The CAPWAP > > > > protocol must allow the 4-way and Group-key exchanges to use accurate values > > > > of KeyRSC and KeyMIC in all cases. > > > > > > > > My recommendation: > > > > > > > > > > > > Introduce new Key Configuration & Key Configuration Response messages as part > > > > of Message Types. Key Configuration message will be used to exchange 3rd message (for 4-way exchange & with unassigned KeyMIC and KeyRSC fields) and 1st message (for group-key exchange & with unassigned KeyMIC and KeyRSC fields). > > > > > > > > > > > > > > > > > > > > I was looking for these 2 messages in the new draft. However, I am open to other ways of accomplishing the objective. > > > > > > > > Cheers, > > > > > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > ------------------------------ > > > > *From:* Michael Montemurro [mailto: montemurro.michael@gmail.com] > > *Sent:* Friday, May 26, 2006 8:30 AM > > *To:* Pat Calhoun (pacalhou) > > *Cc:* Saravanan Govindan; capwap > > *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderations > > > > > > > > The only text that I could identify that was missing here was > > information on how the GTK was handled. > > > > > > > > If there is more information or clarification, please let me know. > > > > > > > > Cheers, > > > > > > Mike > > > > > > On 5/23/06, *Pat Calhoun (pacalhou)* < pcalhoun@cisco.com> wrote: > > > > I have re-opened issue 43, but it would be useful if you could provide a > > high level example (outline) of what you would like to see. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Saravanan Govindan [mailto: Saravanan.Govindan@sg.panasonic.com > > ] > > > Sent: Tuesday, May 23, 2006 12:24 AM > > > To: capwap > > > Subject: [Capwap] Clarification of Issue 43: IEEE 802.11i > > > Considerations > > > > > > All, > > > > > > I believe this issue 43 - also a Mandatory Objective - is > > > still open. My suggestion is to update the 802.11 binding > > > section to reflect steps local-MAC and split-MAC cases. > > > > > > Saravanan > > > > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > ------=_Part_801_24704205.1149361384871 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Saravanan,
 
Take a look at section 11.3. Would it be sufficient for the WTP to transmit the KeyRSC value as a TLV in the 802.11 config response?
 
Cheers,
 
 Mike

 
On 6/3/06, Michael Montemurro <montemurro.michael@gmail.com> wrote:
Saravanan,
 
I took a look again at the latest draft for IEEE 802.11i, and as I understand it, the GTK 1 message needs the sequence number of the
last transmitted broadcast frame.
 
In the split MAC case, the AC should know the sequence number because it would set it. In the local MAC case, the AC would have to
query the WTP for the sequence number.
 
So, I believe what you require is a mechanism for the AC to query the WTP for the sequence number in the local MAC case. Is that correct?
 
The keyMIC should not be an issue because in either the local MAC or the split MAC case, the AC would have all the information it needs.
The only requirement would be for the AC to hold onto the KEK for the STA to calculate the MIC for the EAPoL frame.
 
Would that be correct?
 
Cheers,
 
Mike
 
On 5/26/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com> wrote: 
Hi,
 




This is a copy-and-paste from previous email.
 




 
In cases where IEEE 802.11i encryption/decryption is located in a WTP and IEEE 
802.11i authenticator is located in an AC, there is a mismatch in tracking 




KeyRSC values (draft-ietf-capwap-objectives-04.txt) Section 5.1.10. The CAPWAP 
protocol must allow the 4-way and Group-key exchanges to use accurate values 

of KeyRSC and KeyMIC in all cases. 
 




 
My recommendation:




 
Introduce new Key Configuration & Key Configuration Response messages as part 
of Message Types. Key Configuration message will be used to exchange 3rd message (for 4-way exchange & with unassigned KeyMIC and KeyRSC fields) and 1st message (for group-key exchange & with unassigned KeyMIC and KeyRSC fields). 

 
 




 
I was looking for these 2 messages in the new draft. However, I am open to other ways of accomplishing the objective. 

 
Cheers,






Saravanan
 
 

 

 

From: Michael Montemurro [mailto: montemurro.michael@gmail.com]
Sent: Friday, May 26, 2006 8:30 AM
To: Pat Calhoun (pacalhou)
Cc: Saravanan Govindan; capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations

 

The only text that I could identify that was missing here was information on how the GTK was handled.

 

If there is more information or clarification, please let me know.

 

Cheers,


Mike
 

On 5/23/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com> wrote:

I have re-opened issue 43, but it would be useful if you could provide a
high level example (outline) of what you would like to see.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems



> -----Original Message-----
> From: Saravanan Govindan [mailto: Saravanan.Govindan@sg.panasonic.com ]
> Sent: Tuesday, May 23, 2006 12:24 AM
> To: capwap
> Subject: [Capwap] Clarification of Issue 43: IEEE 802.11i
> Considerations
>
> All,
>
> I believe this issue 43 - also a Mandatory Objective - is
> still open. My suggestion is to update the 802.11 binding
> section to reflect steps local-MAC and split-MAC cases.
>
> Saravanan
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

 



------=_Part_801_24704205.1149361384871-- --===============0146925269== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0146925269==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jun 03 15:12:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmbYR-0000Xc-A7 for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 15:12:59 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmbYP-0000pG-Pt for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 15:12:59 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6AB9D430133 for ; Sat, 3 Jun 2006 12:12:57 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8B394430092 for ; Sat, 3 Jun 2006 12:12:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 79A7D43175A for ; Sat, 3 Jun 2006 12:12:27 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by hermes.tigertech.net (Postfix) with ESMTP id 6F143431751 for ; Sat, 3 Jun 2006 12:12:22 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id c39so814231pyd for ; Sat, 03 Jun 2006 12:12:22 -0700 (PDT) Received: by 10.35.21.1 with SMTP id y1mr4099697pyi; Sat, 03 Jun 2006 12:12:22 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Sat, 3 Jun 2006 12:12:22 -0700 (PDT) Message-ID: <26140d940606031212i353717e3p5be4d3a2f35e5ffc@mail.gmail.com> Date: Sat, 3 Jun 2006 15:12:22 -0400 From: "Michael Montemurro" To: "David T. Perkins" In-Reply-To: <26140d940606031043u9d9ec2cy614ae15cd81bb029@mail.gmail.com> MIME-Version: 1.0 References: <26140d940606031043u9d9ec2cy614ae15cd81bb029@mail.gmail.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0135495388==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --===============0135495388== Content-Type: multipart/alternative; boundary="----=_Part_861_619913.1149361942235" ------=_Part_861_619913.1149361942235 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline David, Would it be sufficient to move Encryption Capabilities from the WTP Descriptor (Section 4.4.34) to the WTP Radio Information message element (Section 4.4.39)? Mike On 6/3/06, Michael Montemurro wrote: > > David, > > I've created issue 125 to track this issue. > > Mike > > > On 6/1/06, David T. Perkins wrote: > > > > HI, > > > > The "(4.4.34)WTP Descriptor" message element has the > > subfield "encryption capabilities". What is this used > > for? If for radios, then it should be per radio. If > > for the user data between the WTP and AC, then > > it doesn't seem appropriate to say the value is > > defined by "specific binding" definitions because > > the WTP can be supporting multiple radios with > > some that provide encryption services and some > > that don't. > > > > In general, I don't feel that this subfield is > > well defined, and it appears to me that it > > should be a per radio attribute. > > > > Regards, > > /david t. perkins > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > ------=_Part_861_619913.1149361942235 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
David,
 
Would it be sufficient to move Encryption Capabilities from the WTP Descriptor (Section 4.4.34) to the WTP Radio Information message element (Section 4.4.39)?
 
Mike

 
On 6/3/06, Michael Montemurro <montemurro.michael@gmail.com> wrote:
David,

I've created issue 125 to track this issue.
 
Mike

 
On 6/1/06, David T. Perkins <dperkins@dsperkins.com > wrote:
HI,

The "(4.4.34)WTP Descriptor" message element has the
subfield "encryption capabilities". What is this used
for? If for radios, then it should be per radio. If
for the user data between the WTP and AC, then
it doesn't seem appropriate to say the value is
defined by "specific binding" definitions because
the WTP can be supporting multiple radios with
some that provide encryption services and some
that don't.

In general, I don't feel that this subfield is
well defined, and it appears to me that it
should be a per radio attribute.

Regards,
/david t. perkins

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


------=_Part_861_619913.1149361942235-- --===============0135495388== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0135495388==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jun 03 15:39:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmbxt-0007hr-47 for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 15:39:17 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fmbxr-0004qQ-NV for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 15:39:17 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B01B1430168 for ; Sat, 3 Jun 2006 12:39:14 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 65C504300CD for ; Sat, 3 Jun 2006 12:38:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2CBB54317A9 for ; Sat, 3 Jun 2006 12:38:47 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by hermes.tigertech.net (Postfix) with ESMTP id 7361F4317A0 for ; Sat, 3 Jun 2006 12:38:43 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id c39so817105pyd for ; Sat, 03 Jun 2006 12:38:42 -0700 (PDT) Received: by 10.35.31.14 with SMTP id i14mr4019947pyj; Sat, 03 Jun 2006 12:38:41 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Sat, 3 Jun 2006 12:38:41 -0700 (PDT) Message-ID: <26140d940606031238l1bf38098ud8b7fcb2abc67499@mail.gmail.com> Date: Sat, 3 Jun 2006 15:38:41 -0400 From: "Michael Montemurro" To: capwap MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.3 tagged_above=-999.0 required=7.0 tests=HTML_10_20, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Proposed resolution for issue 100. Treatment of wireless management frames. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1478309636==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca --===============1478309636== Content-Type: multipart/alternative; boundary="----=_Part_1049_5677488.1149363521220" ------=_Part_1049_5677488.1149363521220 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Here is my proposed resolution to issue 100: - Fix the default priority settings in section 11.6 to the values used in section 4.3.3. - Change the last paragraph in section 4.3 to state that radio technology specific management frames are treated as CAPWAP control messages. It makes sense because control frames are protected. Does this make sense? Cheers, Mike ------=_Part_1049_5677488.1149363521220 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Here is my proposed resolution to issue 100:

- Fix the default priority settings in section 11.6 to the values used in section 4.3.3.

- Change the last paragraph in section 4.3 to state that radio technology specific management frames are treated as CAPWAP control messages. It makes sense because control frames are protected.

Does this make sense?

Cheers,

Mike

 

------=_Part_1049_5677488.1149363521220-- --===============1478309636== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1478309636==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jun 03 15:44:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmc2x-0000vS-Vk for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 15:44:31 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fmc2w-0005UU-C4 for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 15:44:31 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0A32143015C for ; Sat, 3 Jun 2006 12:44:30 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 02E764300CD for ; Sat, 3 Jun 2006 12:44:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E71B0398017 for ; Sat, 3 Jun 2006 12:44:06 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2BC34398007 for ; Sat, 3 Jun 2006 12:44:03 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 03 Jun 2006 12:44:03 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k53Ji3vj009128; Sat, 3 Jun 2006 12:44:03 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k53Ji3KP004005; Sat, 3 Jun 2006 12:44:03 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 3 Jun 2006 12:44:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 3 Jun 2006 12:44:02 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201FC0264@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Terminology section Thread-Index: AcZ/rPwCFF7q1gKBR1CeeP5wj7xbTAHmQ8/g From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" , "Saravanan Govindan" X-OriginalArrivalTime: 03 Jun 2006 19:44:03.0373 (UTC) FILETIME=[11436DD0:01C68746] Authentication-Results: sj-dkim-3.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Terminology section X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Based on this thread, I have created issue 130. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Wednesday, May 24, 2006 8:40 PM > To: Saravanan Govindan > Cc: Pat Calhoun (pacalhou); capwap > Subject: Re: [Capwap] Terminology section > > HI, > > I believe that it is inappropriate to make reference to > RFC4118 or objectives I-D in the CAPWAP document. If there > are needed text, it should be cut and pasted into the CAPWAP > document. This is because the CAPWAP document should be > independent from this documents. > > Regards, > /david t. perkins > > On Thu, 25 May 2006, Saravanan Govindan wrote: > > Here are additional terms that I think can be included a new > > Terminology section. The latter 2 are from Section 13.1 > "CAPWAP Security". > > > > > > [Proposed text] > > > > 1.5. Terminology > > > > This document follows the terminologies of [RFC4118] and > [OBJECTIVES]. > > Additionally, the following terms are defined; > > > > WLAN: A WLAN represents a Logical Group as defined in [OBJECTIVES]. > > > > Protected Data: Refers to CAPWAP messages exchanged between > > authenticated peers with encryption. > > > > Unprotected Data: Refers to CAPWAP messages exchanged between > > authenticated peers without encryption. > > > > [End of proposed text] > > > > > > Saravanan > > > > > > > > > > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Wednesday, May 24, 2006 10:15 PM > > To: Saravanan Govindan > > Subject: RE: [Capwap] Terminology section > > > > Then how about you send me a final set of proposed > terminologies once > > you are done, then I will create the issue. > > > > Sound fair? > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Saravanan Govindan > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > Sent: Tuesday, May 23, 2006 6:28 PM > > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > > Subject: RE: [Capwap] Terminology section > > > > > > Pat, > > > > > > I think more text may be required for other definitions. > I am still > > > in reading the draft for any new terms we are using. > > > > > > Saravanan > > > > > > > > > > > > > > > -----Original Message----- > > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > > Sent: Wednesday, May 24, 2006 1:10 AM > > > To: Saravanan Govindan; capwap@frascone.com > > > Subject: RE: [Capwap] Terminology section > > > > > > Saravanan, I wasn't sure if the text below was complete, > or whether > > > --XX-- implied "more text here". > > > > > > Could you help clarify, after which I will create an > issue to track > > > this change request. > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > -----Original Message----- > > > > From: Saravanan Govindan > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > > Sent: Tuesday, May 23, 2006 12:08 AM > > > > To: capwap@frascone.com > > > > Subject: [Capwap] Terminology section > > > > > > > > All, > > > > > > > > Following from an earlier note, this is the proposed section on > > > > terminologies used in the CAPWAP Specifications. > > > > > > > > Comments appreciated. > > > > > > > > [Insert new subsection in Section 1 "Introduction"] > > > > > > > > 1.5. Terminology > > > > > > > > This document follows the terminologies of [RFC4118] and > > > [OBJECTIVES]. > > > > Additionally, the following terms are defined; > > > > > > > > WLAN: A WLAN represents a Logical Group as defined in > [OBJECTIVES]. > > > > > > > > --XX-- > > > > > > > > > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > To unsubscribe or modify your subscription options, > please visit: > > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jun 03 15:47:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmc5c-0001n7-C0 for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 15:47:16 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fmc5Z-0005jW-LT for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 15:47:16 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 502E6430158 for ; Sat, 3 Jun 2006 12:47:13 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6EFA44300CD for ; Sat, 3 Jun 2006 12:46:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6390E398017 for ; Sat, 3 Jun 2006 12:46:45 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7BB57398013 for ; Sat, 3 Jun 2006 12:46:42 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 03 Jun 2006 12:46:42 -0700 X-IronPort-AV: i="4.05,206,1146466800"; d="scan'208"; a="288364524:sNHT36285104" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k53JkfVf009052; Sat, 3 Jun 2006 12:46:41 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k53JkfCU028458; Sat, 3 Jun 2006 12:46:41 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 3 Jun 2006 12:46:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 3 Jun 2006 12:46:40 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201FC0265@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Selecting image for downloading to WTP Thread-Index: AcaEeoXAM5pTNHMBQpmC/0XxEsZOWACy9gSQ From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" , "qinxia" X-OriginalArrivalTime: 03 Jun 2006 19:46:41.0297 (UTC) FILETIME=[6F64B810:01C68746] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap , Basker Ms Subject: Re: [Capwap] Selecting image for downloading to WTP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Dave, issue 131 has been created based on this thread (and your input). However, you state you are working on a new document - are you expecting a separate CAPWAP booting specification? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Tuesday, May 30, 2006 11:21 PM > To: qinxia > Cc: 'capwap'; 'Basker Ms' > Subject: Re: [Capwap] Selecting image for downloading to WTP > > HI, > > I don't quite follow your contribution. > In simple terms, here is how I see the booting model, which > is not the same as the CAPWAP-01 spec > > 1) A WTP creates a list of potential ACs to connect to > 2) The WTP asks the ACs if it can connect > 3) An AC may respond saying: > a) no > b) Ok if no other AC wants you and here is my > preference to compare with other ACs > c) no, but you should ask the following ACs > d) yes, I'm the AC configured to manage you > 4) The WTP creates a DTLS session with the best AC > (There is a whole lot of details about this > to work out with respect to verifying CERTs, > CA CERTs, and preshared keys) > 5) After the DTLS session is up, the WTP and > AC can thus communicate privately, and determine > if messages have been modified, delayed, and > are from each other > 6) The WTP tells the AC it's device type and > hardware configuration. It also tells the > AC what version of software it is running, > and if it has other software images (and > their versions), and whether or not it > can transfer and run a new image via CAPWAP. > 7) The AC uses the info in #6 and a table that > the AC maintains to decide whether to: > a) continue with the current image > b) ask the WTP to load another image > (which might result in a reboot > of the WTP) > c) ask the WTP to transfer a new image > from the AC and run it (which might > result in a reboot of the WTP > or CAPWAP portion of the WTP) > d) tell the WTP it cannot support it, > and to try the next best AC > (that is have the WTP goto step #4) > 8) If the WTP has to reboot for #7, then > it starts over at step #1 with a single > member in the list of ACs > 9) Otherwise, the AC determines the current > configuration saved on the WTP, and > modifies it (if needed) to have the > configuration desired by the AC at > the WTP > 10) The configuration phase is finished, and > the AC tells the WTP to begin operation. > > NOTE: the significant differences from the boot model and the > boot model (as far as I can determine) in the CAPWAP-01 document are: > 1) The AC's response to WTP's inquiry to be > able to connect. > 2) What information is provided to the AC > by the WTP before a DTLS session is established. > 3) What information is provided to WTPs by ACs > 4) What information is used by an WTP to decide > which AC to connect to > 5) How it is determined what image a WTP is > to run > 6) How initial configuration of the WTP is > done before the WTP starts operation > > I hope that the above set of steps and list of differences > provides you with enough details so that you understand what > I believe is the needed boot model for CAPWAP. > > Just one more detail... > The "table that the AC must maintain" maps WTP hardware to > desired image for the WTP. > The table is not part of the CAPWAP standard, and can be > implemented in any way that the AC vendor chooses. However, > if I were to implement it, the table would support both > classes of devices, such as "vendor X, model Y", and specific > devices, such as "device with ID=zz:zz:zz:zz:zz:zz", and have > a prioritized list of image IDs, and action to take if the > image was not on the WTP. Also, there must be a rule that > specifies what to do if the WTP is not in the table. The > table is really a list of rules for a simple image management system! > A table as described above would allow > 1) an AC to support a WTP from any number > of WTP vendors. > 2) there would be no relationship on the > image identification and versioning > scheme between the WTP and AC, (or > between WTPs) > 3) ideally, the table could be updated in > the field as just another part of > AC configuration. > 4) ideally, new images could be made > available for the AC to transfer to > WTPs as updated configuration for > the AC without requiring new AC > system software > 5) An AC could support different WTPs > (which are the same hardware) running > different versions of sofware (to support > a trial version, or a phased upgrade) > > Note that "the table" could be a single > rule that supports what ever software version that that WTP > is running. Or it could be a single rule that supported only > a single software version for each known WTP hardware type. > > Hope this helps. If not, send email. > Please send me any scenarios that I didn't cover that should be. > I'm working on a real document with > CAPWAP message types and elements. > > On Wed, 31 May 2006, qinxia wrote: > > My comment is inserted in the email, as the following: > > > > > -----Original Message----- > > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > > Sent: Sunday, May 28, 2006 3:30 AM > > > To: Basker Ms > > > Cc: 'capwap' > > > Subject: Re: [Capwap] Selecting image for downloading to WTP > > > > > > HI, > > > > > > Yes, the booting process as currently specified is > seriously broken! > > > > > > Regards, > > > /david t. perkins > > > > > > On Sat, 27 May 2006, Basker Ms wrote: > > > > All, > > > > > > > > According to capwap spec-01, during the discovery phase: > > > > > > > > * WTP will send *its* h/w and s/w version (Section 4.4.34). > > > > * AC will respond with *its* h/w and s/w version (4.4.1) > > > > > > > > WTP enters Image Data state when it determines that its > > > version number > > > > and the version number advertised by the AC are different. > > > > > > > > Suppose, if the AC is connected with many WTPs from > > > different vendors, > > > > how the AC picks the correct image for downloading? > > > > ==> In SNMP, OID indicate the vendor, WTP may send its > OID, then , > > AC will respond with the corresponding version. > > > > > > > > > > > > Or is it that AC will always send the same image to all the > > > WTP(s) in > > > > case of version mismatch? > > > > > > > > Regards, > > > > Basker Swaminathan > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jun 03 15:49:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmc7Y-00040m-Ro for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 15:49:16 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fmc7X-0005mD-E6 for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 15:49:16 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 19CA343015C for ; Sat, 3 Jun 2006 12:49:15 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id AF3564300E3 for ; Sat, 3 Jun 2006 12:48:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8CF8F4317BF for ; Sat, 3 Jun 2006 12:48:48 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id E9EA5431335 for ; Sat, 3 Jun 2006 12:48:45 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 03 Jun 2006 12:48:46 -0700 X-IronPort-AV: i="4.05,206,1146466800"; d="scan'208"; a="1818722967:sNHT31695804" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k53JmjD5009500; Sat, 3 Jun 2006 12:48:45 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k53Jmj9s003977; Sat, 3 Jun 2006 12:48:45 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 3 Jun 2006 12:48:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 3 Jun 2006 12:48:44 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201FC0266@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of protocol goals Thread-Index: AcZ/l7/vR1jdAqKyTDC/ZVAyrz3e/wHrvGhA From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , "capwap" X-OriginalArrivalTime: 03 Jun 2006 19:48:44.0998 (UTC) FILETIME=[B91FFE60:01C68746] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Clarification of protocol goals X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 I created issue 132 to track this change request. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Wednesday, May 24, 2006 6:01 PM > To: capwap > Subject: [Capwap] Clarification of protocol goals > > All, > > One of the goals stated in Section 1.1 "Goals" is; > > "1. To centralize the bridging, forwarding, authentication > and policy ...." > > Centralized bridging seems to be applicable to Split MAC > alone. In the case of CAPWAP being used to manage Local MAC > WTPs, bridging is not centralized. > > I suggest an update to this goal; > > "1. To centralize major functions of a wireless network, such > as configuration, authentication, policy enforcement and in > some cases, bridging and forwarding. " > > Comments? > > Saravanan > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jun 03 15:57:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmcFW-00023V-Rj for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 15:57:30 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmcFV-0007cR-F6 for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 15:57:30 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2074B430158 for ; Sat, 3 Jun 2006 12:57:29 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9572C4300D9 for ; Sat, 3 Jun 2006 12:57:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7C1CC4317C9 for ; Sat, 3 Jun 2006 12:57:04 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by hermes.tigertech.net (Postfix) with ESMTP id CD4CC4317D3 for ; Sat, 3 Jun 2006 12:57:02 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id c39so818986pyd for ; Sat, 03 Jun 2006 12:57:02 -0700 (PDT) Received: by 10.35.49.4 with SMTP id b4mr3990156pyk; Sat, 03 Jun 2006 12:57:02 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Sat, 3 Jun 2006 12:57:02 -0700 (PDT) Message-ID: <26140d940606031257l43fa8a69o23f1d334d07841b6@mail.gmail.com> Date: Sat, 3 Jun 2006 15:57:02 -0400 From: "Michael Montemurro" To: capwap MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Issue 80: Recommend "change MAC address to IP adress in section 10.3" X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2121906665==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa --===============2121906665== Content-Type: multipart/alternative; boundary="----=_Part_1277_9767237.1149364622009" ------=_Part_1277_9767237.1149364622009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I read through the appropriate sections in draft-01. And as far as I could figure, this shouldn't be an issue. Where does text need to be changed in this case? The AC needs to have knowledge of the BSSID in order to manage the WLAN BSS. Cheers, Mike ------=_Part_1277_9767237.1149364622009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I read through the appropriate sections in draft-01. And as far as I could figure, this shouldn't be an issue.
 
Where does text need to be changed in this case? The AC needs to have
knowledge of the BSSID in order to manage the WLAN BSS.
 
Cheers,
 
Mike
------=_Part_1277_9767237.1149364622009-- --===============2121906665== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============2121906665==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jun 03 16:01:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmcIz-0008PR-46 for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 16:01:05 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmcIw-0007s8-JZ for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 16:01:05 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 41C09430159 for ; Sat, 3 Jun 2006 13:01:02 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D7B644300E3 for ; Sat, 3 Jun 2006 13:00:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C243A4317D7 for ; Sat, 3 Jun 2006 13:00:24 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by hermes.tigertech.net (Postfix) with ESMTP id 513FF4317D8 for ; Sat, 3 Jun 2006 13:00:19 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id c39so819302pyd for ; Sat, 03 Jun 2006 13:00:19 -0700 (PDT) Received: by 10.35.9.2 with SMTP id m2mr4030581pyi; Sat, 03 Jun 2006 13:00:19 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Sat, 3 Jun 2006 13:00:19 -0700 (PDT) Message-ID: <26140d940606031300q37a8f93ex328113e5cf75a86f@mail.gmail.com> Date: Sat, 3 Jun 2006 16:00:19 -0400 From: "Michael Montemurro" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201FC0266@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A201FC0266@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: Saravanan Govindan , capwap Subject: Re: [Capwap] Clarification of protocol goals X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0498196056==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --===============0498196056== Content-Type: multipart/alternative; boundary="----=_Part_1317_8755522.1149364819198" ------=_Part_1317_8755522.1149364819198 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I don't have a problem with Saravanan's proposed change. Mike On 6/3/06, Pat Calhoun (pacalhou) wrote: > > I created issue 132 to track this change request. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > > Sent: Wednesday, May 24, 2006 6:01 PM > > To: capwap > > Subject: [Capwap] Clarification of protocol goals > > > > All, > > > > One of the goals stated in Section 1.1 "Goals" is; > > > > "1. To centralize the bridging, forwarding, authentication > > and policy ...." > > > > Centralized bridging seems to be applicable to Split MAC > > alone. In the case of CAPWAP being used to manage Local MAC > > WTPs, bridging is not centralized. > > > > I suggest an update to this goal; > > > > "1. To centralize major functions of a wireless network, such > > as configuration, authentication, policy enforcement and in > > some cases, bridging and forwarding. " > > > > Comments? > > > > Saravanan > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_1317_8755522.1149364819198 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I don't have a problem with Saravanan's proposed change.
 
Mike

 
On 6/3/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
I created issue 132 to track this change request.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems



> -----Original Message-----
> From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]
> Sent: Wednesday, May 24, 2006 6:01 PM
> To: capwap
> Subject: [Capwap] Clarification of protocol goals
>
> All,
>
> One of the goals stated in Section 1.1 "Goals" is;
>
> "1. To centralize the bridging, forwarding, authentication
> and policy ...."
>
> Centralized bridging seems to be applicable to Split MAC
> alone. In the case of CAPWAP being used to manage Local MAC
> WTPs, bridging is not centralized.
>
> I suggest an update to this goal;
>
> "1. To centralize major functions of a wireless network, such
> as configuration, authentication, policy enforcement and in
> some cases, bridging and forwarding. "
>
> Comments?
>
> Saravanan
>
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_1317_8755522.1149364819198-- --===============0498196056== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0498196056==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jun 03 16:09:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmcQx-0008Uk-Sy for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 16:09:19 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmcQw-000810-AE for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 16:09:19 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B0322430113 for ; Sat, 3 Jun 2006 13:09:17 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id EED814300E3 for ; Sat, 3 Jun 2006 13:08:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D9DE0144800E for ; Sat, 3 Jun 2006 13:08:45 -0700 (PDT) X-Greylist-Status: Sender first seen 2 mons 12 days 02:34:44 ago Received: from sinett.com (63-197-255-151.ded.pacbell.net [63.197.255.151]) by hermes.tigertech.net (Postfix) with ESMTP id 2E304144800C for ; Sat, 3 Jun 2006 13:08:42 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 3 Jun 2006 13:08:42 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed resolution for issue 100. Treatment of wirelessmanagement frames. Thread-Index: AcaHRVxunovNxSzURfyaZXEX8VG2BgAAvYng From: "Abhijit Choudhury" To: "Michael Montemurro" , "capwap" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO, HTML_MESSAGE X-Spam-Level: Subject: Re: [Capwap] Proposed resolution for issue 100. Treatment of wirelessmanagement frames. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0135654734==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 This is a multi-part message in MIME format. --===============0135654734== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68749.82CDF473" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68749.82CDF473 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mike, I'm not sure this make sense. =20 The CAPWAP control channel is for "control and provisioning" messages between the AC and the WTP. Per-client information arriving at the WTP should be sent in the data channel as it is all data to the AC, and has nothing to do with "control and provisioning" of the WTP. =20 =20 There could be radio technology specific information=20 (e.g. RSSI/SNR) that are collected on a per-client=20 basis at the AC, and separating out some of the=20 messages into a separate channel will lead to either erroneous accounting or more complicated logic that=20 looks at both channels on a packet-by-packet basis.=20 All packets sent by a client should come up the same channel (the data channel). =20 As for security for management frames, 802.11w should take care of that. =20 Thanks, Abhijit -----Original Message----- From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Saturday, June 03, 2006 12:39 PM To: capwap Subject: [Capwap] Proposed resolution for issue 100. Treatment of wirelessmanagement frames. =09 =09 Here is my proposed resolution to issue 100: - Fix the default priority settings in section 11.6 to the values used in section 4.3.3. - Change the last paragraph in section 4.3 to state that radio technology specific management frames are treated as CAPWAP control messages. It makes sense because control frames are protected. Does this make sense? Cheers, Mike =20 ------_=_NextPart_001_01C68749.82CDF473 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Mike,
I'm not sure this make sense.
 
The CAPWAP control channel is for "control = and
provisioning" messages between the AC and the = WTP.
Per-client information arriving at the WTP = should
be sent in the data channel as it is all data = to
the AC, and has nothing to do with "control = and
provisioning" of the WTP. 
 
There could be radio technology specific = information
(e.g. RSSI/SNR) that are collected on a = per-client=20
basis at the AC, and separating out some of = the=20
messages into a separate channel will lead = to=20 either
erroneous accounting or more complicated logic = that=20
looks at both channels on a = packet-by-packet basis.=20
All packets sent by a client should come = up
the same channel (the data channel).
 
As for security for management frames, = 802.11w
should take care of that.
 
Thanks,
  =20 Abhijit

-----Original Message-----
From: = Michael=20 Montemurro [mailto:montemurro.michael@gmail.com]
Sent: = Saturday,=20 June 03, 2006 12:39 PM
To: capwap
Subject: = [Capwap]=20 Proposed resolution for issue 100. Treatment of wirelessmanagement=20 frames.

Here is my proposed resolution to issue 100:

- Fix the default priority settings in section 11.6 to the = values used=20 in section 4.3.3.

- Change the last paragraph in section 4.3 to state that radio = technology=20 specific management frames are treated as CAPWAP control messages. It = makes=20 sense because control frames are protected.

Does this make sense?

Cheers,

Mike

 

------_=_NextPart_001_01C68749.82CDF473-- --===============0135654734== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0135654734==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jun 03 18:35:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmeiq-00008I-BE for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 18:35:56 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fmeio-0004ed-JN for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 18:35:56 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A28E543017B for ; Sat, 3 Jun 2006 15:35:53 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 53F554300EE for ; Sat, 3 Jun 2006 15:35:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 42C57398013 for ; Sat, 3 Jun 2006 15:35:26 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A03FD398007 for ; Sat, 3 Jun 2006 15:35:23 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k53MZGMQ001097; Sat, 3 Jun 2006 15:35:16 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k53MZG4J001094; Sat, 3 Jun 2006 15:35:16 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Sat, 3 Jun 2006 15:35:16 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201FC0265@xmb-sjc-235.amer.cisco.com> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: qinxia , capwap , Basker Ms Subject: Re: [Capwap] Selecting image for downloading to WTP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f HI, I'm not at all proposing a separate CAPWAP Boot Model document. I just want to make sure the following is clear: 1) what are the supported WTP hardware capabilities, such as WTPs with no storage for image, WTPs that support a single image, WTPs that support multiple images. Plus WTPs that have limited storage for config, and those that have "essentially unlimited" storage for config. And devices that are single function purpose built WTPs, and devices that support the "WTP function" but also perform other functions. 2) a conplete list of configuration attributes, and specified CAPWAP default values 3) support for interoperation of WTPs and AC from different vendors etc The reason that I'm doing this in "a separate document" is that I find that the CAPWAP document has generic portions that have nothing to do with radios and portions that are very radio specific, and I don't find the portion that is generic that describes how WTPs connect to ACs, manage the images, and set initial configuration to be well specified. That's the first step in my implementation of my CAPWAP prototypes of a WTP and AC. I hope it will be clear when done. I wish there were others that were prototyping. If so, please let me know. Regards, /david t. perkins On Sat, 3 Jun 2006, Pat Calhoun (pacalhou) wrote: > Dave, issue 131 has been created based on this thread (and your input). > > However, you state you are working on a new document - are you expecting > a separate CAPWAP booting specification? > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > Sent: Tuesday, May 30, 2006 11:21 PM > > To: qinxia > > Cc: 'capwap'; 'Basker Ms' > > Subject: Re: [Capwap] Selecting image for downloading to WTP > > > > HI, > > > > I don't quite follow your contribution. > > In simple terms, here is how I see the booting model, which > > is not the same as the CAPWAP-01 spec > > > > 1) A WTP creates a list of potential ACs to connect to > > 2) The WTP asks the ACs if it can connect > > 3) An AC may respond saying: > > a) no > > b) Ok if no other AC wants you and here is my > > preference to compare with other ACs > > c) no, but you should ask the following ACs > > d) yes, I'm the AC configured to manage you > > 4) The WTP creates a DTLS session with the best AC > > (There is a whole lot of details about this > > to work out with respect to verifying CERTs, > > CA CERTs, and preshared keys) > > 5) After the DTLS session is up, the WTP and > > AC can thus communicate privately, and determine > > if messages have been modified, delayed, and > > are from each other > > 6) The WTP tells the AC it's device type and > > hardware configuration. It also tells the > > AC what version of software it is running, > > and if it has other software images (and > > their versions), and whether or not it > > can transfer and run a new image via CAPWAP. > > 7) The AC uses the info in #6 and a table that > > the AC maintains to decide whether to: > > a) continue with the current image > > b) ask the WTP to load another image > > (which might result in a reboot > > of the WTP) > > c) ask the WTP to transfer a new image > > from the AC and run it (which might > > result in a reboot of the WTP > > or CAPWAP portion of the WTP) > > d) tell the WTP it cannot support it, > > and to try the next best AC > > (that is have the WTP goto step #4) > > 8) If the WTP has to reboot for #7, then > > it starts over at step #1 with a single > > member in the list of ACs > > 9) Otherwise, the AC determines the current > > configuration saved on the WTP, and > > modifies it (if needed) to have the > > configuration desired by the AC at > > the WTP > > 10) The configuration phase is finished, and > > the AC tells the WTP to begin operation. > > > > NOTE: the significant differences from the boot model and the > > boot model (as far as I can determine) in the CAPWAP-01 document are: > > 1) The AC's response to WTP's inquiry to be > > able to connect. > > 2) What information is provided to the AC > > by the WTP before a DTLS session is established. > > 3) What information is provided to WTPs by ACs > > 4) What information is used by an WTP to decide > > which AC to connect to > > 5) How it is determined what image a WTP is > > to run > > 6) How initial configuration of the WTP is > > done before the WTP starts operation > > > > I hope that the above set of steps and list of differences > > provides you with enough details so that you understand what > > I believe is the needed boot model for CAPWAP. > > > > Just one more detail... > > The "table that the AC must maintain" maps WTP hardware to > > desired image for the WTP. > > The table is not part of the CAPWAP standard, and can be > > implemented in any way that the AC vendor chooses. However, > > if I were to implement it, the table would support both > > classes of devices, such as "vendor X, model Y", and specific > > devices, such as "device with ID=zz:zz:zz:zz:zz:zz", and have > > a prioritized list of image IDs, and action to take if the > > image was not on the WTP. Also, there must be a rule that > > specifies what to do if the WTP is not in the table. The > > table is really a list of rules for a simple image management system! > > A table as described above would allow > > 1) an AC to support a WTP from any number > > of WTP vendors. > > 2) there would be no relationship on the > > image identification and versioning > > scheme between the WTP and AC, (or > > between WTPs) > > 3) ideally, the table could be updated in > > the field as just another part of > > AC configuration. > > 4) ideally, new images could be made > > available for the AC to transfer to > > WTPs as updated configuration for > > the AC without requiring new AC > > system software > > 5) An AC could support different WTPs > > (which are the same hardware) running > > different versions of sofware (to support > > a trial version, or a phased upgrade) > > > > Note that "the table" could be a single > > rule that supports what ever software version that that WTP > > is running. Or it could be a single rule that supported only > > a single software version for each known WTP hardware type. > > > > Hope this helps. If not, send email. > > Please send me any scenarios that I didn't cover that should be. > > I'm working on a real document with > > CAPWAP message types and elements. > > > > On Wed, 31 May 2006, qinxia wrote: > > > My comment is inserted in the email, as the following: > > > > > > > -----Original Message----- > > > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > > > Sent: Sunday, May 28, 2006 3:30 AM > > > > To: Basker Ms > > > > Cc: 'capwap' > > > > Subject: Re: [Capwap] Selecting image for downloading to WTP > > > > > > > > HI, > > > > > > > > Yes, the booting process as currently specified is > > seriously broken! > > > > > > > > Regards, > > > > /david t. perkins > > > > > > > > On Sat, 27 May 2006, Basker Ms wrote: > > > > > All, > > > > > > > > > > According to capwap spec-01, during the discovery phase: > > > > > > > > > > * WTP will send *its* h/w and s/w version (Section 4.4.34). > > > > > * AC will respond with *its* h/w and s/w version (4.4.1) > > > > > > > > > > WTP enters Image Data state when it determines that its > > > > version number > > > > > and the version number advertised by the AC are different. > > > > > > > > > > Suppose, if the AC is connected with many WTPs from > > > > different vendors, > > > > > how the AC picks the correct image for downloading? > > > > > > ==> In SNMP, OID indicate the vendor, WTP may send its > > OID, then , > > > AC will respond with the corresponding version. > > > > > > > > > > > > > > > > Or is it that AC will always send the same image to all the > > > > WTP(s) in > > > > > case of version mismatch? > > > > > > > > > > Regards, > > > > > Basker Swaminathan > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jun 03 18:51:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmexb-00062g-Ek for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 18:51:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmexZ-0006Ym-RF for capwap-archive@lists.ietf.org; Sat, 03 Jun 2006 18:51:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 796AE43019B for ; Sat, 3 Jun 2006 15:51:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id EA4E34300EE for ; Sat, 3 Jun 2006 15:50:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BCC724317FF for ; Sat, 3 Jun 2006 15:50:40 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by hermes.tigertech.net (Postfix) with ESMTP id 795654317FC for ; Sat, 3 Jun 2006 15:50:38 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id c39so836206pyd for ; Sat, 03 Jun 2006 15:50:37 -0700 (PDT) Received: by 10.35.66.12 with SMTP id t12mr4182175pyk; Sat, 03 Jun 2006 15:50:37 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Sat, 3 Jun 2006 15:50:37 -0700 (PDT) Message-ID: <26140d940606031550h249b9a0dqb8669a6632714dda@mail.gmail.com> Date: Sat, 3 Jun 2006 18:50:37 -0400 From: "Michael Montemurro" To: "Abhijit Choudhury" In-Reply-To: MIME-Version: 1.0 References: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_60_70, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Proposed resolution for issue 100. Treatment of wirelessmanagement frames. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0309572849==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c --===============0309572849== Content-Type: multipart/alternative; boundary="----=_Part_2742_3988546.1149375037104" ------=_Part_2742_3988546.1149375037104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Is there consensus that radio techology specific management frames should be carried as CAPWAP data frames? Thanks, Mike On 6/3/06, Abhijit Choudhury wrote: > > Mike, > I'm not sure this make sense. > > The CAPWAP control channel is for "control and > provisioning" messages between the AC and the WTP. > Per-client information arriving at the WTP should > be sent in the data channel as it is all data to > the AC, and has nothing to do with "control and > provisioning" of the WTP. > > There could be radio technology specific information > (e.g. RSSI/SNR) that are collected on a per-client > basis at the AC, and separating out some of the > messages into a separate channel will lead to either > erroneous accounting or more complicated logic that > looks at both channels on a packet-by-packet basis. > All packets sent by a client should come up > the same channel (the data channel). > > As for security for management frames, 802.11w > should take care of that. > > Thanks, > Abhijit > > -----Original Message----- > *From:* Michael Montemurro [mailto:montemurro.michael@gmail.com] > *Sent:* Saturday, June 03, 2006 12:39 PM > *To:* capwap > *Subject:* [Capwap] Proposed resolution for issue 100. Treatment of > wirelessmanagement frames. > > Here is my proposed resolution to issue 100: > > - Fix the default priority settings in section 11.6 to the values used in > section 4.3.3. > > - Change the last paragraph in section 4.3 to state that radio technology > specific management frames are treated as CAPWAP control messages. It makes > sense because control frames are protected. > > Does this make sense? > > Cheers, > > Mike > > > > ------=_Part_2742_3988546.1149375037104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Is there consensus that radio techology specific management frames should be carried as CAPWAP data frames?
 
Thanks,
 
Mike

 
On 6/3/06, Abhijit Choudhury <Abhijit@sinett.com> wrote:
Mike,
I'm not sure this make sense.
 
The CAPWAP control channel is for "control and
provisioning" messages between the AC and the WTP.
Per-client information arriving at the WTP should
be sent in the data channel as it is all data to
the AC, and has nothing to do with "control and
provisioning" of the WTP. 
 
There could be radio technology specific information
(e.g. RSSI/SNR) that are collected on a per-client
basis at the AC, and separating out some of the
messages into a separate channel will lead to either
erroneous accounting or more complicated logic that
looks at both channels on a packet-by-packet basis.
All packets sent by a client should come up
the same channel (the data channel).
 
As for security for management frames, 802.11w
should take care of that.
 
Thanks,
   Abhijit

-----Original Message-----
From: Michael Montemurro [mailto: montemurro.michael@gmail.com]
Sent: Saturday, June 03, 2006 12:39 PM
To: capwap
Subject: [Capwap] Proposed resolution for issue 100. Treatment of wirelessmanagement frames.
Here is my proposed resolution to issue 100:

- Fix the default priority settings in section 11.6 to the values used in section 4.3.3.

- Change the last paragraph in section 4.3 to state that radio technology specific management frames are treated as CAPWAP control messages. It makes sense because control frames are protected.

Does this make sense?

Cheers,

Mike

 


------=_Part_2742_3988546.1149375037104-- --===============0309572849== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0309572849==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Jun 04 13:41:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmwbK-00061G-KL for capwap-archive@lists.ietf.org; Sun, 04 Jun 2006 13:41:22 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmwbI-0003OA-NI for capwap-archive@lists.ietf.org; Sun, 04 Jun 2006 13:41:22 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 546F94300F5 for ; Sun, 4 Jun 2006 10:41:19 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B70B2430018 for ; Sun, 4 Jun 2006 10:40:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9204C39803A for ; Sun, 4 Jun 2006 10:40:53 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id A1E1B398035 for ; Sun, 4 Jun 2006 10:40:51 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 04 Jun 2006 10:40:51 -0700 X-IronPort-AV: i="4.05,207,1146466800"; d="scan'208"; a="288517049:sNHT76152032" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k54HeoPV022081 for ; Sun, 4 Jun 2006 10:40:50 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k54HenCU006944 for ; Sun, 4 Jun 2006 10:40:49 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 4 Jun 2006 10:40:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 4 Jun 2006 10:40:48 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC0197C23F@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Use of SESSION ID Thread-Index: AcaFzY0fAMyAZa0BSjyaecQiqKxhrAApmuxgAACuhhAACyo1kABWhEbw From: "Bob O'Hara (boohara)" To: X-OriginalArrivalTime: 04 Jun 2006 17:40:49.0644 (UTC) FILETIME=[04ABAAC0:01C687FE] Authentication-Results: sj-dkim-4.cisco.com; header.From=boohara@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Use of SESSION ID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Abhijit, I apologize if my original reply seemed to dismiss all of your proposals. I was addressing only the first proposal that was to replace the "shim" header with a CAPWAP header and still run over a single UDP port. I believe that your second proposal is worth further discussion, as it does seem to address the issue of existing switches and routers being able to classify CAPWAP data and control traffic separately. It does leave us with the difficulties you describe below. -Bob -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com] Sent: Friday, June 02, 2006 5:31 PM To: Bob O'Hara (boohara); capwap@frascone.com Subject: RE: [Capwap] Use of SESSION ID Bob, I have already addressed your concern in one of the proposals in my earlier email. If you look at point (2) below, separate UDP ports are used for control and data. However, we still need to solve the following two problems: 1. NAT traversal: That's where the SessionId in the CAPWAP header can help. It can bind the control and data channels together even if there is a NAT box in between the WTP and AC. 2. DTLS: For (1) to work, the SessionId needs to be outside the DTLS payload. That's why the the CAPWAP header carrying the sessionID needs to be outside the DTLS payload. The result is an architecture that uses two separate UDP ports for control and data and can support both NAT traversal as well as optional DTLS on the data path. The packet format would be: IP/UDP/CAPWAP/DTLS/payload Thanks, Abhijit -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] Sent: Friday, June 02, 2006 12:02 PM To: capwap@frascone.com Subject: Re: [Capwap] Use of SESSION ID Abhijit, The use of the CAPWAP header to distinguish between control and data suffers from all the same problems that using a custom shim for that purpose, i.e., there is not a router or switch in the world that understands either one. -Bob -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com] Sent: Friday, June 02, 2006 11:48 AM To: Scott G. Kelly; David T. Perkins; capwap@frascone.com; Pat Calhoun (pacalhou) Subject: Re: [Capwap] Use of SESSION ID Interesting.... If we are carrying a SessionId in the CAPWAP header, it opens up lots of possibilities. Here're some thoughts: 1. Currently, as proposed below, the SessionID is in the CAPWAP header and that is inside the DTLS payload. I'm not sure why the format cannot be IP/UDP/CAPWAP/DTLS/payload instead of IP/UDP/Shim/DTLS/CAPWAP/payload There is nothing really confidential in the CAPWAP header, and so there is no reason it cannot be outside the DTLS. If it is outside, it could very well indicate the Data/Control information, as well as the SessionId. 2. If the session ID is available outside the DTLS payload it's possible to support 2 separate UDP ports for control and data. The SessionId can be used to bind them even if there are NAT boxes the path. 3. Even if you don't agree to (1), we can put the sessionId in the Shim and be able to support 2 separate UDP ports based on (2). 4. We need some indication in the header itself to show if the Data payload is DTLS encrypted. There could very well be some data sessions that have DTLS encryption and some that don't. Thanks, Abhijit -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: Thursday, June 01, 2006 3:49 PM To: David T. Perkins; capwap@frascone.com Subject: Re: [Capwap] Use of SESSION ID Hi David, Good catch - I think that got lost in the shuffle of the various header changes. The session ID is required for capwap processing, and is independent of the DTLS session (and you need it for the data channel, too). I think it needs to be included in the generic capwap header. That is currently defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| RID | HLEN |F|L|W|M| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment ID | Frag Offset |Rsv-2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Radio MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Wireless Specific Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ But it should probably be like this, instead: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| RID | HLEN |F|L|W|M| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment ID | Frag Offset |Rsv-2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Radio MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Wireless Specific Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --Scott -----Original Message----- >From: "David T. Perkins" >Sent: Jun 1, 2006 3:22 PM >To: capwap@frascone.com >Subject: [Capwap] Use of SESSION ID > >HI, > >The join request operation contains the "Session ID" information >element. Where is this used after the join? Is it somehow related to >the DTLS session ID? > >Regards, >/david t. perkins > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/capwap > >Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Jun 04 13:45:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmwff-0000JO-3l for capwap-archive@lists.ietf.org; Sun, 04 Jun 2006 13:45:51 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fmwfc-0003T3-OS for capwap-archive@lists.ietf.org; Sun, 04 Jun 2006 13:45:51 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 04F254300E8 for ; Sun, 4 Jun 2006 10:45:48 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id F2F10430018 for ; Sun, 4 Jun 2006 10:45:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CDE5C430F48 for ; Sun, 4 Jun 2006 10:45:02 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id 6669D430F64 for ; Sun, 4 Jun 2006 10:45:00 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 04 Jun 2006 10:44:59 -0700 X-IronPort-AV: i="4.05,207,1146466800"; d="scan'208,217"; a="1818940517:sNHT82425456" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k54HiwN3001569 for ; Sun, 4 Jun 2006 10:44:58 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k54HiwKP028682 for ; Sun, 4 Jun 2006 10:44:58 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 4 Jun 2006 10:44:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 4 Jun 2006 10:44:57 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC0197C240@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Thread-Index: AcaHOE7KPjw/wDs7RWKbHE/tB6T5mwAxdlnw From: "Bob O'Hara (boohara)" To: "capwap" X-OriginalArrivalTime: 04 Jun 2006 17:44:58.0567 (UTC) FILETIME=[990A4D70:01C687FE] Authentication-Results: sj-dkim-2.cisco.com; header.From=boohara@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0140055762==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 27f32072baa9c4fb41949212e86ea6d2 This is a multi-part message in MIME format. --===============0140055762== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C687FE.98EFE138" This is a multi-part message in MIME format. ------_=_NextPart_001_01C687FE.98EFE138 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mike,=20 =20 I assume you mean the approved 802.11i-2004 amendment, not the latest draft. If anyone needs a copy of this document, it is available for free download (registration required) from the following URL: =20 http://standards.ieee.org/getieee802 =20 -Bob =20 =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Saturday, June 03, 2006 11:05 AM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan,=20 =20 I took a look again at the latest draft for IEEE 802.11i, and as I understand it, the GTK 1 message needs the sequence number of the last transmitted broadcast frame. =20 In the split MAC case, the AC should know the sequence number because it would set it. In the local MAC case, the AC would have to query the WTP for the sequence number.=20 =20 So, I believe what you require is a mechanism for the AC to query the WTP for the sequence number in the local MAC case. Is that correct? =20 The keyMIC should not be an issue because in either the local MAC or the split MAC case, the AC would have all the information it needs.=20 The only requirement would be for the AC to hold onto the KEK for the STA to calculate the MIC for the EAPoL frame. =20 Would that be correct? =20 Cheers, =20 Mike =20 On 5/26/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com > wrote:=20 Hi, =20 =09 =09 =09 This is a copy-and-paste from previous email. =20 =09 =09 =09 =20 In cases where IEEE 802.11i encryption/decryption is located in a WTP and IEEE=20 802.11i authenticator is located in an AC, there is a mismatch in tracking=20 =09 =09 =09 KeyRSC values (draft-ietf-capwap-objectives-04.txt) Section 5.1.10. The CAPWAP=20 protocol must allow the 4-way and Group-key exchanges to use accurate values=20 =09 of KeyRSC and KeyMIC in all cases.=20 =20 =09 =09 =09 =20 My recommendation: =09 =09 =09 =20 Introduce new Key Configuration & Key Configuration Response messages as part=20 of Message Types. Key Configuration message will be used to exchange 3rd message (for 4-way exchange & with unassigned KeyMIC and KeyRSC fields) and 1st message (for group-key exchange & with unassigned KeyMIC and KeyRSC fields).=20 =09 =20 =20 =09 =09 =09 =20 I was looking for these 2 messages in the new draft. However, I am open to other ways of accomplishing the objective.=20 =09 =20 Cheers, =09 =09 =09 =09 =09 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com]=20 Sent: Friday, May 26, 2006 8:30 AM=20 To: Pat Calhoun (pacalhou) Cc: Saravanan Govindan; capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 The only text that I could identify that was missing here was information on how the GTK was handled. =20 If there is more information or clarification, please let me know. =20 Cheers, =09 Mike =20 On 5/23/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com > wrote:=20 I have re-opened issue 43, but it would be useful if you could provide a high level example (outline) of what you would like to see.=20 =09 Pat Calhoun=20 CTO, Wireless Networking Business Unit Cisco Systems =09 =09 =09 > -----Original Message----- > From: Saravanan Govindan [mailto: Saravanan.Govindan@sg.panasonic.com ] > Sent: Tuesday, May 23, 2006 12:24 AM > To: capwap > Subject: [Capwap] Clarification of Issue 43: IEEE 802.11i > Considerations > > All, >=20 > I believe this issue 43 - also a Mandatory Objective - is=20 > still open. My suggestion is to update the 802.11 binding > section to reflect steps local-MAC and split-MAC cases. > > Saravanan=20 > > _________________________________________________________________=20 > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap=20 > =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit:=20 http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =20 ------_=_NextPart_001_01C687FE.98EFE138 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Mike,
 
I assume you mean the approved 802.11i-2004 = amendment,=20 not the latest draft.  If anyone needs a copy of this document, it = is=20 available for free download (registration required) from the following=20 URL:
 
http://standards.ieee.org/g= etieee802
 
 -Bob
 
 

From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Saturday, June = 03, 2006=20 11:05 AM
To: Saravanan Govindan
Cc:=20 capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE = 802.11i=20 Considerations

Saravanan,
 
I took a look again at the latest = draft for=20 IEEE 802.11i, and as I understand it, the GTK 1 message needs the = sequence=20 number of the
last transmitted broadcast = frame.
 
In the split MAC case, the AC should know = the=20 sequence number because it would set it. In the local MAC case, the AC = would=20 have to
query the WTP for the sequence number.=20
 
So, I believe what you require is a = mechanism for=20 the AC to query the WTP for the sequence number in the local MAC case. = Is that=20 correct?
 
The keyMIC should not be an issue because = in either=20 the local MAC or the split MAC case, the AC would have all the = information it=20 needs.
The only requirement would be for the AC = to hold=20 onto the KEK for the STA to calculate = the MIC for=20 the EAPoL frame.
 
Would that be correct?
 
Cheers,
 
Mike
 
On 5/26/06, Saravanan=20 Govindan <=20 Saravanan.Govindan@sg.panasonic.com> wrote: 
Hi,
 



This is a copy-and-paste from previous =
email.
 



 
In cases =
where IEEE 802.11i encryption/decryption is located in a WTP and IEEE =

802.11i authenticator is located in an AC, =
there is a mismatch in tracking 



KeyRSC values (draft-ietf-capwap-objectives-04.txt) Section 5.1.10. The =
CAPWAP 
protocol must allow the 4-way =
and Group-key exchanges to use accurate values=20

of KeyRSC and KeyMIC in all cases. =

 



 
My =
recommendation:



 
Introduce =
new Key Configuration & Key Configuration Response messages as part =

of Message Types. Key Configuration message =
will be used to exchange 3rd message (for 4-way exchange & with =
unassigned KeyMIC and KeyRSC fields) and 1st message (for group-key =
exchange & with unassigned KeyMIC and KeyRSC fields).=20

 
 



 
I was =
looking for these 2 messages in the new draft. However, I am open to =
other ways of accomplishing the objective.=20

 
Cheers,





Saravanan
 
 

 

 

From: Michael=20 Montemurro [mailto: montemurro.michael@gmail.com]
Sent: Friday, May 26, 2006 8:30 = AM=20
To: Pat Calhoun=20 (pacalhou)
Cc: = Saravanan=20 Govindan; capwap
Subject: Re:=20 [Capwap] Clarification of Issue 43: IEEE 802.11i=20 Considerations

 

The only=20 text that I could identify that was missing here was information on = how the=20 GTK was handled.

 

If there=20 is more information or clarification, please let me=20 know.

 

Cheers,


Mike
 

On=20 5/23/06, Pat Calhoun = (pacalhou)=20 < = pcalhoun@cisco.com>=20 wrote:

I have=20 re-opened issue 43, but it would be useful if you could provide = a
high=20 level example (outline) of what you would like to see.

Pat = Calhoun=20
CTO, Wireless Networking Business Unit
Cisco=20 Systems



> -----Original Message-----
> From: = Saravanan=20 Govindan [mailto:=20 Saravanan.Govindan@sg.panasonic.com ]
> Sent: Tuesday, May = 23, 2006=20 12:24 AM
> To: capwap
> Subject: [Capwap] Clarification of = Issue=20 43: IEEE 802.11i
> Considerations
>
> All,
> =
>=20 I believe this issue 43 - also a Mandatory Objective - is
> = still open.=20 My suggestion is to update the 802.11 binding
> section to = reflect steps=20 local-MAC and split-MAC cases.
>
> Saravanan =
>
>=20 _________________________________________________________________ =
> To=20 unsubscribe or modify your subscription options, please visit:
> = http://lists.frascone.com/mailman/listinfo/capwap
= >
>=20 Archives: http://lists.frascone.com/pipermail/capwap=20 =
>
_________________________________________________________= ________
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20

 


------_=_NextPart_001_01C687FE.98EFE138-- --===============0140055762== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0140055762==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Jun 04 14:32:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmxOp-0006Pg-65 for capwap-archive@lists.ietf.org; Sun, 04 Jun 2006 14:32:31 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmxOm-0007QG-O7 for capwap-archive@lists.ietf.org; Sun, 04 Jun 2006 14:32:31 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0A00943016A for ; Sun, 4 Jun 2006 11:32:28 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6545E4301A8 for ; Sun, 4 Jun 2006 11:32:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 58A8C398040 for ; Sun, 4 Jun 2006 11:32:03 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [216.148.227.153]) by zoidberg.tigertech.net (Postfix) with ESMTP id B15D4398031 for ; Sun, 4 Jun 2006 11:32:00 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (rwcrmhc13) with ESMTP id <20060604183200m1300g9t5pe>; Sun, 4 Jun 2006 18:32:00 +0000 Message-ID: <4483271F.9040700@hyperthought.com> Date: Sun, 04 Jun 2006 11:31:59 -0700 From: Scott G Kelly User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "Bob O'Hara (boohara)" References: <17B8C6DE4E228348B4939BDA6B05A9DC0197C23F@xmb-sjc-237.amer.cisco.com> In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC0197C23F@xmb-sjc-237.amer.cisco.com> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Use of SESSION ID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Bob O'Hara (boohara) wrote: > Abhijit, > > I apologize if my original reply seemed to dismiss all of your > proposals. I was addressing only the first proposal that was to replace > the "shim" header with a CAPWAP header and still run over a single UDP > port. I think we need to correct a potential misperception, that being that what is being proposed is kludgy, a "shim", and therefore worthy of denigration. This has no technical justification - and it's what I've been referring to as misdirection, because it tends to evoke a pejorative interpretation which is neither technically justified nor appropriate. CAPWAP is a single protocol which currently supports three classes of protocol data unit (PDU): discovery, control, and data. The proposed de-multiplexing mechanism is simply a PDU type field. We have ample precedence for the use of such PDU type fields in other widely deployed protocols such as tls, snmp, l2tp, pptp, and yes, even lwapp (where the 'c' bit serves this function). Layered protocols are quite common in the Internet today. Existing routers and switches have no difficulty in handling these widely deployed protocols, perhaps because they have no mandate other than to route and or switch the traffic. In particular, there has never been a general IETF protocol design requirement for routers and switches to be able to perform economy packet classication via tcp/udp ports - if there were, all protocols would be tcp/udp-based, and all of the various protocols' PDU's would be similarly decomposed by port. But they aren't. Reiterating my earlier observation, backward compatibility with a particular vendor's legacy network gear in terms of identifying capwap internals is not a stated goal of this working group, nor should it be. It's not in the objectives draft, the architectural taxonomy, or the working group charter. It is not a requirement. And it's not in the common interest of the broader community - vendors *or* customers. --Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Jun 04 16:05:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmyrD-0004eL-Sy for capwap-archive@lists.ietf.org; Sun, 04 Jun 2006 16:05:55 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmyrB-0001ey-9O for capwap-archive@lists.ietf.org; Sun, 04 Jun 2006 16:05:55 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id F41924300FB for ; Sun, 4 Jun 2006 13:05:51 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E187943004F for ; Sun, 4 Jun 2006 13:05:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CC27143151D for ; Sun, 4 Jun 2006 13:05:24 -0700 (PDT) Received: from aruba-mx.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by hermes.tigertech.net (Postfix) with SMTP id B4085431520 for ; Sun, 4 Jun 2006 13:05:21 -0700 (PDT) Received: from aruba-mx1.arubanetworks.com ([10.1.1.17]) by aruba-mx.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Jun 2006 13:06:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 4 Jun 2006 13:06:53 -0700 Message-ID: <99C8B9B2AD99664A87E12C839A2E9093F164B9@aruba-mx1.arubanetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Use of SESSION ID Thread-Index: AcaIBXPjYSnfpLnVRJ26c7Rs0MAmdwABb/xg From: "Partha Narasimhan" To: "Scott G Kelly" , "Bob O'Hara (boohara)" X-OriginalArrivalTime: 04 Jun 2006 20:06:55.0610 (UTC) FILETIME=[6D97EDA0:01C68812] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=-0.0 tagged_above=-999.0 required=7.0 tests=SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Use of SESSION ID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 I am finding it hard to understand some of the reasoning put forth on the list on why we need two UDP ports - one each for data and control. If a few intermediate network devices on the path from the ACs to the WTPs are incapable of classifying traffic based on fields existing in the standard IP header, then it merely means that certain network configurations are not feasible when designing networks to suit specific WLAN network requirements in the presence of such network devices. For example, in the presence of such devices, one can always operate the network in Local MAC mode with local termination of IEEE 802.11 at the WTP. One can also design a split MAC solution except we may have to dimension the network properly so that we stay within the bounds imposed by not being able to classify and handle different traffic types differently in the intermediate network. Assuming for the sake of argument that going down the path of two UDP ports is the only possible solution to dealing with limitations of the intermediate network, how do we see WMM/11e traffic being handled in such scenarios in the intermediate network when all the data traffic goes on a single UDP port assigned for CAPWAP data? Does this mean that we assign multiple UDP ports for CAPWAP data - one each for every WMM/11e AC? Obviously, that doesn't scale. Designing a protocol that covers most of the intermediate network topologies as opposed to all topologies does not mean that the entire protocol is useless, just merely that limitations in the intermediate network could prevent a WLAN network designer from being able to use the full potential of the protocol. Network design, as with any other engineering discipline, has to deal with a set of trade-offs and it is no different here. Going down the path of two separate UDP ports, one each for control and data, adds significant complexity to the protocol and the state machine as has been presented before on other prior threads. If a majority of the devices that we expect to encounter in the intermediate network do not have such limitations, then we cannot choose to impose this complexity on the networks that do not have to deal with significantly higher complexity to achieve the same end results. Adding unnecessary complexity to the protocol will more likely lead the protocol to the dustbin of protocols that never get adopted because they are just too complex to implement and/or troubleshoot. While it may be possible to design a protocol to satisfy every single intermediate network topology, it will not be without the cost of additional complexity. Instead we must design the protocol in such a way that it satisfies most commonly encountered topologies and leave the rest to vendor innovation to deal with the corner cases. Thanks partha > -----Original Message----- > From: Scott G Kelly [mailto:scott@hyperthought.com] > Sent: Sunday, June 04, 2006 11:32 AM > To: Bob O'Hara (boohara) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Use of SESSION ID > > Bob O'Hara (boohara) wrote: > > Abhijit, > > > > I apologize if my original reply seemed to dismiss all of your > > proposals. I was addressing only the first proposal that was to > > replace the "shim" header with a CAPWAP header and still run over a > > single UDP port. > > I think we need to correct a potential misperception, that being that > what is being proposed is kludgy, a "shim", and therefore worthy of > denigration. This has no technical justification - and it's what I've > been referring to as misdirection, because it tends to evoke a > pejorative interpretation which is neither technically justified nor > appropriate. > > CAPWAP is a single protocol which currently supports three classes of > protocol data unit (PDU): discovery, control, and data. The proposed > de-multiplexing mechanism is simply a PDU type field. We have ample > precedence for the use of such PDU type fields in other widely deployed > protocols such as tls, snmp, l2tp, pptp, and yes, even lwapp (where the > 'c' bit serves this function). Layered protocols are quite common in > the Internet today. > > Existing routers and switches have no difficulty in handling these > widely deployed protocols, perhaps because they have no mandate other > than to route and or switch the traffic. In particular, there has never > been a general IETF protocol design requirement for routers and > switches to be able to perform economy packet classication via tcp/udp > ports - if there were, all protocols would be tcp/udp-based, and all of > the various protocols' PDU's would be similarly decomposed by port. But > they aren't. > > Reiterating my earlier observation, backward compatibility with a > particular vendor's legacy network gear in terms of identifying capwap > internals is not a stated goal of this working group, nor should it be. > It's not in the objectives draft, the architectural taxonomy, or the > working group charter. It is not a requirement. And it's not in the > common interest of the broader community - vendors *or* customers. > > --Scott > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Jun 04 20:30:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn2zX-0005LR-6Z for capwap-archive@lists.ietf.org; Sun, 04 Jun 2006 20:30:47 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn2rg-0004LF-Nm for capwap-archive@lists.ietf.org; Sun, 04 Jun 2006 20:22:42 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5A9014300CC for ; Sun, 4 Jun 2006 17:22:40 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 39FE44300B7 for ; Sun, 4 Jun 2006 17:22:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1C5BD1448016 for ; Sun, 4 Jun 2006 17:22:11 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by hermes.tigertech.net (Postfix) with ESMTP id 179F41448014 for ; Sun, 4 Jun 2006 17:22:08 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id c39so1000020pyd for ; Sun, 04 Jun 2006 17:22:08 -0700 (PDT) Received: by 10.35.43.10 with SMTP id v10mr5556424pyj; Sun, 04 Jun 2006 17:22:08 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Sun, 4 Jun 2006 17:22:08 -0700 (PDT) Message-ID: <26140d940606041722w6df0f3eyaac5a3d79d3e0e1c@mail.gmail.com> Date: Sun, 4 Jun 2006 20:22:08 -0400 From: "Michael Montemurro" To: "Abhijit Choudhury" In-Reply-To: <26140d940606031550h249b9a0dqb8669a6632714dda@mail.gmail.com> MIME-Version: 1.0 References: <26140d940606031550h249b9a0dqb8669a6632714dda@mail.gmail.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_60_70, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Proposed resolution for issue 100. Treatment of wirelessmanagement frames. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1749230457==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 --===============1749230457== Content-Type: multipart/alternative; boundary="----=_Part_13697_33295157.1149466928109" ------=_Part_13697_33295157.1149466928109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Actually, I need to make one clarification. If we decide to use CAPWAP data encapsulation, IEEE 802.11 management frames passed from the WTP to the AC in local MAC mode. That would mean there would be three possible forms of processing at the WTP: data frames - bridge locally or tunneled to the AC - CAPWAP data 802.11 management frames - encapulated as CAPWAP data and transmitted to the AC CAPWAP control frames. I think it sounds cleaner to encapsulate management frames and transmit them from the WTP to the AC as control frames. But I'm willing to go whichever way the group decides. Cheers, Mike On 6/3/06, Michael Montemurro wrote: > > Is there consensus that radio techology specific management frames should > be carried as CAPWAP data frames? > > Thanks, > > Mike > > > On 6/3/06, Abhijit Choudhury wrote: > > > > Mike, > > I'm not sure this make sense. > > > > The CAPWAP control channel is for "control and > > provisioning" messages between the AC and the WTP. > > Per-client information arriving at the WTP should > > be sent in the data channel as it is all data to > > the AC, and has nothing to do with "control and > > provisioning" of the WTP. > > > > There could be radio technology specific information > > (e.g. RSSI/SNR) that are collected on a per-client > > basis at the AC, and separating out some of the > > messages into a separate channel will lead to either > > erroneous accounting or more complicated logic that > > looks at both channels on a packet-by-packet basis. > > All packets sent by a client should come up > > the same channel (the data channel). > > > > As for security for management frames, 802.11w > > should take care of that. > > > > Thanks, > > Abhijit > > > > -----Original Message----- > > *From:* Michael Montemurro [mailto: montemurro.michael@gmail.com] > > *Sent:* Saturday, June 03, 2006 12:39 PM > > *To:* capwap > > *Subject:* [Capwap] Proposed resolution for issue 100. Treatment of > > wirelessmanagement frames. > > > > Here is my proposed resolution to issue 100: > > > > - Fix the default priority settings in section 11.6 to the values used > > in section 4.3.3. > > > > - Change the last paragraph in section 4.3 to state that radio > > technology specific management frames are treated as CAPWAP control > > messages. It makes sense because control frames are protected. > > > > Does this make sense? > > > > Cheers, > > > > Mike > > > > > > > > > ------=_Part_13697_33295157.1149466928109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Actually, I need to make one clarification. If we decide to use CAPWAP data encapsulation, IEEE 802.11 management frames passed from the WTP to the AC in local MAC mode. That would mean there would be three possible forms of processing at the WTP:
data frames - bridge locally or tunneled to the AC - CAPWAP data
802.11 management frames - encapulated as CAPWAP data and transmitted to the AC
CAPWAP control frames.
 
I think it sounds cleaner to encapsulate management frames and transmit them from the WTP to the AC as control frames. But I'm willing to go whichever way the group decides.
 
Cheers,
 
Mike

 
On 6/3/06, Michael Montemurro <montemurro.michael@gmail.com> wrote:
Is there consensus that radio techology specific management frames should be carried as CAPWAP data frames?
 
Thanks,
 
Mike

 
On 6/3/06, Abhijit Choudhury <Abhijit@sinett.com > wrote:
Mike,
I'm not sure this make sense.
 
The CAPWAP control channel is for "control and
provisioning" messages between the AC and the WTP.
Per-client information arriving at the WTP should
be sent in the data channel as it is all data to
the AC, and has nothing to do with "control and
provisioning" of the WTP. 
 
There could be radio technology specific information
(e.g. RSSI/SNR) that are collected on a per-client
basis at the AC, and separating out some of the
messages into a separate channel will lead to either
erroneous accounting or more complicated logic that
looks at both channels on a packet-by-packet basis.
All packets sent by a client should come up
the same channel (the data channel).
 
As for security for management frames, 802.11w
should take care of that.
 
Thanks,
   Abhijit

-----Original Message-----
From: Michael Montemurro [mailto: montemurro.michael@gmail.com]
Sent: Saturday, June 03, 2006 12:39 PM
To: capwap
Subject: [Capwap] Proposed resolution for issue 100. Treatment of wirelessmanagement frames.
Here is my proposed resolution to issue 100:

- Fix the default priority settings in section 11.6 to the values used in section 4.3.3.

- Change the last paragraph in section 4.3 to state that radio technology specific management frames are treated as CAPWAP control messages. It makes sense because control frames are protected.

Does this make sense?

Cheers,

Mike

 



------=_Part_13697_33295157.1149466928109-- --===============1749230457== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1749230457==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Jun 04 20:31:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn2zn-0005Nf-E3 for capwap-archive@lists.ietf.org; Sun, 04 Jun 2006 20:31:03 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn2mc-0004Fm-Dw for capwap-archive@lists.ietf.org; Sun, 04 Jun 2006 20:17:28 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A61524300C6 for ; Sun, 4 Jun 2006 17:17:25 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E99604300B7 for ; Sun, 4 Jun 2006 17:16:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D64FA1448014 for ; Sun, 4 Jun 2006 17:16:43 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by hermes.tigertech.net (Postfix) with ESMTP id E70AB144800F for ; Sun, 4 Jun 2006 17:16:39 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id c39so999427pyd for ; Sun, 04 Jun 2006 17:16:39 -0700 (PDT) Received: by 10.35.34.18 with SMTP id m18mr5562241pyj; Sun, 04 Jun 2006 17:16:39 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Sun, 4 Jun 2006 17:16:39 -0700 (PDT) Message-ID: <26140d940606041716g19876c80td1efc4916bb3dd91@mail.gmail.com> Date: Sun, 4 Jun 2006 20:16:39 -0400 From: "Michael Montemurro" To: "Bob O'Hara (boohara)" In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC0197C240@xmb-sjc-237.amer.cisco.com> MIME-Version: 1.0 References: <17B8C6DE4E228348B4939BDA6B05A9DC0197C240@xmb-sjc-237.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_60_70, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1572285896==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b --===============1572285896== Content-Type: multipart/alternative; boundary="----=_Part_13649_33081495.1149466599008" ------=_Part_13649_33081495.1149466599008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Bob, Yes, You are correct. Mike On 6/4/06, Bob O'Hara (boohara) wrote: > > Mike, > > I assume you mean the approved 802.11i-2004 amendment, not the latest > draft. If anyone needs a copy of this document, it is available for free > download (registration required) from the following URL: > > http://standards.ieee.org/getieee802 > > -Bob > > > > ------------------------------ > *From:* Michael Montemurro [mailto:montemurro.michael@gmail.com] > *Sent:* Saturday, June 03, 2006 11:05 AM > *To:* Saravanan Govindan > *Cc:* capwap > > *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderations > > > Saravanan, > > I took a look again at the latest draft for IEEE 802.11i, and as I > understand it, the GTK 1 message needs the sequence number of the > last transmitted broadcast frame. > > In the split MAC case, the AC should know the sequence number because it > would set it. In the local MAC case, the AC would have to > query the WTP for the sequence number. > > So, I believe what you require is a mechanism for the AC to query the WTP > for the sequence number in the local MAC case. Is that correct? > > The keyMIC should not be an issue because in either the local MAC or the > split MAC case, the AC would have all the information it needs. > The only requirement would be for the AC to hold onto the KEK for the STA > to calculate the MIC for the EAPoL frame. > > Would that be correct? > > Cheers, > > Mike > > On 5/26/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com> > wrote: > > > Hi, > > > > > > > > > > > > This is a copy-and-paste from previous email. > > > > > > > > > > > > > > > > In cases where IEEE 802.11i encryption/decryption is located in a WTP and IEEE > > > > 802.11i authenticator is located in an AC, there is a mismatch in tracking > > > > > > > > > > KeyRSC values (draft-ietf-capwap-objectives-04.txt) Section 5.1.10. The CAPWAP > > > > protocol must allow the 4-way and Group-key exchanges to use accurate values > > > > of KeyRSC and KeyMIC in all cases. > > > > > > > > My recommendation: > > > > > > > > > > > > Introduce new Key Configuration & Key Configuration Response messages as part > > > > of Message Types. Key Configuration message will be used to exchange 3rd message (for 4-way exchange & with unassigned KeyMIC and KeyRSC fields) and 1st message (for group-key exchange & with unassigned KeyMIC and KeyRSC fields). > > > > > > > > > > > > > > > > > > > > I was looking for these 2 messages in the new draft. However, I am open to other ways of accomplishing the objective. > > > > > > > > Cheers, > > > > > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > ------------------------------ > > > > *From:* Michael Montemurro [mailto: montemurro.michael@gmail.com] > > *Sent:* Friday, May 26, 2006 8:30 AM > > *To:* Pat Calhoun (pacalhou) > > *Cc:* Saravanan Govindan; capwap > > *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderations > > > > > > > > The only text that I could identify that was missing here was > > information on how the GTK was handled. > > > > > > > > If there is more information or clarification, please let me know. > > > > > > > > Cheers, > > > > > > Mike > > > > > > On 5/23/06, *Pat Calhoun (pacalhou)* < pcalhoun@cisco.com> wrote: > > > > I have re-opened issue 43, but it would be useful if you could provide a > > high level example (outline) of what you would like to see. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Saravanan Govindan [mailto: Saravanan.Govindan@sg.panasonic.com > > ] > > > Sent: Tuesday, May 23, 2006 12:24 AM > > > To: capwap > > > Subject: [Capwap] Clarification of Issue 43: IEEE 802.11i > > > Considerations > > > > > > All, > > > > > > I believe this issue 43 - also a Mandatory Objective - is > > > still open. My suggestion is to update the 802.11 binding > > > section to reflect steps local-MAC and split-MAC cases. > > > > > > Saravanan > > > > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_13649_33081495.1149466599008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Bob,
 
Yes, You are correct.
 
Mike

 
On 6/4/06, Bob O'Hara (boohara) <boohara@cisco.com> wrote:
Mike,
 
I assume you mean the approved 802.11i-2004 amendment, not the latest draft.  If anyone needs a copy of this document, it is available for free download (registration required) from the following URL:
 
 
 -Bob
 
 

From: Michael Montemurro [mailto:montemurro.michael@gmail.com]
Sent: Saturday, June 03, 2006 11:05 AM
To: Saravanan Govindan
Cc: capwap

Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations

 
Saravanan,
 
I took a look again at the latest draft for IEEE 802.11i, and as I understand it, the GTK 1 message needs the sequence number of the
last transmitted broadcast frame.
 
In the split MAC case, the AC should know the sequence number because it would set it. In the local MAC case, the AC would have to
query the WTP for the sequence number.
 
So, I believe what you require is a mechanism for the AC to query the WTP for the sequence number in the local MAC case. Is that correct?
 
The keyMIC should not be an issue because in either the local MAC or the split MAC case, the AC would have all the information it needs.
The only requirement would be for the AC to hold onto the KEK for the STA to calculate the MIC for the EAPoL frame.
 
Would that be correct?
 
Cheers,
 
Mike
 
On 5/26/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com> wrote: 
Hi,
 




This is a copy-and-paste from previous email.
 




 
In cases where IEEE 802.11i encryption/decryption is located in a WTP and IEEE 
802.11i authenticator is located in an AC, there is a mismatch in tracking 




KeyRSC values (draft-ietf-capwap-objectives-04.txt) Section 5.1.10. The CAPWAP 
protocol must allow the 4-way and Group-key exchanges to use accurate values 

of KeyRSC and KeyMIC in all cases. 
 




 
My recommendation:




 
Introduce new Key Configuration & Key Configuration Response messages as part 
of Message Types. Key Configuration message will be used to exchange 3rd message (for 4-way exchange & with unassigned KeyMIC and KeyRSC fields) and 1st message (for group-key exchange & with unassigned KeyMIC and KeyRSC fields). 

 
 




 
I was looking for these 2 messages in the new draft. However, I am open to other ways of accomplishing the objective. 

 
Cheers,






Saravanan
 
 

 

 

From: Michael Montemurro [mailto: montemurro.michael@gmail.com]
Sent: Friday, May 26, 2006 8:30 AM
To: Pat Calhoun (pacalhou)
Cc: Saravanan Govindan; capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations

 

The only text that I could identify that was missing here was information on how the GTK was handled.

 

If there is more information or clarification, please let me know.

 

Cheers,


Mike
 

On 5/23/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com> wrote:

I have re-opened issue 43, but it would be useful if you could provide a
high level example (outline) of what you would like to see.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems



> -----Original Message-----
> From: Saravanan Govindan [mailto: Saravanan.Govindan@sg.panasonic.com ]
> Sent: Tuesday, May 23, 2006 12:24 AM
> To: capwap
> Subject: [Capwap] Clarification of Issue 43: IEEE 802.11i
> Considerations
>
> All,
>
> I believe this issue 43 - also a Mandatory Objective - is
> still open. My suggestion is to update the 802.11 binding
> section to reflect steps local-MAC and split-MAC cases.
>
> Saravanan
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

 



_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


------=_Part_13649_33081495.1149466599008-- --===============1572285896== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1572285896==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 05 11:21:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnGtc-0001cz-Ph for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 11:21:36 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnGtb-0001UJ-1x for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 11:21:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1340F4301C9 for ; Mon, 5 Jun 2006 08:21:34 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 894AF4300B7 for ; Mon, 5 Jun 2006 08:21:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D913A39804B for ; Mon, 5 Jun 2006 08:21:02 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id 86A40398053 for ; Mon, 5 Jun 2006 08:20:57 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 05 Jun 2006 08:20:57 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k55FKuTA025616; Mon, 5 Jun 2006 08:20:56 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k55FKu9s026160; Mon, 5 Jun 2006 08:20:56 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Jun 2006 08:20:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Jun 2006 08:20:55 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201FC036F@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Encryption Capabilities Thread-Index: AcaHQb1cyL4SXBQyTD6djEL17xZbDwBavIsQ From: "Pat Calhoun (pacalhou)" To: "Michael Montemurro" , "David T. Perkins" X-OriginalArrivalTime: 05 Jun 2006 15:20:56.0696 (UTC) FILETIME=[A47F2F80:01C688B3] Authentication-Results: sj-dkim-3.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.468 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1149225499==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee This is a multi-part message in MIME format. --===============1149225499== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C688B3.A45684C0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C688B3.A45684C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Actually, this field was intended to allow the WTP to communicate whether it is capable of providing its capabilities, and therefore allow the AC to determine whether it should perform centralized encryption. However, with the transition to DTLS, I propose that we always require the WTP to provide wireless encryption, and use DTLS between the AC and the WTP.=20 =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Saturday, June 03, 2006 12:12 PM To: David T. Perkins Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities =09 =09 David, =20 Would it be sufficient to move Encryption Capabilities from the WTP Descriptor (Section 4.4.34) to the WTP Radio Information message element (Section 4.4.39)? =20 Mike =09 =20 On 6/3/06, Michael Montemurro wrote:=20 David,=20 =09 I've created issue 125 to track this issue. =20 Mike =09 =20 =09 On 6/1/06, David T. Perkins wrote:=20 HI, =09 The "(4.4.34)WTP Descriptor" message element has the subfield "encryption capabilities". What is this used=20 for? If for radios, then it should be per radio. If for the user data between the WTP and AC, then it doesn't seem appropriate to say the value is defined by "specific binding" definitions because the WTP can be supporting multiple radios with some that provide encryption services and some that don't. =09 In general, I don't feel that this subfield is well defined, and it appears to me that it should be a per radio attribute.=20 =09 Regards, /david t. perkins =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: =09 http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 ------_=_NextPart_001_01C688B3.A45684C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Actually, this field was intended to allow the WTP to = communicate whether=20 it is capable of providing its capabilities, and therefore allow the AC = to=20 determine whether it should perform centralized encryption. However, = with the=20 transition to DTLS, I propose that we always require the WTP = to=20 provide wireless encryption, and use DTLS between the AC and the WTP.=20
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Saturday, June = 03, 2006=20 12:12 PM
To: David T. Perkins
Cc:=20 capwap@frascone.com
Subject: Re: [Capwap] Encryption=20 Capabilities

David,
 
Would it be sufficient to move Encryption Capabilities from the = WTP=20 Descriptor (Section 4.4.34) to the WTP Radio Information message = element=20 (Section 4.4.39)?
 
Mike

 
On 6/3/06, Michael=20 Montemurro <montemurro.michael@gmail.com= >=20 wrote:=20
David,

I've created issue 125 to track this = issue.
 
Mike

 
On 6/1/06, David T.=20 Perkins <dperkins@dsperkins.com=20 > wrote:=20
HI,

The=20 "(4.4.34)WTP Descriptor" message element has the
subfield = "encryption=20 capabilities". What is this used
for? If for radios, then it = should be=20 per radio. If
for the user data between the WTP and AC, = then
it=20 doesn't seem appropriate to say the value is
defined by = "specific=20 binding" definitions because
the WTP can be supporting multiple = radios=20 with
some that provide encryption services and some
that=20 don't.

In general, I don't feel that this subfield = is
well=20 defined, and it appears to me that it
should be a per radio = attribute.=20

Regards,
/david t.=20 = perkins

__________________________________________________________= _______
To=20 unsubscribe or modify your subscription options, please = visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20 =


------_=_NextPart_001_01C688B3.A45684C0-- --===============1149225499== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1149225499==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 05 11:23:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnGvA-0001jC-HR for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 11:23:12 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnGv9-0001WA-PJ for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 11:23:12 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 67E004301BD for ; Mon, 5 Jun 2006 08:23:11 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 789C54300B7 for ; Mon, 5 Jun 2006 08:22:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2E24F1448018 for ; Mon, 5 Jun 2006 08:22:36 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id E72A0144801F for ; Mon, 5 Jun 2006 08:22:31 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 05 Jun 2006 08:22:31 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k55FMVqm018191; Mon, 5 Jun 2006 08:22:31 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k55FMVcL010253; Mon, 5 Jun 2006 08:22:31 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Jun 2006 08:22:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Jun 2006 08:22:29 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201FC0372@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Encryption Capabilities Thread-Index: AcaHQb1cyL4SXBQyTD6djEL17xZbDwBavIsQAAHJGzA= From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , "Michael Montemurro" , "David T. Perkins" X-OriginalArrivalTime: 05 Jun 2006 15:22:30.0984 (UTC) FILETIME=[DCB26480:01C688B3] Authentication-Results: sj-dkim-5.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0650376824==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 This is a multi-part message in MIME format. --===============0650376824== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C688B3.DC83ED60" This is a multi-part message in MIME format. ------_=_NextPart_001_01C688B3.DC83ED60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I should have noted that securing the data plane should be optional. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Pat Calhoun (pacalhou)=20 Sent: Monday, June 05, 2006 8:21 AM To: Michael Montemurro; David T. Perkins Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities =09 =09 Actually, this field was intended to allow the WTP to communicate whether it is capable of providing its capabilities, and therefore allow the AC to determine whether it should perform centralized encryption. However, with the transition to DTLS, I propose that we always require the WTP to provide wireless encryption, and use DTLS between the AC and the WTP.=20 =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Saturday, June 03, 2006 12:12 PM To: David T. Perkins Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities =09 =09 David, =20 Would it be sufficient to move Encryption Capabilities from the WTP Descriptor (Section 4.4.34) to the WTP Radio Information message element (Section 4.4.39)? =20 Mike =09 =20 On 6/3/06, Michael Montemurro wrote:=20 David,=20 =09 I've created issue 125 to track this issue. =20 Mike =09 =20 =09 On 6/1/06, David T. Perkins wrote:=20 HI, =09 The "(4.4.34)WTP Descriptor" message element has the subfield "encryption capabilities". What is this used=20 for? If for radios, then it should be per radio. If for the user data between the WTP and AC, then it doesn't seem appropriate to say the value is defined by "specific binding" definitions because the WTP can be supporting multiple radios with some that provide encryption services and some that don't. =09 In general, I don't feel that this subfield is well defined, and it appears to me that it should be a per radio attribute.=20 =09 Regards, /david t. perkins =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: =09 http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 ------_=_NextPart_001_01C688B3.DC83ED60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 should have noted that securing the data plane should be=20 optional.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Pat Calhoun (pacalhou) =
Sent:=20 Monday, June 05, 2006 8:21 AM
To: Michael Montemurro; David = T.=20 Perkins
Cc: capwap@frascone.com
Subject: Re: = [Capwap]=20 Encryption Capabilities

Actually, this field was intended to allow the WTP to = communicate=20 whether it is capable of providing its capabilities, and therefore = allow the=20 AC to determine whether it should perform centralized encryption. = However,=20 with the transition to DTLS, I propose that we always = require the=20 WTP to provide wireless encryption, and use DTLS between the AC and = the WTP.=20
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Saturday, = June 03,=20 2006 12:12 PM
To: David T. Perkins
Cc:=20 capwap@frascone.com
Subject: Re: [Capwap] Encryption=20 Capabilities

David,
 
Would it be sufficient to move Encryption Capabilities from the = WTP=20 Descriptor (Section 4.4.34) to the WTP Radio Information message = element=20 (Section 4.4.39)?
 
Mike

 
On 6/3/06, Michael=20 Montemurro <montemurro.michael@gmail.com= >=20 wrote:=20
David,

I've created issue 125 to track this = issue.
 
Mike

 
On 6/1/06, David T.=20 Perkins <dperkins@dsperkins.com=20 > wrote:=20
HI,

The=20 "(4.4.34)WTP Descriptor" message element has the
subfield = "encryption=20 capabilities". What is this used
for? If for radios, then it = should=20 be per radio. If
for the user data between the WTP and AC, = then
it=20 doesn't seem appropriate to say the value is
defined by = "specific=20 binding" definitions because
the WTP can be supporting = multiple=20 radios with
some that provide encryption services and = some
that=20 don't.

In general, I don't feel that this subfield = is
well=20 defined, and it appears to me that it
should be a per radio=20 attribute.

Regards,
/david t.=20 = perkins

__________________________________________________________= _______
To=20 unsubscribe or modify your subscription options, please = visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20 =


------_=_NextPart_001_01C688B3.DC83ED60-- --===============0650376824== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0650376824==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 05 11:42:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHDS-0003UD-Gj for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 11:42:06 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnHDQ-0004f7-Vw for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 11:42:06 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3E877430134 for ; Mon, 5 Jun 2006 08:42:04 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D68A24300B7 for ; Mon, 5 Jun 2006 08:41:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A91F21448019 for ; Mon, 5 Jun 2006 08:41:35 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by hermes.tigertech.net (Postfix) with ESMTP id 81FD11448023 for ; Mon, 5 Jun 2006 08:41:33 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 05 Jun 2006 08:41:33 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k55FfWlO021422 for ; Mon, 5 Jun 2006 08:41:32 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k55FfW9s012187 for ; Mon, 5 Jun 2006 08:41:32 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Jun 2006 08:41:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Jun 2006 08:41:31 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC0197C379@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Use of SESSION ID Thread-Index: AcaIBSumuCsNq4BCQOmWmeNq/qsGpwAryZZw From: "Bob O'Hara (boohara)" To: X-OriginalArrivalTime: 05 Jun 2006 15:41:32.0321 (UTC) FILETIME=[84FC9910:01C688B6] Authentication-Results: sj-dkim-3.cisco.com; header.From=boohara@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Use of SESSION ID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Scott, I believe you were the first to use the word "shim", not me. If it is pejorative, it is your word, not mine. As to the need to be backward compatible with "a particular vendor's legacy network gear", this is also your argument, not mine. I am not arguing for separate ports due to the fact that my LWAPP equipment uses them. I am arguing for the use of separate ports for exactly the reason that I chose to use separate ports on my LWAPP equipment. The reason is that using separate ports requires NO CHANGE TO EXISTING NETWORK INFRASTRUCTURE EQUIPMENT, while providing the capability to easily classify data and control traffic separately on that existing equipment. At the time I chose two ports for LWAPP, I was a competitor to every other networking equipment vendor in the world. As a matter of fact, so were you. I had no interest in making my competitors comfortable. My intention was exactly the opposite. But, since you won't accept this argument from me, let me copy the eloquent words of another poster to this list, who's message has been conveniently forgotten: On May 16, 2006, Chris Stradtman wrote: from an service provider point of view I can think of 2 off the top of my head. 1. A service provider may not choose to trustingly pass through the QOS markings and may wish to rewrite the QOS markings based on other policies internal to the service provider. 2. The service provider may wish to send the data and control channels down different physical paths based on economic factors. If the streams are muxed then the service provider need to have equipment in the middle that understands the capwap protocol out of the gate (although some gear can use explicity bitstrings and offsets into the packet). This is unlikely to happen and in my opinion would slow down the adoption and implementation of the protocol in the "real world". What Chris has described above is a very common practice, not only in service providers, but also in enterprise networks. His "equipment in the middle" is today's router or switch, neither of which understand the CAPWAP header. Granted, some of that equipment has the logo of my employer on it. But, much of it does not. Yes, that "equipment in the middle" may understand other protocols than TCP and UDP, exactly because they are widely deployed. But, requiring that the "equipment in the middle" be upgraded by the customer to get the same functionality they get on every other protocol will only serve to delay the adoption of CAPWAP. It may also guarantee that CAPWAP never becomes widely deployed. If you can't understand the reason to use separate ports or won't accept my arguments, at least listen to the customers that might (or might not) buy equipment that uses CAPWAP. -Bob -----Original Message----- From: Scott G Kelly [mailto:scott@hyperthought.com] Sent: Sunday, June 04, 2006 11:32 AM To: Bob O'Hara (boohara) Cc: capwap@frascone.com Subject: Re: [Capwap] Use of SESSION ID Bob O'Hara (boohara) wrote: > Abhijit, > > I apologize if my original reply seemed to dismiss all of your > proposals. I was addressing only the first proposal that was to replace > the "shim" header with a CAPWAP header and still run over a single UDP > port. I think we need to correct a potential misperception, that being that what is being proposed is kludgy, a "shim", and therefore worthy of denigration. This has no technical justification - and it's what I've been referring to as misdirection, because it tends to evoke a pejorative interpretation which is neither technically justified nor appropriate. CAPWAP is a single protocol which currently supports three classes of protocol data unit (PDU): discovery, control, and data. The proposed de-multiplexing mechanism is simply a PDU type field. We have ample precedence for the use of such PDU type fields in other widely deployed protocols such as tls, snmp, l2tp, pptp, and yes, even lwapp (where the 'c' bit serves this function). Layered protocols are quite common in the Internet today. Existing routers and switches have no difficulty in handling these widely deployed protocols, perhaps because they have no mandate other than to route and or switch the traffic. In particular, there has never been a general IETF protocol design requirement for routers and switches to be able to perform economy packet classication via tcp/udp ports - if there were, all protocols would be tcp/udp-based, and all of the various protocols' PDU's would be similarly decomposed by port. But they aren't. Reiterating my earlier observation, backward compatibility with a particular vendor's legacy network gear in terms of identifying capwap internals is not a stated goal of this working group, nor should it be. It's not in the objectives draft, the architectural taxonomy, or the working group charter. It is not a requirement. And it's not in the common interest of the broader community - vendors *or* customers. --Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 05 12:20:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHoP-0004tS-H8 for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 12:20:17 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnHoM-0000GS-TH for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 12:20:17 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4712543011E for ; Mon, 5 Jun 2006 09:20:14 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2075D4300A7 for ; Mon, 5 Jun 2006 09:19:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id F313E1448020 for ; Mon, 5 Jun 2006 09:19:34 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by hermes.tigertech.net (Postfix) with ESMTP id B6E9B1448015 for ; Mon, 5 Jun 2006 09:19:32 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id c39so1170441pyd for ; Mon, 05 Jun 2006 09:19:32 -0700 (PDT) Received: by 10.35.99.17 with SMTP id b17mr6647646pym; Mon, 05 Jun 2006 09:12:48 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Mon, 5 Jun 2006 09:12:48 -0700 (PDT) Message-ID: <26140d940606050912y5c5a804eja5ba870da7867eee@mail.gmail.com> Date: Mon, 5 Jun 2006 12:12:48 -0400 From: "Michael Montemurro" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201FC036F@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A201FC036F@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_50_60, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0349740485==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba --===============0349740485== Content-Type: multipart/alternative; boundary="----=_Part_4766_10092892.1149523968127" ------=_Part_4766_10092892.1149523968127 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Pat, Are you saying that we should remove the Encryption Capabilities field? If not, do you agree that it makes more sense to include it as part of the radio information. Cheers, Mike On 6/5/06, Pat Calhoun (pacalhou) wrote: > > Actually, this field was intended to allow the WTP to communicate whether > it is capable of providing its capabilities, and therefore allow the AC to > determine whether it should perform centralized encryption. However, with > the transition to DTLS, I propose that we always require the WTP to provide > wireless encryption, and use DTLS between the AC and the WTP. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > ------------------------------ > *From:* Michael Montemurro [mailto:montemurro.michael@gmail.com] > *Sent:* Saturday, June 03, 2006 12:12 PM > *To:* David T. Perkins > *Cc:* capwap@frascone.com > *Subject:* Re: [Capwap] Encryption Capabilities > > > > David, > > Would it be sufficient to move Encryption Capabilities from the WTP > Descriptor (Section 4.4.34) to the WTP Radio Information message element > (Section 4.4.39)? > > Mike > > > On 6/3/06, Michael Montemurro wrote: > > > > David, > > > > I've created issue 125 to track this issue. > > > > Mike > > > > > > On 6/1/06, David T. Perkins wrote: > > > > > > HI, > > > > > > The "(4.4.34)WTP Descriptor" message element has the > > > subfield "encryption capabilities". What is this used > > > for? If for radios, then it should be per radio. If > > > for the user data between the WTP and AC, then > > > it doesn't seem appropriate to say the value is > > > defined by "specific binding" definitions because > > > the WTP can be supporting multiple radios with > > > some that provide encryption services and some > > > that don't. > > > > > > In general, I don't feel that this subfield is > > > well defined, and it appears to me that it > > > should be a per radio attribute. > > > > > > Regards, > > > /david t. perkins > > > > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > ------=_Part_4766_10092892.1149523968127 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Pat,
 
Are you saying that we should remove the Encryption Capabilities field? If not, do you agree that it makes more sense to include it as part of the radio information.
 
Cheers,
 
Mike

 
On 6/5/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
Actually, this field was intended to allow the WTP to communicate whether it is capable of providing its capabilities, and therefore allow the AC to determine whether it should perform centralized encryption. However, with the transition to DTLS, I propose that we always require the WTP to provide wireless encryption, and use DTLS between the AC and the WTP.
 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

From: Michael Montemurro [mailto:montemurro.michael@gmail.com]
Sent: Saturday, June 03, 2006 12:12 PM
To: David T. Perkins
Cc: capwap@frascone.com
Subject: Re: [Capwap] Encryption Capabilities

 
David,
 
Would it be sufficient to move Encryption Capabilities from the WTP Descriptor (Section 4.4.34) to the WTP Radio Information message element (Section 4.4.39)?
 
Mike

 
On 6/3/06, Michael Montemurro <montemurro.michael@gmail.com > wrote:
David,

I've created issue 125 to track this issue.
 
Mike

 
On 6/1/06, David T. Perkins <dperkins@dsperkins.com > wrote:
HI,

The "(4.4.34)WTP Descriptor" message element has the
subfield "encryption capabilities". What is this used
for? If for radios, then it should be per radio. If
for the user data between the WTP and AC, then
it doesn't seem appropriate to say the value is
defined by "specific binding" definitions because
the WTP can be supporting multiple radios with
some that provide encryption services and some
that don't.

In general, I don't feel that this subfield is
well defined, and it appears to me that it
should be a per radio attribute.

Regards,
/david t. perkins

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap



------=_Part_4766_10092892.1149523968127-- --===============0349740485== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0349740485==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 05 13:06:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnIXC-0001Fb-Su for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 13:06:34 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnIXB-0004if-3U for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 13:06:34 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 21255430122 for ; Mon, 5 Jun 2006 10:06:32 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4436C430077 for ; Mon, 5 Jun 2006 10:05:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 321781448011 for ; Mon, 5 Jun 2006 10:05:51 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id 1C3011448015 for ; Mon, 5 Jun 2006 10:05:46 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 05 Jun 2006 10:05:44 -0700 X-IronPort-AV: i="4.05,211,1146466800"; d="scan'208,217"; a="288962218:sNHT74295080" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k55H5iMn029428; Mon, 5 Jun 2006 10:05:44 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k55H5iKR003083; Mon, 5 Jun 2006 10:05:44 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Jun 2006 10:05:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Jun 2006 10:05:43 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201FC040B@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Encryption Capabilities Thread-Index: AcaIuxskpCeyvBW8RAKJyrDxt453IQAByfkg From: "Pat Calhoun (pacalhou)" To: "Michael Montemurro" X-OriginalArrivalTime: 05 Jun 2006 17:05:44.0514 (UTC) FILETIME=[48541220:01C688C2] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0958878697==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b This is a multi-part message in MIME format. --===============0958878697== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C688C2.48282E2E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C688C2.48282E2E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, I agree. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Monday, June 05, 2006 9:13 AM To: Pat Calhoun (pacalhou) Cc: David T. Perkins; capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities =09 =09 Pat, =20 Are you saying that we should remove the Encryption Capabilities field? If not, do you agree that it makes more sense to include it as part of the radio information. =20 Cheers, =20 Mike =09 =20 On 6/5/06, Pat Calhoun (pacalhou) wrote:=20 Actually, this field was intended to allow the WTP to communicate whether it is capable of providing its capabilities, and therefore allow the AC to determine whether it should perform centralized encryption. However, with the transition to DTLS, I propose that we always require the WTP to provide wireless encryption, and use DTLS between the AC and the WTP.=20 =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Saturday, June 03, 2006 12:12 PM To: David T. Perkins Cc: capwap@frascone.com=20 Subject: Re: [Capwap] Encryption Capabilities =09 =20 =09 David, =20 Would it be sufficient to move Encryption Capabilities from the WTP Descriptor (Section 4.4.34) to the WTP Radio Information message element (Section 4.4.39)? =20 Mike =09 =20 On 6/3/06, Michael Montemurro wrote:=20 David,=20 =09 I've created issue 125 to track this issue. =20 Mike =09 =20 =09 On 6/1/06, David T. Perkins wrote:=20 HI, =09 The "(4.4.34)WTP Descriptor" message element has the subfield "encryption capabilities". What is this used=20 for? If for radios, then it should be per radio. If for the user data between the WTP and AC, then it doesn't seem appropriate to say the value is defined by "specific binding" definitions because the WTP can be supporting multiple radios with some that provide encryption services and some that don't. =09 In general, I don't feel that this subfield is well defined, and it appears to me that it should be a per radio attribute.=20 =09 Regards, /david t. perkins =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: =09 http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 ------_=_NextPart_001_01C688C2.48282E2E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yes, I=20 agree.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Monday, June = 05, 2006=20 9:13 AM
To: Pat Calhoun (pacalhou)
Cc: David T. = Perkins;=20 capwap@frascone.com
Subject: Re: [Capwap] Encryption=20 Capabilities

Pat,
 
Are you saying that we should remove the Encryption Capabilities = field?=20 If not, do you agree that it makes more sense to include it as part of = the=20 radio information.
 
Cheers,
 
Mike

 
On 6/5/06, Pat Calhoun=20 (pacalhou) <pcalhoun@cisco.com> = wrote:=20
Actually, = this field was=20 intended to allow the WTP to communicate whether it is capable of = providing=20 its capabilities, and therefore allow the AC to determine whether it = should=20 perform centralized encryption. However, with the transition to = DTLS, I=20 propose that we always require the WTP to provide wireless = encryption,=20 and use DTLS between the AC and the WTP.
 

Pat Calhoun
CTO, Wireless = Networking Business=20 Unit
Cisco Systems

 

From: Michael Montemurro = [mailto:montemurro.michael@gmail.com]
Sent: = Saturday,=20 June 03, 2006 12:12 PM
To: David T. = Perkins
Cc: capwap@frascone.com=20
Subject: Re: [Capwap] Encryption=20 Capabilities

 
David,
 
Would it be sufficient to move Encryption Capabilities from the = WTP=20 Descriptor (Section 4.4.34) to the WTP Radio Information message = element=20 (Section 4.4.39)?
 
Mike

 
On 6/3/06, Michael=20 Montemurro <montemurro.michael@gmail.com > wrote:=20
David,

I've created issue 125 to track this = issue.
 
Mike

 
On 6/1/06, David T.=20 Perkins <dperkins@dsperkins.com=20 > wrote:=20
HI,

The=20 "(4.4.34)WTP Descriptor" message element has the
subfield = "encryption=20 capabilities". What is this used
for? If for radios, then it = should=20 be per radio. If
for the user data between the WTP and AC, = then
it=20 doesn't seem appropriate to say the value is
defined by = "specific=20 binding" definitions because
the WTP can be supporting = multiple=20 radios with
some that provide encryption services and = some
that=20 don't.

In general, I don't feel that this subfield = is
well=20 defined, and it appears to me that it
should be a per radio=20 attribute.

Regards,
/david t.=20 = perkins

__________________________________________________________= _______
To=20 unsubscribe or modify your subscription options, please = visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20 =


=

= ------_=_NextPart_001_01C688C2.48282E2E-- --===============0958878697== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0958878697==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 05 20:04:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnP3o-0006qn-FK for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 20:04:40 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnP3m-00058H-LK for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 20:04:40 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 96987430112 for ; Mon, 5 Jun 2006 17:04:36 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 28864430085 for ; Mon, 5 Jun 2006 17:04:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 090C6144801A for ; Mon, 5 Jun 2006 17:04:02 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.207]) by hermes.tigertech.net (Postfix) with ESMTP id 0B8B91448015 for ; Mon, 5 Jun 2006 17:03:57 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id t13so820303wxc for ; Mon, 05 Jun 2006 17:03:57 -0700 (PDT) Received: by 10.70.47.1 with SMTP id u1mr6743662wxu; Mon, 05 Jun 2006 17:03:56 -0700 (PDT) Received: by 10.70.133.2 with HTTP; Mon, 5 Jun 2006 17:03:56 -0700 (PDT) Message-ID: <5bfe7a820606051703k47c5b833v60798cf314efece7@mail.gmail.com> Date: Mon, 5 Jun 2006 17:03:56 -0700 From: "Dorothy Stanley" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201FC036F@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A201FC036F@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.6 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_50_60, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0682224885==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc --===============0682224885== Content-Type: multipart/alternative; boundary="----=_Part_47959_13939429.1149552236779" ------=_Part_47959_13939429.1149552236779 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I do not agree with always requiring the WTP to provide wireless encryption. The split MAC architecture allows 802.11 encryption/decryption at either the WTP or the AC, and this flexibility should be retained, with use of the field in question clearly defined. Dorothy On 6/5/06, Pat Calhoun (pacalhou) wrote: > > Actually, this field was intended to allow the WTP to communicate whether > it is capable of providing its capabilities, and therefore allow the AC to > determine whether it should perform centralized encryption. However, with > the transition to DTLS, I propose that we always require the WTP to provide > wireless encryption, and use DTLS between the AC and the WTP. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > ------------------------------ > *From:* Michael Montemurro [mailto:montemurro.michael@gmail.com] > *Sent:* Saturday, June 03, 2006 12:12 PM > *To:* David T. Perkins > *Cc:* capwap@frascone.com > *Subject:* Re: [Capwap] Encryption Capabilities > > David, > > Would it be sufficient to move Encryption Capabilities from the WTP > Descriptor (Section 4.4.34) to the WTP Radio Information message element > (Section 4.4.39)? > > Mike > > > On 6/3/06, Michael Montemurro wrote: > > > > David, > > > > I've created issue 125 to track this issue. > > > > Mike > > > > > > On 6/1/06, David T. Perkins wrote: > > > > > > HI, > > > > > > The "(4.4.34)WTP Descriptor" message element has the > > > subfield "encryption capabilities". What is this used > > > for? If for radios, then it should be per radio. If > > > for the user data between the WTP and AC, then > > > it doesn't seem appropriate to say the value is > > > defined by "specific binding" definitions because > > > the WTP can be supporting multiple radios with > > > some that provide encryption services and some > > > that don't. > > > > > > In general, I don't feel that this subfield is > > > well defined, and it appears to me that it > > > should be a per radio attribute. > > > > > > Regards, > > > /david t. perkins > > > > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_47959_13939429.1149552236779 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I do not agree with always requiring the WTP to provide wireless
encryption. The split MAC architecture allows 802.11 encryption/decryption
at either the WTP or the AC, and this flexibility should be retained, with use of the
field in question clearly defined.

Dorothy


On 6/5/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
Actually, this field was intended to allow the WTP to communicate whether it is capable of providing its capabilities, and therefore allow the AC to determine whether it should perform centralized encryption. However, with the transition to DTLS, I propose that we always require the WTP to provide wireless encryption, and use DTLS between the AC and the WTP.
 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

From: Michael Montemurro [mailto:montemurro.michael@gmail.com]
Sent: Saturday, June 03, 2006 12:12 PM
To: David T. Perkins
Cc: capwap@frascone.com
Subject: Re: [Capwap] Encryption Capabilities

David,
 
Would it be sufficient to move Encryption Capabilities from the WTP Descriptor (Section 4.4.34) to the WTP Radio Information message element (Section 4.4.39)?
 
Mike

 
On 6/3/06, Michael Montemurro <montemurro.michael@gmail.com> wrote:
David,

I've created issue 125 to track this issue.
 
Mike

 
On 6/1/06, David T. Perkins <dperkins@dsperkins.com > wrote:
HI,

The "(4.4.34)WTP Descriptor" message element has the
subfield "encryption capabilities". What is this used
for? If for radios, then it should be per radio. If
for the user data between the WTP and AC, then
it doesn't seem appropriate to say the value is
defined by "specific binding" definitions because
the WTP can be supporting multiple radios with
some that provide encryption services and some
that don't.

In general, I don't feel that this subfield is
well defined, and it appears to me that it
should be a per radio attribute.

Regards,
/david t. perkins

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap



_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


------=_Part_47959_13939429.1149552236779-- --===============0682224885== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0682224885==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 05 20:08:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnP7H-0000Qa-Kx for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 20:08:15 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnP7E-0005kr-B2 for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 20:08:15 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id AC316430085 for ; Mon, 5 Jun 2006 17:08:11 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 2ACC84300FE for ; Mon, 5 Jun 2006 17:07:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E8622398039 for ; Mon, 5 Jun 2006 17:06:59 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6707639804A for ; Mon, 5 Jun 2006 17:06:55 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 05 Jun 2006 17:06:10 -0700 X-IronPort-AV: i="4.05,212,1146466800"; d="scan'208,217"; a="289236026:sNHT3267838014" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k5606AA9014445; Mon, 5 Jun 2006 17:06:10 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5606AcN025821; Mon, 5 Jun 2006 17:06:10 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Jun 2006 17:06:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Jun 2006 17:06:09 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201FC06C8@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 85 - Proposed Resolution/wasRe: Proposal for updatedState Machine Thread-Index: AcZ/T1MydZbDFk3SQEeufkDXFKyEHQJra0hA From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "David T. Perkins" X-OriginalArrivalTime: 06 Jun 2006 00:06:10.0103 (UTC) FILETIME=[03F37C70:01C688FD] Authentication-Results: sj-dkim-7.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.373 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Issue 85 - Proposed Resolution/wasRe: Proposal for updatedState Machine X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1589504453==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bd14a31ed5bce9138736cf0e98bb014 This is a multi-part message in MIME format. --===============1589504453== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C688FD.03AAB33A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C688FD.03AAB33A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That works for me. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Wednesday, May 24, 2006 9:29 AM To: David T. Perkins Cc: capwap Subject: [Capwap] Issue 85 - Proposed Resolution/wasRe: Proposal for updatedState Machine =09 =09 All, =09 Issue 85 is listed below. Apart from the initial posting, there has been no follow-up discussion. Issue 85 provided comments on the draft-00 state machine.=20 =09 Proposed resolution for Issue 85: =09 - Issue 85 changes 1 and 3 have been incorporated into the -01 state machine.=20 =09 - Issue 85 changes 2&4 - introduce explicit start states for the WTP and the AC. Propose to reject,=20 as a single state with the accompanying text is sufficient =09 - Issue 85 change 5 Proposes 2 config states, one for image version determination, and another for completed initial configuration. Propose to defer here as part of Issue 85, and include any state machine changes related to configuration in the resolution of Issue 108, which addresses configuration as a whole. =09 Comments? =09 Thanks, =09 Dorothy =09 =09 On 3/20/06, David T. Perkins < dperkins@dsperkins.com > wrote:=20 HI, =09 Below is a proposal for an updated state machine: =09 /-------------\ | v | +------------+ | | WTP-start |<---------------------------------------+ | +------------+ | | ^ |a | | | | y | | | | +-------------+------------+ | | | | | | DTLS-rekey | | | | | | +--------->+------------+ | | | | | | |6 ^ | | | V | x V | | | | +--------+--+ +------------+ | | / | | Run |------>| DTLS-Reset |<---|----\ | / | r+-----------+ u +------------+ | | | / | ^ ^ v| | | | | v | | | | | | | +--------------+ | /----/ V | | | | | Discovery | q| k| +-------+ | | | | b+--------------+ +-------------+ | Reset |-+ w | | | |d f| ^ | Configure |<--\ +-------+ | | | | | | +-------------+ | | | |e v | | \----------\ | | +---------+ v |i |2 | | | Sulking | +------------+ +--------------+ +---------+ | | +---------+ | DTLS-Init |--->| DTLS-Complete|--->| Config1 | | | +------------+ z +--------------+ x3 +---------+ | | |h ^ |4 | | | | v o / \ | | +------------+-------/ \-----------------/ |x2 | Image Data | +----------+ +------------+n | AC-Start | x1+----------+ =09 =09 Changes: 1) Removed the "C" in all states 2) Renamed state "Idle" to "WTP start" 3) Removed transition "t" from "Run" to "WTP start(Idle)"=20 4) Added state "AC start" and "x1" and "x2" States: WTP-Start - the "start state" for WTPs AC-Start - the "start state for ACs Transitions: x1 - AC-Start to AC-Start - the AC recieves a Discover=20 request message and responds with a Discovery response message x2 - AC-Start to DTLS-Init - the AC does this transition when it receives a ClientHello from a WTP 5) Added start "Config1", renamed state "Configure" to "Config2",=20 moved transition "2" from "DTLS-Complete" to "Configure" to "Config1" to "Config2", added transition "x3", and moved transition "4" from "DTL-Complete" to "Image Data"=20 to "Config1" to "Image Data". The results are: States: Config1 - image version determination for the WTP Config2 - the "complete" initial configuration of a WTP=20 Transitions: x3 - the DTLS session is established transition to state where the AC determines the WTP physical configuration, and the list of images available on the WTP, and the image that=20 the WTP is running. 2 - The AC determined that the image that the WTP is running is appropriate and proceeds to a state to set the initial configuration of the WTP. 4 - The AC determined that either that the WTP needs=20 a new image, or that the WTP needs to be running a different image. Thus, it proceeds to a state to put (if needed) a new image on the WTP and set it to be used after the WTP resets.=20 =09 Regards, /david t. perkins =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 ------_=_NextPart_001_01C688FD.03AAB33A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
That=20 works for me.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Wednesday, May 24, = 2006 9:29=20 AM
To: David T. Perkins
Cc: = capwap
Subject:=20 [Capwap] Issue 85 - Proposed Resolution/wasRe: Proposal for = updatedState=20 Machine

All,

Issue 85 is listed below.  Apart from the = initial=20 posting, there has been
no follow-up discussion. Issue 85 provided = comments=20 on the draft-00 state machine.

Proposed resolution for Issue=20 85:

- Issue 85 changes 1 and 3
have been incorporated into = the -01=20 state machine.

- Issue 85 changes 2&4 - introduce explicit = start=20 states for the WTP and the AC.  Propose to reject,
as a = single state=20 with the accompanying text is sufficient

- Issue 85 change 5 = Proposes 2=20 config states, one for image version determination, and another
for = completed initial configuration. Propose to defer here as part of = Issue 85,=20 and include any
state machine changes related to configuration in = the=20 resolution of Issue 108, which addresses configuration as a=20 whole.

Comments?

Thanks,

Dorothy

On 3/20/06, David T.=20 Perkins <=20 dperkins@dsperkins.com> wrote:
HI,

Below=20 is a proposal for an updated state machine:

  =20 /-------------\
  =20 = |            = =20 v
   |      =20 +------------+
   |       = |=20 = WTP-start  |<---------------------------------------+
&nb= sp; =20 |      =20 = +------------+          = ;            =             &= nbsp;   =20 |
  =20 = |        ^    = ;|a           &nbs= p;            = ;            =         =20 |
  =20 = |        |    = ;|            = ;            =     y        =         =20 |
  =20 = |        |    = ;|            = ;  +-------------+------------+    |
&nb= sp; =20 = |        |    = ;|            = ;  |          = ;  =20 | DTLS-rekey |    |
  =20 = |        |    = ;|            = ;  |  +--------->+------------+   &= nbsp;|
  =20 = |        |    = ;|            = ;  |  |       &nbs= p;          |6 &nb= sp;      ^
  =20 = |        |    = ;|            = ;  V  |=20 = x            =     V        = =20 |
  =20 = |        |    = ;|        +--------+--+ &nbs= p;    =20 +------------+    |
  =20 |       /    =20 = |        |    = ;Run    |------>|=20 DTLS-Reset |<---|----\
   |    =20 /       = |      =20 r+-----------+     u=20 +------------+    |    =20 |
  =20 = |    /        = ;|            = ;  ^          = ;      ^    =20 v|       |    =20 |
   |  =20 |        =20 = v            =   |          =       |      = |      =20 |     |
   |   = |  =20 +--------------+    =20 = |          /----/ =      =20 V       |    =20 |
   |   |  =20 |  Discovery  =20 = |    q|       &nbs= p;k|          =20 +-------+ |     |
   |  =20 = |  b+--------------+    +-------------+&nbs= p;       |=20 Reset |-+ w   |
   |  =20 |     |d    =20 = f|  ^      |  Configure=   |<--\    +-------+   &n= bsp;  =20 |
   |   |    =20 |      =20 = |  |      +-------------+ &n= bsp;=20 = |            =         |
  =20 |  =20 |e    v      =20 = |  |          = ;            =   \----------\         = |
  =20 = |  +---------+    v  |i &nbs= p;            = ;            =         |2    = ;    |
  =20 |  | Sulking |  =20 = +------------+    +--------------+   &= nbsp;+---------+=20 |
   |  +---------+   |=20 DTLS-Init  |--->| DTLS-Complete|--->| Config1 |=20 |
  =20 = |            =     +------------+=20 z  +--------------+ x3 +---------+ |
  =20 = |            =       =20 = |h  ^         &nbs= p;            = ;        =20 |4         |
   = = |            =       =20 |  =20 = |            =             &= nbsp;     =20 v        o=20 = /
    \       &= nbsp;          | &= nbsp;=20 = |            =         +------------+-------/    =20 \-----------------/  =20 = |x2           &nbs= p;      |=20 Image Data=20 = |
           &n= bsp;           &nb= sp;=20 = +----------+           = = +------------+n
         =             &= nbsp;  =20 | AC-Start=20 = |
           &n= bsp;          =20 x1+----------+


Changes:
1) Removed the "C" in all = states
2)=20 Renamed state "Idle" to "WTP start"
3) Removed transition "t" = from "Run"=20 to "WTP start(Idle)"
4) Added state "AC start" and "x1" and=20 "x2"
   States:
     WTP-Start - = the=20 "start state" for WTPs
     AC-Start - the = "start=20 state for ACs
   = Transitions:
     x1 -=20 AC-Start to AC-Start - the AC recieves a Discover=20 =
          request=20 message and responds with a=20 = Discovery
          = response=20 message
     x2 - AC-Start to DTLS-Init - the = AC does=20 this=20 = transition
          = ;when=20 it receives a ClientHello from a WTP
5) Added start "Config1", = renamed=20 state "Configure" to "Config2",
   moved transition = "2" from=20 "DTLS-Complete" to "Configure"
   to "Config1" to = "Config2",=20 added transition "x3", and
   moved transition "4" from = "DTL-Complete" to "Image Data"
   to "Config1" to = "Image=20 Data". The results are:
   = States:
    =20 Config1 - image version determination for the=20 WTP
     Config2 - the "complete" initial=20 configuration=20 = of
           &= nbsp;  =20 a WTP
   Transitions:
     x3 - = the=20 DTLS session is established transition=20 = to
          state=20 where the AC=20 = determines
          = ;the=20 WTP physical configuration, and the list=20 = of
          images = available on the WTP, and the image that=20
          the = WTP is=20 running.
     2 - The AC determined that the = image=20 that the WTP is
         = running=20 is appropriate and proceeds to a=20 state
         to set the = initial=20 configuration of the WTP.
     4 - The AC = determined=20 that either that the WTP needs=20
         a new image, or = that=20 the WTP needs to be=20 running
         a = different=20 image. Thus, it proceeds to a=20 state
         to put (if = needed)=20 a new image on the WTP=20 and
         set it to be = used=20 after the WTP resets.

Regards,
/david t.=20 = perkins

__________________________________________________________= _______
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20

------_=_NextPart_001_01C688FD.03AAB33A-- --===============1589504453== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1589504453==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 05 20:21:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPKO-0006KA-Cy for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 20:21:48 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPKM-0006Os-PR for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 20:21:48 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 43C11430138 for ; Mon, 5 Jun 2006 17:21:46 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 74E34430085 for ; Mon, 5 Jun 2006 17:21:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5639A1448005 for ; Mon, 5 Jun 2006 17:21:21 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id A12DF1448011 for ; Mon, 5 Jun 2006 17:21:17 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 05 Jun 2006 17:21:17 -0700 X-IronPort-AV: i="4.05,212,1146466800"; d="scan'208"; a="1819730969:sNHT34314896" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k560LGVs022675; Mon, 5 Jun 2006 17:21:16 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k560LGCU006989; Mon, 5 Jun 2006 17:21:16 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Jun 2006 17:21:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Jun 2006 17:21:15 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201FC06DC@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 97: Discovery Type DefinitionInconsistencies Thread-Index: AcZ/ZcRSTtA2aLQASKSLn4tBBq/bIwJmPubQ From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "capwap" X-OriginalArrivalTime: 06 Jun 2006 00:21:16.0621 (UTC) FILETIME=[204727D0:01C688FF] Authentication-Results: sj-dkim-4.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Proposed Resolution to Issue 97: Discovery Type DefinitionInconsistencies X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 I would like to propose something different. How about: The Discovery Type message element is used by the WTP to indicate how it has come to know about the existence of the AC, to which it has sent the Discovery Request. 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Discovery Type| +-+-+-+-+-+-+-+-+ Type: 19 for Discovery Type Length: 1 Discovery Type: An 8-bit value indicating WTP knowledge of the AC The following values are supported: 0 - Unknown 1 - Statically Configured 2 - DHCP 3 - DNS Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com] Sent: Wednesday, May 24, 2006 12:10 PM To: capwap Subject: [Capwap] Proposed Resolution to Issue 97: Discovery Type DefinitionInconsistencies All, Issue 97 is listed below, together with a proposed resolution. Comments please. Thanks, Dorothy ------------- Proposed Resolution: Accept, see 4.4.19, Change from: The Discovery message element is used to configure a WTP to operate in a specific mode. 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Discovery Type| +-+-+-+-+-+-+-+-+ Type: 19 for Discovery Type Length: 1 Discovery Type: An 8-bit value indicating how the AC was discovered. The following values are supported: 0 - Broadcast 1 - Configured to The Discovery Type message element is used to indicate that the WTP has been configured with the AC address to which the corresponding Discovery Request message is sent. 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Discovery Type| +-+-+-+-+-+-+-+-+ Type: 19 for Discovery Type Length: 1 Discovery Type: An 8-bit value indicating WTP knowledge of the AC The following values are supported: 0 - Unknown 1 - Configured Issue 97: Section 5.1.1 Defines the Discovery Type message element. This message element is included in the Discovery Request message, sent by WTPs to discover potential ACs. The current definition is below: The Discovery message element is used to configure a WTP to operate in a specific mode. 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Discovery Type| +-+-+-+-+-+-+-+-+ Type: 58 for Discovery Type Length: 1 Discovery Type: An 8-bit value indicating how the AC was discovered. The following values are supported: 0 - Broadcast 1 - Configured Comments: 1. The statement that " The Discovery message element is used to configure a WTP to operate in a specific mode." seems inconsistent with its inclusion in the Discovery Request message. 2. Discovery Type: An 8-bit value indicating how the AC was discovered. - The AC hasn't been discovered yet. Does this mean the mode - unicast, broadcast/multi-cast in which the discovery request message was sent? Must the WTP be either configured with the AC address, or find the address on its own? Seems like this would be part of WTP configuration, rather than being included in the discovery request message. 3. What is the purpose/value of including "Discovery Type"? Either define consistently, or delete it Do we mean the following? The Discovery Type message element is used to indicate that the WTP has been configured with the AC address to which the corresponding Discovery Request message is sent. 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Discovery Type| +-+-+-+-+-+-+-+-+ Type: 58 for Discovery Type Length: 1 Discovery Type: An 8-bit value indicating WTP knowledge of the AC The following values are supported: 0 - Unknown 1 - Configured _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 05 20:23:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPLb-0007b9-S7 for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 20:23:03 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPLa-0006S8-RW for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 20:23:03 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6D08A43011D for ; Mon, 5 Jun 2006 17:23:02 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id EB599430085 for ; Mon, 5 Jun 2006 17:22:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DBB7C1448013 for ; Mon, 5 Jun 2006 17:22:23 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by hermes.tigertech.net (Postfix) with ESMTP id C9C491448005 for ; Mon, 5 Jun 2006 17:22:20 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 05 Jun 2006 17:22:20 -0700 X-IronPort-AV: i="4.05,212,1146466800"; d="scan'208,217"; a="429909041:sNHT56885352" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k560MJLa002269; Mon, 5 Jun 2006 17:22:19 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k560MJ9s028876; Mon, 5 Jun 2006 17:22:19 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Jun 2006 17:22:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Jun 2006 17:22:18 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201FC06DD@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 97: Discovery TypeDefinition Inconsistencies Thread-Index: AcaAAhyRShD+kfRIRjKvKvJjqrogAAI/SQOQ From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "David T. Perkins" X-OriginalArrivalTime: 06 Jun 2006 00:22:19.0497 (UTC) FILETIME=[45C14590:01C688FF] Authentication-Results: sj-dkim-3.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_30_40, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Proposed Resolution to Issue 97: Discovery TypeDefinition Inconsistencies X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0369791341==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: efb5d987e2484f3d9a304cc31a003441 This is a multi-part message in MIME format. --===============0369791341== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C688FF.458646A0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C688FF.458646A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Dorothy's proposal. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Thursday, May 25, 2006 6:46 AM To: David T. Perkins Cc: capwap Subject: Re: [Capwap] Proposed Resolution to Issue 97: Discovery TypeDefinition Inconsistencies =09 =09 David, =09 The scope of Issue 97 is terminology related to one message element used in the discovery process, and appears to make the language clearer, and internally consistent with what is currently in the document. =09 I suggest that a new issue along the lines of "Boot Model Incomplete" be opened to cover the broader boot model definition that you are raising. =09 Dorothy =09 =09 On 5/24/06, David T. Perkins wrote:=20 HI, =09 I think that this problem description and proposed resolution are premature. A complete description and solution is needed on the boot process. I feel that the current draft is not there yet, since the model is not well described.=20 =09 I've been working on my prototype code using the DTLS implemention from the OpenSSL project, and haven't yet sent in an updated description for a proposed CAPWAP boot model. I do apologize. I'll try to juggle priorities to make this happen.=20 =09 Regards, /david t. perkins =09 On Wed, 24 May 2006, Dorothy Stanley wrote: > All, > > Issue 97 is listed below, together with a proposed resolution. > > Comments please. >=20 > Thanks, > > Dorothy > ------------- > > Proposed Resolution: Accept, see 4.4.19, > > Change from: > > The Discovery message element is used to configure a WTP to operate in a=20 > specific mode. > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > | Discovery Type| > +-+-+-+-+-+-+-+-+ > > Type: 19 for Discovery Type > > Length: 1 > Discovery Type: An 8-bit value indicating how the AC was discovered.=20 > The following values are supported: > 0 - Broadcast > 1 - Configured > > to > > The Discovery Type message element is used to indicate that the WTP has been > configured with the AC address=20 > to which the corresponding Discovery Request message is sent. > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > | Discovery Type| > +-+-+-+-+-+-+-+-+ > > Type: 19 for Discovery Type=20 > > Length: 1 > Discovery Type: An 8-bit value indicating WTP knowledge of the AC > The following values are supported: > 0 - Unknown > 1 - Configured > > > >=20 > > > > > > > > > Issue 97: > > Section 5.1.1 Defines the Discovery Type message element. This message element > is included in the > Discovery Request message, sent by WTPs to discover potential ACs.=20 > > The current definition is below: > > The Discovery message element is used to configure a WTP to operate in a > specific mode. > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+=20 > | Discovery Type| > +-+-+-+-+-+-+-+-+ > > Type: 58 for Discovery Type > > Length: 1 > Discovery Type: An 8-bit value indicating how the AC was discovered. > The following values are supported:=20 > 0 - Broadcast > 1 - Configured > > Comments: > 1. The statement that " The Discovery message element is used to configure a WTP > to operate in a specific mode." seems inconsistent=20 > with its inclusion in the Discovery Request message. > 2. Discovery Type: An 8-bit value indicating how the AC was discovered. - The AC > hasn't been discovered yet. Does this mean the mode - unicast,=20 > broadcast/multi-cast > in which the discovery request message was sent? Must the WTP be either > configured with the AC address, or find the address on its own? Seems like this > would be part of WTP configuration, rather than being included in the discovery=20 > request message. > 3. What is the purpose/value of including "Discovery Type"? Either define > consistently, or delete it > > Do we mean the following? > > > The Discovery Type message element is used to indicate that the WTP has been=20 > configured with the AC address > to which the corresponding Discovery Request message is sent. > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > | Discovery Type| > +-+-+-+-+-+-+-+-+=20 > > Type: 58 for Discovery Type > > Length: 1 > Discovery Type: An 8-bit value indicating WTP knowledge of the AC > The following values are supported: > 0 - Unknown > 1 - Configured=20 > =09 =09 ------_=_NextPart_001_01C688FF.458646A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 agree with Dorothy's proposal.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Thursday, May 25, = 2006 6:46=20 AM
To: David T. Perkins
Cc: = capwap
Subject: Re:=20 [Capwap] Proposed Resolution to Issue 97: Discovery TypeDefinition=20 Inconsistencies

David,

The scope of Issue 97 is terminology related = to one=20 message
element used in the discovery process, and appears to make=20 the
language clearer, and internally consistent with what is = currently in=20 the
document.

I suggest that a new issue along the lines = of
"Boot=20 Model Incomplete" be opened to cover the broader
boot model = definition that=20 you are raising.

Dorothy

On 5/24/06, David T.=20 Perkins <dperkins@dsperkins.com>=20 wrote:
HI,

I=20 think that this problem description and proposed resolution=20 are
premature. A complete description and solution is needed on=20 the
boot process. I feel that the current draft is not there=20 yet,
since the model is not well described.

I've been = working on=20 my prototype code using the DTLS implemention
from the OpenSSL = project,=20 and haven't yet sent in an updated
description for a proposed = CAPWAP boot=20 model. I do apologize.
I'll try to juggle priorities to make this = happen.=20

Regards,
/david t. perkins

On Wed, 24 May 2006, = Dorothy=20 Stanley wrote:
> All,
>
> Issue 97 is listed = below,=20 together with a proposed resolution.
>
> Comments=20 please.
>
> Thanks,
>
> Dorothy
>=20 -------------
>
> Proposed Resolution: Accept, see=20 4.4.19,
>
> Change from:
>
> The Discovery = message=20 element is used to configure a WTP to operate in a
> specific = mode.
>  0
>  0 1 2 3 4 5 6 = 7
>=20 +-+-+-+-+-+-+-+-+
>  | Discovery=20 Type|
>  +-+-+-+-+-+-+-+-+
>
> Type: 19 = for=20 Discovery Type
>
>  Length: 1
> = Discovery Type:=20 An 8-bit value indicating how the AC was discovered.
> The = following=20 values are supported:
>  0 - Broadcast
> 1 -=20 Configured
>
> to
>
> The Discovery Type = message=20 element is used to indicate that the WTP has been
> configured = with=20 the AC address
> to which the corresponding Discovery Request = message=20 is sent.
>  0
>  0 1 2 3 4 5 6 = 7
>=20 +-+-+-+-+-+-+-+-+
>  | Discovery=20 Type|
>  +-+-+-+-+-+-+-+-+
>
> Type: 19 = for=20 Discovery Type
>
>  Length: 1
> = Discovery Type:=20 An 8-bit value indicating WTP knowledge of the AC
> The = following=20 values are supported:
>  0 - Unknown
> 1=20 -  Configured
>
>
>
>=20 =
>
>
>
>
>
>
>
>
> = Issue 97:
>
> Section 5.1.1 Defines the Discovery Type = message=20 element. This message element
> is included in the
> = Discovery=20 Request message, sent by WTPs to discover potential ACs. =
>
>=20 The current definition is below:
>
> The Discovery = message=20 element is used to configure a WTP to operate in a
> specific=20 mode.
>  0
>  0 1 2 3 4 5 6 = 7
>=20 +-+-+-+-+-+-+-+-+
>  | Discovery=20 Type|
>  +-+-+-+-+-+-+-+-+
>
> Type: 58 = for=20 Discovery Type
>
>  Length: 1
> = Discovery Type:=20 An 8-bit value indicating how the AC was discovered.
> The = following=20 values are supported:
>  0 - Broadcast
> 1 -=20 Configured
>
> Comments:
> 1. The statement that " = The=20 Discovery message element is used to configure a WTP
> to = operate in a=20 specific mode." seems inconsistent
> with its inclusion in = the=20 Discovery Request message.
> 2. Discovery Type: An 8-bit value = indicating how the AC was discovered. - The AC
> hasn't been=20 discovered yet. Does this mean the mode - unicast,
>=20 broadcast/multi-cast
> in which the discovery request message = was=20 sent? Must the WTP be either
> configured with the AC address, = or find=20 the address on its own? Seems like this
> would be part of WTP = configuration, rather than being included in the discovery
> = request=20 message.
> 3. What is the purpose/value of including = "Discovery Type"?=20 Either define
> consistently, or delete it
>
> Do = we mean=20 the following?
>
>
> The Discovery Type message = element is=20 used to indicate that the WTP has been
> configured with the = AC=20 address
> to which the corresponding Discovery Request message = is=20 sent.
>  0
>  0 1 2 3 4 5 6 = 7
>=20 +-+-+-+-+-+-+-+-+
>  | Discovery=20 Type|
>  +-+-+-+-+-+-+-+-+
>
> Type: 58 = for=20 Discovery Type
>
>  Length: 1
> = Discovery Type:=20 An 8-bit value indicating WTP knowledge of the AC
> The = following=20 values are supported:
>  0 - Unknown
> 1=20 -  Configured=20
>


------_=_NextPart_001_01C688FF.458646A0-- --===============0369791341== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0369791341==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 05 20:28:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPQY-0008QH-0U for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 20:28:10 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPQX-0006Yo-1s for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 20:28:09 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9D767430113 for ; Mon, 5 Jun 2006 17:28:08 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 812824300CC for ; Mon, 5 Jun 2006 17:27:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 698E51448018 for ; Mon, 5 Jun 2006 17:27:32 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id 55D251448013 for ; Mon, 5 Jun 2006 17:27:30 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 05 Jun 2006 17:27:30 -0700 X-IronPort-AV: i="4.05,212,1146466800"; d="scan'208,217"; a="1819734579:sNHT56560552" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k560RTrP007225; Mon, 5 Jun 2006 17:27:29 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k560RTCU012116; Mon, 5 Jun 2006 17:27:29 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Jun 2006 17:27:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Jun 2006 17:27:28 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201FC06E4@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Rsolution Issue 81: Minor edits and questionsCAPWAP Protocol specification Thread-Index: AcaAMX+vQHbMrcP5Ql29BvQ0ZqYeiwIzmEBQ From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "capwap" X-OriginalArrivalTime: 06 Jun 2006 00:27:29.0680 (UTC) FILETIME=[FEA37100:01C688FF] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_40_50, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Proposed Rsolution Issue 81: Minor edits and questionsCAPWAP Protocol specification X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0053874761==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: bfef20db74c24e87b6dbcd42ea7ba67c This is a multi-part message in MIME format. --===============0053874761== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C688FF.FE7048E6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C688FF.FE7048E6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dorothy, =20 My comments (using your numbering below). 1. ok with change 2. How would a WTP communicate that it is capable of providing local bridging services to the AC? 3. ok with change =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Thursday, May 25, 2006 12:28 PM To: capwap Subject: [Capwap] Proposed Rsolution Issue 81: Minor edits and questionsCAPWAP Protocol specification =09 =09 All, =09 The proposed resolution to Issue 81 is listed below.=20 =09 Comments welcome. =09 Thanks, =09 Dorothy =09 ------------------------------------------------------------------------ ---------- =09 Issue 81: =09 Very Readable -- some minor comments =09 Page 33 -- Section 5.1 -- 5th paragraph =09 If a Discovery Response .... equal to SilentInterval before sending further=20 Discovery Request messages. =09 change to =09 =09 If a Discovery Response .... equal to SilentInterval before returning to the=20 ide stand and sending further Discovery Request messages. =09 =09 Section 5.1.5 WTP Frame Type -- Page 37 - Local Bridging =09 =09 What do the frames look like -- do not understand what is sent or received. =09 =09 Page 51 -- Top of Page -- Secton 7.3.2 =09 cause repeated twice -- delete 1st reference 1. Page 33, Section 5.1 is the Discovery Request Message definition =09 The proposed change is to the following text: =09 If a Discovery Response message is not received after sending the maximum number of Discovery Request messages, the WTP enters the Sulking state and MUST wait for an interval equal to SilentInterval before sending further Discovery Request messages. =09 Proposed resolution: In the -01 state machine, the WTP remains in the Discover state whle determining which AC to send the Join Request message to, see the description of state (b), Discovery to Discovery. Reject the proposed change. =09 2. Section 5.1.4, WTP Frame Type is now section 4.4.36,=20 WTP Frame Encapsulation Type, copied below. It is unclear why local bridging is listed as a frame type/eccapsulation type. =09 Recommended change: =09 Change from: =09 4.4.36. WTP Frame Encapsulation Type =09 The WTP Frame EncapsultationType message element allows the WTP to communicate the encapsulation type, or tunneling modes of operation which it supports to the AC. A WTP that advertises support for all types allows the AC to select which type will be used, based on its local policy. =09 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Frame Enc Type | +-+-+-+-+-+-+-+-+ =09 Type: 36 for WTP Frame Encapsulation Type =09 Length: 1 =09 Frame Encapsulation Type: The Frame type specifies the encapsulation modes supported by the WTP. The following values are supported: =09 1 - Local Bridging: Local Bridging allows the WTP to perform the bridging function. This value MUST NOT be used when the WTP MAC Type is set to Split-MAC. =09 2 - 802.3 Bridging: 802.3 Bridging requires the WTP and AC to encapsulate all user payload as native IEEE 802.3 frames (see Section 4.2). This value MUST NOT be used when the WTP MAC Type is set to Split-MAC. =09 4 - Native Bridging: Native Bridging requires the WTP and AC to encapsulate all user payloads as native wireless frames, as defined by the wireless binding (see Section 4.2). =09 7 - All: The WTP is capable of supporting all frame encapsulation types. =09 To: =09 4.4.36. WTP Frame Encapsulation Type =09 The WTP Frame EncapsultationType message element allows the WTP to communicate the encapsulation type, or tunneling modes of operation which it supports to the AC. A WTP that advertises support for all types allows the AC to select which type will be used, based on its local policy. =09 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Frame Enc Type | +-+-+-+-+-+-+-+-+ =09 Type: 36 for WTP Frame Encapsulation Type =09 Length: 1 =09 Frame Encapsulation Type: The Frame type specifies the encapsulation modes supported by the WTP. The following values are supported: =09 1 - 802.3 Encapsulation: 802.3 Bridging requires the WTP and AC to encapsulate all user payload as native IEEE 802.3 frames (see Section 4.2). This value MUST NOT be used when the WTP MAC Type is set to Split-MAC. =09 2 - Native Encapsulation: Native Bridging requires the WTP and AC to encapsulate all user payloads as native wireless frames, as defined by the wireless binding (see Section 4.2). =09 3 - All: The WTP is capable of supporting both frame encapsulation types. =09 =09 3. Change State Event, now 4.4.11 - the first "case" reference, (duplicate text) has been deleted in draft -01. =09 =09 =09 ------_=_NextPart_001_01C688FF.FE7048E6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dorothy,
 
My=20 comments (using your numbering below).
1. ok=20 with change
2. How=20 would a WTP communicate that it is capable of providing local bridging = services=20 to the AC?
3. ok=20 with change
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Thursday, May 25, = 2006 12:28=20 PM
To: capwap
Subject: [Capwap] Proposed Rsolution = Issue=20 81: Minor edits and questionsCAPWAP Protocol=20 specification

All,

The proposed resolution to Issue 81 is listed = below.=20

Comments=20 = welcome.

Thanks,

Dorothy
-------------------------------= ---------------------------------------------------

Issue=20 81:
Very Readable -- some minor comments

Page 33 -- =
Section 5.1 -- 5th paragraph

If a Discovery Response .... equal =
to SilentInterval before sending further 
Discovery Request =
messages.

change to


If a Discovery Response .... equal to SilentInterval before =
returning to the 
ide stand and sending further Discovery Request =
messages.


Section 5.1.5 WTP Frame Type -- Page 37 - Local =
Bridging


What do the frames look like -- do not understand what is sent or =
received.


Page 51 -- Top of Page -- Secton 7.3.2

cause =
repeated twice -- delete 1st reference

1.=20 Page 33, Section 5.1 is the Discovery Request Message = definition

The=20 proposed change is to the following text:

   If a = Discovery=20 Response message is not received after sending the
   = maximum=20 number of Discovery Request messages, the WTP enters = the
  =20 Sulking state and MUST wait for an interval equal to=20 SilentInterval
   before sending further Discovery = Request=20 messages.

Proposed resolution: In the -01 state machine, the = WTP=20 remains
in the Discover state whle determining which AC to send the = Join=20 Request
message to, see the description of state (b), Discovery to=20 Discovery.
Reject the proposed change.

2. Section 5.1.4, WTP = Frame=20 Type is now section 4.4.36,
WTP Frame Encapsulation Type, copied = below. It=20 is unclear
why local bridging is listed as a frame = type/eccapsulation=20 type.

Recommended change:

Change = from:

4.4.36.  WTP=20 Frame Encapsulation Type

   The WTP Frame = EncapsultationType=20 message element allows the WTP to
   communicate the=20 encapsulation type, or tunneling modes of operation
   = which it=20 supports to the AC.  A WTP that advertises support for=20 all
   types allows the AC to select which type will be = used,=20 based on its
   local=20 policy.

     =20 0
      0 1 2 3 4 5 6=20 7
     = +-+-+-+-+-+-+-+-+
    =20 |Frame Enc Type  |
    =20 +-+-+-+-+-+-+-+-+

   Type:  36 for WTP Frame=20 Encapsulation Type

   Length:  = 1

  =20 Frame Encapsulation Type:  The Frame type specifies the=20 encapsulation
      modes supported by the = WTP.  The following values are=20 supported:

      1 - Local = Bridging: =20 Local Bridging allows the WTP to perform=20 the
         bridging=20 function.  This value MUST NOT be used when the=20 WTP
         MAC Type is = set to=20 Split-MAC.

      2 - 802.3 = Bridging: =20 802.3 Bridging requires the WTP and AC=20 to
         encapsulate all = user=20 payload as native IEEE 802.3 frames=20 (see
         Section = 4.2). =20 This value MUST NOT be used when the WTP=20 MAC
         Type is set to = Split-MAC.

      4 - Native = Bridging: =20 Native Bridging requires the WTP and AC=20 to
         encapsulate all = user=20 payloads as native wireless frames,=20 as
         defined by the = wireless=20 binding (see Section 4.2).

      7 -=20 All:  The WTP is capable of supporting all frame=20 encapsulation
        =20 types.

To:

4.4.36.  WTP Frame Encapsulation=20 Type

   The WTP Frame EncapsultationType message = element=20 allows the WTP to
   communicate the encapsulation type, = or=20 tunneling modes of operation
   which it supports to the=20 AC.  A WTP that advertises support for all
   types = allows=20 the AC to select which type will be used, based on its
   = local=20 policy.

     =20 0
      0 1 2 3 4 5 6=20 7
     = +-+-+-+-+-+-+-+-+
    =20 |Frame Enc Type  |
    =20 +-+-+-+-+-+-+-+-+

   Type:  36 for WTP Frame=20 Encapsulation Type

   Length:  = 1

  =20 Frame Encapsulation Type:  The Frame type specifies the=20 encapsulation
      modes supported by the = WTP.  The following values are=20 supported:

      1 - 802.3=20 Encapsulation:  802.3 Bridging requires the WTP and AC=20 to
         encapsulate all = user=20 payload as native IEEE 802.3 frames=20 (see
         Section = 4.2). =20 This value MUST NOT be used when the WTP=20 MAC
         Type is set to = Split-MAC.

      2 - Native=20 Encapsulation:  Native Bridging requires the WTP and AC=20 to
         encapsulate all = user=20 payloads as native wireless frames,=20 as
         defined by the = wireless=20 binding (see Section 4.2).

      3 -=20 All:  The WTP is capable of supporting both frame=20 encapsulation
        =20 types.


3. Change State Event, now 4.4.11 - the first "case" = reference, (duplicate
text) has been deleted in draft=20 -01.


------_=_NextPart_001_01C688FF.FE7048E6-- --===============0053874761== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0053874761==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 05 20:38:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPa6-000587-Mt for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 20:38:02 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPa5-0008G9-5S for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 20:38:02 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4FA8443014A for ; Mon, 5 Jun 2006 17:38:00 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 41D4D4300CC for ; Mon, 5 Jun 2006 17:37:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1C9DE1448005 for ; Mon, 5 Jun 2006 17:37:35 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6B8391448013 for ; Mon, 5 Jun 2006 17:37:33 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k560bWDZ028724; Mon, 5 Jun 2006 17:37:32 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k560bWGo028720; Mon, 5 Jun 2006 17:37:32 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Mon, 5 Jun 2006 17:37:31 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201FC06DC@xmb-sjc-235.amer.cisco.com> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Proposed Resolution to Issue 97: Discovery Type DefinitionInconsistencies X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 HI, In addition to the below, I would add the following: 4 - AC downloaded a new image and rebooted the WTP 5 - AC reset the WTP 6 - AC provided this referral 7 - AC was connected, but session was lost That is (except for 6), there is a set of values that indicate that a WTP was connected to an AC, but an operation or event caused the DTLS session to be terminated (and maybe the WTP process/device restarted). The WTP wants to "fast trace" a reconnection to the AC without going through the complete discovery (because this can take lots of time), with possibly reusing cached DTLS session state. Did I get all of the operations and events? Regards, /david t. perkins On Mon, 5 Jun 2006, Pat Calhoun (pacalhou) wrote: > I would like to propose something different. How about: > > > The Discovery Type message element is used by the WTP to indicate how > it has come to know about the existence of the AC, to which it has sent > the Discovery Request. > > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > | Discovery Type| > +-+-+-+-+-+-+-+-+ > > Type: 19 for Discovery Type > > Length: 1 > > Discovery Type: An 8-bit value indicating WTP knowledge of the AC > The following values are supported: > 0 - Unknown > 1 - Statically Configured > 2 - DHCP > 3 - DNS > > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > ________________________________ > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > Sent: Wednesday, May 24, 2006 12:10 PM > To: capwap > Subject: [Capwap] Proposed Resolution to Issue 97: Discovery > Type DefinitionInconsistencies > > > All, > > Issue 97 is listed below, together with a proposed resolution. > > Comments please. > > Thanks, > > Dorothy > ------------- > > Proposed Resolution: Accept, see 4.4.19, > > Change from: > > > The Discovery message element is used to configure a WTP to > operate in a > specific mode. > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > | Discovery Type| > +-+-+-+-+-+-+-+-+ > > Type: 19 for Discovery Type > > > Length: 1 > Discovery Type: An 8-bit value indicating how the AC was > discovered. > The following values are supported: > 0 - Broadcast > 1 - Configured > > to > > The Discovery Type message element is used to indicate that the > WTP has been > > configured with the AC address > to which the corresponding Discovery Request message is sent. > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > | Discovery Type| > +-+-+-+-+-+-+-+-+ > > Type: 19 for Discovery Type > > > Length: 1 > Discovery Type: An 8-bit value indicating WTP knowledge of the > AC > The following values are supported: > 0 - Unknown > 1 - Configured > > > > > > > > > > > > > Issue 97: > > Section 5.1.1 Defines the Discovery Type message element. This > message element > is included in the > Discovery Request message, sent by WTPs to discover potential > ACs. > > The current definition is below: > > > The Discovery message element is used to configure a WTP to > operate in a > specific mode. > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > | Discovery Type| > +-+-+-+-+-+-+-+-+ > > Type: 58 for Discovery Type > > > Length: 1 > Discovery Type: An 8-bit value indicating how the AC was > discovered. > The following values are supported: > 0 - Broadcast > 1 - Configured > > Comments: > 1. The statement that " The Discovery message element is used to > configure a WTP > > to operate in a specific mode." seems inconsistent > with its inclusion in the Discovery Request message. > 2. Discovery Type: An 8-bit value indicating how the AC was > discovered. - The AC > hasn't been discovered yet. Does this mean the mode - unicast, > broadcast/multi-cast > > in which the discovery request message was sent? Must the WTP be > either > configured with the AC address, or find the address on its own? > Seems like this > would be part of WTP configuration, rather than being included > in the discovery > > request message. > 3. What is the purpose/value of including "Discovery Type"? > Either define > consistently, or delete it > > Do we mean the following? > > > The Discovery Type message element is used to indicate that the > WTP has been > > configured with the AC address > to which the corresponding Discovery Request message is sent. > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > | Discovery Type| > +-+-+-+-+-+-+-+-+ > > Type: 58 for Discovery Type > > > Length: 1 > Discovery Type: An 8-bit value indicating WTP knowledge of the > AC > The following values are supported: > 0 - Unknown > 1 - Configured > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 05 20:39:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPbs-0005VO-Sk for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 20:39:52 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPbr-0000OE-7p for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 20:39:52 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D2671430109 for ; Mon, 5 Jun 2006 17:39:50 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 0C1B54300CC for ; Mon, 5 Jun 2006 17:39:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id F4210398008 for ; Mon, 5 Jun 2006 17:39:20 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1C1BF398039 for ; Mon, 5 Jun 2006 17:39:18 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 05 Jun 2006 17:39:17 -0700 X-IronPort-AV: i="4.05,212,1146466800"; d="scan'208,217"; a="289253217:sNHT143089496" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k560dHcS005322; Mon, 5 Jun 2006 17:39:17 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k560dH9s011291; Mon, 5 Jun 2006 17:39:17 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Jun 2006 17:39:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Jun 2006 17:39:07 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201FC06F6@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 63 - Are all fields in the IEEE 802.11 Add Mobilerequired for Local Mac Thread-Index: AcaAR4PoW9+BPKDBQzGZ46HlNUdf8AIuYytQ From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "capwap" X-OriginalArrivalTime: 06 Jun 2006 00:39:08.0687 (UTC) FILETIME=[9F4771F0:01C68901] Authentication-Results: sj-dkim-4.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.548 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE, NORMAL_HTTP_TO_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Issue 63 - Are all fields in the IEEE 802.11 Add Mobilerequired for Local Mac X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0219786119==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 This is a multi-part message in MIME format. --===============0219786119== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68901.9F17FD1A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68901.9F17FD1A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Thursday, May 25, 2006 3:06 PM To: capwap Subject: [Capwap] Issue 63 - Are all fields in the IEEE 802.11 Add Mobilerequired for Local Mac =09 =09 All, =09 Issue 63 is listed below: =09 > Page 96, Section 11.7.1.1. Is all of this information=20 > required for Add Mobile in the local MAC case? Section 11.7.1.1 of draft -00 is now section 11.10.11 in draft -01, and includes the following fields: =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Association ID | Flags | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Capabilities | WLAN ID |Supported Rates =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 Radio ID: An 8-bit value representing the radio =09 Association ID: A 16-bit value specifying the IEEE 802.11 Association Identifier =09 Flags: The Flags field MUST be set to zero =09 Capabilities: A 16-bit field containing the IEEE 802.11 capabilities to use with the mobile. =09 WLAN ID: An 8-bit value specifying the WLAN Identifier =09 Supported Rates: The variable length field containing the supported rates to be used with the mobile station. =09 =09 The commenter is asking if all of the fields are needed in the Local MAC case.=20 =09 Proposed resolution: Yes, all fields are required. =09 Comments please. =09 Thanks, =09 Dorothy =09 ------_=_NextPart_001_01C68901.9F17FD1A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 agree.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Thursday, May 25, = 2006 3:06=20 PM
To: capwap
Subject: [Capwap] Issue 63 - Are all = fields=20 in the IEEE 802.11 Add Mobilerequired for Local = Mac

All,

Issue 63 is listed below:
> Page 96, =
Section 11.7.1.1. Is all of this =
information 
> required for Add Mobile in the local MAC =
case?
Section=20 11.7.1.1 of draft -00 is now section = 11.10.11 in=20 draft -01, and includes the = following
fields:
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |    Radio ID  =20 |        Association=20 ID         = |    =20 Flags     |
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |         =20 Capabilities         = |  =20 WLAN ID     |Supported = Rates
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=   =20 Radio ID:  An 8-bit value representing the = radio

  =20 Association ID:  A 16-bit value specifying the IEEE=20 802.11
      Association=20 Identifier

   Flags:  The Flags field MUST be = set to=20 zero

   Capabilities:  A 16-bit field containing = the=20 IEEE 802.11 capabilities
      to use with = the=20 mobile.

   WLAN ID:  An 8-bit value specifying = the WLAN=20 Identifier

   Supported Rates:  The variable = length=20 field containing the supported
      rates = to be=20 used with the mobile station.


The commenter is asking if = all of the=20 fields are needed in the
Local MAC case.

Proposed = resolution: =20 Yes, all fields are required.

Comments=20 please.

Thanks,

Dorothy
------_=_NextPart_001_01C68901.9F17FD1A-- --===============0219786119== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0219786119==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 05 20:52:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPnv-0006up-0O for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 20:52:19 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPnu-0001sh-9D for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 20:52:18 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DB55B43013A for ; Mon, 5 Jun 2006 17:52:17 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 973BB4300FE for ; Mon, 5 Jun 2006 17:51:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7C20D1448007 for ; Mon, 5 Jun 2006 17:51:52 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id 975B51448013 for ; Mon, 5 Jun 2006 17:51:50 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 05 Jun 2006 17:51:50 -0700 X-IronPort-AV: i="4.05,212,1146466800"; d="scan'208"; a="289258405:sNHT35771900" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k560pnwG003469; Mon, 5 Jun 2006 17:51:49 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k560pnCU023415; Mon, 5 Jun 2006 17:51:49 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Jun 2006 17:51:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Jun 2006 17:51:48 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201FC06FE@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 97: Discovery Type DefinitionInconsistencies Thread-Index: AcaJAWk32sRP+57VQpSEBIfFsNxXJAAAewPg From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" X-OriginalArrivalTime: 06 Jun 2006 00:51:49.0724 (UTC) FILETIME=[64E479C0:01C68903] Authentication-Results: sj-dkim-1.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Proposed Resolution to Issue 97: Discovery Type DefinitionInconsistencies X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Actually, I believe that #6 is valid. However, I think the other types proposed by David really belong in the "WTP Reboot Statistics" message element. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Monday, June 05, 2006 5:38 PM > To: Pat Calhoun (pacalhou) > Cc: Dorothy Stanley; capwap > Subject: Re: [Capwap] Proposed Resolution to Issue 97: > Discovery Type DefinitionInconsistencies > > HI, > > In addition to the below, I would add the following: > 4 - AC downloaded a new image and rebooted the WTP > 5 - AC reset the WTP > 6 - AC provided this referral > 7 - AC was connected, but session was lost > > That is (except for 6), there is a set of values that > indicate that a WTP was connected to an AC, but an operation > or event caused the DTLS session to be terminated (and maybe > the WTP process/device restarted). The WTP wants to "fast > trace" a reconnection to the AC without going through the > complete discovery (because this can take lots of time), with > possibly reusing cached DTLS session state. > > Did I get all of the operations and events? > > Regards, > /david t. perkins > > On Mon, 5 Jun 2006, Pat Calhoun (pacalhou) wrote: > > I would like to propose something different. How about: > > > > > > The Discovery Type message element is used by the WTP to > indicate how > > it has come to know about the existence of the AC, to which it has > > sent the Discovery Request. > > > > 0 > > 0 1 2 3 4 5 6 7 > > +-+-+-+-+-+-+-+-+ > > | Discovery Type| > > +-+-+-+-+-+-+-+-+ > > > > Type: 19 for Discovery Type > > > > Length: 1 > > > > Discovery Type: An 8-bit value indicating WTP knowledge of > the AC The > > following values are supported: > > 0 - Unknown > > 1 - Statically Configured > > 2 - DHCP > > 3 - DNS > > > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > ________________________________ > > > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > > Sent: Wednesday, May 24, 2006 12:10 PM > > To: capwap > > Subject: [Capwap] Proposed Resolution to Issue 97: > Discovery Type > > DefinitionInconsistencies > > > > > > All, > > > > Issue 97 is listed below, together with a proposed resolution. > > > > Comments please. > > > > Thanks, > > > > Dorothy > > ------------- > > > > Proposed Resolution: Accept, see 4.4.19, > > > > Change from: > > > > > > The Discovery message element is used to configure a > WTP to operate > > in a > > specific mode. > > 0 > > 0 1 2 3 4 5 6 7 > > +-+-+-+-+-+-+-+-+ > > | Discovery Type| > > +-+-+-+-+-+-+-+-+ > > > > Type: 19 for Discovery Type > > > > > > Length: 1 > > Discovery Type: An 8-bit value indicating how the AC > was discovered. > > The following values are supported: > > 0 - Broadcast > > 1 - Configured > > > > to > > > > The Discovery Type message element is used to indicate > that the WTP > > has been > > > > configured with the AC address > > to which the corresponding Discovery Request message is sent. > > 0 > > 0 1 2 3 4 5 6 7 > > +-+-+-+-+-+-+-+-+ > > | Discovery Type| > > +-+-+-+-+-+-+-+-+ > > > > Type: 19 for Discovery Type > > > > > > Length: 1 > > Discovery Type: An 8-bit value indicating WTP knowledge > of the AC > > The following values are supported: > > 0 - Unknown > > 1 - Configured > > > > > > > > > > > > > > > > > > > > > > > > > > Issue 97: > > > > Section 5.1.1 Defines the Discovery Type message element. This > > message element > > is included in the > > Discovery Request message, sent by WTPs to discover > potential ACs. > > > > The current definition is below: > > > > > > The Discovery message element is used to configure a > WTP to operate > > in a > > specific mode. > > 0 > > 0 1 2 3 4 5 6 7 > > +-+-+-+-+-+-+-+-+ > > | Discovery Type| > > +-+-+-+-+-+-+-+-+ > > > > Type: 58 for Discovery Type > > > > > > Length: 1 > > Discovery Type: An 8-bit value indicating how the AC > was discovered. > > The following values are supported: > > 0 - Broadcast > > 1 - Configured > > > > Comments: > > 1. The statement that " The Discovery message element > is used to > > configure a WTP > > > > to operate in a specific mode." seems inconsistent > > with its inclusion in the Discovery Request message. > > 2. Discovery Type: An 8-bit value indicating how the AC was > > discovered. - The AC > > hasn't been discovered yet. Does this mean the mode - unicast, > > broadcast/multi-cast > > > > in which the discovery request message was sent? Must > the WTP be > > either > > configured with the AC address, or find the address on its own? > > Seems like this > > would be part of WTP configuration, rather than being > included in the > > discovery > > > > request message. > > 3. What is the purpose/value of including "Discovery Type"? > > Either define > > consistently, or delete it > > > > Do we mean the following? > > > > > > The Discovery Type message element is used to indicate > that the WTP > > has been > > > > configured with the AC address > > to which the corresponding Discovery Request message is sent. > > 0 > > 0 1 2 3 4 5 6 7 > > +-+-+-+-+-+-+-+-+ > > | Discovery Type| > > +-+-+-+-+-+-+-+-+ > > > > Type: 58 for Discovery Type > > > > > > Length: 1 > > Discovery Type: An 8-bit value indicating WTP knowledge > of the AC > > The following values are supported: > > 0 - Unknown > > 1 - Configured > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 05 20:55:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPqs-0008Ml-6k for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 20:55:22 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPqq-0002I4-MP for capwap-archive@lists.ietf.org; Mon, 05 Jun 2006 20:55:22 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5222E430109 for ; Mon, 5 Jun 2006 17:55:20 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4181B4300CC for ; Mon, 5 Jun 2006 17:54:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 27C34398008 for ; Mon, 5 Jun 2006 17:54:43 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by zoidberg.tigertech.net (Postfix) with ESMTP id 600BE39801D for ; Mon, 5 Jun 2006 17:54:40 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 05 Jun 2006 17:54:41 -0700 X-IronPort-AV: i="4.05,212,1146466800"; d="scan'208"; a="429911606:sNHT33112216" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k560seRB026057; Mon, 5 Jun 2006 17:54:40 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k560scCU024674; Mon, 5 Jun 2006 17:54:38 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Jun 2006 17:54:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Jun 2006 17:54:37 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201FC0700@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 105 - Reset IEEE 802.11 statistics/was Re: [Capwap] some suggestion for 802.11 binding TLV Thread-Index: AcZ/YHtJQtyAIoMgRBaDD8X5QSld8QJo0Pew From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "young" X-OriginalArrivalTime: 06 Jun 2006 00:54:38.0816 (UTC) FILETIME=[C9ADDE00:01C68903] Authentication-Results: sj-dkim-3.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 105 - Reset IEEE 802.11 statistics/was Re: some suggestion for 802.11 binding TLV X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Dorothy, Here is text from the original post: 1) New TLV "reset IEEE 802.11 Statistics" a) Why we need it? Now, the draft defines "IEEE 802.11 Statistics" to report Multicast Tx Count, Multiple Retry Count and so on. As AP keep updating the statistic value, after some time, the statistic value will become very great, and it could not reflect the real state of network. So administrator need a method to reset IEEE 802.11 Statistics" b) The TLV could be carried in the "Configure Update request" c) The TLV format is as follow: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Radio ID | +-+-+-+-+-+-+-+-+ When AP side get radio id from TLV, it will reset the radio as per radio ID. d) Other suggestion: Whether it needs a "Reset interval" element? By this way, user could configure after how many time (seconds) AP will reset Statistics for a specific radio. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com] Sent: Wednesday, May 24, 2006 11:33 AM To: young Cc: Pat Calhoun (pacalhou); capwap@frascone.com Subject: Issue 105 - Reset IEEE 802.11 statistics/was Re: [Capwap] some suggestion for 802.11 binding TLV All, I would like to develop text to resolve Issue 105, but need some more information as to exactly what the issue is. Input please. The discussion on issue 105 to date is listed below. Thanks, Dorothy On 4/19/06, young wrote: Dear all: I have some suggestion about CAPWAP draft, please kindly discuss it. 1) For IEEE 802.11 Statistics I suggest we should add new TLV for "reset IEEE 802.11 Statistics" Issue 105 has been opened for item (1). Can you provide suggested text for a description of the proposed TLV? This will enable a more informed discussion, and give insight into the problem that is being solved. Is this a boolean, which when set causes the WTP to reset all of its statistics collection counters? Is it included in the statistics message element? A new message element? In which message elements and messages would it be included? _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 01:28:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnU7D-0006ge-Ms for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 01:28:31 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnU7B-00052T-QN for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 01:28:31 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2821D430138 for ; Mon, 5 Jun 2006 22:28:29 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D60264300E6 for ; Mon, 5 Jun 2006 22:27:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C3132398010 for ; Mon, 5 Jun 2006 22:27:51 -0700 (PDT) Received: from huawei.com (szxga03-in.huawei.com [61.144.161.55]) by zoidberg.tigertech.net (Postfix) with ESMTP id DE22E398038 for ; Mon, 5 Jun 2006 22:27:48 -0700 (PDT) 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 <0J0F00IUXBKUNU@szxga03-in.huawei.com> for capwap@frascone.com; Tue, 06 Jun 2006 13:36:31 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0F00A6OBKU68@szxga03-in.huawei.com> for capwap@frascone.com; Tue, 06 Jun 2006 13:36:30 +0800 (CST) Received: from dell60 ([10.18.7.113]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0F001AUBN7MF@szxml04-in.huawei.com> for capwap@frascone.com; Tue, 06 Jun 2006 13:37:56 +0800 (CST) Date: Tue, 06 Jun 2006 10:57:31 +0530 From: sujay In-reply-to: <26140d940606041722w6df0f3eyaac5a3d79d3e0e1c@mail.gmail.com> To: 'Michael Montemurro' , 'Abhijit Choudhury' Message-id: <000001c68929$e94d75b0$7107120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.028 tagged_above=-999 required=7 tests=HTML_60_70, HTML_MESSAGE X-Spam-Level: Cc: 'capwap' Subject: Re: [Capwap] Proposed resolution for issue 100. Treatment ofwirelessmanagement frames. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0525960764==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 17cf8eab1d6bbd2874a56f9e3554d91d This is a multi-part message in MIME format. --===============0525960764== Content-type: multipart/alternative; boundary="Boundary_(ID_amf41s2uOiC34OjJD3wtfQ)" This is a multi-part message in MIME format. --Boundary_(ID_amf41s2uOiC34OjJD3wtfQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Mike, I would prefer encapsulating the 802.11 mgt frames as capwap data and send to AC. For , such binding specific mgt frames can be easily carried and understood by the AC. There is no need for CAPWAP taking an extra operation of converting it into an equivalent control message. But then again as it is in the data channel and the Ack for it is carried implicitly in the control channel (add mobile message) OR as Response message(Association response), in the data channel, retransmission mechanism implementations should be made aware of both possibilities. Least it MAY cause inter-op issues. >> >From Section 11.1.2 While the MAC is terminated on the WTP, it is necessary for the AC to...... WTP MUST forward the IEEE 802.11 Association Requests to the AC, and the AC " MAY " reply with a failed Association Response if it deems it necessary. Regds, Sujay G My Location; http://maps.google.com/maps?ll=14.626109,76.959229 &spn=4.724852,7.525085&t=h&hl=en This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Michael Montemurro [mailto:montemurro.michael@gmail.com] Sent: Monday, June 05, 2006 5:52 AM To: Abhijit Choudhury Cc: capwap Subject: Re: [Capwap] Proposed resolution for issue 100. Treatment ofwirelessmanagement frames. Actually, I need to make one clarification. If we decide to use CAPWAP data encapsulation, IEEE 802.11 management frames passed from the WTP to the AC in local MAC mode. That would mean there would be three possible forms of processing at the WTP: data frames - bridge locally or tunneled to the AC - CAPWAP data 802.11 management frames - encapulated as CAPWAP data and transmitted to the AC CAPWAP control frames. I think it sounds cleaner to encapsulate management frames and transmit them from the WTP to the AC as control frames. But I'm willing to go whichever way the group decides. Cheers, Mike On 6/3/06, Michael Montemurro wrote: Is there consensus that radio techology specific management frames should be carried as CAPWAP data frames? Thanks, Mike On 6/3/06, Abhijit Choudhury > wrote: Mike, I'm not sure this make sense. The CAPWAP control channel is for "control and provisioning" messages between the AC and the WTP. Per-client information arriving at the WTP should be sent in the data channel as it is all data to the AC, and has nothing to do with "control and provisioning" of the WTP. There could be radio technology specific information (e.g. RSSI/SNR) that are collected on a per-client basis at the AC, and separating out some of the messages into a separate channel will lead to either erroneous accounting or more complicated logic that looks at both channels on a packet-by-packet basis. All packets sent by a client should come up the same channel (the data channel). As for security for management frames, 802.11w should take care of that. Thanks, Abhijit -----Original Message----- From: Michael Montemurro [mailto: montemurro.michael@gmail.com] Sent: Saturday, June 03, 2006 12:39 PM To: capwap Subject: [Capwap] Proposed resolution for issue 100. Treatment of wirelessmanagement frames. Here is my proposed resolution to issue 100: - Fix the default priority settings in section 11.6 to the values used in section 4.3.3. - Change the last paragraph in section 4.3 to state that radio technology specific management frames are treated as CAPWAP control messages. It makes sense because control frames are protected. Does this make sense? Cheers, Mike --Boundary_(ID_amf41s2uOiC34OjJD3wtfQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Message
Mike,
 
I would prefer encapsulating the 802.11 mgt frames as capwap data and send to AC.
For , such binding specific mgt frames can be easily carried and understood
by the AC.
 
There is no need for CAPWAP taking an extra operation of converting it into an
equivalent control message.
 
But then again as it is in the data channel and the Ack for it is carried implicitly in
the control channel (add mobile message) OR as Response message(Association response),
 in the data channel, retransmission mechanism implementations should be
 made aware of both possibilities.
 
Least it MAY cause inter-op issues.
 
>>
From Section 11.1.2
 
While the MAC is terminated on the WTP, it is necessary for the AC to......
WTP MUST forward the IEEE 802.11 Association Requests to the AC, and
the AC " MAY " reply with a failed Association Response if it deems it
necessary.
 
 
Regds,
Sujay G
My Location;
http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085&t=h&hl=en


This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
-----Original Message-----
From: Michael Montemurro [mailto:montemurro.michael@gmail.com]
Sent: Monday, June 05, 2006 5:52 AM
To: Abhijit Choudhury
Cc: capwap
Subject: Re: [Capwap] Proposed resolution for issue 100. Treatment ofwirelessmanagement frames.

Actually, I need to make one clarification. If we decide to use CAPWAP data encapsulation, IEEE 802.11 management frames passed from the WTP to the AC in local MAC mode. That would mean there would be three possible forms of processing at the WTP:
data frames - bridge locally or tunneled to the AC - CAPWAP data
802.11 management frames - encapulated as CAPWAP data and transmitted to the AC
CAPWAP control frames.
 
I think it sounds cleaner to encapsulate management frames and transmit them from the WTP to the AC as control frames. But I'm willing to go whichever way the group decides.
 
Cheers,
 
Mike

 
On 6/3/06, Michael Montemurro <montemurro.michael@gmail.com> wrote:
Is there consensus that radio techology specific management frames should be carried as CAPWAP data frames?
 
Thanks,
 
Mike

 
On 6/3/06, Abhijit Choudhury <Abhijit@sinett.com > wrote:
Mike,
I'm not sure this make sense.
 
The CAPWAP control channel is for "control and
provisioning" messages between the AC and the WTP.
Per-client information arriving at the WTP should
be sent in the data channel as it is all data to
the AC, and has nothing to do with "control and
provisioning" of the WTP. 
 
There could be radio technology specific information
(e.g. RSSI/SNR) that are collected on a per-client
basis at the AC, and separating out some of the
messages into a separate channel will lead to either
erroneous accounting or more complicated logic that
looks at both channels on a packet-by-packet basis.
All packets sent by a client should come up
the same channel (the data channel).
 
As for security for management frames, 802.11w
should take care of that.
 
Thanks,
   Abhijit

-----Original Message-----
From: Michael Montemurro [mailto: montemurro.michael@gmail.com]
Sent: Saturday, June 03, 2006 12:39 PM
To: capwap
Subject: [Capwap] Proposed resolution for issue 100. Treatment of wirelessmanagement frames.

Here is my proposed resolution to issue 100:

- Fix the default priority settings in section 11.6 to the values used in section 4.3.3.

- Change the last paragraph in section 4.3 to state that radio technology specific management frames are treated as CAPWAP control messages. It makes sense because control frames are protected.

Does this make sense?

Cheers,

Mike

 



--Boundary_(ID_amf41s2uOiC34OjJD3wtfQ)-- --===============0525960764== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0525960764==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 02:51:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnVPx-0004AX-V8 for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 02:51:57 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnVPw-0006VH-IO for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 02:51:57 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 86EFC43010D for ; Mon, 5 Jun 2006 23:51:55 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8C2CC4300D2 for ; Mon, 5 Jun 2006 23:51:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 48C91144801A for ; Mon, 5 Jun 2006 23:51:36 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id C1174144801D for ; Mon, 5 Jun 2006 23:51:33 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k566pX3g010029 for ; Mon, 5 Jun 2006 23:51:33 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k566pWF1010025 for ; Mon, 5 Jun 2006 23:51:33 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Mon, 5 Jun 2006 23:51:32 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [Capwap] Data Transfer message X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 HI, In reading over the definition of the data transfer request(9.7), and its message elements (Data Transfer Mode(4.4.13) and Data Transfer Data(4.4.12)), I'm really confused. First, because the description of Data transfer request, says it's from the WTP to the AC, but the description of Data transfer mode, says it's between the AC and WTP. Also, it this is to be used for crash files and memory dumps, but these will not fit in one message. I don't see how a crash file (a core dump) would be sent. Finally, there is no higher level description of the operation that is occuring. (That is, no description of the use case.) Also, it would seem likely that the AC would control what memory areas that would be returned. I don't see how this is done. So, could someone explain this operation. Thanks, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 04:58:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnXO6-0002kx-Na for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 04:58:10 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnXO5-0005Lz-8W for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 04:58:10 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3C6A6430125 for ; Tue, 6 Jun 2006 01:58:08 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 5335B4300D2 for ; Tue, 6 Jun 2006 01:57:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3BB0643063E for ; Tue, 6 Jun 2006 01:57:43 -0700 (PDT) X-Greylist-Status: Sender first seen 00:51:02 ago Received: from co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by hermes.tigertech.net (Postfix) with ESMTP id 4A5C843086B for ; Tue, 6 Jun 2006 01:57:39 -0700 (PDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5684QoV013759 for ; Tue, 6 Jun 2006 04:04:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jun 2006 11:06:33 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 105 - Reset IEEE 802.11 statistics/was Re: somesuggestion for 802.11 binding TLV Thread-Index: AcZ/YHtJQtyAIoMgRBaDD8X5QSld8QJo0PewAA7HJ6A= From: "Romascanu, Dan (Dan)" To: "Pat Calhoun (pacalhou)" , "Dorothy Stanley" , "young" X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 105 - Reset IEEE 802.11 statistics/was Re: somesuggestion for 802.11 binding TLV X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c I do not believe that a "reset IEEE 802.11 Statistics" TLV is useful. Actually it may be harmful. When using statistics objects in order to understand 'the real state of the network' an administrator MUST NOT rely on the absolute values of statistic objects (typically counters), but on the delta values of successive readings, correlated with the timestamp of the reading. Dan > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Tuesday, June 06, 2006 3:55 AM > To: Dorothy Stanley; young > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 105 - Reset IEEE 802.11 > statistics/was Re: somesuggestion for 802.11 binding TLV > > Dorothy, Here is text from the original post: > > 1) New TLV "reset IEEE 802.11 Statistics" > > a) Why we need it? > > Now, the draft defines "IEEE 802.11 Statistics" to report > Multicast Tx Count, Multiple Retry Count and so on. As AP > keep updating the statistic value, after some time, the > statistic value will become very great, and it could not > reflect the real state of network. So administrator need a > method to reset IEEE 802.11 Statistics" > > b) The TLV could be carried in the "Configure Update request" > > c) The TLV format is as follow: > > 0 1 2 3 4 5 6 7 > > +-+-+-+-+-+-+-+-+ > > | Radio ID | > > +-+-+-+-+-+-+-+-+ > > When AP side get radio id from TLV, it will reset the > radio as per radio ID. > > d) Other suggestion: > > Whether it needs a "Reset interval" element? By this way, > user could configure after how many time (seconds) AP will > reset Statistics for a specific radio. > > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > ________________________________ > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > Sent: Wednesday, May 24, 2006 11:33 AM > To: young > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: Issue 105 - Reset IEEE 802.11 statistics/was Re: > [Capwap] some suggestion for 802.11 binding TLV > > > All, > > I would like to develop text to resolve Issue 105, but > need some more information as to exactly what the > issue is. Input please. The discussion on issue 105 > to date is listed below. > > Thanks, > > Dorothy > > > > > On 4/19/06, young wrote: > > Dear all: > > > > I have some suggestion about CAPWAP > draft, please kindly discuss it. > > 1) For IEEE 802.11 Statistics > > I suggest we should add new TLV for "reset IEEE > 802.11 Statistics" > > > Issue 105 has been opened for item (1). > > Can you provide suggested text for a > description of the proposed TLV? This will enable a more > informed discussion, and > give insight into the problem that is being solved. > Is this a boolean, which when set causes the > WTP to reset all of its statistics collection counters? > Is it included in the statistics message > element? A new message element? In which message elements > and messages would it be included? > > > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 08:56:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnb76-0006mz-Q3 for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 08:56:52 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnb74-0005kw-AU for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 08:56:52 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1B896430125 for ; Tue, 6 Jun 2006 05:56:49 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 79634430085 for ; Tue, 6 Jun 2006 05:56:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4BB931448026 for ; Tue, 6 Jun 2006 05:56:20 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by hermes.tigertech.net (Postfix) with ESMTP id 4E1661448025 for ; Tue, 6 Jun 2006 05:56:18 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id w49so1473233pyg for ; Tue, 06 Jun 2006 05:56:17 -0700 (PDT) Received: by 10.35.88.17 with SMTP id q17mr8105377pyl; Tue, 06 Jun 2006 05:56:17 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Tue, 6 Jun 2006 05:56:17 -0700 (PDT) Message-ID: <26140d940606060556t765abdc4laa98546590fc8a96@mail.gmail.com> Date: Tue, 6 Jun 2006 08:56:17 -0400 From: "Michael Montemurro" To: "David T. Perkins" In-Reply-To: MIME-Version: 1.0 References: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Data Transfer message X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1632131733==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 --===============1632131733== Content-Type: multipart/alternative; boundary="----=_Part_24794_13017354.1149598577098" ------=_Part_24794_13017354.1149598577098 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline David, I've created issue 133 to track this issue On 6/6/06, David T. Perkins wrote: > > HI, > > In reading over the definition of the data transfer request(9.7), > and its message elements (Data Transfer Mode(4.4.13) and > Data Transfer Data(4.4.12)), I'm really confused. > > First, because the description of Data transfer request, > says it's from the WTP to the AC, but the description of > Data transfer mode, says it's between the AC and WTP. > Also, it this is to be used for crash files and memory > dumps, but these will not fit in one message. I don't see > how a crash file (a core dump) would be sent. > Finally, there is no higher level description of the > operation that is occuring. (That is, no description > of the use case.) Also, it would seem likely > that the AC would control what memory areas that > would be returned. I don't see how this is done. > > So, could someone explain this operation. > > Thanks, > /david t. perkins > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_24794_13017354.1149598577098 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
David,

I've created issue 133 to track this issue

 
On 6/6/06, David T. Perkins <dperkins@dsperkins.com> wrote:
HI,

In reading over the definition of the data transfer request(9.7),
and its message elements (Data Transfer Mode( 4.4.13) and
Data Transfer Data(4.4.12)), I'm really confused.

First, because the description of Data transfer request,
says it's from the WTP to the AC, but the description of
Data transfer mode, says it's between the AC and WTP.
Also, it this is to be used for crash files and memory
dumps, but these will not fit in one message. I don't see
how a crash file (a core dump) would be sent.
Finally, there is no higher level description of the
operation that is occuring. (That is, no description
of the use case.) Also, it would seem likely
that the AC would control what memory areas that
would be returned. I don't see how this is done.

So, could someone explain this operation.

Thanks,
/david t. perkins




_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_24794_13017354.1149598577098-- --===============1632131733== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1632131733==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 09:58:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnc4p-0008BE-CO for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 09:58:35 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnc4n-0002nG-Tt for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 09:58:35 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7040B430195 for ; Tue, 6 Jun 2006 06:58:32 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D2E904300A5 for ; Tue, 6 Jun 2006 06:58:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DA18E1448026 for ; Tue, 6 Jun 2006 06:58:08 -0700 (PDT) Received: from rwcrmhc15.comcast.net (rwcrmhc15.comcast.net [204.127.192.85]) by hermes.tigertech.net (Postfix) with ESMTP id A866C144802A for ; Tue, 6 Jun 2006 06:58:04 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (rwcrmhc15) with ESMTP id <20060606135803m15000q3s3e>; Tue, 6 Jun 2006 13:58:03 +0000 Message-ID: <448589EB.8080607@hyperthought.com> Date: Tue, 06 Jun 2006 06:58:03 -0700 From: Scott G Kelly User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "Bob O'Hara (boohara)" References: <17B8C6DE4E228348B4939BDA6B05A9DC0197C379@xmb-sjc-237.amer.cisco.com> In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC0197C379@xmb-sjc-237.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Use of SESSION ID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Bob O'Hara (boohara) wrote: > Scott, > > I believe you were the first to use the word "shim", not me. If it is > pejorative, it is your word, not mine. Okay - so it seems we agree that there is no reason to view protocol layering in a negative light. > As to the need to be backward compatible with "a particular vendor's > legacy network gear", this is also your argument, not mine. I am not > arguing for separate ports due to the fact that my LWAPP equipment uses > them. I am arguing for the use of separate ports for exactly the reason > that I chose to use separate ports on my LWAPP equipment. The reason is > that using separate ports requires NO CHANGE TO EXISTING NETWORK > INFRASTRUCTURE EQUIPMENT, while providing the capability to easily > classify data and control traffic separately on that existing equipment. I am not referring to airespace gear - I'm referring to legacy routers and non-wlan switches. And as a point of fact, a single capwap protocol also requires "NO CHANGE TO EXISTING NETWORK INFRASTRUCTURE EQUIPMENT". There is no requirement in our objectives, architectural taxonomy, or charter that we expose capwap protocol internals to existing routers and switches. If we want to manipulate the ways in which they make forwarding decisions, we can accomplish this with vlan and QoS tagging. As for the balance of this post, I didn't respond to Chris' email because there's nothing material to our discussion there. Can you name some compelling QoS applications that entail encapsulating ostensibly important and latency sensitive traffic in CAPWAP, forwarding it over a WAN link to a controller, and risking re-marking by the ISP on the way? Speculating on generalized woulda/coulda/mighta applications cannot provide our motivation for making such a dramatic design decision, and it's a waste of our energy to be addressing such speculation. We've seen what a mess we'll get into if we split these streams into per PDU-type datagram channels. It's happened before (h.323, ipsec, early attempts at pptp, etc). It creates firewall configuration and operational problems, we have to devise a reliable channel binding scheme, NATs have to implement ALGs, the state machines on both sides become significantly more complex, and we have to run coordinated, dual-channel keep-alive schemes. The decision brings very real implementation, deployment, and operational pain. I provided a very detailed analysis of the technical trade-offs, and the conclusions of that analysis have not been disputed (but they do seem to have been forgotten). Partha also made a number of important points, not the least of which is that if we try to design a swiss-army-knife-style protocol that solves every corner case someone can dream up, we will never produce anything useful. Rather, we should be designing a minimal necessary and sufficient protocol which meets the needs of the broad community as the base. Then, as we gain deployment experience, everyone is free to propose worthwhile extensions. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 10:08:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FncED-0004gW-GO for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 10:08:17 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FncEC-00034c-1P for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 10:08:17 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 124E143016B for ; Tue, 6 Jun 2006 07:08:15 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 20A614300A5 for ; Tue, 6 Jun 2006 07:07:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5D34E144802A for ; Tue, 6 Jun 2006 07:07:51 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id 7CFA81448031 for ; Tue, 6 Jun 2006 07:07:45 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 06 Jun 2006 07:07:44 -0700 X-IronPort-AV: i="4.05,214,1146466800"; d="scan'208"; a="289668877:sNHT32182264" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k56E7i0S025206; Tue, 6 Jun 2006 07:07:44 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k56E7ike026926; Tue, 6 Jun 2006 07:07:44 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Jun 2006 07:07:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jun 2006 07:07:43 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201FC07A8@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Use of SESSION ID Thread-Index: AcaJcVEoE2nLxXNmSxmwO/zG221CgQAAK7uQ From: "Pat Calhoun (pacalhou)" To: "Scott G Kelly" , "Bob O'Hara (boohara)" X-OriginalArrivalTime: 06 Jun 2006 14:07:44.0468 (UTC) FILETIME=[94F02140:01C68972] Authentication-Results: sj-dkim-1.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Use of SESSION ID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Scott G Kelly [mailto:scott@hyperthought.com] says: > a single capwap protocol also requires "NO CHANGE TO EXISTING > NETWORK INFRASTRUCTURE EQUIPMENT". Working for a manufacturer that happens to build a significant amount of network infrastructure, and that have a rather large customer base that use both wired, and wireless, products, I will once more state that I completely disagree with you. > As for the balance of this post, I didn't respond to Chris' > email because there's nothing material to our discussion > there. I've provided you with countless examples, as have others, some such as Chris that actually have to build and run networks, but these views have been consistently waved aside by you as being irrelevant. At this point I will once more state that I completely disagree with your views, and leave it at that. We clearly don't have rough concensus on this point. Not sure how to move forward. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 10:56:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fncyo-0002DA-Kr for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 10:56:26 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fncym-0000Dh-Q6 for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 10:56:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E1706430112 for ; Tue, 6 Jun 2006 07:56:23 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 678044300E6 for ; Tue, 6 Jun 2006 07:55:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 56E00398051 for ; Tue, 6 Jun 2006 07:55:48 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id 263A139800D for ; Tue, 6 Jun 2006 07:55:45 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 06 Jun 2006 07:55:44 -0700 X-IronPort-AV: i="4.05,214,1146466800"; d="scan'208,217"; a="1820217267:sNHT124368118" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k56EtiHp005876; Tue, 6 Jun 2006 07:55:44 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k56Etike029655; Tue, 6 Jun 2006 07:55:44 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Jun 2006 07:55:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jun 2006 07:55:43 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201FC07D5@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed resolution for issue 100. Treatment ofwirelessmanagement frames. Thread-Index: AcaINi2hWMEKp0BMTC6Icj1uFs6YnABQwUjA From: "Pat Calhoun (pacalhou)" To: "Michael Montemurro" , "Abhijit Choudhury" X-OriginalArrivalTime: 06 Jun 2006 14:55:44.0591 (UTC) FILETIME=[49A005F0:01C68979] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.4 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Proposed resolution for issue 100. Treatment ofwirelessmanagement frames. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0088299429==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb This is a multi-part message in MIME format. --===============0088299429== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68979.4954F4F0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68979.4954F4F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I prefer that 802.11 management frames be carried as CAPWAP data frames, as the protocol defines today. So I would propose rejecting a change to encapsulate these as CAPWAP control packets. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Sunday, June 04, 2006 5:22 PM To: Abhijit Choudhury Cc: capwap Subject: Re: [Capwap] Proposed resolution for issue 100. Treatment ofwirelessmanagement frames. =09 =09 Actually, I need to make one clarification. If we decide to use CAPWAP data encapsulation, IEEE 802.11 management frames passed from the WTP to the AC in local MAC mode. That would mean there would be three possible forms of processing at the WTP:=20 data frames - bridge locally or tunneled to the AC - CAPWAP data 802.11 management frames - encapulated as CAPWAP data and transmitted to the AC CAPWAP control frames. =20 I think it sounds cleaner to encapsulate management frames and transmit them from the WTP to the AC as control frames. But I'm willing to go whichever way the group decides. =20 Cheers, =20 Mike =09 =20 On 6/3/06, Michael Montemurro wrote:=20 Is there consensus that radio techology specific management frames should be carried as CAPWAP data frames? =20 Thanks, =20 Mike =09 =20 =09 On 6/3/06, Abhijit Choudhury wrote:=20 Mike, I'm not sure this make sense. =20 The CAPWAP control channel is for "control and provisioning" messages between the AC and the WTP. Per-client information arriving at the WTP should be sent in the data channel as it is all data to the AC, and has nothing to do with "control and provisioning" of the WTP. =20 =20 There could be radio technology specific information=20 (e.g. RSSI/SNR) that are collected on a per-client=20 basis at the AC, and separating out some of the=20 messages into a separate channel will lead to either erroneous accounting or more complicated logic that=20 looks at both channels on a packet-by-packet basis.=20 All packets sent by a client should come up the same channel (the data channel). =20 As for security for management frames, 802.11w should take care of that. =20 Thanks, =09 Abhijit =09 =09 =09 -----Original Message----- From: Michael Montemurro [mailto: montemurro.michael@gmail.com ]=20 Sent: Saturday, June 03, 2006 12:39 PM To: capwap Subject: [Capwap] Proposed resolution for issue 100. Treatment of wirelessmanagement frames. =09 =09 Here is my proposed resolution to issue 100: - Fix the default priority settings in section 11.6 to the values used in section 4.3.3. - Change the last paragraph in section 4.3 to state that radio technology specific management frames are treated as CAPWAP control messages. It makes sense because control frames are protected. Does this make sense? Cheers, Mike =20 ------_=_NextPart_001_01C68979.4954F4F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 prefer that 802.11 management frames be carried as CAPWAP data frames, = as the=20 protocol defines today. So I would propose rejecting a change to = encapsulate=20 these as CAPWAP control packets.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Sunday, June = 04, 2006=20 5:22 PM
To: Abhijit Choudhury
Cc:=20 capwap
Subject: Re: [Capwap] Proposed resolution for issue = 100.=20 Treatment ofwirelessmanagement frames.

Actually, I need to make one clarification. If we decide to use = CAPWAP=20 data encapsulation, IEEE 802.11 management frames passed from the WTP = to the=20 AC in local MAC mode. That would mean there would be three possible = forms of=20 processing at the WTP:
data frames - bridge locally or tunneled to the AC - CAPWAP = data
802.11 management frames - encapulated as CAPWAP data and = transmitted to=20 the AC
CAPWAP control frames.
 
I think it sounds cleaner to encapsulate management frames and = transmit=20 them from the WTP to the AC as control frames. But I'm willing to go = whichever=20 way the group decides.
 
Cheers,
 
Mike

 
On 6/3/06, Michael=20 Montemurro <montemurro.michael@gmail.com= >=20 wrote:=20
Is there consensus that radio techology specific management = frames=20 should be carried as CAPWAP data frames?
 
Thanks,
 
Mike

 
On 6/3/06, Abhijit=20 Choudhury <Abhijit@sinett.com >=20 wrote:=20
Mike,
I'm = not sure this=20 make sense.
 
The = CAPWAP=20 control channel is for "control and
provisioning"=20 messages between the AC and the WTP.
Per-client=20 information arriving at the WTP should
be = sent in the=20 data channel as it is all data to
the = AC, and has=20 nothing to do with "control and
provisioning" of=20 the WTP. 
 
There could be=20 radio technology specific information
(e.g. RSSI/SNR)=20 that are=20 collected on a per-client
basis at the AC,=20 and=20 separating out some of the
messages into a=20 separate=20 channel will lead to either
erroneous=20 accounting or more complicated logic that
looks at both=20 channels=20 on a packet-by-packet basis.
All = packets=20 sent by a client should come up
the = same channel=20 (the data channel).
 
As = for security=20 for management frames, 802.11w
should take care=20 of that.
 
Thanks,
  =20 Abhijit

-----Original Message-----
From: Michael = Montemurro=20 [mailto:=20 montemurro.michael@gmail.com]
Sent: Saturday, = June 03,=20 2006 12:39 PM
To: capwap
Subject: [Capwap] = Proposed=20 resolution for issue 100. Treatment of wirelessmanagement=20 frames.

Here is my proposed resolution to issue 100:

- Fix the default priority settings in section 11.6 to = the=20 values used in section 4.3.3.

- Change the last paragraph in section 4.3 to state that = radio=20 technology specific management frames are treated as CAPWAP = control=20 messages. It makes sense because control frames are = protected.

Does this make sense?

Cheers,

Mike

 

=

<= BR> ------_=_NextPart_001_01C68979.4954F4F0-- --===============0088299429== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0088299429==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 10:57:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnd01-0002Ir-8r for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 10:57:41 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnczz-0000PS-JX for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 10:57:41 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2284543017B for ; Tue, 6 Jun 2006 07:57:39 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id DE11E4301A9 for ; Tue, 6 Jun 2006 07:56:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B76F9144802A for ; Tue, 6 Jun 2006 07:56:47 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id 8C5A91448028 for ; Tue, 6 Jun 2006 07:56:44 -0700 (PDT) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 06 Jun 2006 07:56:43 -0700 X-IronPort-AV: i="4.05,214,1146466800"; d="scan'208,217"; a="289705399:sNHT168349406" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k56EugMX017310; Tue, 6 Jun 2006 07:56:42 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k56EuccP016160; Tue, 6 Jun 2006 07:56:42 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Jun 2006 07:56:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jun 2006 07:56:39 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201FC07D7@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Typo in section 8.6 Thread-Index: AcaHP17wnJTW53ZrS7iHdiCorslxvwCOgkbA From: "Pat Calhoun (pacalhou)" To: "Michael Montemurro" , "David T. Perkins" X-OriginalArrivalTime: 06 Jun 2006 14:56:40.0207 (UTC) FILETIME=[6AC659F0:01C68979] Authentication-Results: sj-dkim-6.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Typo in section 8.6 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0111332021==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 This is a multi-part message in MIME format. --===============0111332021== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68979.6A9BA712" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68979.6A9BA712 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Works for me. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Saturday, June 03, 2006 11:55 AM To: David T. Perkins Cc: capwap@frascone.com Subject: Re: [Capwap] Typo in section 8.6 =09 =09 David, =20 I will make this fix. There is also text in section 8.7 that needed to be fixed. It states that the WTP sends the change state event response message. The AC transmits that message. =20 Mike =09 =20 On 6/2/06, David T. Perkins wrote:=20 HI, =09 Section 8.6 has the following text that looks like it has a typo. =09 A Change State Event Response message is by a WTP after receiving a=20 Change State Event Request message. =09 This should be something like: =09 A Change State Event Response message is sent by an AC after =09 ^^^^^^^^^^^^^modified receiving a Change State Event Request message. =09 Regards, /david t. perkins =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit:=20 http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 ------_=_NextPart_001_01C68979.6A9BA712 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Works=20 for me.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Saturday, June = 03, 2006=20 11:55 AM
To: David T. Perkins
Cc:=20 capwap@frascone.com
Subject: Re: [Capwap] Typo in section=20 8.6

David,
 
I will make this fix. There is also text in section 8.7 that = needed to be=20 fixed. It states that the WTP sends the change state event response = message.=20 The AC transmits that message.
 
 Mike

 
On 6/2/06, David T.=20 Perkins <dperkins@dsperkins.com>=20 wrote:=20
HI,

Section=20 8.6 has the following text that looks like it
has a=20 typo.

  A Change State Event Response message is by = a WTP=20 after receiving a
  Change State Event Request=20 message.

This should be something like:

  A = Change=20 State Event Response message is sent by an AC=20 = after
          &nbs= p;            = ;            =        =20 ^^^^^^^^^^^^^modified
  receiving a Change State Event = Request=20 message.

Regards,
/david t.=20 = perkins

__________________________________________________________= _______
To=20 unsubscribe or modify your subscription options, please visit: =
http://lists.f= rascone.com/mailman/listinfo/capwap

Archives:=20 http://lists.frascone= .com/pipermail/capwap=20

------_=_NextPart_001_01C68979.6A9BA712-- --===============0111332021== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0111332021==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 11:03:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnd5e-0004ul-Vu for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 11:03:30 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnd5d-0002xE-DQ for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 11:03:30 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B7A4B430162 for ; Tue, 6 Jun 2006 08:03:28 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 33EDD4300D5 for ; Tue, 6 Jun 2006 08:02:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2041C1448028 for ; Tue, 6 Jun 2006 08:02:59 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by hermes.tigertech.net (Postfix) with ESMTP id ED969144801D for ; Tue, 6 Jun 2006 08:02:56 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id w49so1514188pyg for ; Tue, 06 Jun 2006 08:02:55 -0700 (PDT) Received: by 10.35.117.5 with SMTP id u5mr467848pym; Tue, 06 Jun 2006 08:02:55 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Tue, 6 Jun 2006 08:02:55 -0700 (PDT) Message-ID: <26140d940606060802q38a867bej9a7046cf62db8dd7@mail.gmail.com> Date: Tue, 6 Jun 2006 11:02:55 -0400 From: "Michael Montemurro" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201FC07D7@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A201FC07D7@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_60_70, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Typo in section 8.6 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1013961926==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 --===============1013961926== Content-Type: multipart/alternative; boundary="----=_Part_2817_29776170.1149606175262" ------=_Part_2817_29776170.1149606175262 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I'll fix this in -02 On 6/6/06, Pat Calhoun (pacalhou) wrote: > > Works for me. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > ------------------------------ > *From:* Michael Montemurro [mailto:montemurro.michael@gmail.com] > *Sent:* Saturday, June 03, 2006 11:55 AM > *To:* David T. Perkins > *Cc:* capwap@frascone.com > *Subject:* Re: [Capwap] Typo in section 8.6 > > > > David, > > I will make this fix. There is also text in section 8.7 that needed to be > fixed. It states that the WTP sends the change state event response message. > The AC transmits that message. > > Mike > > > On 6/2/06, David T. Perkins wrote: > > > > HI, > > > > Section 8.6 has the following text that looks like it > > has a typo. > > > > A Change State Event Response message is by a WTP after receiving a > > Change State Event Request message. > > > > This should be something like: > > > > A Change State Event Response message is sent by an AC after > > ^^^^^^^^^^^^^modified > > receiving a Change State Event Request message. > > > > Regards, > > /david t. perkins > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > ------=_Part_2817_29776170.1149606175262 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I'll fix this in -02

On 6/6/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
Works for me.
 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

From: Michael Montemurro [mailto:montemurro.michael@gmail.com]
Sent: Saturday, June 03, 2006 11:55 AM
To: David T. Perkins
Cc: capwap@frascone.com
Subject: Re: [Capwap] Typo in section 8.6

 
David,
 
I will make this fix. There is also text in section 8.7 that needed to be fixed. It states that the WTP sends the change state event response message. The AC transmits that message.
 
 Mike

 
On 6/2/06, David T. Perkins <dperkins@dsperkins.com > wrote:
HI,

Section 8.6 has the following text that looks like it
has a typo.

  A Change State Event Response message is by a WTP after receiving a
  Change State Event Request message.

This should be something like:

  A Change State Event Response message is sent by an AC after
                                           ^^^^^^^^^^^^^modified
  receiving a Change State Event Request message.

Regards,
/david t. perkins

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


------=_Part_2817_29776170.1149606175262-- --===============1013961926== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1013961926==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 11:04:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnd6d-00051f-L0 for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 11:04:31 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnd6c-0003Au-Lx for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 11:04:31 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0D5BA4301AE for ; Tue, 6 Jun 2006 08:04:30 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 261D04300D5 for ; Tue, 6 Jun 2006 08:03:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 13F2C1448030 for ; Tue, 6 Jun 2006 08:03:59 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by hermes.tigertech.net (Postfix) with ESMTP id A3C2E1448034 for ; Tue, 6 Jun 2006 08:03:55 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id w49so1514518pyg for ; Tue, 06 Jun 2006 08:03:54 -0700 (PDT) Received: by 10.35.132.13 with SMTP id j13mr8375414pyn; Tue, 06 Jun 2006 08:03:54 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Tue, 6 Jun 2006 08:03:54 -0700 (PDT) Message-ID: <26140d940606060803r2bd51f9et8aabb37f5b2c9bd3@mail.gmail.com> Date: Tue, 6 Jun 2006 11:03:54 -0400 From: "Michael Montemurro" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201FC07D5@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A201FC07D5@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_60_70, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap , Abhijit Choudhury Subject: Re: [Capwap] Proposed resolution for issue 100. Treatment ofwirelessmanagement frames. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0163710945==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 --===============0163710945== Content-Type: multipart/alternative; boundary="----=_Part_2857_13327085.1149606234393" ------=_Part_2857_13327085.1149606234393 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cool. I'll ensure that -02 is updated in this manner. Mike On 6/6/06, Pat Calhoun (pacalhou) wrote: > > I prefer that 802.11 management frames be carried as CAPWAP data frames, > as the protocol defines today. So I would propose rejecting a change to > encapsulate these as CAPWAP control packets. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > ------------------------------ > *From:* Michael Montemurro [mailto:montemurro.michael@gmail.com] > *Sent:* Sunday, June 04, 2006 5:22 PM > > *To:* Abhijit Choudhury > *Cc:* capwap > *Subject:* Re: [Capwap] Proposed resolution for issue 100. Treatment > ofwirelessmanagement frames. > > > > Actually, I need to make one clarification. If we decide to use CAPWAP > data encapsulation, IEEE 802.11 management frames passed from the WTP to > the AC in local MAC mode. That would mean there would be three possible > forms of processing at the WTP: > data frames - bridge locally or tunneled to the AC - CAPWAP data > 802.11 management frames - encapulated as CAPWAP data and transmitted to > the AC > CAPWAP control frames. > > I think it sounds cleaner to encapsulate management frames and transmit > them from the WTP to the AC as control frames. But I'm willing to go > whichever way the group decides. > > Cheers, > > Mike > > > On 6/3/06, Michael Montemurro wrote: > > > > Is there consensus that radio techology specific management frames > > should be carried as CAPWAP data frames? > > > > Thanks, > > > > Mike > > > > > > On 6/3/06, Abhijit Choudhury wrote: > > > > > > Mike, > > > I'm not sure this make sense. > > > > > > The CAPWAP control channel is for "control and > > > provisioning" messages between the AC and the WTP. > > > Per-client information arriving at the WTP should > > > be sent in the data channel as it is all data to > > > the AC, and has nothing to do with "control and > > > provisioning" of the WTP. > > > > > > There could be radio technology specific information > > > (e.g. RSSI/SNR) that are collected on a per-client > > > basis at the AC, and separating out some of the > > > messages into a separate channel will lead to either > > > erroneous accounting or more complicated logic that > > > looks at both channels on a packet-by-packet basis. > > > All packets sent by a client should come up > > > the same channel (the data channel). > > > > > > As for security for management frames, 802.11w > > > should take care of that. > > > > > > Thanks, > > > Abhijit > > > > > > -----Original Message----- > > > *From:* Michael Montemurro [mailto: montemurro.michael@gmail.com] > > > *Sent:* Saturday, June 03, 2006 12:39 PM > > > *To:* capwap > > > *Subject:* [Capwap] Proposed resolution for issue 100. Treatment of > > > wirelessmanagement frames. > > > > > > Here is my proposed resolution to issue 100: > > > > > > - Fix the default priority settings in section 11.6 to the values used > > > in section 4.3.3. > > > > > > - Change the last paragraph in section 4.3 to state that radio > > > technology specific management frames are treated as CAPWAP control > > > messages. It makes sense because control frames are protected. > > > > > > Does this make sense? > > > > > > Cheers, > > > > > > Mike > > > > > > > > > > > > > > > ------=_Part_2857_13327085.1149606234393 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Cool. I'll ensure that -02 is updated in this manner.
 
Mike

 
On 6/6/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
I prefer that 802.11 management frames be carried as CAPWAP data frames, as the protocol defines today. So I would propose rejecting a change to encapsulate these as CAPWAP control packets.
 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

From: Michael Montemurro [mailto:montemurro.michael@gmail.com]
Sent: Sunday, June 04, 2006 5:22 PM

To: Abhijit Choudhury
Cc: capwap
Subject: Re: [Capwap] Proposed resolution for issue 100. Treatment ofwirelessmanagement frames.

 
Actually, I need to make one clarification. If we decide to use CAPWAP data encapsulation, IEEE 802.11 management frames passed from the WTP to the AC in local MAC mode. That would mean there would be three possible forms of processing at the WTP:
data frames - bridge locally or tunneled to the AC - CAPWAP data
802.11 management frames - encapulated as CAPWAP data and transmitted to the AC
CAPWAP control frames.
 
I think it sounds cleaner to encapsulate management frames and transmit them from the WTP to the AC as control frames. But I'm willing to go whichever way the group decides.
 
Cheers,
 
Mike

 
On 6/3/06, Michael Montemurro <montemurro.michael@gmail.com > wrote:
Is there consensus that radio techology specific management frames should be carried as CAPWAP data frames?
 
Thanks,
 
Mike

 
On 6/3/06, Abhijit Choudhury <Abhijit@sinett.com > wrote:
Mike,
I'm not sure this make sense.
 
The CAPWAP control channel is for "control and
provisioning" messages between the AC and the WTP.
Per-client information arriving at the WTP should
be sent in the data channel as it is all data to
the AC, and has nothing to do with "control and
provisioning" of the WTP. 
 
There could be radio technology specific information
(e.g. RSSI/SNR) that are collected on a per-client
basis at the AC, and separating out some of the
messages into a separate channel will lead to either
erroneous accounting or more complicated logic that
looks at both channels on a packet-by-packet basis.
All packets sent by a client should come up
the same channel (the data channel).
 
As for security for management frames, 802.11w
should take care of that.
 
Thanks,
   Abhijit

-----Original Message-----
From: Michael Montemurro [mailto: montemurro.michael@gmail.com]
Sent: Saturday, June 03, 2006 12:39 PM
To: capwap
Subject: [Capwap] Proposed resolution for issue 100. Treatment of wirelessmanagement frames.
Here is my proposed resolution to issue 100:

- Fix the default priority settings in section 11.6 to the values used in section 4.3.3.

- Change the last paragraph in section 4.3 to state that radio technology specific management frames are treated as CAPWAP control messages. It makes sense because control frames are protected.

Does this make sense?

Cheers,

Mike

 




------=_Part_2857_13327085.1149606234393-- --===============0163710945== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0163710945==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 11:06:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnd8I-0006WU-S3 for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 11:06:14 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnd8I-0003Fn-9O for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 11:06:14 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C57EF4301A5 for ; Tue, 6 Jun 2006 08:06:13 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id C132B430103 for ; Tue, 6 Jun 2006 08:05:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 69755398051 for ; Tue, 6 Jun 2006 08:05:47 -0700 (PDT) Received: from huawei.com (szxga02-in.huawei.com [61.144.161.54]) by zoidberg.tigertech.net (Postfix) with ESMTP id 881C0398027 for ; Tue, 6 Jun 2006 08:05:43 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0G00EBC2N62M@szxga02-in.huawei.com> for capwap@frascone.com; Tue, 06 Jun 2006 23:21:06 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0G00HCX2N6WT@szxga02-in.huawei.com> for capwap@frascone.com; Tue, 06 Jun 2006 23:21:06 +0800 (CST) Received: from dell60 ([10.18.7.113]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0G004TW1YZ43@szxml03-in.huawei.com> for capwap@frascone.com; Tue, 06 Jun 2006 23:06:36 +0800 (CST) Date: Tue, 06 Jun 2006 20:35:29 +0530 From: sujay In-reply-to: <4FF84B0BC277FF45AA27FE969DD956A201FC07A9@xmb-sjc-235.amer.cisco.com> To: "'Pat Calhoun (pacalhou)'" , "'Romascanu, Dan (Dan)'" , 'Dorothy Stanley' , 'young' Message-id: <000001c6897a$a72d7f30$7107120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 105 - Reset IEEE 802.11 statistics/was Re:somesuggestion for 802.11 binding TLV X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Only delta values of increment are important, but how does one specify the beginning and end of the measured time period? Typically ,It would be required if I were to need the stats data collected over a period of time. (say from an NMS tool) The simplest implementation would be to specify a reset wlan stats message. Regds, Sujay G My Location; http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085 &t=h&hl=en This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Tuesday, June 06, 2006 7:38 PM To: Romascanu, Dan (Dan); Dorothy Stanley; young Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 105 - Reset IEEE 802.11 statistics/was Re:somesuggestion for 802.11 binding TLV I tend to agree. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Tuesday, June 06, 2006 1:07 AM > To: Pat Calhoun (pacalhou); Dorothy Stanley; young > Cc: capwap@frascone.com > Subject: RE: [Capwap] Issue 105 - Reset IEEE 802.11 > statistics/was Re: somesuggestion for 802.11 binding TLV > > I do not believe that a "reset IEEE 802.11 Statistics" TLV is useful. > Actually it may be harmful. > > When using statistics objects in order to understand 'the > real state of the network' an administrator MUST NOT rely on > the absolute values of statistic objects (typically > counters), but on the delta values of successive readings, > correlated with the timestamp of the reading. > > > Dan > > > > > > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Tuesday, June 06, 2006 3:55 AM > > To: Dorothy Stanley; young > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 105 - Reset IEEE 802.11 > statistics/was Re: > > somesuggestion for 802.11 binding TLV > > > > Dorothy, Here is text from the original post: > > > > 1) New TLV "reset IEEE 802.11 Statistics" > > > > a) Why we need it? > > > > Now, the draft defines "IEEE 802.11 Statistics" to report > Multicast Tx > > Count, Multiple Retry Count and so on. As AP keep updating the > > statistic value, after some time, the statistic value will > become very > > great, and it could not reflect the real state of network. So > > administrator need a method to reset IEEE 802.11 Statistics" > > > > b) The TLV could be carried in the "Configure Update request" > > > > c) The TLV format is as follow: > > > > 0 1 2 3 4 5 6 7 > > > > +-+-+-+-+-+-+-+-+ > > > > | Radio ID | > > > > +-+-+-+-+-+-+-+-+ > > > > When AP side get radio id from TLV, it will reset the > radio as per > > radio ID. > > > > d) Other suggestion: > > > > Whether it needs a "Reset interval" element? By this way, > user could > > configure after how many time (seconds) AP will reset > Statistics for a > > specific radio. > > > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > ________________________________ > > > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > > Sent: Wednesday, May 24, 2006 11:33 AM > > To: young > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > Subject: Issue 105 - Reset IEEE 802.11 statistics/was Re: [Capwap] > > some suggestion for 802.11 binding TLV > > > > > > All, > > > > I would like to develop text to resolve Issue 105, but > need some more > > information as to exactly what the > > issue is. Input please. The discussion on issue 105 > to date is > > listed below. > > > > Thanks, > > > > Dorothy > > > > > > > > > > On 4/19/06, young wrote: > > > > Dear all: > > > > > > > > I have some suggestion about CAPWAP > draft, please kindly discuss > > it. > > > > 1) For IEEE 802.11 Statistics > > > > I suggest we should add new TLV for "reset IEEE > > 802.11 Statistics" > > > > > > Issue 105 has been opened for item (1). > > > > Can you provide suggested text for a > description of the proposed > > TLV? This will enable a more informed discussion, and > > give insight into the problem that is being solved. > > Is this a boolean, which when set causes the > WTP to reset all of its > > statistics collection counters? > > Is it included in the statistics message > element? A new message > > element? In which message elements and messages would it > be included? > > > > > > > > > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 11:07:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnd9Q-0006hr-Ng for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 11:07:24 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnd9P-0003PF-Qt for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 11:07:24 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5D95C430179 for ; Tue, 6 Jun 2006 08:07:23 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E3E944301A5 for ; Tue, 6 Jun 2006 08:06:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C7CC7144803B for ; Tue, 6 Jun 2006 08:06:02 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by hermes.tigertech.net (Postfix) with ESMTP id 154A9144802D for ; Tue, 6 Jun 2006 08:05:58 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id w49so1515152pyg for ; Tue, 06 Jun 2006 08:05:58 -0700 (PDT) Received: by 10.35.41.14 with SMTP id t14mr461211pyj; Tue, 06 Jun 2006 08:05:57 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Tue, 6 Jun 2006 08:05:57 -0700 (PDT) Message-ID: <26140d940606060805h7a1181ccie35c316e4eab4480@mail.gmail.com> Date: Tue, 6 Jun 2006 11:05:57 -0400 From: "Michael Montemurro" To: "Dorothy Stanley" In-Reply-To: <5bfe7a820606051703k47c5b833v60798cf314efece7@mail.gmail.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A201FC036F@xmb-sjc-235.amer.cisco.com> <5bfe7a820606051703k47c5b833v60798cf314efece7@mail.gmail.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_50_60, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1273802568==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c --===============1273802568== Content-Type: multipart/alternative; boundary="----=_Part_2937_19411918.1149606357740" ------=_Part_2937_19411918.1149606357740 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline So then, I'll go back to my original proposed change to address this issue: Would it be sufficient to move Encryption Capabilities from the WTP Descriptor (Section 4.4.34) to the WTP Radio Information message element (Section 4.4.39)? Cheers, Mike On 6/5/06, Dorothy Stanley wrote: > > > I do not agree with always requiring the WTP to provide wireless > encryption. The split MAC architecture allows 802.11 encryption/decryption > at either the WTP or the AC, and this flexibility should be retained, with > use of the > field in question clearly defined. > > > Dorothy > > > On 6/5/06, Pat Calhoun (pacalhou) wrote: > > > Actually, this field was intended to allow the WTP to communicate > > whether it is capable of providing its capabilities, and therefore allow the > > AC to determine whether it should perform centralized encryption. However, > > with the transition to DTLS, I propose that we always require the WTP to > > provide wireless encryption, and use DTLS between the AC and the WTP. > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > ------------------------------ > > *From:* Michael Montemurro [mailto:montemurro.michael@gmail.com] > > *Sent:* Saturday, June 03, 2006 12:12 PM > > *To:* David T. Perkins > > *Cc:* capwap@frascone.com > > *Subject:* Re: [Capwap] Encryption Capabilities > > > > > > > > David, > > > > Would it be sufficient to move Encryption Capabilities from the WTP > > Descriptor (Section 4.4.34) to the WTP Radio Information message element > > (Section 4.4.39)? > > > > Mike > > > > > > On 6/3/06, Michael Montemurro wrote: > > > > > > David, > > > > > > I've created issue 125 to track this issue. > > > > > > Mike > > > > > > > > > On 6/1/06, David T. Perkins wrote: > > > > > > > > HI, > > > > > > > > The "(4.4.34)WTP Descriptor" message element has the > > > > subfield "encryption capabilities". What is this used > > > > for? If for radios, then it should be per radio. If > > > > for the user data between the WTP and AC, then > > > > it doesn't seem appropriate to say the value is > > > > defined by "specific binding" definitions because > > > > the WTP can be supporting multiple radios with > > > > some that provide encryption services and some > > > > that don't. > > > > > > > > In general, I don't feel that this subfield is > > > > well defined, and it appears to me that it > > > > should be a per radio attribute. > > > > > > > > Regards, > > > > /david t. perkins > > > > > > > > _________________________________________________________________ > > > > To unsubscribe or modify your subscription options, please visit: > > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > ------=_Part_2937_19411918.1149606357740 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
So then, I'll go back to my original proposed change to address this issue:
 
Would it be sufficient to move Encryption Capabilities from the WTP Descriptor (Section 4.4.34) to the WTP Radio Information message element (Section 4.4.39)?
 
Cheers,
 
Mike


 
On 6/5/06, Dorothy Stanley <dstanley1389@gmail.com> wrote:

I do not agree with always requiring the WTP to provide wireless
encryption. The split MAC architecture allows 802.11 encryption/decryption
at either the WTP or the AC, and this flexibility should be retained, with use of the
field in question clearly defined.
 

Dorothy


On 6/5/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com> wrote:
Actually, this field was intended to allow the WTP to communicate whether it is capable of providing its capabilities, and therefore allow the AC to determine whether it should perform centralized encryption. However, with the transition to DTLS, I propose that we always require the WTP to provide wireless encryption, and use DTLS between the AC and the WTP.
 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

From: Michael Montemurro [mailto:montemurro.michael@gmail.com]
Sent: Saturday, June 03, 2006 12:12 PM
To: David T. Perkins
Cc: capwap@frascone.com
Subject: Re: [Capwap] Encryption Capabilities

 
David,
 
Would it be sufficient to move Encryption Capabilities from the WTP Descriptor (Section 4.4.34) to the WTP Radio Information message element (Section 4.4.39)?
 
Mike

 
On 6/3/06, Michael Montemurro <montemurro.michael@gmail.com > wrote:
David,

I've created issue 125 to track this issue.
 
Mike

 
On 6/1/06, David T. Perkins <dperkins@dsperkins.com > wrote:
HI,

The "(4.4.34)WTP Descriptor" message element has the
subfield "encryption capabilities". What is this used
for? If for radios, then it should be per radio. If
for the user data between the WTP and AC, then
it doesn't seem appropriate to say the value is
defined by "specific binding" definitions because
the WTP can be supporting multiple radios with
some that provide encryption services and some
that don't.

In general, I don't feel that this subfield is
well defined, and it appears to me that it
should be a per radio attribute.

Regards,
/david t. perkins

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap



_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


 

------=_Part_2937_19411918.1149606357740-- --===============1273802568== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1273802568==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 11:14:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FndG1-0001zv-T7 for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 11:14:13 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FndG0-0004Wl-AI for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 11:14:13 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C26DF43016E for ; Tue, 6 Jun 2006 08:14:11 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6B45C4300A5 for ; Tue, 6 Jun 2006 08:13:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 515B7398011 for ; Tue, 6 Jun 2006 08:13:43 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [216.148.227.153]) by zoidberg.tigertech.net (Postfix) with ESMTP id 98027398051 for ; Tue, 6 Jun 2006 08:13:40 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (rwcrmhc13) with ESMTP id <20060606151339m1300jgr0re>; Tue, 6 Jun 2006 15:13:40 +0000 Message-ID: <44859BA3.3030000@hyperthought.com> Date: Tue, 06 Jun 2006 08:13:39 -0700 From: Scott G Kelly User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Michael Montemurro References: <4FF84B0BC277FF45AA27FE969DD956A201FC036F@xmb-sjc-235.amer.cisco.com> <5bfe7a820606051703k47c5b833v60798cf314efece7@mail.gmail.com> <26140d940606060805h7a1181ccie35c316e4eab4480@mail.gmail.com> In-Reply-To: <26140d940606060805h7a1181ccie35c316e4eab4480@mail.gmail.com> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c I second Dorothy's comments, and I think Mike is right: this should be included with the radio information element. Michael Montemurro wrote: > So then, I'll go back to my original proposed change to address this issue: > > Would it be sufficient to move Encryption Capabilities from the WTP > Descriptor (Section 4.4.34) to the WTP Radio Information message element > (Section 4.4.39)? > > Cheers, > > Mike > > > > On 6/5/06, *Dorothy Stanley* > wrote: > > > I do not agree with always requiring the WTP to provide wireless > encryption. The split MAC architecture allows 802.11 > encryption/decryption > at either the WTP or the AC, and this flexibility should be > retained, with use of the > field in question clearly defined. > > > Dorothy > > > On 6/5/06, *Pat Calhoun (pacalhou)* < pcalhoun@cisco.com > > wrote: > > Actually, this field was intended to allow the WTP to > communicate whether it is capable of providing its capabilities, > and therefore allow the AC to determine whether it should > perform centralized encryption. However, with the transition to > DTLS, I propose that we always require the WTP to provide > wireless encryption, and use DTLS between the AC and the WTP. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > ------------------------------------------------------------------------ > *From:* Michael Montemurro > [mailto:montemurro.michael@gmail.com > ] > *Sent:* Saturday, June 03, 2006 12:12 PM > *To:* David T. Perkins > *Cc:* capwap@frascone.com > *Subject:* Re: [Capwap] Encryption Capabilities > > > > David, > > Would it be sufficient to move Encryption Capabilities from the > WTP Descriptor (Section 4.4.34) to the WTP Radio Information > message element (Section 4.4.39)? > > Mike > > > On 6/3/06, *Michael Montemurro* > wrote: > > David, > > I've created issue 125 to track this issue. > > Mike > > > On 6/1/06, *David T. Perkins* > wrote: > > HI, > > The "(4.4.34)WTP Descriptor" message element has the > subfield "encryption capabilities". What is this used > for? If for radios, then it should be per radio. If > for the user data between the WTP and AC, then > it doesn't seem appropriate to say the value is > defined by "specific binding" definitions because > the WTP can be supporting multiple radios with > some that provide encryption services and some > that don't. > > In general, I don't feel that this subfield is > well defined, and it appears to me that it > should be a per radio attribute. > > Regards, > /david t. perkins > > _________________________________________________________________ > To unsubscribe or modify your subscription options, > please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > ------------------------------------------------------------------------ > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 11:36:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FndbM-0001wE-CI for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 11:36:16 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FndbK-0007tF-Vo for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 11:36:16 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 486A343013F for ; Tue, 6 Jun 2006 08:36:14 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 27C304300D5 for ; Tue, 6 Jun 2006 08:35:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0CE46144802A for ; Tue, 6 Jun 2006 08:35:47 -0700 (PDT) X-Greylist-Status: Sender first seen 07:29:04 ago Received: from co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by hermes.tigertech.net (Postfix) with ESMTP id DA264144802D for ; Tue, 6 Jun 2006 08:35:41 -0700 (PDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k56FXUHQ007972 for ; Tue, 6 Jun 2006 11:33:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jun 2006 18:35:38 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 105 - Reset IEEE 802.11 statistics/was Re:somesuggestion for 802.11 binding TLV Thread-Index: AcaJerHSWaVNtu7NRvC5mJwe+1qRZQAA8JPw From: "Romascanu, Dan (Dan)" To: "sujay" , "Pat Calhoun (pacalhou)" , "Dorothy Stanley" , "young" X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 105 - Reset IEEE 802.11 statistics/was Re:somesuggestion for 802.11 binding TLV X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a > -----Original Message----- > From: sujay [mailto:sujayg@huawei.com] > Sent: Tuesday, June 06, 2006 6:05 PM > To: 'Pat Calhoun (pacalhou)'; Romascanu, Dan (Dan); 'Dorothy > Stanley'; 'young' > Cc: capwap@frascone.com > Subject: RE: [Capwap] Issue 105 - Reset IEEE 802.11 > statistics/was Re:somesuggestion for 802.11 binding TLV > > Only delta values of increment are important, but how does > one specify the beginning and end of the measured time period? You do not need to specify this if you retrieve the time-stamp when each one of the absolute sample was taken. Anyway, in most cases this is not just beginning and end, but about a periodical retrieval or polling process. Dan _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 12:17:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FneFi-00079t-3E for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 12:17:58 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FneFf-0003dz-0c for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 12:17:58 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 72F834300E6 for ; Tue, 6 Jun 2006 09:17:53 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4EECD4300D5 for ; Tue, 6 Jun 2006 09:17:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0C1361448026 for ; Tue, 6 Jun 2006 09:17:03 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.204]) by hermes.tigertech.net (Postfix) with ESMTP id 6223C1448031 for ; Tue, 6 Jun 2006 09:16:58 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id i30so1454093wxd for ; Tue, 06 Jun 2006 09:16:57 -0700 (PDT) Received: by 10.70.73.13 with SMTP id v13mr7740268wxa; Tue, 06 Jun 2006 09:16:56 -0700 (PDT) Received: by 10.70.133.2 with HTTP; Tue, 6 Jun 2006 09:16:56 -0700 (PDT) Message-ID: <5bfe7a820606060916ic44fb8cl725fd2570e71ed50@mail.gmail.com> Date: Tue, 6 Jun 2006 09:16:56 -0700 From: "Dorothy Stanley" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201FC06E4@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A201FC06E4@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.6 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Proposed Rsolution Issue 81: Minor edits and questionsCAPWAP Protocol specification X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1473129417==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 --===============1473129417== Content-Type: multipart/alternative; boundary="----=_Part_60006_28112854.1149610616363" ------=_Part_60006_28112854.1149610616363 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Pat, 2. How would a WTP communicate that it is capable of providing local bridging services to the AC? Local Bridging: Local Bridging allows the WTP to perform the bridging function. This value MUST NOT be used when the WTP MAC Type is set to Split-MAC. What does "the local bridging function" mean? Based on the above (removed) definition, local bridging applies only to local-MAC cases, and "allows the WTP to perform the bridging function". This sounds like what any local-MAC WTP would already do, and if so, it's not clear that an indication other than "local-MAC" provided in section 4.4.38, " WTP MAC Type" is needed. Or, is a different meaning intended? Thanks, Dorothy On 6/5/06, Pat Calhoun (pacalhou) wrote: > > Dorothy, > > My comments (using your numbering below). > 1. ok with change > 2. How would a WTP communicate that it is capable of providing local > bridging services to the AC? > 3. ok with change > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > ------------------------------ > *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] > *Sent:* Thursday, May 25, 2006 12:28 PM > *To:* capwap > *Subject:* [Capwap] Proposed Rsolution Issue 81: Minor edits and > questionsCAPWAP Protocol specification > > All, > > The proposed resolution to Issue 81 is listed below. > > Comments welcome. > > Thanks, > > Dorothy > > ---------------------------------------------------------------------------------- > > Issue 81: > > Very Readable -- some minor comments > > Page 33 -- Section 5.1 -- 5th paragraph > > If a Discovery Response .... equal to SilentInterval before sending further > Discovery Request messages. > > change to > > > If a Discovery Response .... equal to SilentInterval before returning to the > ide stand and sending further Discovery Request messages. > > > Section 5.1.5 WTP Frame Type -- Page 37 - Local Bridging > > > What do the frames look like -- do not understand what is sent or received. > > > Page 51 -- Top of Page -- Secton 7.3.2 > > cause repeated twice -- delete 1st reference > > > 1. Page 33, Section 5.1 is the Discovery Request Message definition > > The proposed change is to the following text: > > If a Discovery Response message is not received after sending the > maximum number of Discovery Request messages, the WTP enters the > Sulking state and MUST wait for an interval equal to SilentInterval > before sending further Discovery Request messages. > > Proposed resolution: In the -01 state machine, the WTP remains > in the Discover state whle determining which AC to send the Join Request > message to, see the description of state (b), Discovery to Discovery. > Reject the proposed change. > > 2. Section 5.1.4, WTP Frame Type is now section 4.4.36, > WTP Frame Encapsulation Type, copied below. It is unclear > why local bridging is listed as a frame type/eccapsulation type. > > Recommended change: > > Change from: > > 4.4.36. WTP Frame Encapsulation Type > > The WTP Frame EncapsultationType message element allows the WTP to > communicate the encapsulation type, or tunneling modes of operation > which it supports to the AC. A WTP that advertises support for all > types allows the AC to select which type will be used, based on its > local policy. > > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |Frame Enc Type | > +-+-+-+-+-+-+-+-+ > > Type: 36 for WTP Frame Encapsulation Type > > Length: 1 > > Frame Encapsulation Type: The Frame type specifies the encapsulation > modes supported by the WTP. The following values are supported: > > 1 - Local Bridging: Local Bridging allows the WTP to perform the > bridging function. This value MUST NOT be used when the WTP > MAC Type is set to Split-MAC. > > 2 - 802.3 Bridging: 802.3 Bridging requires the WTP and AC to > encapsulate all user payload as native IEEE 802.3 frames (see > Section 4.2). This value MUST NOT be used when the WTP MAC > Type is set to Split-MAC. > > 4 - Native Bridging: Native Bridging requires the WTP and AC to > encapsulate all user payloads as native wireless frames, as > defined by the wireless binding (see Section 4.2). > > 7 - All: The WTP is capable of supporting all frame encapsulation > types. > > To: > > 4.4.36. WTP Frame Encapsulation Type > > The WTP Frame EncapsultationType message element allows the WTP to > communicate the encapsulation type, or tunneling modes of operation > which it supports to the AC. A WTP that advertises support for all > types allows the AC to select which type will be used, based on its > local policy. > > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |Frame Enc Type | > +-+-+-+-+-+-+-+-+ > > Type: 36 for WTP Frame Encapsulation Type > > Length: 1 > > Frame Encapsulation Type: The Frame type specifies the encapsulation > modes supported by the WTP. The following values are supported: > > 1 - 802.3 Encapsulation: 802.3 Bridging requires the WTP and AC to > encapsulate all user payload as native IEEE 802.3 frames (see > Section 4.2). This value MUST NOT be used when the WTP MAC > Type is set to Split-MAC. > > 2 - Native Encapsulation: Native Bridging requires the WTP and AC > to > encapsulate all user payloads as native wireless frames, as > defined by the wireless binding (see Section 4.2). > > 3 - All: The WTP is capable of supporting both frame encapsulation > types. > > > 3. Change State Event, now 4.4.11 - the first "case" reference, (duplicate > text) has been deleted in draft -01. > > > ------=_Part_60006_28112854.1149610616363 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Pat,

2. How would a WTP communicate that it is capable of providing local bridging services to the AC?

 Local Bridging:  Local Bridging allows the WTP to perform the
         bridging function.  This value MUST NOT be used when the WTP
         MAC Type is set to Split-MAC.

What does "the local bridging function" mean? Based on the above (removed) definition, local bridging applies only
to local-MAC cases, and "allows the WTP to perform the
bridging function". This sounds like what any local-MAC WTP would already do, and
if so, it's not clear that an indication other than "local-MAC" provided in section 4.4.38,
" WTP MAC Type" is needed.

Or, is a different meaning intended?

Thanks,

Dorothy


On 6/5/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
Dorothy,
 
My comments (using your numbering below).
1. ok with change
2. How would a WTP communicate that it is capable of providing local bridging services to the AC?
3. ok with change
 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

From: Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Thursday, May 25, 2006 12:28 PM
To: capwap
Subject: [Capwap] Proposed Rsolution Issue 81: Minor edits and questionsCAPWAP Protocol specification

All,

The proposed resolution to Issue 81 is listed below.

Comments welcome.

Thanks,

Dorothy
----------------------------------------------------------------------------------

Issue 81:
Very Readable -- some minor comments

Page 33 -- Section 5.1 -- 5th paragraph

If a Discovery Response .... equal to SilentInterval before sending further 
Discovery Request messages.


change to


If a Discovery Response .... equal to SilentInterval before returning to the 
ide stand and sending further Discovery Request messages.


Section 5.1.5 WTP Frame Type -- Page 37 - Local Bridging



What do the frames look like -- do not understand what is sent or received.


Page 51 -- Top of Page -- Secton 7.3.2

cause repeated twice -- delete 1st reference

1. Page 33, Section 5.1 is the Discovery Request Message definition

The proposed change is to the following text:

   If a Discovery Response message is not received after sending the
   maximum number of Discovery Request messages, the WTP enters the
   Sulking state and MUST wait for an interval equal to SilentInterval
   before sending further Discovery Request messages.

Proposed resolution: In the -01 state machine, the WTP remains
in the Discover state whle determining which AC to send the Join Request
message to, see the description of state (b), Discovery to Discovery.
Reject the proposed change.

2. Section 5.1.4, WTP Frame Type is now section 4.4.36,
WTP Frame Encapsulation Type, copied below. It is unclear
why local bridging is listed as a frame type/eccapsulation type.

Recommended change:

Change from:

4.4.36.  WTP Frame Encapsulation Type

   The WTP Frame EncapsultationType message element allows the WTP to
   communicate the encapsulation type, or tunneling modes of operation
   which it supports to the AC.  A WTP that advertises support for all
   types allows the AC to select which type will be used, based on its
   local policy.

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |Frame Enc Type  |
     +-+-+-+-+-+-+-+-+

   Type:  36 for WTP Frame Encapsulation Type

   Length:  1

   Frame Encapsulation Type:  The Frame type specifies the encapsulation
      modes supported by the WTP.  The following values are supported:

      1 - Local Bridging:  Local Bridging allows the WTP to perform the
         bridging function.  This value MUST NOT be used when the WTP
         MAC Type is set to Split-MAC.

      2 - 802.3 Bridging:  802.3 Bridging requires the WTP and AC to
         encapsulate all user payload as native IEEE 802.3 frames (see
         Section 4.2).  This value MUST NOT be used when the WTP MAC
         Type is set to Split-MAC.

      4 - Native Bridging:  Native Bridging requires the WTP and AC to
         encapsulate all user payloads as native wireless frames, as
         defined by the wireless binding (see Section 4.2).

      7 - All:  The WTP is capable of supporting all frame encapsulation
         types.

To:

4.4.36.  WTP Frame Encapsulation Type

   The WTP Frame EncapsultationType message element allows the WTP to
   communicate the encapsulation type, or tunneling modes of operation
   which it supports to the AC.  A WTP that advertises support for all
   types allows the AC to select which type will be used, based on its
   local policy.

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |Frame Enc Type  |
     +-+-+-+-+-+-+-+-+

   Type:  36 for WTP Frame Encapsulation Type

   Length:  1

   Frame Encapsulation Type:  The Frame type specifies the encapsulation
      modes supported by the WTP.  The following values are supported:

      1 - 802.3 Encapsulation:  802.3 Bridging requires the WTP and AC to
         encapsulate all user payload as native IEEE 802.3 frames (see
         Section 4.2).  This value MUST NOT be used when the WTP MAC
         Type is set to Split-MAC.

      2 - Native Encapsulation:  Native Bridging requires the WTP and AC to
         encapsulate all user payloads as native wireless frames, as
         defined by the wireless binding (see Section 4.2).

      3 - All:  The WTP is capable of supporting both frame encapsulation
         types.


3. Change State Event, now 4.4.11 - the first "case" reference, (duplicate
text) has been deleted in draft -01.



------=_Part_60006_28112854.1149610616363-- --===============1473129417== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1473129417==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 12:29:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FneQX-0004Gc-Bx for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 12:29:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FncYF-0004U1-M8 for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 10:28:59 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FncF2-0004MS-Cs for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 10:09:10 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C7AA443012F for ; Tue, 6 Jun 2006 07:09:06 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 33F874300FE for ; Tue, 6 Jun 2006 07:08:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B25051448026 for ; Tue, 6 Jun 2006 07:08:26 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id B4B4D144801D for ; Tue, 6 Jun 2006 07:08:21 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Jun 2006 07:08:21 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k56E8Kr6014262; Tue, 6 Jun 2006 07:08:20 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k56E8J9s002081; Tue, 6 Jun 2006 07:08:19 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Jun 2006 07:08:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jun 2006 07:08:18 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201FC07A9@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 105 - Reset IEEE 802.11 statistics/was Re: somesuggestion for 802.11 binding TLV Thread-Index: AcZ/YHtJQtyAIoMgRBaDD8X5QSld8QJo0PewAA7HJ6AADPF14A== From: "Pat Calhoun (pacalhou)" To: "Romascanu, Dan (Dan)" , "Dorothy Stanley" , "young" X-OriginalArrivalTime: 06 Jun 2006 14:08:19.0359 (UTC) FILETIME=[A9BC12F0:01C68972] Authentication-Results: sj-dkim-3.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 105 - Reset IEEE 802.11 statistics/was Re: somesuggestion for 802.11 binding TLV X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.5 (--) X-Scan-Signature: 225414c974e0d6437992164e91287a51 I tend to agree. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Tuesday, June 06, 2006 1:07 AM > To: Pat Calhoun (pacalhou); Dorothy Stanley; young > Cc: capwap@frascone.com > Subject: RE: [Capwap] Issue 105 - Reset IEEE 802.11 > statistics/was Re: somesuggestion for 802.11 binding TLV > > I do not believe that a "reset IEEE 802.11 Statistics" TLV is useful. > Actually it may be harmful. > > When using statistics objects in order to understand 'the > real state of the network' an administrator MUST NOT rely on > the absolute values of statistic objects (typically > counters), but on the delta values of successive readings, > correlated with the timestamp of the reading. > > > Dan > > > > > > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Tuesday, June 06, 2006 3:55 AM > > To: Dorothy Stanley; young > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 105 - Reset IEEE 802.11 > statistics/was Re: > > somesuggestion for 802.11 binding TLV > > > > Dorothy, Here is text from the original post: > > > > 1) New TLV "reset IEEE 802.11 Statistics" > > > > a) Why we need it? > > > > Now, the draft defines "IEEE 802.11 Statistics" to report > Multicast Tx > > Count, Multiple Retry Count and so on. As AP keep updating the > > statistic value, after some time, the statistic value will > become very > > great, and it could not reflect the real state of network. So > > administrator need a method to reset IEEE 802.11 Statistics" > > > > b) The TLV could be carried in the "Configure Update request" > > > > c) The TLV format is as follow: > > > > 0 1 2 3 4 5 6 7 > > > > +-+-+-+-+-+-+-+-+ > > > > | Radio ID | > > > > +-+-+-+-+-+-+-+-+ > > > > When AP side get radio id from TLV, it will reset the > radio as per > > radio ID. > > > > d) Other suggestion: > > > > Whether it needs a "Reset interval" element? By this way, > user could > > configure after how many time (seconds) AP will reset > Statistics for a > > specific radio. > > > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > ________________________________ > > > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > > Sent: Wednesday, May 24, 2006 11:33 AM > > To: young > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > Subject: Issue 105 - Reset IEEE 802.11 statistics/was Re: > > [Capwap] some suggestion for 802.11 binding TLV > > > > > > All, > > > > I would like to develop text to resolve Issue 105, but > need some more > > information as to exactly what the > > issue is. Input please. The discussion on issue 105 > to date is > > listed below. > > > > Thanks, > > > > Dorothy > > > > > > > > > > On 4/19/06, young wrote: > > > > Dear all: > > > > > > > > I have some suggestion about CAPWAP > draft, please kindly discuss > > it. > > > > 1) For IEEE 802.11 Statistics > > > > I suggest we should add new TLV for "reset IEEE > > 802.11 Statistics" > > > > > > Issue 105 has been opened for item (1). > > > > Can you provide suggested text for a > description of the proposed > > TLV? This will enable a more informed discussion, and > > give insight into the problem that is being solved. > > Is this a boolean, which when set causes the > WTP to reset all of its > > statistics collection counters? > > Is it included in the statistics message > element? A new message > > element? In which message elements and messages would it > be included? > > > > > > > > > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 12:38:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FneZJ-0000Hb-BA for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 12:38:13 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FneZI-0007YM-GK for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 12:38:13 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1E332430196 for ; Tue, 6 Jun 2006 09:38:12 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4184A430148 for ; Tue, 6 Jun 2006 09:36:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2EF24398053 for ; Tue, 6 Jun 2006 09:36:25 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7E90C398068 for ; Tue, 6 Jun 2006 09:36:20 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 06 Jun 2006 09:36:16 -0700 X-IronPort-AV: i="4.05,214,1146466800"; d="scan'208,217"; a="1820294762:sNHT446171246" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k56GaDNx024166 for ; Tue, 6 Jun 2006 09:36:13 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k56GaDIs028573 for ; Tue, 6 Jun 2006 09:36:13 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Jun 2006 09:36:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jun 2006 09:36:11 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC019D88D5@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Encryption Capabilities Thread-Index: AcaI/Q9Cz8NEKehJQea5avLtZTsisQAicg1A From: "Bob O'Hara (boohara)" To: X-OriginalArrivalTime: 06 Jun 2006 16:36:13.0146 (UTC) FILETIME=[52EC83A0:01C68987] Authentication-Results: sj-dkim-7.cisco.com; header.From=boohara@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.468 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1491351584==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d This is a multi-part message in MIME format. --===============1491351584== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68987.52D6144E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68987.52D6144E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dorothy, =20 Given that protection of the CAPWAP data packet is (optionally) available using DTLS in -01, why should we also include an optional binding-specific protection mechanism that protects only the encapsulated 802.11 data frame? This seems to me to be two ways to do the same thing, with one of those ways available only when the binding is 802.11. =20 I suggest that we standardize on the DTLS method, which would be available to any binding and eliminate the 802.11-encrypted mechanism. -Bob =20 =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Monday, June 05, 2006 5:04 PM To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities I do not agree with always requiring the WTP to provide wireless encryption. The split MAC architecture allows 802.11 encryption/decryption at either the WTP or the AC, and this flexibility should be retained, with use of the field in question clearly defined. Dorothy On 6/5/06, Pat Calhoun (pacalhou) wrote:=20 Actually, this field was intended to allow the WTP to communicate whether it is capable of providing its capabilities, and therefore allow the AC to determine whether it should perform centralized encryption. However, with the transition to DTLS, I propose that we always require the WTP to provide wireless encryption, and use DTLS between the AC and the WTP.=20 =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Saturday, June 03, 2006 12:12 PM To: David T. Perkins Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities =09 =09 =09 David, =20 Would it be sufficient to move Encryption Capabilities from the WTP Descriptor (Section 4.4.34) to the WTP Radio Information message element (Section 4.4.39)? =20 Mike =09 =20 On 6/3/06, Michael Montemurro wrote:=20 David,=20 =09 I've created issue 125 to track this issue. =20 Mike =09 =20 =09 On 6/1/06, David T. Perkins wrote:=20 HI, =09 The "(4.4.34)WTP Descriptor" message element has the subfield "encryption capabilities". What is this used=20 for? If for radios, then it should be per radio. If for the user data between the WTP and AC, then it doesn't seem appropriate to say the value is defined by "specific binding" definitions because the WTP can be supporting multiple radios with some that provide encryption services and some that don't. =09 In general, I don't feel that this subfield is well defined, and it appears to me that it should be a per radio attribute.=20 =09 Regards, /david t. perkins =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: =09 http://lists.frascone.com/mailman/listinfo/capwap=20 =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 ------_=_NextPart_001_01C68987.52D6144E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dorothy,
 
Given that protection of the CAPWAP data packet = is=20 (optionally) available using DTLS in -01, why should we also include an=20 optional binding-specific protection mechanism that protects only = the=20 encapsulated 802.11 data frame?  This seems to me to be two ways to = do the=20 same thing, with one of those ways available only when the binding is=20 802.11.
 
I suggest that we standardize on the DTLS = method, which=20 would be available to any binding and eliminate the 802.11-encrypted=20 mechanism.

 -Bob
 

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Monday, June 05, 2006 = 5:04=20 PM
To: Pat Calhoun (pacalhou)
Cc:=20 capwap@frascone.com
Subject: Re: [Capwap] Encryption=20 Capabilities


I do not agree with always requiring the WTP to provide=20 wireless
encryption. The split MAC architecture allows 802.11=20 encryption/decryption
at either the WTP or the AC, and this = flexibility=20 should be retained, with use of the
field in question clearly=20 defined.

Dorothy


On 6/5/06, Pat Calhoun=20 (pacalhou) <pcalhoun@cisco.com> = wrote:
Actually, this = field was=20 intended to allow the WTP to communicate whether it is capable of = providing=20 its capabilities, and therefore allow the AC to determine whether it = should=20 perform centralized encryption. However, with the transition to = DTLS, I=20 propose that we always require the WTP to provide wireless = encryption,=20 and use DTLS between the AC and the WTP.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Michael Montemurro = [mailto:montemurro.michael@gmail.com]
Sent: = Saturday,=20 June 03, 2006 12:12 PM
To: David T. Perkins
Cc: = capwap@frascone.com
Subject: Re: = [Capwap]=20 Encryption Capabilities

David,
 
Would it be sufficient to move Encryption Capabilities from the = WTP=20 Descriptor (Section 4.4.34) to the WTP Radio Information message = element=20 (Section 4.4.39)?
 
Mike

 
On 6/3/06, Michael=20 Montemurro <montemurro.michael@gmail.com> wrote:=20
David,

I've created issue 125 to track this = issue.
 
Mike

 
On 6/1/06, David T.=20 Perkins <dperkins@dsperkins.com=20 > wrote:=20
HI,

The=20 "(4.4.34)WTP Descriptor" message element has the
subfield = "encryption=20 capabilities". What is this used
for? If for radios, then it = should be=20 per radio. If
for the user data between the WTP and AC, = then
it=20 doesn't seem appropriate to say the value is
defined by = "specific=20 binding" definitions because
the WTP can be supporting multiple = radios=20 with
some that provide encryption services and some
that=20 don't.

In general, I don't feel that this subfield = is
well=20 defined, and it appears to me that it
should be a per radio = attribute.=20

Regards,
/david t.=20 = perkins

__________________________________________________________= _______
To=20 unsubscribe or modify your subscription options, please = visit:
http://lists.frascone.com/mailman/listinfo/capwap=20

Archives: http://lists.frascone.com/pipermail/capwap=20 =


=

____________________________________________________= _____________
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20


------_=_NextPart_001_01C68987.52D6144E-- --===============1491351584== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1491351584==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 12:39:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fneap-0001OQ-Oo for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 12:39:47 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fneao-0007lk-6o for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 12:39:47 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D17FD430128 for ; Tue, 6 Jun 2006 09:39:45 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 69824430146 for ; Tue, 6 Jun 2006 09:37:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4F975144802A for ; Tue, 6 Jun 2006 09:37:25 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id 2A690430D00 for ; Tue, 6 Jun 2006 09:37:20 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 06 Jun 2006 09:37:10 -0700 X-IronPort-AV: i="4.05,214,1146466800"; d="scan'208,217"; a="289781883:sNHT2198220504" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k56Gb9oS024676; Tue, 6 Jun 2006 09:37:09 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k56Gb9cL016175; Tue, 6 Jun 2006 09:37:09 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Jun 2006 09:37:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jun 2006 09:37:08 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201FC0873@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New Issue - Local MAC MUST vs MAY forward associationrequest messages Thread-Index: AcZdl4b4X4r9V/WQRmKPjwyqaSa1yQr791jA From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "capwap" X-OriginalArrivalTime: 06 Jun 2006 16:37:09.0411 (UTC) FILETIME=[7475DF30:01C68987] Authentication-Results: sj-dkim-7.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_40_50, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] New Issue - Local MAC MUST vs MAY forward associationrequest messages X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0832614014==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c This is a multi-part message in MIME format. --===============0832614014== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68987.7454938C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68987.7454938C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I disagree with this change request. The AC MUST know what STAs are being serviced by WTPs. The term MUST cannot be changed to MAY. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Tuesday, April 11, 2006 11:41 AM To: capwap Subject: [Capwap] New Issue - Local MAC MUST vs MAY forward associationrequest messages =09 =09 All, =09 Section 11.1.2 Local MAC describes the Local MAC operation. It currently states (second paragraph below Figure 6): =09 While the MAC is terminated on the WTP, it is necessary for the AC to be aware of mobility events within the WTPs.=20 As a consequence, the WTP MUST forward the IEEE 802.11 Association Requests to the AC, and the AC MAY reply=20 with a failed Association Response if it deems it necessary.=20 =09 =09 Since this is the Local MAC case, it seems that a MAY should be sufficient. =09 Recommended change: =09 The MAC is terminated on the WTP, but the AC may need to be aware of mobility events within the WTPs.=20 As a consequence, the WTP MAY forward the IEEE 802.11 Association Requests to the AC, and the AC MAY reply=20 with a failed Association Response. =09 Comments? =09 Thanks, =09 Dorothy =09 ------_=_NextPart_001_01C68987.7454938C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 disagree with this change request. The AC MUST know what STAs are being = serviced=20 by WTPs. The term MUST cannot be changed to MAY.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Tuesday, April 11, = 2006 11:41=20 AM
To: capwap
Subject: [Capwap] New Issue - Local = MAC MUST=20 vs MAY forward associationrequest messages

All,

Section 11.1.2 Local MAC describes the Local = MAC=20 operation. It currently states
(second paragraph below Figure=20 6):

While the MAC is terminated on the WTP, it is necessary for = the AC=20 to be aware of mobility events within the WTPs.
As a consequence, = the WTP=20 MUST forward the IEEE 802.11 Association Requests to the AC, and the = AC MAY=20 reply
with a failed Association Response if it deems it necessary. =


Since this is the Local MAC case, it seems that a MAY = should=20 be
sufficient.

Recommended change:

The MAC is = terminated on=20 the WTP, but the AC may need to be aware of mobility events within the = WTPs.=20
As a consequence, the WTP MAY forward the IEEE 802.11 Association = Requests=20 to the AC, and the AC MAY reply
with a failed Association=20 = Response.

Comments?

Thanks,

Dorothy
= ------_=_NextPart_001_01C68987.7454938C-- --===============0832614014== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0832614014==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 12:51:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnemV-0008Kt-2n for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 12:51:51 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnemV-0000H7-1P for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 12:51:51 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FneY4-0007Fx-2z for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 12:36:59 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C5CB1430133 for ; Tue, 6 Jun 2006 09:36:54 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 5C6E04300F1 for ; Tue, 6 Jun 2006 09:36:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4FF71398053 for ; Tue, 6 Jun 2006 09:36:17 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5441B398066 for ; Tue, 6 Jun 2006 09:36:14 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Jun 2006 09:36:13 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k56GaD3c031719; Tue, 6 Jun 2006 09:36:13 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k56GaD9s027658; Tue, 6 Jun 2006 09:36:13 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Jun 2006 09:36:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jun 2006 09:36:12 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201FC086E@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New issue - Correct Clause 11 Message Naming, Clean-up terminology Thread-Index: AcZdh9XNbAlZJrZATp2K6yeDTaRXwQr/x0Rw From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "capwap" X-OriginalArrivalTime: 06 Jun 2006 16:36:13.0733 (UTC) FILETIME=[53461550:01C68987] Authentication-Results: sj-dkim-3.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] New issue - Correct Clause 11 Message Naming, Clean-up terminology X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.5 (--) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 2. 11.1.2 Local MAC - Last paragraph describes optionally tunnelling data frames to the AC, which is not consistent with Local MAC. Recommended change: Delete the last paragraph This text was requested by folks on the list, as well as by the evaluation team, which was to allow for optional tunneling in local MAC mode, using 802.3 frame format. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com] Sent: Tuesday, April 11, 2006 9:48 AM To: capwap Subject: [Capwap] New issue - Correct Clause 11 Message Naming,Clean-up terminology All, Some suggested, largely editorial changes, throughout Clause 11: 1. Figures 5,7,8 show examples of message Flow and Roaming, and show "Add Mobile" as the message exchanged between the AC and WTP. But "Add Mobile" is the message element, not the message - the Mobile Config Request, changing to "Mobile Station Config Request" is the message name. Recommended change: Change "Add Mobile" to "Mobile Station Config Request[Add Mobile...]" 3. 11.3.1 Wording change: From: The CAPWAP protocol defines the data frame, which allows a wireless payload to be encapsulated. to: The CAPWAP protocol defines CAPWAP data packets, which are used to encapsulate an IEEE 802.11 payload. 4. 11.1.1 and 11.1.2 - Clarity In the function lists, change from Probe Response to Generate Probe Response 5. 11.1.1 Split MAC, first paragraph below the figure The Distribution and Integration services reside on the AC, and therefore all user data is tunneled between the WTP and the AC. As noted above, all real-time 802.11 services, including the control protocol and the beacon and probe response frames, are handled on the WTP. "control protocol" usually refers to the CAPWAP control protocol. Change to The Distribution and Integration services reside on the AC, and all user data is tunneled between the WTP and the AC. All real-time IEEE 802.11 services, including the IEEE 802.11 control frames, such as the Beacon and Probe Response frames, are handled on the WTP. 6. 11.3 - Correct use of terms 11.3 Transport specific bindings "All CAPWAP transports have the following IEEE 802.11 specific bindings:" Section 3, "CAPWAP Transport" talks about UDP with IPv4 or IPv6, rather than the payload encapsulation and status and WLANs field Suggest 11.3 IEEE 802.11 bindings for the CAPWAP Protocol This section defines the IEEE 802.11 specific bindings used with the CAPWAP protocol. 7. I1.2, First sentence in the second paragraph, change "access point" to "WTP". Comments please. Thanks, Dorothy _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 13:09:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnf3J-0008BP-Qb for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 13:09:13 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnf3G-0001VV-MW for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 13:09:13 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D693F4301D2 for ; Tue, 6 Jun 2006 10:09:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C898C4300D5 for ; Tue, 6 Jun 2006 10:08:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 78FCB144802A for ; Tue, 6 Jun 2006 10:08:41 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id E0F89144801E for ; Tue, 6 Jun 2006 10:08:37 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k56H8b0e019337; Tue, 6 Jun 2006 10:08:37 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k56H8ahF019333; Tue, 6 Jun 2006 10:08:36 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 6 Jun 2006 10:08:36 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201FC0873@xmb-sjc-235.amer.cisco.com> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap Subject: Re: [Capwap] New Issue - Local MAC MUST vs MAY forward associationrequest messages X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 HI, ABSOLUTELY agree with Pat. That is the AC MUST know what STAs are be serviced by the WTPs, and MUST decide which STAs are allowed to associate and send traffic. This is the fundamental difference between a CAPWAP network and a collection of APs. Regards, /david t. perkins On Tue, 6 Jun 2006, Pat Calhoun (pacalhou) wrote: > I disagree with this change request. The AC MUST know what STAs are > being serviced by WTPs. The term MUST cannot be changed to MAY. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > ________________________________ > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > Sent: Tuesday, April 11, 2006 11:41 AM > To: capwap > Subject: [Capwap] New Issue - Local MAC MUST vs MAY forward > associationrequest messages > > > All, > > Section 11.1.2 Local MAC describes the Local MAC operation. It > currently states > (second paragraph below Figure 6): > > While the MAC is terminated on the WTP, it is necessary for the > AC to be aware of mobility events within the WTPs. > As a consequence, the WTP MUST forward the IEEE 802.11 > Association Requests to the AC, and the AC MAY reply > with a failed Association Response if it deems it necessary. > > > Since this is the Local MAC case, it seems that a MAY should be > sufficient. > > Recommended change: > > The MAC is terminated on the WTP, but the AC may need to be > aware of mobility events within the WTPs. > As a consequence, the WTP MAY forward the IEEE 802.11 > Association Requests to the AC, and the AC MAY reply > with a failed Association Response. > > Comments? > > Thanks, > > Dorothy > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 13:13:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnf7T-0003IO-L2 for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 13:13:31 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnf7S-0001s7-Pj for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 13:13:31 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6430A43012F for ; Tue, 6 Jun 2006 10:13:30 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id F3CE24300D5 for ; Tue, 6 Jun 2006 10:12:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D1897144801E for ; Tue, 6 Jun 2006 10:12:52 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id A965C1448040 for ; Tue, 6 Jun 2006 10:12:48 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 06 Jun 2006 10:12:47 -0700 X-IronPort-AV: i="4.05,214,1146466800"; d="scan'208,217"; a="289815815:sNHT85978152" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k56HClHk016548; Tue, 6 Jun 2006 10:12:47 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k56HCk9s021932; Tue, 6 Jun 2006 10:12:46 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Jun 2006 10:12:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jun 2006 10:12:45 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201FC08B9@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Encryption Capabilities Thread-Index: AcaI/QoqYeXpXd2LQNSzGISIztbPtwAABXnQ From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" X-OriginalArrivalTime: 06 Jun 2006 17:12:46.0830 (UTC) FILETIME=[6E7620E0:01C6898C] Authentication-Results: sj-dkim-3.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1353609983==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: b058151374d77ee76edaac850f7449fb This is a multi-part message in MIME format. --===============1353609983== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6898C.6E4959C8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6898C.6E4959C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable But what we end up doing is providing two means to do the exact same thing. I admit that I was surprised when the optional DTLS support was added for data frames in the CAPWAP draft. However, having thought through the impact of this change, it actually does address the previous issues I had raised against centralized 802.11i security, which are: =20 1. By encrypting at the AC, how does one support 802.11e (specifically frame fragmentation to fit a service period) 2. How does the AC provide 802.11n A-MPDU/MSDU aggregation? =20 So I would propose we define one way, and I prefer the DTLS mechanism as it doesn't introduce any issues in supporting any 802.11 feature. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Monday, June 05, 2006 5:04 PM To: Pat Calhoun (pacalhou) Cc: Michael Montemurro; David T. Perkins; capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities =09 =09 I do not agree with always requiring the WTP to provide wireless encryption. The split MAC architecture allows 802.11 encryption/decryption at either the WTP or the AC, and this flexibility should be retained, with use of the field in question clearly defined. =09 Dorothy =09 =09 =09 On 6/5/06, Pat Calhoun (pacalhou) wrote:=20 Actually, this field was intended to allow the WTP to communicate whether it is capable of providing its capabilities, and therefore allow the AC to determine whether it should perform centralized encryption. However, with the transition to DTLS, I propose that we always require the WTP to provide wireless encryption, and use DTLS between the AC and the WTP.=20 =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Saturday, June 03, 2006 12:12 PM To: David T. Perkins Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities =09 =09 =09 David, =20 Would it be sufficient to move Encryption Capabilities from the WTP Descriptor (Section 4.4.34) to the WTP Radio Information message element (Section 4.4.39)? =20 Mike =09 =20 On 6/3/06, Michael Montemurro wrote:=20 David,=20 =09 I've created issue 125 to track this issue. =20 Mike =09 =20 =09 On 6/1/06, David T. Perkins wrote:=20 HI, =09 The "(4.4.34)WTP Descriptor" message element has the subfield "encryption capabilities". What is this used=20 for? If for radios, then it should be per radio. If for the user data between the WTP and AC, then it doesn't seem appropriate to say the value is defined by "specific binding" definitions because the WTP can be supporting multiple radios with some that provide encryption services and some that don't. =09 In general, I don't feel that this subfield is well defined, and it appears to me that it should be a per radio attribute.=20 =09 Regards, /david t. perkins =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: =09 http://lists.frascone.com/mailman/listinfo/capwap=20 =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 ------_=_NextPart_001_01C6898C.6E4959C8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
But=20 what we end up doing is providing two means to do the exact same thing. = I admit=20 that I was surprised when the optional DTLS support was added for data = frames in=20 the CAPWAP draft. However, having thought through the impact of this = change, it=20 actually does address the previous issues I had raised against = centralized=20 802.11i security, which are:
 
1. By=20 encrypting at the AC, how does one support 802.11e (specifically frame=20 fragmentation to fit a service period)
2. How=20 does the AC provide 802.11n A-MPDU/MSDU aggregation?
 
So I=20 would propose we define one way, and I prefer the DTLS mechanism as it = doesn't=20 introduce any issues in supporting any 802.11 = feature.

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Monday, June 05, 2006 = 5:04=20 PM
To: Pat Calhoun (pacalhou)
Cc: Michael = Montemurro;=20 David T. Perkins; capwap@frascone.com
Subject: Re: [Capwap]=20 Encryption Capabilities


I do not agree with always requiring the WTP to provide = wireless
encryption. The split MAC architecture allows 802.11=20 encryption/decryption
at either the WTP or the AC, and this = flexibility=20 should be retained, with use of the
field in question clearly=20 defined.

Dorothy


On 6/5/06, Pat Calhoun=20 (pacalhou) <pcalhoun@cisco.com> = wrote:
Actually, = this field was=20 intended to allow the WTP to communicate whether it is capable of = providing=20 its capabilities, and therefore allow the AC to determine whether it = should=20 perform centralized encryption. However, with the transition to = DTLS, I=20 propose that we always require the WTP to provide wireless = encryption,=20 and use DTLS between the AC and the WTP.
 

Pat Calhoun
CTO, Wireless = Networking Business=20 Unit
Cisco Systems

 

From: Michael Montemurro = [mailto:montemurro.michael@gmail.com]
Sent: = Saturday,=20 June 03, 2006 12:12 PM
To: David T. = Perkins
Cc: capwap@frascone.com
Subject: Re: = [Capwap]=20 Encryption Capabilities

David,
 
Would it be sufficient to move Encryption Capabilities from the = WTP=20 Descriptor (Section 4.4.34) to the WTP Radio Information message = element=20 (Section 4.4.39)?
 
Mike

 
On 6/3/06, Michael=20 Montemurro <montemurro.michael@gmail.com> wrote:=20
David,

I've created issue 125 to track this = issue.
 
Mike

 
On 6/1/06, David T.=20 Perkins <dperkins@dsperkins.com=20 > wrote:=20
HI,

The=20 "(4.4.34)WTP Descriptor" message element has the
subfield = "encryption=20 capabilities". What is this used
for? If for radios, then it = should=20 be per radio. If
for the user data between the WTP and AC, = then
it=20 doesn't seem appropriate to say the value is
defined by = "specific=20 binding" definitions because
the WTP can be supporting = multiple=20 radios with
some that provide encryption services and = some
that=20 don't.

In general, I don't feel that this subfield = is
well=20 defined, and it appears to me that it
should be a per radio=20 attribute.

Regards,
/david t.=20 = perkins

__________________________________________________________= _______
To=20 unsubscribe or modify your subscription options, please = visit:
http://lists.frascone.com/mailman/listinfo/capwap=20

Archives: http://lists.frascone.com/pipermail/capwap=20 =


=

____________________________________________________= _____________
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20


------_=_NextPart_001_01C6898C.6E4959C8-- --===============1353609983== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1353609983==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 13:16:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnfAa-0003oZ-OT for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 13:16:44 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnfAZ-0002Rz-Kv for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 13:16:44 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1DA99430199 for ; Tue, 6 Jun 2006 10:16:43 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 186704300D5 for ; Tue, 6 Jun 2006 10:16:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 00B2C39805D for ; Tue, 6 Jun 2006 10:16:03 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id 550A3398061 for ; Tue, 6 Jun 2006 10:16:01 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 06 Jun 2006 10:16:00 -0700 X-IronPort-AV: i="4.05,214,1146466800"; d="scan'208,217"; a="1820333698:sNHT112846700" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k56HG0g2009425; Tue, 6 Jun 2006 10:16:00 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k56HG09s024683; Tue, 6 Jun 2006 10:16:00 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Jun 2006 10:16:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jun 2006 10:15:59 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201FC08C1@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Rsolution Issue 81: Minor edits and questionsCAPWAP Protocol specification Thread-Index: AcaJhKkvm/3gSeg1SPGobh463+Av1wACDBvw From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" X-OriginalArrivalTime: 06 Jun 2006 17:16:00.0108 (UTC) FILETIME=[E1AA02C0:01C6898C] Authentication-Results: sj-dkim-4.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.459 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_40_50, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Proposed Rsolution Issue 81: Minor edits and questionsCAPWAP Protocol specification X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0827543990==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 6f51ba5266426a53fc06c7d32a3c18b6 This is a multi-part message in MIME format. --===============0827543990== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6898C.E171CEDA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6898C.E171CEDA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Recall that folks asked for 802.3 tunneling as optional in local MAC. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Tuesday, June 06, 2006 9:17 AM To: Pat Calhoun (pacalhou) Cc: capwap Subject: Re: [Capwap] Proposed Rsolution Issue 81: Minor edits and questionsCAPWAP Protocol specification =09 =09 Pat, =09 2. How would a WTP communicate that it is capable of providing local bridging services to the AC? =09 Local Bridging: Local Bridging allows the WTP to perform the bridging function. This value MUST NOT be used when the WTP MAC Type is set to Split-MAC. =09 What does "the local bridging function" mean? Based on the above (removed) definition, local bridging applies only to local-MAC cases, and "allows the WTP to perform the bridging function". This sounds like what any local-MAC WTP would already do, and if so, it's not clear that an indication other than "local-MAC" provided in section 4.4.38,=20 " WTP MAC Type" is needed. =09 Or, is a different meaning intended? =09 Thanks, =09 Dorothy =09 =09 =09 On 6/5/06, Pat Calhoun (pacalhou) wrote:=20 Dorothy, =20 My comments (using your numbering below). 1. ok with change 2. How would a WTP communicate that it is capable of providing local bridging services to the AC? 3. ok with change =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Thursday, May 25, 2006 12:28 PM To: capwap Subject: [Capwap] Proposed Rsolution Issue 81: Minor edits and questionsCAPWAP Protocol specification =09 =09 All, =09 The proposed resolution to Issue 81 is listed below.=20 =09 Comments welcome. =09 Thanks, =09 Dorothy =09 ------------------------------------------------------------------------ ---------- =09 Issue 81: =09 Very Readable -- some minor comments =09 Page 33 -- Section 5.1 -- 5th paragraph =09 If a Discovery Response .... equal to SilentInterval before sending further=20 Discovery Request messages. =09 =09 change to =09 =09 If a Discovery Response .... equal to SilentInterval before returning to the=20 ide stand and sending further Discovery Request messages. =09 =09 Section 5.1.5 WTP Frame Type -- Page 37 - Local Bridging =09 =09 =09 What do the frames look like -- do not understand what is sent or received. =09 =09 Page 51 -- Top of Page -- Secton 7.3.2 =09 cause repeated twice -- delete 1st reference 1. Page 33, Section 5.1 is the Discovery Request Message definition =09 The proposed change is to the following text: =09 If a Discovery Response message is not received after sending the maximum number of Discovery Request messages, the WTP enters the Sulking state and MUST wait for an interval equal to SilentInterval before sending further Discovery Request messages. =09 Proposed resolution: In the -01 state machine, the WTP remains in the Discover state whle determining which AC to send the Join Request message to, see the description of state (b), Discovery to Discovery. Reject the proposed change. =09 2. Section 5.1.4, WTP Frame Type is now section 4.4.36,=20 WTP Frame Encapsulation Type, copied below. It is unclear why local bridging is listed as a frame type/eccapsulation type. =09 Recommended change: =09 Change from: =09 4.4.36. WTP Frame Encapsulation Type =09 The WTP Frame EncapsultationType message element allows the WTP to communicate the encapsulation type, or tunneling modes of operation which it supports to the AC. A WTP that advertises support for all types allows the AC to select which type will be used, based on its local policy. =09 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Frame Enc Type | +-+-+-+-+-+-+-+-+ =09 Type: 36 for WTP Frame Encapsulation Type =09 Length: 1 =09 Frame Encapsulation Type: The Frame type specifies the encapsulation modes supported by the WTP. The following values are supported: =09 1 - Local Bridging: Local Bridging allows the WTP to perform the bridging function. This value MUST NOT be used when the WTP MAC Type is set to Split-MAC. =09 2 - 802.3 Bridging: 802.3 Bridging requires the WTP and AC to encapsulate all user payload as native IEEE 802.3 frames (see Section 4.2). This value MUST NOT be used when the WTP MAC Type is set to Split-MAC. =09 4 - Native Bridging: Native Bridging requires the WTP and AC to encapsulate all user payloads as native wireless frames, as defined by the wireless binding (see Section 4.2). =09 7 - All: The WTP is capable of supporting all frame encapsulation types. =09 To: =09 4.4.36. WTP Frame Encapsulation Type =09 The WTP Frame EncapsultationType message element allows the WTP to communicate the encapsulation type, or tunneling modes of operation which it supports to the AC. A WTP that advertises support for all types allows the AC to select which type will be used, based on its local policy. =09 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Frame Enc Type | +-+-+-+-+-+-+-+-+ =09 Type: 36 for WTP Frame Encapsulation Type =09 Length: 1 =09 Frame Encapsulation Type: The Frame type specifies the encapsulation modes supported by the WTP. The following values are supported: =09 1 - 802.3 Encapsulation: 802.3 Bridging requires the WTP and AC to encapsulate all user payload as native IEEE 802.3 frames (see Section 4.2). This value MUST NOT be used when the WTP MAC Type is set to Split-MAC. =09 2 - Native Encapsulation: Native Bridging requires the WTP and AC to encapsulate all user payloads as native wireless frames, as defined by the wireless binding (see Section 4.2). =09 3 - All: The WTP is capable of supporting both frame encapsulation types. =09 =09 3. Change State Event, now 4.4.11 - the first "case" reference, (duplicate text) has been deleted in draft -01. =09 =09 =09 ------_=_NextPart_001_01C6898C.E171CEDA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Recall=20 that folks asked for 802.3 tunneling as optional in local=20 MAC.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Tuesday, June 06, = 2006 9:17=20 AM
To: Pat Calhoun (pacalhou)
Cc:=20 capwap
Subject: Re: [Capwap] Proposed Rsolution Issue 81: = Minor=20 edits and questionsCAPWAP Protocol specification

Pat,

2. How=20 would a WTP communicate that it is capable of providing local bridging = services to the AC?

 Local Bridging:  = Local=20 Bridging allows the WTP to perform=20 the
         bridging=20 function.  This value MUST NOT be used when the=20 WTP
         MAC Type is = set to=20 Split-MAC.

What does "the local bridging function" mean? Based = on the=20 above (removed) definition, local bridging applies only
to = local-MAC cases,=20 and "allows the WTP to perform the
bridging function". This sounds = like=20 what any local-MAC WTP would already do, and
if so, it's not clear = that an=20 indication other than "local-MAC" provided in section 4.4.38,
" = WTP MAC=20 Type" is needed.

Or, is a different meaning=20 intended?

Thanks,

Dorothy


On 6/5/06, Pat Calhoun=20 (pacalhou) <pcalhoun@cisco.com> = wrote:
Dorothy,
 
My comments = (using your=20 numbering below).
1. ok with=20 change
2. How would = a WTP=20 communicate that it is capable of providing local bridging services = to the=20 AC?
3. ok with=20 change
 

Pat Calhoun
CTO, Wireless = Networking Business=20 Unit
Cisco Systems

 

From: Dorothy Stanley = [mailto:dstanley1389@gmail.com]
Sent: = Thursday, May=20 25, 2006 12:28 PM
To: capwap
Subject: [Capwap] = Proposed Rsolution Issue 81: Minor edits and questionsCAPWAP = Protocol=20 specification

All,

The proposed resolution to Issue 81 is = listed=20 below.

Comments=20 = welcome.

Thanks,

Dorothy
-------------------------------= ---------------------------------------------------

Issue=20 81:
Very Readable -- some minor comments

Page 33 -- =
Section 5.1 -- 5th paragraph

If a Discovery Response .... equal =
to SilentInterval before sending further 
Discovery Request =
messages.


change to


If a Discovery Response .... equal to =
SilentInterval before returning to the 
ide stand and sending further =
Discovery Request messages.


Section 5.1.5 WTP Frame Type -- =
Page 37 - Local Bridging



What do the frames look like -- do not understand what is =
sent or received.


Page 51 -- Top of Page -- Secton =
7.3.2

cause repeated twice -- delete 1st reference

1.=20 Page 33, Section 5.1 is the Discovery Request Message=20 definition

The proposed change is to the following=20 text:

   If a Discovery Response message is not = received=20 after sending the
   maximum number of Discovery = Request=20 messages, the WTP enters the
   Sulking state and = MUST wait=20 for an interval equal to SilentInterval
   before = sending=20 further Discovery Request messages.

Proposed resolution: In = the -01=20 state machine, the WTP remains
in the Discover state whle = determining=20 which AC to send the Join Request
message to, see the = description of=20 state (b), Discovery to Discovery.
Reject the proposed=20 change.

2. Section 5.1.4, WTP Frame Type is now section = 4.4.36,=20
WTP Frame Encapsulation Type, copied below. It is = unclear
why local=20 bridging is listed as a frame type/eccapsulation = type.

Recommended=20 change:

Change from:

4.4.36.  WTP Frame = Encapsulation=20 Type

   The WTP Frame EncapsultationType message = element=20 allows the WTP to
   communicate the encapsulation = type, or=20 tunneling modes of operation
   which it supports to = the=20 AC.  A WTP that advertises support for all
   = types=20 allows the AC to select which type will be used, based on=20 its
   local = policy.

     =20 0
      0 1 2 3 4 5 6=20 7
    =20 +-+-+-+-+-+-+-+-+
     |Frame Enc = Type =20 |
     = +-+-+-+-+-+-+-+-+

  =20 Type:  36 for WTP Frame Encapsulation = Type

  =20 Length:  1

   Frame Encapsulation = Type:  The=20 Frame type specifies the = encapsulation
     =20 modes supported by the WTP.  The following values are=20 supported:

      1 - Local = Bridging: =20 Local Bridging allows the WTP to perform=20 the
         bridging=20 function.  This value MUST NOT be used when the=20 WTP
         MAC Type = is set to=20 Split-MAC.

      2 - 802.3 = Bridging: =20 802.3 Bridging requires the WTP and AC=20 to
         encapsulate = all=20 user payload as native IEEE 802.3 frames=20 (see
         Section=20 4.2).  This value MUST NOT be used when the WTP=20 MAC
         Type is = set to=20 Split-MAC.

      4 - Native=20 Bridging:  Native Bridging requires the WTP and AC=20 to
         encapsulate = all=20 user payloads as native wireless frames,=20 as
         defined by = the=20 wireless binding (see Section = 4.2).

     =20 7 - All:  The WTP is capable of supporting all frame=20 encapsulation
        =20 types.

To:

4.4.36.  WTP Frame Encapsulation=20 Type

   The WTP Frame EncapsultationType message = element=20 allows the WTP to
   communicate the encapsulation = type, or=20 tunneling modes of operation
   which it supports to = the=20 AC.  A WTP that advertises support for all
   = types=20 allows the AC to select which type will be used, based on=20 its
   local = policy.

     =20 0
      0 1 2 3 4 5 6=20 7
    =20 +-+-+-+-+-+-+-+-+
     |Frame Enc = Type =20 |
     = +-+-+-+-+-+-+-+-+

  =20 Type:  36 for WTP Frame Encapsulation = Type

  =20 Length:  1

   Frame Encapsulation = Type:  The=20 Frame type specifies the = encapsulation
     =20 modes supported by the WTP.  The following values are=20 supported:

      1 - 802.3=20 Encapsulation:  802.3 Bridging requires the WTP and AC=20 to
         encapsulate = all=20 user payload as native IEEE 802.3 frames=20 (see
         Section=20 4.2).  This value MUST NOT be used when the WTP=20 MAC
         Type is = set to=20 Split-MAC.

      2 - Native=20 Encapsulation:  Native Bridging requires the WTP and AC=20 to
         encapsulate = all=20 user payloads as native wireless frames,=20 as
         defined by = the=20 wireless binding (see Section = 4.2).

     =20 3 - All:  The WTP is capable of supporting both frame=20 encapsulation
        =20 types.


3. Change State Event, now 4.4.11 - the first = "case"=20 reference, (duplicate
text) has been deleted in draft=20 = -01.



------_=_NextPart_001_01C6898C.E171CEDA-- --===============0827543990== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0827543990==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 14:08:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnfyJ-0004US-7r for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 14:08:07 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnfyH-00010h-8U for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 14:08:07 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C783B4301DF for ; Tue, 6 Jun 2006 11:08:04 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 92868430133 for ; Tue, 6 Jun 2006 11:07:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7F4D11448053 for ; Tue, 6 Jun 2006 11:07:27 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.204]) by hermes.tigertech.net (Postfix) with ESMTP id 3ED981448044 for ; Tue, 6 Jun 2006 11:07:22 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id t13so955586wxc for ; Tue, 06 Jun 2006 11:07:22 -0700 (PDT) Received: by 10.70.27.12 with SMTP id a12mr7858316wxa; Tue, 06 Jun 2006 11:07:21 -0700 (PDT) Received: by 10.70.133.2 with HTTP; Tue, 6 Jun 2006 11:07:21 -0700 (PDT) Message-ID: <5bfe7a820606061107gd85503cx863fd4bd39031e5a@mail.gmail.com> Date: Tue, 6 Jun 2006 11:07:21 -0700 From: "Dorothy Stanley" To: "Bob O'Hara (boohara)" In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC019D88D5@xmb-sjc-237.amer.cisco.com> MIME-Version: 1.0 References: <17B8C6DE4E228348B4939BDA6B05A9DC019D88D5@xmb-sjc-237.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.6 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_50_60, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1584595249==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd --===============1584595249== Content-Type: multipart/alternative; boundary="----=_Part_61585_4795961.1149617241596" ------=_Part_61585_4795961.1149617241596 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Bob, Perhaps we are talking about two different "same things". One function is to terminate the 802.11 encryption, another is to protect the CAPWAP data packets as they traverse the WTP to AC link. The later could be optionally provided by DTLS. The 802.11 local and split MAC architectures are intended to allow multiple options - including the ability to terminate the 802.11 encryption at the AC. My statement was that the ability to do this provides architectural flexibility to 802.11 systems and should not be removed. Use of DTLS to protect CAPWAP data packets is a separate, general CAPWAP capability. Dorothy On 6/6/06, Bob O'Hara (boohara) wrote: > > Dorothy, > > Given that protection of the CAPWAP data packet is (optionally) available > using DTLS in -01, why should we also include an optional binding-specific > protection mechanism that protects only the encapsulated 802.11 data > frame? This seems to me to be two ways to do the same thing, with one of > those ways available only when the binding is 802.11. > > I suggest that we standardize on the DTLS method, which would be available > to any binding and eliminate the 802.11-encrypted mechanism. > > -Bob > > > > ------------------------------ > *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] > *Sent:* Monday, June 05, 2006 5:04 PM > *To:* Pat Calhoun (pacalhou) > *Cc:* capwap@frascone.com > > *Subject:* Re: [Capwap] Encryption Capabilities > > > I do not agree with always requiring the WTP to provide wireless > encryption. The split MAC architecture allows 802.11 encryption/decryption > at either the WTP or the AC, and this flexibility should be retained, with > use of the > field in question clearly defined. > > Dorothy > > > On 6/5/06, Pat Calhoun (pacalhou) wrote: > > > Actually, this field was intended to allow the WTP to communicate > > whether it is capable of providing its capabilities, and therefore allow the > > AC to determine whether it should perform centralized encryption. However, > > with the transition to DTLS, I propose that we always require the WTP to > > provide wireless encryption, and use DTLS between the AC and the WTP. > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > ------------------------------ > > *From:* Michael Montemurro [mailto:montemurro.michael@gmail.com] > > > > *Sent:* Saturday, June 03, 2006 12:12 PM > > *To:* David T. Perkins > > *Cc:* capwap@frascone.com > > *Subject:* Re: [Capwap] Encryption Capabilities > > > > David, > > > > Would it be sufficient to move Encryption Capabilities from the WTP > > Descriptor (Section 4.4.34) to the WTP Radio Information message element > > (Section 4.4.39)? > > > > Mike > > > > > > On 6/3/06, Michael Montemurro wrote: > > > > > David, > > > > I've created issue 125 to track this issue. > > > > Mike > > > > > > On 6/1/06, David T. Perkins wrote: > > > > > HI, > > > > The "(4.4.34)WTP Descriptor" message element has the > > subfield "encryption capabilities". What is this used > > for? If for radios, then it should be per radio. If > > for the user data between the WTP and AC, then > > it doesn't seem appropriate to say the value is > > defined by "specific binding" definitions because > > the WTP can be supporting multiple radios with > > some that provide encryption services and some > > that don't. > > > > In general, I don't feel that this subfield is > > well defined, and it appears to me that it > > should be a per radio attribute. > > > > Regards, > > /david t. perkins > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > ------=_Part_61585_4795961.1149617241596 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Bob,

Perhaps we are talking about two different "same things".
One  function is to terminate the 802.11 encryption, another is
to protect the CAPWAP data packets as they traverse the WTP to AC link.
The later could be optionally provided by DTLS.

The 802.11 local and split MAC architectures are intended to allow
multiple options  - including the ability to terminate the 802.11 encryption at the
AC.  My statement was that the ability to do this provides architectural flexibility
to 802.11 systems and should not be removed.

Use of DTLS to protect CAPWAP data packets is a separate, general CAPWAP capability.

Dorothy


On 6/6/06, Bob O'Hara (boohara) <boohara@cisco.com> wrote:
Dorothy,
 
Given that protection of the CAPWAP data packet is (optionally) available using DTLS in -01, why should we also include an optional binding-specific protection mechanism that protects only the encapsulated 802.11 data frame?  This seems to me to be two ways to do the same thing, with one of those ways available only when the binding is 802.11.
 
I suggest that we standardize on the DTLS method, which would be available to any binding and eliminate the 802.11-encrypted mechanism.

 -Bob
 

 

From: Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Monday, June 05, 2006 5:04 PM
To: Pat Calhoun (pacalhou)
Cc: capwap@frascone.com

Subject: Re: [Capwap] Encryption Capabilities


I do not agree with always requiring the WTP to provide wireless
encryption. The split MAC architecture allows 802.11 encryption/decryption
at either the WTP or the AC, and this flexibility should be retained, with use of the
field in question clearly defined.

Dorothy


On 6/5/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
Actually, this field was intended to allow the WTP to communicate whether it is capable of providing its capabilities, and therefore allow the AC to determine whether it should perform centralized encryption. However, with the transition to DTLS, I propose that we always require the WTP to provide wireless encryption, and use DTLS between the AC and the WTP.
 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

From: Michael Montemurro [mailto:montemurro.michael@gmail.com ]

Sent: Saturday, June 03, 2006 12:12 PM
To: David T. Perkins
Cc: capwap@frascone.com
Subject: Re: [Capwap] Encryption Capabilities

David,
 
Would it be sufficient to move Encryption Capabilities from the WTP Descriptor (Section 4.4.34) to the WTP Radio Information message element (Section 4.4.39)?
 
Mike

 
On 6/3/06, Michael Montemurro <montemurro.michael@gmail.com> wrote:
David,

I've created issue 125 to track this issue.
 
Mike

 
On 6/1/06, David T. Perkins <dperkins@dsperkins.com > wrote:
HI,

The "(4.4.34)WTP Descriptor" message element has the
subfield "encryption capabilities". What is this used
for? If for radios, then it should be per radio. If
for the user data between the WTP and AC, then
it doesn't seem appropriate to say the value is
defined by "specific binding" definitions because
the WTP can be supporting multiple radios with
some that provide encryption services and some
that don't.

In general, I don't feel that this subfield is
well defined, and it appears to me that it
should be a per radio attribute.

Regards,
/david t. perkins

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap




------=_Part_61585_4795961.1149617241596-- --===============1584595249== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1584595249==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 14:27:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FngGf-0005yA-Mf for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 14:27:05 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FngGe-0002XT-6T for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 14:27:05 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 96A434301F8 for ; Tue, 6 Jun 2006 11:27:03 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 30211430133 for ; Tue, 6 Jun 2006 11:26:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0D5381448059 for ; Tue, 6 Jun 2006 11:26:43 -0700 (PDT) X-Greylist-Status: Bypassed (other successful deliveries from server) Received: from rwcrmhc15.comcast.net (unknown [216.148.227.155]) by hermes.tigertech.net (Postfix) with ESMTP id 710FA1448027 for ; Tue, 6 Jun 2006 11:26:40 -0700 (PDT) Received: from ceili (c-66-30-121-250.hsd1.ma.comcast.net[66.30.121.250]) by comcast.net (rwcrmhc15) with SMTP id <20060606182638m15000pksje>; Tue, 6 Jun 2006 18:26:39 +0000 From: "Margaret Wasserman" To: Date: Tue, 6 Jun 2006 14:26:38 -0400 Message-ID: <013d01c68996$c0b1df20$791fa8c0@corp.devicescape.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaJli5fhSGaTjnISAuRK+fpjTsQFA== X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [Capwap] RC4 Encryption? X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Hi All, I tried to send a message to the list on this topic a while back, but I don't think it ever went out... Sorry if this is a duplicate. I have a possible application for CAPWAP that involves running the WTP portion on a DSP-only device. In that situation, it will be very difficult to support AES encryption, due to the processing overhead. Would the WG consider supporting a lighter weight algorithm for encryption, such as RC4? We could state that AES is preferred when possible, but make RC4 an accepted option in cases where the hardware would not support the processing overhead of AES encryption. Thoughts? Margaret _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 14:27:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FngHQ-0007Pn-16 for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 14:27:52 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FngHO-0002Zj-Ku for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 14:27:52 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 44CCC430221 for ; Tue, 6 Jun 2006 11:27:50 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 57C654301EF for ; Tue, 6 Jun 2006 11:27:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 44F82144802F for ; Tue, 6 Jun 2006 11:27:11 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9268B1448054 for ; Tue, 6 Jun 2006 11:27:08 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k56IR81d010306 for ; Tue, 6 Jun 2006 11:27:08 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k56IR6i8010298 for ; Tue, 6 Jun 2006 11:27:08 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 6 Jun 2006 11:27:06 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [Capwap] 802.11 WTP mode and type X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 HI, In section 11.9.3 is a table of 802.11 message elements. I can't figure out the section number for element IEEE 802.11 WTP Mode and Type Has this been obsoleted, and thus, should be removed from the table? Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 14:31:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FngL1-0000VJ-6Q for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 14:31:35 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FngKy-00032I-Mo for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 14:31:35 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3AAB9430224 for ; Tue, 6 Jun 2006 11:31:32 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D2A97430133 for ; Tue, 6 Jun 2006 11:31:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id B5AB6398069 for ; Tue, 6 Jun 2006 11:31:04 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id E9B3B398086 for ; Tue, 6 Jun 2006 11:31:01 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Jun 2006 11:31:01 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k56IV1JB019125; Tue, 6 Jun 2006 11:31:01 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k56IV19u010061; Tue, 6 Jun 2006 11:31:01 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Jun 2006 11:31:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jun 2006 11:31:00 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201FC0964@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] RC4 Encryption? Thread-Index: AcaJli5fhSGaTjnISAuRK+fpjTsQFAAAScjw From: "Pat Calhoun (pacalhou)" To: "Margaret Wasserman" , X-OriginalArrivalTime: 06 Jun 2006 18:31:01.0254 (UTC) FILETIME=[5C8E6260:01C68997] Authentication-Results: sj-dkim-3.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] RC4 Encryption? X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Margaret, Are you asking in terms of DTLS support? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Margaret Wasserman [mailto:MRW@devicescape.com] > Sent: Tuesday, June 06, 2006 11:27 AM > To: capwap@frascone.com > Subject: [Capwap] RC4 Encryption? > > > Hi All, > > I tried to send a message to the list on this topic a while > back, but I don't think it ever went out... Sorry if this is > a duplicate. > > I have a possible application for CAPWAP that involves > running the WTP portion on a DSP-only device. In that > situation, it will be very difficult to support AES > encryption, due to the processing overhead. > > Would the WG consider supporting a lighter weight algorithm > for encryption, such as RC4? We could state that AES is > preferred when possible, but make > RC4 an accepted option in cases where the hardware would not > support the processing overhead of AES encryption. > > Thoughts? > > Margaret > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 14:32:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FngML-0000cS-Nl for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 14:32:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FngGd-0002Wi-T5 for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 14:27:03 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fng6U-0008WT-Ij for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 14:16:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 32B7B43015B for ; Tue, 6 Jun 2006 11:16:33 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4BF6943012E for ; Tue, 6 Jun 2006 11:15:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2E6F51448055 for ; Tue, 6 Jun 2006 11:15:53 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by hermes.tigertech.net (Postfix) with ESMTP id 119561448054 for ; Tue, 6 Jun 2006 11:15:49 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id t13so956977wxc for ; Tue, 06 Jun 2006 11:15:48 -0700 (PDT) Received: by 10.70.113.20 with SMTP id l20mr7916216wxc; Tue, 06 Jun 2006 11:15:48 -0700 (PDT) Received: by 10.70.133.2 with HTTP; Tue, 6 Jun 2006 11:15:48 -0700 (PDT) Message-ID: <5bfe7a820606061115w545e6b3bhbc2eb71e29fb44f1@mail.gmail.com> Date: Tue, 6 Jun 2006 11:15:48 -0700 From: "Dorothy Stanley" To: "David T. Perkins" In-Reply-To: MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A201FC0873@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.6 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] New Issue - Local MAC MUST vs MAY forward associationrequest messages X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1521401830==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -1.7 (-) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 --===============1521401830== Content-Type: multipart/alternative; boundary="----=_Part_61789_6087742.1149617748607" ------=_Part_61789_6087742.1149617748607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Pat, David, Your comments are consistent with those received back in April, when this mail was sent out - thus I did not make, and had not planned to make the proposed change. Thanks, Dorothy On 6/6/06, David T. Perkins wrote: > > HI, > > ABSOLUTELY agree with Pat. That is the AC MUST know what STAs > are be serviced by the WTPs, and MUST decide which STAs are > allowed to associate and send traffic. > This is the fundamental difference between a CAPWAP network > and a collection of APs. > > Regards, > /david t. perkins > > On Tue, 6 Jun 2006, Pat Calhoun (pacalhou) wrote: > > > I disagree with this change request. The AC MUST know what STAs are > > being serviced by WTPs. The term MUST cannot be changed to MAY. > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > > ________________________________ > > > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > > Sent: Tuesday, April 11, 2006 11:41 AM > > To: capwap > > Subject: [Capwap] New Issue - Local MAC MUST vs MAY forward > > associationrequest messages > > > > > > All, > > > > Section 11.1.2 Local MAC describes the Local MAC operation. It > > currently states > > (second paragraph below Figure 6): > > > > While the MAC is terminated on the WTP, it is necessary for the > > AC to be aware of mobility events within the WTPs. > > As a consequence, the WTP MUST forward the IEEE 802.11 > > Association Requests to the AC, and the AC MAY reply > > with a failed Association Response if it deems it necessary. > > > > > > Since this is the Local MAC case, it seems that a MAY should be > > sufficient. > > > > Recommended change: > > > > The MAC is terminated on the WTP, but the AC may need to be > > aware of mobility events within the WTPs. > > As a consequence, the WTP MAY forward the IEEE 802.11 > > Association Requests to the AC, and the AC MAY reply > > with a failed Association Response. > > > > Comments? > > > > Thanks, > > > > Dorothy > > > > > > > > ------=_Part_61789_6087742.1149617748607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Pat, David,
 
Your comments are consistent with those received back in April, when
this mail was sent out - thus
I did not make, and had not planned to make the proposed change.
 
Thanks,
 
Dorothy

 
On 6/6/06, David T. Perkins <dperkins@dsperkins.com> wrote:
HI,

ABSOLUTELY agree with Pat. That is the AC MUST know what STAs
are be serviced by the WTPs, and MUST decide which STAs are
allowed to associate and send traffic.
This is the fundamental difference between a CAPWAP network
and a collection of APs.

Regards,
/david t. perkins

On Tue, 6 Jun 2006, Pat Calhoun (pacalhou) wrote:

> I disagree with this change request. The AC MUST know what STAs are
> being serviced by WTPs. The term MUST cannot be changed to MAY.
>
>
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
>
>
>
>
> ________________________________
>
>       From: Dorothy Stanley [mailto:dstanley1389@gmail.com]
>       Sent: Tuesday, April 11, 2006 11:41 AM
>       To: capwap
>       Subject: [Capwap] New Issue - Local MAC MUST vs MAY forward
> associationrequest messages
>
>
>       All,
>
>       Section 11.1.2 Local MAC describes the Local MAC operation. It
> currently states
>       (second paragraph below Figure 6):
>
>       While the MAC is terminated on the WTP, it is necessary for the
> AC to be aware of mobility events within the WTPs.
>       As a consequence, the WTP MUST forward the IEEE 802.11
> Association Requests to the AC, and the AC MAY reply
>       with a failed Association Response if it deems it necessary.
>
>
>       Since this is the Local MAC case, it seems that a MAY should be
>       sufficient.
>
>       Recommended change:
>
>       The MAC is terminated on the WTP, but the AC may need to be
> aware of mobility events within the WTPs.
>       As a consequence, the WTP MAY forward the IEEE 802.11
> Association Requests to the AC, and the AC MAY reply
>       with a failed Association Response.
>
>       Comments?
>
>       Thanks,
>
>       Dorothy
>
>
>


------=_Part_61789_6087742.1149617748607-- --===============1521401830== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1521401830==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 16:01:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnhjd-0004tu-CQ for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 16:01:05 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnhjb-0000Uc-EX for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 16:01:05 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 36C204300E9 for ; Tue, 6 Jun 2006 13:01:02 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1C47A4300E9 for ; Tue, 6 Jun 2006 13:00:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0728239808E for ; Tue, 6 Jun 2006 13:00:41 -0700 (PDT) Received: from raman.networkresonance.com (raman.networkresonance.com [198.144.196.3]) by zoidberg.tigertech.net (Postfix) with ESMTP id 50F4E398090 for ; Tue, 6 Jun 2006 13:00:37 -0700 (PDT) Received: by raman.networkresonance.com (Postfix, from userid 1001) id 78B351E8C1C; Tue, 6 Jun 2006 13:00:37 -0700 (PDT) To: "Margaret Wasserman" References: <013d01c68996$c0b1df20$791fa8c0@corp.devicescape.com> From: Eric Rescorla Date: Tue, 06 Jun 2006 13:00:37 -0700 In-Reply-To: <013d01c68996$c0b1df20$791fa8c0@corp.devicescape.com> (Margaret Wasserman's message of "Tue, 6 Jun 2006 14:26:38 -0400") Message-ID: <86verevyu2.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] RC4 Encryption? X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: EKR List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 "Margaret Wasserman" writes: > Hi All, > > I tried to send a message to the list on this topic a while back, but I > don't think it ever went out... Sorry if this is a duplicate. > > I have a possible application for CAPWAP that involves running the WTP > portion on a DSP-only device. In that situation, it will be very difficult > to support AES encryption, due to the processing overhead. > > Would the WG consider supporting a lighter weight algorithm for encryption, > such as RC4? We could state that AES is preferred when possible, but make > RC4 an accepted option in cases where the hardware would not support the > processing overhead of AES encryption. > > Thoughts? Stream ciphers like RC4 are hard to use correctly in unreliable environments (i.e., where packets may be lost). Pretty much at minimum you need to generate a new key schedule for each packet. Doing this securely with RC4 pretty much requires using a secure KDF (e.g., HMAC) to generate the per-packet key. Failure to do this was one of the problems with WEP [0]. A secondary problem with RC4 is that there are known biases in the initial ciphertext bytes [1] which means that new designs should really discard the first 1K or so, if they use RC4 at all. On commodity processors (I don't know about DSPs so I'd be happy to see new numbers), AES is about 50% as fast as RC4, so when you factor in the additional work (both computational and design) you need to do to use RC4 safely, I doubt it's worth it. -Ekr [0] Weaknesses in the Key Scheduling Algorithm of RC4, Fluhrer, Mantin and Shamir, SAC 2001 [1] Ilya Mironov, (Not So) Random Shuffles of RC4. CRYPTO 2002. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 22:30:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnnox-0000wj-MT for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 22:30:59 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnnov-0006vl-85 for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 22:30:59 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DDDC94300F9 for ; Tue, 6 Jun 2006 19:30:56 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1FB89430085 for ; Tue, 6 Jun 2006 19:30:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0E70D39803E for ; Tue, 6 Jun 2006 19:30:33 -0700 (PDT) Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by zoidberg.tigertech.net (Postfix) with ESMTP id 26A58398011 for ; Tue, 6 Jun 2006 19:30:29 -0700 (PDT) Received: from [127.0.0.1] (really [24.75.172.194]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060607023024.TMHT27996.mta10.adelphia.net@[127.0.0.1]>; Tue, 6 Jun 2006 22:30:24 -0400 Message-ID: <44863A61.7010202@cs.umd.edu> Date: Tue, 06 Jun 2006 22:30:57 -0400 From: Charles Clancy User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman References: <013d01c68996$c0b1df20$791fa8c0@corp.devicescape.com> In-Reply-To: <013d01c68996$c0b1df20$791fa8c0@corp.devicescape.com> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.373 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] RC4 Encryption? X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Are you suggesting adding DTLS ciphersuites such as TLS_RSA_WITH_RC4_128_SHA and TLS_PSK_WITH_RC4_128_SHA? There's a fundamental problem when using RC4 with DTLS (that incidentally does not appear to be addressed in RFC 4279). In particular, we seed the KDF and use its never-ending output to encrypt data by XORing it with the plaintext packets. However in DTLS, we can lose packets. This means gaps in the keystream, and the key states become out of sync. The only way to fix this is to do what WEP did, with per-packet IVs, and then you get all the same problems found in WEP. So, as-is, RC4 ciphersuites don't work well with DTLS, and if we fix them, we introduce security problems. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy Margaret Wasserman wrote: > Hi All, > > I tried to send a message to the list on this topic a while back, but I > don't think it ever went out... Sorry if this is a duplicate. > > I have a possible application for CAPWAP that involves running the WTP > portion on a DSP-only device. In that situation, it will be very difficult > to support AES encryption, due to the processing overhead. > > Would the WG consider supporting a lighter weight algorithm for encryption, > such as RC4? We could state that AES is preferred when possible, but make > RC4 an accepted option in cases where the hardware would not support the > processing overhead of AES encryption. > > Thoughts? > > Margaret > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 22:54:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnoBP-0003s0-Sj for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 22:54:11 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnnKf-0003R1-IF for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 21:59:41 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fnn78-00074C-2e for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 21:45:43 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A80D94300DD for ; Tue, 6 Jun 2006 18:45:40 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E52BA430054 for ; Tue, 6 Jun 2006 18:45:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id DA67B398039 for ; Tue, 6 Jun 2006 18:45:12 -0700 (PDT) Received: from mgw-ext14.nokia.com (mgw-ext14.nokia.com [131.228.20.173]) by zoidberg.tigertech.net (Postfix) with ESMTP id F0E37398011 for ; Tue, 6 Jun 2006 18:45:09 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k571iwCs000799; Wed, 7 Jun 2006 04:45:06 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 04:45:00 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jun 2006 20:44:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jun 2006 18:44:52 -0700 Message-ID: <893AE265F4ADF94AB7FB26D31A788E4102295E7E@mvebe101.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New mux header for CAPWAP Thread-Index: AcaJ0/iIUlcV3UUgRz+e4ctlG4c80g== From: To: X-OriginalArrivalTime: 07 Jun 2006 01:44:54.0692 (UTC) FILETIME=[F9B1C640:01C689D3] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.265 tagged_above=-999 required=7 tests=HTML_40_50, HTML_MESSAGE, NO_REAL_NAME X-Spam-Level: Subject: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1515920439==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b This is a multi-part message in MIME format. --===============1515920439== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C689D3.F9A4608F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C689D3.F9A4608F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The CAPWAP editors have asked the Chairs to resolve the Mux vs Multiport issue # 115, in order to progress the specification. Based on the discussion that has taken place the chairs are in agreement the simplest, cleanest solution for this is to add a Mux header. Barring any unforseen events, we will instruct the editors resolve in favor of a new Mux header. We intend to close this issue by the end of the week, Friday, 6/9. Please review the issue and send any constructive comments to the list by Friday.=20 Best Regards, Dorothy ------_=_NextPart_001_01C689D3.F9A4608F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New mux header for CAPWAP

The CAPWAP editors have asked the = Chairs to resolve the Mux vs Multiport issue # 115, in order to progress = the specification.  Based on the discussion that has taken place = the chairs are in agreement the simplest, cleanest solution for this is = to add a Mux header.  Barring any unforseen events, we will = instruct the editors resolve in favor of a new Mux header.

We intend to close this issue by the = end of the week, Friday, 6/9.  Please review the issue and send any = constructive comments to the list by Friday.

Best Regards,
Dorothy




------_=_NextPart_001_01C689D3.F9A4608F-- --===============1515920439== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1515920439==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 22:57:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnoEA-0004cv-2K for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 22:57:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnoEA-0002rG-0s for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 22:57:02 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FnoAe-0007tu-CV for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 22:53:30 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0A422430109 for ; Tue, 6 Jun 2006 19:53:23 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 24BCE430054 for ; Tue, 6 Jun 2006 19:52:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 133221448018 for ; Tue, 6 Jun 2006 19:52:55 -0700 (PDT) Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by hermes.tigertech.net (Postfix) with ESMTP id F0204144801C for ; Tue, 6 Jun 2006 19:52:52 -0700 (PDT) Received: from [127.0.0.1] (really [24.75.172.194]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060607025252.NSVC21801.mta9.adelphia.net@[127.0.0.1]>; Tue, 6 Jun 2006 22:52:52 -0400 Message-ID: <44863FA4.6060500@cs.umd.edu> Date: Tue, 06 Jun 2006 22:53:24 -0400 From: Charles Clancy User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <4FF84B0BC277FF45AA27FE969DD956A201FC08B9@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201FC08B9@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Removing centralized encryption doesn't change the security properties of CAPWAP. HOWEVER, if you really want packets encrypted all the way to the AC, and you remove centralized encryption, your WTPs first have to decrypt the 802.11 packet, and then re-encrypt it for DTLS transport. This seems like a lot of extra processor time for devices that need to be cheap and disposable. For example, OpenSSL on my dual 2.8GHz P4 machine can process AES at roughly 424Mbps [1]. An embedded device with 1/10 my processing power could only keep up with a 21.2 Mbps data flow. [1] openssl speed -elapsed -evp aes-128-cbc -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy Pat Calhoun (pacalhou) wrote: > But what we end up doing is providing two means to do the exact same > thing. I admit that I was surprised when the optional DTLS support was > added for data frames in the CAPWAP draft. However, having thought > through the impact of this change, it actually does address the previous > issues I had raised against centralized 802.11i security, which are: > > 1. By encrypting at the AC, how does one support 802.11e (specifically > frame fragmentation to fit a service period) > 2. How does the AC provide 802.11n A-MPDU/MSDU aggregation? > > So I would propose we define one way, and I prefer the DTLS mechanism as > it doesn't introduce any issues in supporting any 802.11 feature. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > ------------------------------------------------------------------------ > *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] > *Sent:* Monday, June 05, 2006 5:04 PM > *To:* Pat Calhoun (pacalhou) > *Cc:* Michael Montemurro; David T. Perkins; capwap@frascone.com > *Subject:* Re: [Capwap] Encryption Capabilities > > > I do not agree with always requiring the WTP to provide wireless > encryption. The split MAC architecture allows 802.11 > encryption/decryption > at either the WTP or the AC, and this flexibility should be > retained, with use of the > field in question clearly defined. > > Dorothy > > > On 6/5/06, *Pat Calhoun (pacalhou)* > wrote: > > Actually, this field was intended to allow the WTP to > communicate whether it is capable of providing its capabilities, > and therefore allow the AC to determine whether it should > perform centralized encryption. However, with the transition to > DTLS, I propose that we always require the WTP to provide > wireless encryption, and use DTLS between the AC and the WTP. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > ------------------------------------------------------------------------ > *From:* Michael Montemurro > [mailto:montemurro.michael@gmail.com > ] > *Sent:* Saturday, June 03, 2006 12:12 PM > *To:* David T. Perkins > *Cc:* capwap@frascone.com > *Subject:* Re: [Capwap] Encryption Capabilities > > David, > > Would it be sufficient to move Encryption Capabilities from the > WTP Descriptor (Section 4.4.34) to the WTP Radio Information > message element (Section 4.4.39)? > > Mike > > > On 6/3/06, *Michael Montemurro* > wrote: > > David, > > I've created issue 125 to track this issue. > > Mike > > > On 6/1/06, *David T. Perkins* > wrote: > > HI, > > The "(4.4.34)WTP Descriptor" message element has the > subfield "encryption capabilities". What is this used > for? If for radios, then it should be per radio. If > for the user data between the WTP and AC, then > it doesn't seem appropriate to say the value is > defined by "specific binding" definitions because > the WTP can be supporting multiple radios with > some that provide encryption services and some > that don't. > > In general, I don't feel that this subfield is > well defined, and it appears to me that it > should be a per radio attribute. > > Regards, > /david t. perkins > > _________________________________________________________________ > To unsubscribe or modify your subscription options, > please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > ------------------------------------------------------------------------ > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 22:59:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnoGA-0005Cg-Pl for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 22:59:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnoGA-0003Hd-Nl for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 22:59:06 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FnoG8-0007zP-PF for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 22:59:06 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0842343012E for ; Tue, 6 Jun 2006 19:59:04 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id BF017430054 for ; Tue, 6 Jun 2006 19:58:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A8C5439801D for ; Tue, 6 Jun 2006 19:58:41 -0700 (PDT) Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by zoidberg.tigertech.net (Postfix) with ESMTP id B06D5398011 for ; Tue, 6 Jun 2006 19:58:38 -0700 (PDT) Received: from [127.0.0.1] (really [24.75.172.194]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060607025837.PDLJ10985.mta13.adelphia.net@[127.0.0.1]>; Tue, 6 Jun 2006 22:58:37 -0400 Message-ID: <448640FE.8020200@cs.umd.edu> Date: Tue, 06 Jun 2006 22:59:10 -0400 From: Charles Clancy User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: capwap@frascone.com References: <013d01c68996$c0b1df20$791fa8c0@corp.devicescape.com> <44863A61.7010202@cs.umd.edu> In-Reply-To: <44863A61.7010202@cs.umd.edu> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.373 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS X-Spam-Level: Cc: Margaret Wasserman Subject: Re: [Capwap] RC4 Encryption (correction)? X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Err... I cited the wrong RFC below. I meant 4347, and it is addressed: "The only stream cipher described in TLS 1.1 is RC4, which cannot be randomly accessed. RC4 MUST NOT be used with DTLS." -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy Charles Clancy wrote: > Are you suggesting adding DTLS ciphersuites such as > TLS_RSA_WITH_RC4_128_SHA and TLS_PSK_WITH_RC4_128_SHA? > > There's a fundamental problem when using RC4 with DTLS (that > incidentally does not appear to be addressed in RFC 4279). In > particular, we seed the KDF and use its never-ending output to encrypt > data by XORing it with the plaintext packets. However in DTLS, we can > lose packets. This means gaps in the keystream, and the key states > become out of sync. The only way to fix this is to do what WEP did, > with per-packet IVs, and then you get all the same problems found in WEP. > > So, as-is, RC4 ciphersuites don't work well with DTLS, and if we fix > them, we introduce security problems. > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 06 23:28:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnoiq-0003wH-Ak for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 23:28:44 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnoio-0004oB-Tu for capwap-archive@lists.ietf.org; Tue, 06 Jun 2006 23:28:44 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0F06543010D for ; Tue, 6 Jun 2006 20:28:42 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 68197430054 for ; Tue, 6 Jun 2006 20:28:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5372B398011 for ; Tue, 6 Jun 2006 20:28:22 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 406BC39803E for ; Tue, 6 Jun 2006 20:28:18 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060308/3.7W/jazz) with ESMTP id k573S7oX012289; Wed, 7 Jun 2006 12:28:07 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k573S7Q16143; Wed, 7 Jun 2006 12:28:07 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id k573S6j05818; Wed, 7 Jun 2006 12:28:06 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 7 Jun 2006 11:21:39 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDEEEEB7@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] 802.11 WTP mode and type Thread-Index: AcaJlp75FVNm0IjuTbiI9OmPwap4/wAS9FQg From: "Saravanan Govindan" To: "David T. Perkins" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Subject: Re: [Capwap] 802.11 WTP mode and type X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 I think "WTP Mode" and "WTP Type" have been replaced by "MAC Mode" and "Tunnel Mode" - both in Section 11.10.1 (IEEE 802.11 Add WLAN) in v01. Cheers, Saravanan -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Wednesday, June 07, 2006 2:27 AM To: capwap@frascone.com Subject: [Capwap] 802.11 WTP mode and type HI, In section 11.9.3 is a table of 802.11 message elements. I can't figure out the section number for element IEEE 802.11 WTP Mode and Type Has this been obsoleted, and thus, should be removed from the table? Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 00:43:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnptP-0000oH-G1 for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 00:43:43 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnptN-0006Ed-OL for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 00:43:43 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CA2D9430116 for ; Tue, 6 Jun 2006 21:43:40 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 6773E430054 for ; Tue, 6 Jun 2006 21:43:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4CCE0144800A for ; Tue, 6 Jun 2006 21:43:11 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id 1BCA4144801D for ; Tue, 6 Jun 2006 21:43:06 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 06 Jun 2006 21:43:05 -0700 X-IronPort-AV: i="4.05,215,1146466800"; d="scan'208"; a="290244021:sNHT1189319796" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k574h5tH014271; Tue, 6 Jun 2006 21:43:05 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k574h5cL021359; Tue, 6 Jun 2006 21:43:05 -0700 (PDT) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Jun 2006 21:43:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jun 2006 21:43:03 -0700 Message-ID: <08A9A3213527A6428774900A80DBD8D8020B03A6@xmb-sjc-222.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Encryption Capabilities Thread-Index: AcaJ3Y84crkqQJnUSaC6EDFvApp+RgABmatw From: "Nancy Winget (ncamwing)" To: "Charles Clancy" , "Pat Calhoun (pacalhou)" X-OriginalArrivalTime: 07 Jun 2006 04:43:04.0809 (UTC) FILETIME=[DD802D90:01C689EC] Authentication-Results: sj-dkim-5.cisco.com; header.From=ncamwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Charles, I think I agree with you though I'm not sure I understand the full thread. It seems that the current email thread is mixing the securing of different transport layers, e.g. CAPWAP with that of 802.11i. 802.11i is designed to afford protection of the 802.11 transport layer, providing both packet confidentiality and authentication; but it does not address securing the CAPWAP transport layer. An obvious example of this is that the CAPWAP header is not authenticated! So whether the 802.11i crypto is done either at the WTP or AC should be construed as a different feature than that of securing the CAPWAP transport layer. Also, I do not understand what the notion of "centralized" encryption is as the client has no clue of the topology or architecture behind the AP? >From a threat model, if we are intending to address secure transport of data packets within CAPWAP, doing 802.11i at the AC does not address this requirement, CAPWAP must secure its own encapsulation as well. That is why the draft includes the option of establishing a DTLS tunnel for its data transport. Nancy. -----Original Message----- From: Charles Clancy [mailto:clancy@cs.umd.edu] Sent: Tuesday, June 06, 2006 7:53 PM To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities Removing centralized encryption doesn't change the security properties of CAPWAP. HOWEVER, if you really want packets encrypted all the way to the AC, and you remove centralized encryption, your WTPs first have to decrypt the 802.11 packet, and then re-encrypt it for DTLS transport. This seems like a lot of extra processor time for devices that need to be cheap and disposable. For example, OpenSSL on my dual 2.8GHz P4 machine can process AES at roughly 424Mbps [1]. An embedded device with 1/10 my processing power could only keep up with a 21.2 Mbps data flow. [1] openssl speed -elapsed -evp aes-128-cbc -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy Pat Calhoun (pacalhou) wrote: > But what we end up doing is providing two means to do the exact same > thing. I admit that I was surprised when the optional DTLS support was > added for data frames in the CAPWAP draft. However, having thought > through the impact of this change, it actually does address the > previous issues I had raised against centralized 802.11i security, which are: > > 1. By encrypting at the AC, how does one support 802.11e (specifically > frame fragmentation to fit a service period) 2. How does the AC > provide 802.11n A-MPDU/MSDU aggregation? > > So I would propose we define one way, and I prefer the DTLS mechanism > as it doesn't introduce any issues in supporting any 802.11 feature. > > Pat Calhoun > CTO, Wireless Networking Business Unit Cisco Systems > > > > ------------------------------------------------------------------------ > *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] > *Sent:* Monday, June 05, 2006 5:04 PM > *To:* Pat Calhoun (pacalhou) > *Cc:* Michael Montemurro; David T. Perkins; capwap@frascone.com > *Subject:* Re: [Capwap] Encryption Capabilities > > > I do not agree with always requiring the WTP to provide wireless > encryption. The split MAC architecture allows 802.11 > encryption/decryption > at either the WTP or the AC, and this flexibility should be > retained, with use of the > field in question clearly defined. > > Dorothy > > > On 6/5/06, *Pat Calhoun (pacalhou)* > wrote: > > Actually, this field was intended to allow the WTP to > communicate whether it is capable of providing its capabilities, > and therefore allow the AC to determine whether it should > perform centralized encryption. However, with the transition to > DTLS, I propose that we always require the WTP to provide > wireless encryption, and use DTLS between the AC and the WTP. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > ------------------------------------------------------------------------ > *From:* Michael Montemurro > [mailto:montemurro.michael@gmail.com > ] > *Sent:* Saturday, June 03, 2006 12:12 PM > *To:* David T. Perkins > *Cc:* capwap@frascone.com > *Subject:* Re: [Capwap] Encryption Capabilities > > David, > > Would it be sufficient to move Encryption Capabilities from the > WTP Descriptor (Section 4.4.34) to the WTP Radio Information > message element (Section 4.4.39)? > > Mike > > > On 6/3/06, *Michael Montemurro* > wrote: > > David, > > I've created issue 125 to track this issue. > > Mike > > > On 6/1/06, *David T. Perkins* > wrote: > > HI, > > The "(4.4.34)WTP Descriptor" message element has the > subfield "encryption capabilities". What is this used > for? If for radios, then it should be per radio. If > for the user data between the WTP and AC, then > it doesn't seem appropriate to say the value is > defined by "specific binding" definitions because > the WTP can be supporting multiple radios with > some that provide encryption services and some > that don't. > > In general, I don't feel that this subfield is > well defined, and it appears to me that it > should be a per radio attribute. > > Regards, > /david t. perkins > > _________________________________________________________________ > To unsubscribe or modify your subscription options, > please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > ---------------------------------------------------------------------- > -- > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 01:22:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnqVP-0002GH-GU for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 01:22:59 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnqTQ-0001VA-A8 for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 01:20:58 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DDB9343010C for ; Tue, 6 Jun 2006 22:20:55 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3CFAF430054 for ; Tue, 6 Jun 2006 22:20:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2DC2C398036 for ; Tue, 6 Jun 2006 22:20:05 -0700 (PDT) X-Greylist-Status: Sender first seen 2 mons 15 days 11:46:03 ago Received: from sinett.com (63-197-255-151.ded.pacbell.net [63.197.255.151]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1054E398008 for ; Tue, 6 Jun 2006 22:20:01 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 6 Jun 2006 22:20:01 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Encryption Capabilities Thread-Index: AcaJ3YK9qrrN6Qn9SmG5SFPUpapyngAE6+z7 References: <4FF84B0BC277FF45AA27FE969DD956A201FC08B9@xmb-sjc-235.amer.cisco.com> <44863FA4.6060500@cs.umd.edu> From: "Abhijit Choudhury" To: "Charles Clancy" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.146 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO, HTML_50_60, HTML_MESSAGE X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0634005238==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: ee8eaa76ea6a4fb3ccc9059a3f656ffc This is a multi-part message in MIME format. --===============0634005238== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C689F2.06A45493" This is a multi-part message in MIME format. ------_=_NextPart_001_01C689F2.06A45493 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Charles, I agree with you. I don't see why this option needs to be removed. =20 =20 As you have noted, DTLS in the data path is going to require the WTPs to seriously beef up their crypto capabilities, especially with 802.11n around the corner. Terminating roughly 300-350Mbps of 802.11i encryption traffic and then re-encrypting it for DTLS is going to be a challenge at low cost points. =20 It's amusing that within a span of roughly 2 years we have gone from "fat" APs to "fit" APs and now to "weight-lifter" APs. :-) =20 Abhijit =20 ________________________________ From: Charles Clancy [mailto:clancy@cs.umd.edu] Sent: Tue 6/6/2006 7:53 PM To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities Removing centralized encryption doesn't change the security properties of CAPWAP. HOWEVER, if you really want packets encrypted all the way to the AC, and you remove centralized encryption, your WTPs first have to decrypt the 802.11 packet, and then re-encrypt it for DTLS transport. This seems like a lot of extra processor time for devices that need to be cheap and disposable. For example, OpenSSL on my dual 2.8GHz P4 machine can process AES at roughly 424Mbps [1]. An embedded device with 1/10 my processing power could only keep up with a 21.2 Mbps data flow. [1] openssl speed -elapsed -evp aes-128-cbc -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy Pat Calhoun (pacalhou) wrote: > But what we end up doing is providing two means to do the exact same > thing. I admit that I was surprised when the optional DTLS support was > added for data frames in the CAPWAP draft. However, having thought > through the impact of this change, it actually does address the = previous > issues I had raised against centralized 802.11i security, which are: >=20 > 1. By encrypting at the AC, how does one support 802.11e (specifically > frame fragmentation to fit a service period) > 2. How does the AC provide 802.11n A-MPDU/MSDU aggregation? >=20 > So I would propose we define one way, and I prefer the DTLS mechanism = as > it doesn't introduce any issues in supporting any 802.11 feature. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > >=20 > > = ------------------------------------------------------------------------ > *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] > *Sent:* Monday, June 05, 2006 5:04 PM > *To:* Pat Calhoun (pacalhou) > *Cc:* Michael Montemurro; David T. Perkins; capwap@frascone.com > *Subject:* Re: [Capwap] Encryption Capabilities > > > I do not agree with always requiring the WTP to provide wireless > encryption. The split MAC architecture allows 802.11 > encryption/decryption > at either the WTP or the AC, and this flexibility should be > retained, with use of the > field in question clearly defined. > > Dorothy > > > On 6/5/06, *Pat Calhoun (pacalhou)* > wrote: > > Actually, this field was intended to allow the WTP to > communicate whether it is capable of providing its = capabilities, > and therefore allow the AC to determine whether it should > perform centralized encryption. However, with the transition = to > DTLS, I propose that we always require the WTP to provide > wireless encryption, and use DTLS between the AC and the WTP. > =20 > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > =20 > > = ------------------------------------------------------------------------ > *From:* Michael Montemurro > [mailto:montemurro.michael@gmail.com > ] > *Sent:* Saturday, June 03, 2006 12:12 PM > *To:* David T. Perkins > *Cc:* capwap@frascone.com > *Subject:* Re: [Capwap] Encryption Capabilities > > David, > =20 > Would it be sufficient to move Encryption Capabilities from = the > WTP Descriptor (Section 4.4.34) to the WTP Radio Information > message element (Section 4.4.39)? > =20 > Mike > > =20 > On 6/3/06, *Michael Montemurro* > wrote: > > David, > > I've created issue 125 to track this issue. > =20 > Mike > > =20 > On 6/1/06, *David T. Perkins* > wrote: > > HI, > > The "(4.4.34)WTP Descriptor" message element has the > subfield "encryption capabilities". What is this used > for? If for radios, then it should be per radio. If > for the user data between the WTP and AC, then > it doesn't seem appropriate to say the value is > defined by "specific binding" definitions because > the WTP can be supporting multiple radios with > some that provide encryption services and some > that don't. > > In general, I don't feel that this subfield is > well defined, and it appears to me that it > should be a per radio attribute. > > Regards, > /david t. perkins > > = _________________________________________________________________ > To unsubscribe or modify your subscription options, > please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > = _________________________________________________________________ > To unsubscribe or modify your subscription options, please = visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > = ------------------------------------------------------------------------ > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap ------_=_NextPart_001_01C689F2.06A45493 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [Capwap] Encryption Capabilities=0A= =0A= =0A=
=0A=
Charles,
=0A=
I agree with you.  I = don't see why =0A= this option needs
=0A=
to be removed.   =
=0A=
 
=0A=
As you have noted,  DTLS = in the data =0A= path is going
=0A=
to require the WTPs to = seriously beef up =0A= their
=0A=
crypto capabilities, = especially with =0A= 802.11n around
=0A=
the corner.  Terminating = roughly =0A= 300-350Mbps of
=0A=
802.11i encryption traffic = and then =0A= re-encrypting it
=0A=
for DTLS is going to be a = challenge at low =0A= cost points.
=0A=
 
=0A=
It's amusing that within a = span of =0A= roughly
=0A=
2 years we have gone from = "fat"  APs =0A= to "fit" APs and
=0A=
now to "weight-lifter" APs. =0A= :-)
=0A=
 
=0A=
Abhijit
=0A=

 
=0A=
=0A=
=0A=
=0A=
From: Charles Clancy =0A= [mailto:clancy@cs.umd.edu]
Sent: Tue 6/6/2006 7:53 = PM
To: =0A= Pat Calhoun (pacalhou)
Cc: = capwap@frascone.com
Subject: Re: =0A= [Capwap] Encryption Capabilities

=0A=
=0A=

Removing centralized encryption doesn't change the = security =0A= properties
of CAPWAP.

HOWEVER, if you really want packets = encrypted =0A= all the way to the AC, and
you remove centralized encryption, your = WTPs first =0A= have to decrypt the
802.11 packet, and then re-encrypt it for DTLS =0A= transport.  This seems
like a lot of extra processor time for = devices =0A= that need to be cheap and
disposable.  For example, OpenSSL on = my dual =0A= 2.8GHz P4 machine can
process AES at roughly 424Mbps [1].  An = embedded =0A= device with 1/10 my
processing power could only keep up with a 21.2 = Mbps data =0A= flow.

[1] openssl speed -elapsed -evp aes-128-cbc

--
t. = charles =0A= clancy, ph.d.  <>  tcc@umd.edu  <>  =0A= www.cs.umd.edu/~clancy

Pat Calhoun (pacalhou) wrote:
> But = what we =0A= end up doing is providing two means to do the exact same
> thing. = I admit =0A= that I was surprised when the optional DTLS support was
> added = for data =0A= frames in the CAPWAP draft. However, having thought
> through the = impact =0A= of this change, it actually does address the previous
> issues I = had =0A= raised against centralized 802.11i security, which = are:
> 
> 1. =0A= By encrypting at the AC, how does one support 802.11e = (specifically
> =0A= frame fragmentation to fit a service period)
> 2. How does the AC = provide =0A= 802.11n A-MPDU/MSDU aggregation?
> 
> So I would = propose we =0A= define one way, and I prefer the DTLS mechanism as
> it doesn't = introduce =0A= any issues in supporting any 802.11 feature.
>
> Pat = Calhoun
> =0A= CTO, Wireless Networking Business Unit
> Cisco =0A= Systems
>
> 
>
>     =0A= ------------------------------------------------------------------------<= BR>>     =0A= *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com]=
>     =0A= *Sent:* Monday, June 05, 2006 5:04 PM
>     = *To:* Pat =0A= Calhoun (pacalhou)
>     *Cc:* Michael = Montemurro; =0A= David T. Perkins; capwap@frascone.com
>     = *Subject:* =0A= Re: [Capwap] Encryption =0A= Capabilities
>
>
>     I do not = agree with =0A= always requiring the WTP to provide = wireless
>     =0A= encryption. The split MAC architecture allows =0A= 802.11
>     =0A= encryption/decryption
>     at either the WTP = or the =0A= AC, and this flexibility should be
>     = retained, =0A= with use of the
>     field in question = clearly =0A= defined.
>
>     =0A= Dorothy
>
>
>     On 6/5/06, *Pat = Calhoun =0A= (pacalhou)* <pcalhoun@cisco.com
>     = <mailto:pcalhoun@cisco.com>> =0A= wrote:
>
>         = Actually, =0A= this field was intended to allow the WTP =0A= to
>         communicate = whether =0A= it is capable of providing its =0A= capabilities,
>         = and =0A= therefore allow the AC to determine whether it =0A= should
>         perform =0A= centralized encryption. However, with the transition =0A= to
>         DTLS, I = propose that =0A= we always require the WTP to =0A= provide
>         wireless =0A= encryption, and use DTLS between the AC and the =0A= WTP.
>         
>= ;
>         =0A= Pat Calhoun
>         CTO, =0A= Wireless Networking Business =0A= Unit
>         Cisco =0A= Systems
>
>        &n= bsp;
>
>         = ;    =0A= ------------------------------------------------------------------------<= BR>>           =   =0A= *From:* Michael =0A= Montemurro
>         &= nbsp;   =0A= [mailto:montemurro.michael@gm= ail.com
>         =     =0A= <mailto:montemurro.michael@gm= ail.com>]
>        &= nbsp;    =0A= *Sent:* Saturday, June 03, 2006 12:12 =0A= PM
>          &nb= sp;  =0A= *To:* David T. =0A= Perkins
>         &nbs= p;   =0A= *Cc:* capwap@frascone.com <mailto:capwap@frascone.com>>           &n= bsp; =0A= *Subject:* Re: [Capwap] Encryption =0A= Capabilities
>
>       &nb= sp; =0A= David,
>         
&= gt;         =0A= Would it be sufficient to move Encryption Capabilities from =0A= the
>         WTP = Descriptor =0A= (Section 4.4.34) to the WTP Radio =0A= Information
>         = message =0A= element (Section =0A= 4.4.39)?
>         >         =0A= Mike
>
>         = ;
>         =0A= On 6/3/06, *Michael Montemurro* =0A= <montemurro.michael@gmail.com
>     &nb= sp;   =0A= <mailto:montemurro.michael@gm= ail.com>> =0A= wrote:
>
>        &nb= sp;    =0A= David,
>
>        &nb= sp;    =0A= I've created issue 125 to track this =0A= issue.
>          = ;   
>       &nbs= p;     =0A= Mike
>
>         = ;    
>      &nbs= p;      =0A= On 6/1/06, *David T. Perkins* =0A= <dperkins@dsperkins.com
>      &nb= sp;      =0A= <mailto:dperkins@dsperkins.com&= gt;> =0A= wrote:
>
>        &nb= sp;        =0A= HI,
>
>         =         =0A= The "(4.4.34)WTP Descriptor" message element has =0A= the
>          &n= bsp;      =0A= subfield "encryption capabilities". What is this =0A= used
>          &= nbsp;      =0A= for? If for radios, then it should be per radio. =0A= If
>          &nb= sp;      =0A= for the user data between the WTP and AC, =0A= then
>          &= nbsp;      =0A= it doesn't seem appropriate to say the value =0A= is
>          &nb= sp;      =0A= defined by "specific binding" definitions =0A= because
>         &nbs= p;       =0A= the WTP can be supporting multiple radios =0A= with
>          &= nbsp;      =0A= some that provide encryption services and =0A= some
>          &= nbsp;      =0A= that =0A= don't.
>
>        &nb= sp;        =0A= In general, I don't feel that this subfield =0A= is
>          &nb= sp;      =0A= well defined, and it appears to me that =0A= it
>          &nb= sp;      =0A= should be a per radio =0A= attribute.
>
>        = ;         =0A= Regards,
>         &nb= sp;       =0A= /david t. =0A= perkins
>
>        &n= bsp;        =0A= _________________________________________________________________
>=             &= nbsp;    =0A= To unsubscribe or modify your subscription =0A= options,
>         &nb= sp;       =0A= please =0A= visit:
>          = ;       =0A= http://lists.f= rascone.com/mailman/listinfo/capwap
>    &n= bsp;            =0A= <http://lists.f= rascone.com/mailman/listinfo/capwap>
>
>  &n= bsp;           &nb= sp;  =0A= Archives: http://lists.frascone= .com/pipermail/capwap
>      &nbs= p;          =0A= <http://lists.frascone= .com/pipermail/capwap>
>
>
>
>
>&nbs= p;        =0A= _________________________________________________________________
>=          =0A= To unsubscribe or modify your subscription options, please =0A= visit:
>         http://lists.f= rascone.com/mailman/listinfo/capwap
>
>   =       =0A= Archives: http://lists.frascone= .com/pipermail/capwap
>      &nbs= p;  =0A= <http://lists.frascone= .com/pipermail/capwap>
>
>
>
> =0A= ------------------------------------------------------------------------<= BR>>
> =0A= _________________________________________________________________
>= To =0A= unsubscribe or modify your subscription options, please visit:
> = http://lists.f= rascone.com/mailman/listinfo/capwap
>
> =0A= Archives: http://lists.frascone= .com/pipermail/capwap


____________________________________= _____________________________
To =0A= unsubscribe or modify your subscription options, please visit:
http://lists.f= rascone.com/mailman/listinfo/capwap

Archives: =0A= http://lists.frascone= .com/pipermail/capwap

=0A= =0A= =0A= ------_=_NextPart_001_01C689F2.06A45493-- --===============0634005238== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0634005238==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 01:23:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnqVc-0002Ow-Ra for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 01:23:12 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnqVb-0001dd-37 for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 01:23:12 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id ACF70430097 for ; Tue, 6 Jun 2006 22:23:10 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7B127430054 for ; Tue, 6 Jun 2006 22:22:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 675981448021 for ; Tue, 6 Jun 2006 22:22:33 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 3BED01448020 for ; Tue, 6 Jun 2006 22:22:29 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060308/3.7W/bulls) with ESMTP id k575MQX2017160 for ; Wed, 7 Jun 2006 14:22:27 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k575MRQ02289 for ; Wed, 7 Jun 2006 14:22:27 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with SMTP id k575MSw14561 for ; Wed, 7 Jun 2006 14:22:28 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 7 Jun 2006 13:20:16 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDEEEEF7@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 84: Statistics for WTP Event Request Thread-Index: AcZ+ksLzl8cVexZLRbyDo8Rs4tEuFQAP+erwAsUGCXA= From: "Saravanan Govindan" To: "capwap" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_MESSAGE X-Spam-Level: Subject: [Capwap] Issue 84: Statistics for WTP Event Request X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0710731526==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8e140a89d08e89747ee196e282ac2228 This is a multi-part message in MIME format. --===============0710731526== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C689F2.0F9E8B05" This is a multi-part message in MIME format. ------_=_NextPart_001_01C689F2.0F9E8B05 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 For generic, non-binding-specific statistics, I suggest WTP Event Request be used to exchange this information.=20 =20 Saravanan =20 =20 Suggested updates: =20 =20 Section 9.5. WTP Event Request =20 [Add the following type of message element at end of the section] =20 * System Statistics, see Section 4.4.45 =20 =20 =20 Section 4.4. CAPWAP Protocol Message Elements =20 [Add the following sub-section for non-binding-specific statistics 4.4.45] =20 =20 4.4.45. System Statistics =20 The System Statistics message element in used to exchange state and capacity information of the wireless network as a whole. This message element is sent by a WTP to an AC.=20 =20 =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WTP Load | WTP Transmit Queue | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Channel Interference | Congestion | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =20 Type: 45 =20 Length: 8 =20 WTP Load: A 16-bit value specifying the load (frames/sec) exchanged by the WTP. =20 WTP Transmit Queue: A 16-bit value specifying the prevailing queue level as a=20 portion of total queue size. =20 Channel Interference: A 16-bit value specifying SINR (dB) monitored by the WTP. =20 Congestion: A 16-bit value specifying the congestion experienced by the WTP. =20 =20 =20 ------_=_NextPart_001_01C689F2.0F9E8B05 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

For generic, non-binding-specific statistics, I suggest WTP Event Request be used to exchange this = information.

 

Saravanan

 

 

Suggested = updates:

 

 

Section 9.5. WTP Event = Request

 

[Add the following type of message = element at end of the section]

 

  • System Statistics, = see Section 4.4.45

 

 

 

Section 4.4. CAPWAP Protocol = Message Elements

 

[Add the following sub-section for non-binding-specific statistics 4.4.45]

 

 

4.4.45.     = System Statistics

 

The System Statistics message = element in used to exchange state and capacity information of the wireless network = as a whole. This message element is sent by a WTP to an AC. =

 

 

      0            =        1            =        2            =        3

      0 1 = 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |           WTP Load            |     WTP Transmit Queue        = |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |      Channel = Interference     |          Congestion           = |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

 

Type: =
45
 
Length: =
8
 
WTP Load: A =
16-bit value specifying the load (frames/sec) exchanged by the =
WTP.
 
WTP Transmit =
Queue: A 16-bit value specifying the prevailing queue level as a =

          &nb=
sp;         portion of =
total queue size.
 
Channel =
Interference: A 16-bit value specifying SINR (dB) monitored by the =
WTP.
 
Congestion: A =
16-bit value specifying the congestion experienced by the =
WTP.

 

 

 

------_=_NextPart_001_01C689F2.0F9E8B05-- --===============0710731526== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0710731526==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 02:31:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnrZw-00023S-8r for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 02:31:44 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnqnh-00051z-04 for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 01:41:53 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FnqZD-00010E-5j for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 01:26:59 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A3A5C430103 for ; Tue, 6 Jun 2006 22:26:53 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id DD9B8430064 for ; Tue, 6 Jun 2006 22:25:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D1B1E39800F for ; Tue, 6 Jun 2006 22:25:58 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id CFF65398036 for ; Tue, 6 Jun 2006 22:25:55 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060308/3.7W/bulls) with ESMTP id k575Prx4019865; Wed, 7 Jun 2006 14:25:53 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k575Psb02138; Wed, 7 Jun 2006 14:25:54 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with SMTP id k575Pua13224; Wed, 7 Jun 2006 14:25:56 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 7 Jun 2006 13:23:42 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDEEEEFA@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Thread-Index: AcaHQBAAfR7pDNbiSRikmVg/jB2m7wClTO7A From: "Saravanan Govindan" To: "Michael Montemurro" , "capwap" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.425 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_MESSAGE X-Spam-Level: Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2136463303==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 53bbbffb1f9e780660701ef83a59efe0 This is a multi-part message in MIME format. --===============2136463303== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C689F2.8A9C4D57" This is a multi-part message in MIME format. ------_=_NextPart_001_01C689F2.8A9C4D57 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mike, My concern is with where the KeyRSC value is maintained for the purposes of both the 4-way handshake and group key handshake. Section 11.3 describes group key refresh operations alone.=20 =20 The issue is that the KeyRSC can be maintained in either the WTP or AC. And the prevailing KeyRSC value is needed for the 4-way handshake (particularly for message 3) and group key handshake (particularly for message 1).=20 =20 I think the suggestion for transmitting KeyRSC value from WTP to AC may cause mismatches due to propagation between WTP and AC. This is the reason for suggesting a new CAPWAP control message that carries message-3 (in case of 4-way handshake) with unassigned KeyRSC from AC to WTP. The WTP can then use the current value of KeyRSC for message-3.=20 =20 I will re-send a formatted note with this suggestion. =20 Cheers, Saravanan =20 =20 =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Sunday, June 04, 2006 3:03 AM To: Saravanan Govindan Cc: Pat Calhoun (pacalhou); capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 Take a look at section 11.3. Would it be sufficient for the WTP to transmit the KeyRSC value as a TLV in the 802.11 config response? =20 Cheers, =20 Mike =20 On 6/3/06, Michael Montemurro wrote:=20 Saravanan,=20 =20 I took a look again at the latest draft for IEEE 802.11i, and as I understand it, the GTK 1 message needs the sequence number of the last transmitted broadcast frame. =20 In the split MAC case, the AC should know the sequence number because it would set it. In the local MAC case, the AC would have to query the WTP for the sequence number.=20 =20 So, I believe what you require is a mechanism for the AC to query the WTP for the sequence number in the local MAC case. Is that correct? =20 The keyMIC should not be an issue because in either the local MAC or the split MAC case, the AC would have all the information it needs.=20 The only requirement would be for the AC to hold onto the KEK for the STA to calculate the MIC for the EAPoL frame. =20 Would that be correct? =20 Cheers, =20 Mike =20 On 5/26/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com > wrote:=20 Hi, =20 =20 =20 =20 =20 This is a copy-and-paste from previous email. =20 =20 =20 =20 =20 =20 In cases where IEEE 802.11i encryption/decryption is located in a WTP and IEEE=20 =20 802.11i authenticator is located in an AC, there is a mismatch in tracking=20 =20 =20 =20 =20 KeyRSC values (draft-ietf-capwap-objectives-04.txt) Section 5.1.10. The CAPWAP=20 protocol must allow the 4-way and Group-key exchanges to use accurate values=20 of KeyRSC and KeyMIC in all cases.=20 =20 =20 =20 =20 =20 My recommendation: =20 =20 =20 =20 =20 Introduce new Key Configuration & Key Configuration Response messages as part=20 of Message Types. Key Configuration message will be used to exchange 3rd message (for 4-way exchange & with unassigned KeyMIC and KeyRSC fields) and 1st message (for group-key exchange & with unassigned KeyMIC and KeyRSC fields).=20 =20 =20 =20 =20 =20 =20 =20 I was looking for these 2 messages in the new draft. However, I am open to other ways of accomplishing the objective.=20 =20 Cheers, =20 =20 =20 =20 =09 =09 =09 =09 =09 =20 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Michael Montemurro [mailto: montemurro.michael@gmail.com]=20 Sent: Friday, May 26, 2006 8:30 AM=20 To: Pat Calhoun (pacalhou) Cc: Saravanan Govindan; capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 The only text that I could identify that was missing here was information on how the GTK was handled. =20 If there is more information or clarification, please let me know. =20 Cheers, =09 Mike =20 On 5/23/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com > wrote:=20 I have re-opened issue 43, but it would be useful if you could provide a high level example (outline) of what you would like to see.=20 =09 Pat Calhoun=20 CTO, Wireless Networking Business Unit Cisco Systems =09 =09 =09 > -----Original Message----- > From: Saravanan Govindan [mailto: Saravanan.Govindan@sg.panasonic.com ] > Sent: Tuesday, May 23, 2006 12:24 AM > To: capwap > Subject: [Capwap] Clarification of Issue 43: IEEE 802.11i > Considerations > > All, >=20 > I believe this issue 43 - also a Mandatory Objective - is=20 > still open. My suggestion is to update the 802.11 binding > section to reflect steps local-MAC and split-MAC cases. > > Saravanan=20 > > _________________________________________________________________=20 > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap=20 > =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit:=20 http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =20 =20 ------_=_NextPart_001_01C689F2.8A9C4D57 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mike,


My concern is with where the KeyRSC value is maintained for the purposes = of both the 4-way handshake and group key handshake. Section 11.3 describes = group key refresh operations alone.

 

The issue is that the KeyRSC can be maintained in = either the WTP or AC. And the prevailing KeyRSC value is needed for the 4-way = handshake (particularly for message 3) and group key handshake (particularly for = message 1).

 

I think the suggestion for transmitting KeyRSC value = from WTP to AC may cause mismatches due to propagation between WTP and AC. = This is the reason for suggesting a new CAPWAP control message that carries = message-3 (in case of 4-way handshake) with unassigned KeyRSC from AC to WTP. The = WTP can then use the current value of KeyRSC for message-3. =

 

I will re-send a formatted note with this = suggestion.

 

Cheers,


Saravanan

 

 

 

From: = Michael Montemurro [mailto:montemurro.michael@gmail.com]
Sent: Sunday, June 04, = 2006 3:03 AM
To: Saravanan Govindan
Cc: Pat Calhoun = (pacalhou); capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

 

Saravanan,

 

Take a look at section 11.3. Would it be sufficient for the = WTP to transmit the KeyRSC value as a TLV in the 802.11 config = response?

 

Cheers,

 

 Mike

 

On 6/3/06, Michael Montemurro <montemurro.michael@gmail.com= > wrote:

Saravanan,

 

I took a look again at the latest draft = for IEEE 802.11i, and as I understand it, the GTK 1 message needs the = sequence number of the

last transmitted broadcast = frame.

 

In the split MAC case, the AC should know the = sequence number because it would set it. In the local MAC case, the AC would have = to

query the WTP for the sequence number. =

 

So, I believe what you require is a mechanism = for the AC to query the WTP for the sequence number in the local MAC case. Is = that correct?

 

The keyMIC should not be an issue because in = either the local MAC or the split MAC case, the AC would have all the = information it needs.

The only requirement would be for the AC to = hold onto the KEK for the STA to calculate the MIC for the EAPoL = frame.

 

Would that be = correct?

 

Cheers,

 

Mike

 

On 5/26/06, Saravanan = Govindan < Saravanan.Govindan@sg.panasonic.com> wrote: =

= 
Hi,
 
 
 
 
 
This is a =
copy-and-paste from previous =
email.
 
 
 
 
 
 
In cases =
where IEEE 802.11i encryption/decryption is located in a WTP and IEEE =

 
802.11i =
authenticator is located in an AC, there is a mismatch in tracking =

 
 
 
 
KeyRSC =
values (draft-ietf-capwap-objectives-04.txt) Section 5.1.10. The CAPWAP =

protocol =
must allow the 4-way and Group-key exchanges to use accurate values =

of KeyRSC =
and KeyMIC in all cases. 
 
 
 
 
 =

My =
recommendation:
 
 
 
 
 
Introduce =
new Key Configuration & Key Configuration Response messages as part =

of =
Message Types. Key Configuration message will be used to exchange 3rd =
message (for 4-way exchange & with unassigned KeyMIC and KeyRSC =
fields) and 1st message (for group-key exchange & with unassigned =
KeyMIC and KeyRSC fields). 
 
 
 
 
 
 
 
I was =
looking for these 2 messages in the new draft. However, I am open to =
other ways of accomplishing the objective. =

 
Cheers,
 
 
 
 





 
Saravanan
<=
font
size=3D2 face=3D"Courier New"> 
 

 

 

From: Michael Montemurro = [mailto: montemurro.michael@gmail.com]
Sent: Friday, May 26, = 2006 8:30 AM
To: Pat Calhoun = (pacalhou)
Cc: Saravanan Govindan; capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

 

The only text that I could identify that was missing here was information on how = the GTK was handled.

 

If there is more information or clarification, please let me = know.

 

Cheers,


Mike
 

On 5/23/06, Pat Calhoun = (pacalhou) < = pcalhoun@cisco.com> wrote:

I have re-opened issue 43, but it would be useful if you could provide a
high level example (outline) of what you would like to see.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems



> -----Original Message-----
> From: Saravanan = Govindan [mailto: Saravanan.Govindan@sg.panasonic.com ]
> Sent: Tuesday, May 23, 2006 12:24 AM
> To: capwap
> Subject: [Capwap] Clarification of Issue 43: IEEE 802.11i
> Considerations
>
> All,
>
> I believe this issue 43 - also a Mandatory Objective - is
> still open. My suggestion is to update the 802.11 binding
> section to reflect steps local-MAC and split-MAC cases.
>
> Saravanan
>
> _________________________________________________________________ =
> To unsubscribe or modify your subscription options, please = visit:
> http://lists.frascone.com/mailman/listinfo/capwap >
> Archives: http://lists.frascone.com/pipermail/capwap
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
Archives: http://lists.frascone.com/pipermail/capwap

 



 

------_=_NextPart_001_01C689F2.8A9C4D57-- --===============2136463303== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============2136463303==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 03:21:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnsMD-00024q-09 for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 03:21:37 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnsMA-0007Rw-Aq for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 03:21:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 31FEE430148 for ; Wed, 7 Jun 2006 00:21:33 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 8B82C430054 for ; Wed, 7 Jun 2006 00:21:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 79FB7398036 for ; Wed, 7 Jun 2006 00:21:04 -0700 (PDT) Received: from mgw-ext13.nokia.com (mgw-ext13.nokia.com [131.228.20.172]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0501639800F for ; Wed, 7 Jun 2006 00:21:00 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k577Kqwj025185; Wed, 7 Jun 2006 10:20:54 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 10:20:53 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 02:20:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Jun 2006 00:20:49 -0700 Message-ID: <8A76136424391244A5CF01653370853701AD2F2A@mvebe101.NOE.Nokia.com> In-Reply-To: <08A9A3213527A6428774900A80DBD8D8020B03A6@xmb-sjc-222.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Encryption Capabilities Thread-Index: AcaJ3Y84crkqQJnUSaC6EDFvApp+RgABmatwAAdfoJA= From: To: , , X-OriginalArrivalTime: 07 Jun 2006 07:20:51.0008 (UTC) FILETIME=[E7CB8400:01C68A02] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.178 tagged_above=-999 required=7 tests=NO_REAL_NAME X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Hi Nancy, Comments inline... -----Original Message----- From: ext Nancy Winget (ncamwing) [mailto:ncamwing@cisco.com] Sent: Tuesday, June 06, 2006 9:43 PM To: Charles Clancy; Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities Charles, I think I agree with you though I'm not sure I understand the full thread. It seems that the current email thread is mixing the securing of different transport layers, e.g. CAPWAP with that of 802.11i. 802.11i is designed to afford protection of the 802.11 transport layer, providing both packet confidentiality and authentication; but it does not address securing the CAPWAP transport layer. An obvious example of this is that the CAPWAP header is not authenticated! So whether the 802.11i crypto is done either at the WTP or AC should be construed as a different feature than that of securing the CAPWAP transport layer. /mgw/ Yes. I read Charles as also agreeing with this. Also, I do not understand what the notion of "centralized" encryption is as the client has no clue of the topology or architecture behind the AP? /mgw/ The centralized comment refers to where the upstream 802.11i decryption is happening. If it is happening at the AC endpoint of the CAPWAP tunnel (centralized), then the WTP is only performing encryption for the CAPWAP tunnel and is not involved in downstream OTA encryption. If the .11i decryption is happening at the WTP, then the WTP is decrypting packets from the STA first, then encrypting to send the clear text packet through the protected CAPWAP tunnel upstream to the AC. >From a threat model, if we are intending to address secure transport of data packets within CAPWAP, doing 802.11i at the AC does not address this requirement, CAPWAP must secure its own encapsulation as well. That is why the draft includes the option of establishing a DTLS tunnel for its data transport. /mgw/ Agreed! Nancy. -----Original Message----- From: Charles Clancy [mailto:clancy@cs.umd.edu] Sent: Tuesday, June 06, 2006 7:53 PM To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities Removing centralized encryption doesn't change the security properties of CAPWAP. HOWEVER, if you really want packets encrypted all the way to the AC, and you remove centralized encryption, your WTPs first have to decrypt the 802.11 packet, and then re-encrypt it for DTLS transport. This seems like a lot of extra processor time for devices that need to be cheap and disposable. For example, OpenSSL on my dual 2.8GHz P4 machine can process AES at roughly 424Mbps [1]. An embedded device with 1/10 my processing power could only keep up with a 21.2 Mbps data flow. [1] openssl speed -elapsed -evp aes-128-cbc -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy Pat Calhoun (pacalhou) wrote: > But what we end up doing is providing two means to do the exact same > thing. I admit that I was surprised when the optional DTLS support was > added for data frames in the CAPWAP draft. However, having thought > through the impact of this change, it actually does address the > previous issues I had raised against centralized 802.11i security, which are: > > 1. By encrypting at the AC, how does one support 802.11e (specifically > frame fragmentation to fit a service period) 2. How does the AC > provide 802.11n A-MPDU/MSDU aggregation? > > So I would propose we define one way, and I prefer the DTLS mechanism > as it doesn't introduce any issues in supporting any 802.11 feature. > > Pat Calhoun > CTO, Wireless Networking Business Unit Cisco Systems > > > > ------------------------------------------------------------------------ > *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] > *Sent:* Monday, June 05, 2006 5:04 PM > *To:* Pat Calhoun (pacalhou) > *Cc:* Michael Montemurro; David T. Perkins; capwap@frascone.com > *Subject:* Re: [Capwap] Encryption Capabilities > > > I do not agree with always requiring the WTP to provide wireless > encryption. The split MAC architecture allows 802.11 > encryption/decryption > at either the WTP or the AC, and this flexibility should be > retained, with use of the > field in question clearly defined. > > Dorothy > > > On 6/5/06, *Pat Calhoun (pacalhou)* > wrote: > > Actually, this field was intended to allow the WTP to > communicate whether it is capable of providing its capabilities, > and therefore allow the AC to determine whether it should > perform centralized encryption. However, with the transition to > DTLS, I propose that we always require the WTP to provide > wireless encryption, and use DTLS between the AC and the WTP. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > ------------------------------------------------------------------------ > *From:* Michael Montemurro > [mailto:montemurro.michael@gmail.com > ] > *Sent:* Saturday, June 03, 2006 12:12 PM > *To:* David T. Perkins > *Cc:* capwap@frascone.com > *Subject:* Re: [Capwap] Encryption Capabilities > > David, > > Would it be sufficient to move Encryption Capabilities from the > WTP Descriptor (Section 4.4.34) to the WTP Radio Information > message element (Section 4.4.39)? > > Mike > > > On 6/3/06, *Michael Montemurro* > wrote: > > David, > > I've created issue 125 to track this issue. > > Mike > > > On 6/1/06, *David T. Perkins* > wrote: > > HI, > > The "(4.4.34)WTP Descriptor" message element has the > subfield "encryption capabilities". What is this used > for? If for radios, then it should be per radio. If > for the user data between the WTP and AC, then > it doesn't seem appropriate to say the value is > defined by "specific binding" definitions because > the WTP can be supporting multiple radios with > some that provide encryption services and some > that don't. > > In general, I don't feel that this subfield is > well defined, and it appears to me that it > should be a per radio attribute. > > Regards, > /david t. perkins > > _________________________________________________________________ > To unsubscribe or modify your subscription options, > please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > ---------------------------------------------------------------------- > -- > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 07:51:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnwZe-0006sa-Il for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 07:51:46 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnwZc-0000RN-5u for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 07:51:46 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 345A4430134 for ; Wed, 7 Jun 2006 04:51:43 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id CF59C430064 for ; Wed, 7 Jun 2006 04:51:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B70BF430BE4 for ; Wed, 7 Jun 2006 04:51:22 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [12.129.211.51]) by hermes.tigertech.net (Postfix) with ESMTP id 1C5BE430BDB for ; Wed, 7 Jun 2006 04:51:19 -0700 (PDT) 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 <0J0H00BLING49S@usaga01-in.huawei.com> for capwap@frascone.com; Wed, 07 Jun 2006 04:48:05 -0700 (PDT) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0H00IPRNG3UD@usaga01-in.huawei.com> for capwap@frascone.com; Wed, 07 Jun 2006 04:48:04 -0700 (PDT) Received: from [172.24.1.24] (Forwarded-For: [10.18.7.115]) by szxmc01-in.huawei.com (mshttpd); Wed, 07 Jun 2006 16:51:14 +0500 Date: Wed, 07 Jun 2006 16:51:14 +0500 From: zhaoyujin 31390 To: capwap@frascone.com Message-id: <11fc301234d5.1234d511fc30@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-language: zh-CN Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [Capwap] How to transmit 802.11 association packet to AC for Local mode X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Dear all: In section "11.1.2 Local MAC" defines Local MAC mode architecture. And in figure 6 has next process and description: 802.11 Association <---------------------------( - )-------------------------> Add Mobile (Clear Text, 802.1X Only) <-------------------------> o The WTP forwards the 802.11 Authentication and Association frames to the AC, which is responsible for responding to the client. Because CAPWAP data tunnel maybe only transmit 802.3 frames for Local MAC mode, I cannot understand how to transmit 802.11 association frames to AC. Best regards Michael _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 09:25:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fny26-000580-BT for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 09:25:14 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fny24-0000Jr-MT for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 09:25:14 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 861BD4300B2 for ; Wed, 7 Jun 2006 06:25:11 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 615F6430054 for ; Wed, 7 Jun 2006 06:24:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4EA21430E12 for ; Wed, 7 Jun 2006 06:24:31 -0700 (PDT) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by hermes.tigertech.net (Postfix) with ESMTP id 8DB484306FD for ; Wed, 7 Jun 2006 06:24:26 -0700 (PDT) Received: from vivi.cc.vt.edu (IDENT:mirapoint@evil-vivi.cc.vt.edu [10.1.1.12]) by lennier.cc.vt.edu (8.12.11.20060308/8.12.11) with ESMTP id k57DFeO7004136; Wed, 7 Jun 2006 09:24:22 -0400 Received: from [127.0.0.1] (e030168.vtacs.vt.edu [63.164.30.168]) by vivi.cc.vt.edu (MOS 3.8.0-FCS) with ESMTP id FQC38814; Wed, 7 Jun 2006 09:24:25 -0400 (EDT) Message-ID: <4486D3AA.9030100@cs.umd.edu> Date: Wed, 07 Jun 2006 09:24:58 -0400 From: Charles Clancy User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Nancy Winget (ncamwing)" References: <08A9A3213527A6428774900A80DBD8D8020B03A6@xmb-sjc-222.amer.cisco.com> In-Reply-To: <08A9A3213527A6428774900A80DBD8D8020B03A6@xmb-sjc-222.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Nancy, You've brought up a good point. Relying on 11i to encrypt data packets between the WTP and AC only provides confidentiality of the data, and does not protect the CAPWAP data transport protocol. Each scenario has its pros and cons... this to me implies they should all be supported in the standard, and let users pick the one that fits their environment (though that can be dangerous when it comes to security). -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy Nancy Winget (ncamwing) wrote: > Charles, > > I think I agree with you though I'm not sure I understand the full > thread. > > It seems that the current email thread is mixing the securing of > different transport layers, e.g. CAPWAP with that of 802.11i. > > 802.11i is designed to afford protection of the 802.11 transport layer, > providing both packet confidentiality and authentication; but it does > not address securing the CAPWAP transport layer. An obvious example of > this is that the CAPWAP header is not authenticated! > > So whether the 802.11i crypto is done either at the WTP or AC should be > construed as a different feature than that of securing the CAPWAP > transport layer. Also, I do not understand what the notion of > "centralized" encryption is as the client has no clue of the topology or > architecture behind the AP? > >>From a threat model, if we are intending to address secure transport of > data packets within CAPWAP, doing 802.11i at the AC does not address > this requirement, CAPWAP must secure its own encapsulation as well. > That is why the draft includes the option of establishing a DTLS tunnel > for its data transport. > > Nancy. > > > > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Tuesday, June 06, 2006 7:53 PM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Encryption Capabilities > > Removing centralized encryption doesn't change the security properties > of CAPWAP. > > HOWEVER, if you really want packets encrypted all the way to the AC, and > you remove centralized encryption, your WTPs first have to decrypt the > 802.11 packet, and then re-encrypt it for DTLS transport. This seems > like a lot of extra processor time for devices that need to be cheap and > disposable. For example, OpenSSL on my dual 2.8GHz P4 machine can > process AES at roughly 424Mbps [1]. An embedded device with 1/10 my > processing power could only keep up with a 21.2 Mbps data flow. > > [1] openssl speed -elapsed -evp aes-128-cbc > > -- > t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy > > Pat Calhoun (pacalhou) wrote: > >>But what we end up doing is providing two means to do the exact same >>thing. I admit that I was surprised when the optional DTLS support was > > >>added for data frames in the CAPWAP draft. However, having thought >>through the impact of this change, it actually does address the >>previous issues I had raised against centralized 802.11i security, > > which are: > >> >>1. By encrypting at the AC, how does one support 802.11e (specifically > > >>frame fragmentation to fit a service period) 2. How does the AC >>provide 802.11n A-MPDU/MSDU aggregation? >> >>So I would propose we define one way, and I prefer the DTLS mechanism >>as it doesn't introduce any issues in supporting any 802.11 feature. >> >>Pat Calhoun >>CTO, Wireless Networking Business Unit Cisco Systems >> >> >> >> > > ------------------------------------------------------------------------ > >> *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] >> *Sent:* Monday, June 05, 2006 5:04 PM >> *To:* Pat Calhoun (pacalhou) >> *Cc:* Michael Montemurro; David T. Perkins; capwap@frascone.com >> *Subject:* Re: [Capwap] Encryption Capabilities >> >> >> I do not agree with always requiring the WTP to provide wireless >> encryption. The split MAC architecture allows 802.11 >> encryption/decryption >> at either the WTP or the AC, and this flexibility should be >> retained, with use of the >> field in question clearly defined. >> >> Dorothy >> >> >> On 6/5/06, *Pat Calhoun (pacalhou)* > > wrote: >> >> Actually, this field was intended to allow the WTP to >> communicate whether it is capable of providing its > > capabilities, > >> and therefore allow the AC to determine whether it should >> perform centralized encryption. However, with the transition > > to > >> DTLS, I propose that we always require the WTP to provide >> wireless encryption, and use DTLS between the AC and the WTP. >> >> >> Pat Calhoun >> CTO, Wireless Networking Business Unit >> Cisco Systems >> >> >> >> > > ------------------------------------------------------------------------ > >> *From:* Michael Montemurro >> [mailto:montemurro.michael@gmail.com >> ] >> *Sent:* Saturday, June 03, 2006 12:12 PM >> *To:* David T. Perkins >> *Cc:* capwap@frascone.com >> *Subject:* Re: [Capwap] Encryption Capabilities >> >> David, >> >> Would it be sufficient to move Encryption Capabilities from > > the > >> WTP Descriptor (Section 4.4.34) to the WTP Radio Information >> message element (Section 4.4.39)? >> >> Mike >> >> >> On 6/3/06, *Michael Montemurro* > > wrote: >> >> David, >> >> I've created issue 125 to track this issue. >> >> Mike >> >> >> On 6/1/06, *David T. Perkins* > > wrote: >> >> HI, >> >> The "(4.4.34)WTP Descriptor" message element has the >> subfield "encryption capabilities". What is this used >> for? If for radios, then it should be per radio. If >> for the user data between the WTP and AC, then >> it doesn't seem appropriate to say the value is >> defined by "specific binding" definitions because >> the WTP can be supporting multiple radios with >> some that provide encryption services and some >> that don't. >> >> In general, I don't feel that this subfield is >> well defined, and it appears to me that it >> should be a per radio attribute. >> >> Regards, >> /david t. perkins >> >> > > _________________________________________________________________ > >> To unsubscribe or modify your subscription options, >> please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> >> Archives: http://lists.frascone.com/pipermail/capwap >> >> >> >> >> >> > _________________________________________________________________ > >> To unsubscribe or modify your subscription options, please > > visit: > >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap >> >> >> >> >>---------------------------------------------------------------------- >>-- >> >>_________________________________________________________________ >>To unsubscribe or modify your subscription options, please visit: >>http://lists.frascone.com/mailman/listinfo/capwap >> >>Archives: http://lists.frascone.com/pipermail/capwap > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 10:40:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnzDH-00056Y-QN for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 10:40:51 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnzDG-0001Gp-C5 for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 10:40:51 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3EFE4430129 for ; Wed, 7 Jun 2006 07:40:49 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 0184F430054 for ; Wed, 7 Jun 2006 07:40:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E744E398051 for ; Wed, 7 Jun 2006 07:40:19 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id ED5AA39801D for ; Wed, 7 Jun 2006 07:40:15 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 07 Jun 2006 07:40:15 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="290624928:sNHT41332240" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k57EeF3R032641; Wed, 7 Jun 2006 07:40:15 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k57Ee9ko012707; Wed, 7 Jun 2006 07:40:14 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 07:40:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Jun 2006 07:40:11 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2020373A7@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Encryption Capabilities Thread-Index: AcaJ3YK9qrrN6Qn9SmG5SFPUpapyngAE6+z7ABOoX4A= From: "Pat Calhoun (pacalhou)" To: "Abhijit Choudhury" , "Charles Clancy" X-OriginalArrivalTime: 07 Jun 2006 14:40:12.0467 (UTC) FILETIME=[4872F030:01C68A40] Authentication-Results: sj-dkim-4.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 > As you have noted, DTLS in the data path is going > to require the WTPs to seriously beef up their > crypto capabilities, especially with 802.11n around > the corner. Terminating roughly 300-350Mbps of > 802.11i encryption traffic and then re-encrypting it > for DTLS is going to be a challenge at low cost points. What about the AC that now needs to double encrypt/decrypt packets? The standard allows for the AC to perform both functions, which is expensive. So the way I see it, both crypto functions provide a different level of security, but if the purpose of the function is to protect the packets over the wire, 802.11i doesn't do that because it only protects the 802.11 payload - not the CAPWAP header. > It's amusing that within a span of roughly > 2 years we have gone from "fat" APs to "fit" APs and > now to "weight-lifter" APs. :-) Abhijit, the purpose of CAPWAP is not to make Aps cheaper. In fact the whole "light weight" concept was not really about making them less expensive, but repositioning the functions to make more effective use of the processor in the WTP. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 11:01:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnzV8-0005Wy-UV for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 10:59:18 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnzJA-0002yl-05 for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 10:46:57 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9DC6443013A for ; Wed, 7 Jun 2006 07:46:55 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6C046430063 for ; Wed, 7 Jun 2006 07:46:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5894A398058 for ; Wed, 7 Jun 2006 07:46:30 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id 94526398056 for ; Wed, 7 Jun 2006 07:46:26 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2006 07:46:26 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="1821166492:sNHT65388676" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k57EkQbQ018947; Wed, 7 Jun 2006 07:46:26 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k57EkPCU029099; Wed, 7 Jun 2006 07:46:25 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 07:46:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Jun 2006 07:46:25 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2020373AD@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Encryption Capabilities Thread-Index: AcaKNbPqE0PdlsMESbG5HGsk0GyjdwACppVQ From: "Pat Calhoun (pacalhou)" To: "Charles Clancy" , "Nancy Winget (ncamwing)" X-OriginalArrivalTime: 07 Jun 2006 14:46:25.0902 (UTC) FILETIME=[270898E0:01C68A41] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 > You've brought up a good point. Relying on 11i to encrypt > data packets between the WTP and AC only provides > confidentiality of the data, and does not protect the CAPWAP > data transport protocol. > > Each scenario has its pros and cons... this to me implies > they should all be supported in the standard, and let users > pick the one that fits their environment (though that can be > dangerous when it comes to security). Charles, are you stating that DTLS doesn't provide sufficient security of the data packets, and therefore supplementing DTLS with 802.11i provides a more secure solution? I suspect I'm interpreting your comment incorrectly. At this point, my concern is the level of complexity that has been Introduced into the protocol through all of these various options. In the End, this IETF effort is all about interoperability, but let's look at The optional features we now currently have: Local MAC 802.3 Tunneling No Encryption DTLS Encryption Local Bridging Split MAC 802.11 Tunneling No Encryption DTLS Encryption 802.11i Encryption Both DTLS and 802.11i Encryption 802.3 Tunneling (as some folks have recently requested, but isn't in the current spec) No Encryption DTLS Encryption So given the above modes of operation, how does one guarantee interoperability when creating a solution? At this point, I'd like to see some focus on simplification. By removing 802.11i, and only using DTLS, we've at least reduced the number of combinations from 9 to 7 - a worthwhile exercise if you ask me. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 11:01:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnzUr-0005OF-8N for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 10:59:01 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnzPZ-0004ZH-Vr for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 10:53:35 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9B8B8430136 for ; Wed, 7 Jun 2006 07:53:33 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 5237D430054 for ; Wed, 7 Jun 2006 07:53:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3A4C5398041 for ; Wed, 7 Jun 2006 07:53:03 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5F73E39803E for ; Wed, 7 Jun 2006 07:53:01 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 07 Jun 2006 07:53:00 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208,217"; a="290635432:sNHT55510912" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k57Er0Cb005986; Wed, 7 Jun 2006 07:53:00 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k57Er0CU005306; Wed, 7 Jun 2006 07:53:00 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 07:53:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Jun 2006 07:52:59 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2020373B0@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New mux header for CAPWAP Thread-Index: AcaJ0/iIUlcV3UUgRz+e4ctlG4c80gAbU9GQ From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 07 Jun 2006 14:53:00.0632 (UTC) FILETIME=[124F9D80:01C68A42] Authentication-Results: sj-dkim-1.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.459 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_40_50, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1927596340==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb This is a multi-part message in MIME format. --===============1927596340== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68A42.12222060" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68A42.12222060 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dorothy, =20 I'm somewhat surprised by your conclusion. While some vendors have claimed that adding the MUX is simpler, folks more familiar with Ethernet switches and routers than the ones that have come up with this proposal, including folks that have to deploy them (read: customers), have stated on this list that this feature will make it very complex to run CAPWAP in their networks. =20 So once more, I will state my concern. Let's assume that a branch office is connected through a WAN. The WTP will mark packets as it sees fit, but given that all CAPWAP packets are encrypted, there is no way for the enterprise customer to specify what QoS properties to apply to LWAPP control, IEEE 802.11 management and data frames on the WAN router. The only thing one can do is let the WTP apply the labels, but these labels may be inconsistent with the QoS policies used in all of the other applications used by the customers. The reality is that the CAPWAP protocol is timing sensitive, especially as it comes to control, and 802.11 management packets.=20 =20 So in order to deploy CAPWAP, they have to change their network wide QoS policies across all of their infrastructure. =20 How can this possibly justify taking the easy route? How does this decision benefit the internet community? =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com]=20 Sent: Tuesday, June 06, 2006 6:45 PM To: capwap@frascone.com Subject: [Capwap] New mux header for CAPWAP =09 =09 The CAPWAP editors have asked the Chairs to resolve the Mux vs Multiport issue # 115, in order to progress the specification. Based on the discussion that has taken place the chairs are in agreement the simplest, cleanest solution for this is to add a Mux header. Barring any unforseen events, we will instruct the editors resolve in favor of a new Mux header. We intend to close this issue by the end of the week, Friday, 6/9. Please review the issue and send any constructive comments to the list by Friday.=20 Best Regards,=20 Dorothy=20 ------_=_NextPart_001_01C68A42.12222060 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New mux header for CAPWAP
Dorothy,
 
I'm=20 somewhat surprised by your conclusion. While some vendors have claimed = that=20 adding the MUX is simpler, folks more familiar with Ethernet = switches and=20 routers than the ones that have come up with this proposal, including = folks that=20 have to deploy them (read: customers), have stated on this list that = this=20 feature will make it very complex to run CAPWAP in their=20 networks.
 
So=20 once more, I will state my concern. Let's assume that a branch office is = connected through a WAN. The WTP will mark packets as it sees fit, but = given=20 that all CAPWAP packets are encrypted, there is no way for the = enterprise=20 customer to specify what QoS properties to apply to LWAPP control, IEEE = 802.11=20 management and data frames on the WAN router. The only thing one can do = is let=20 the WTP apply the labels, but these labels may be inconsistent with the = QoS=20 policies used in all of the other applications used by the customers. = The=20 reality is that the CAPWAP protocol is timing sensitive, especially as = it comes=20 to control, and 802.11 management packets.
 
So in=20 order to deploy CAPWAP, they have to change their network wide QoS = policies=20 across all of their infrastructure.
 
How=20 can this possibly justify taking the easy route? How does this decision = benefit=20 the internet community?
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Dorothy.Gellert@nokia.com=20 [mailto:Dorothy.Gellert@nokia.com]
Sent: Tuesday, June 06, = 2006=20 6:45 PM
To: capwap@frascone.com
Subject: [Capwap] = New mux=20 header for CAPWAP


The CAPWAP editors have asked the = Chairs to resolve=20 the Mux vs Multiport issue # 115, in order to progress the=20 specification.  Based on the discussion that has taken place the = chairs=20 are in agreement the simplest, cleanest solution for this is to add a = Mux=20 header.  Barring any unforseen events, we will instruct the = editors=20 resolve in favor of a new Mux header.

We intend to close this issue by the = end of the=20 week, Friday, 6/9.  Please review the issue and send any = constructive=20 comments to the list by Friday.

Best Regards,
Dorothy




------_=_NextPart_001_01C68A42.12222060-- --===============1927596340== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1927596340==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 11:03:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnzYv-0008TM-AQ for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 11:03:13 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnzYr-00065d-Se for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 11:03:13 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 868B543015C for ; Wed, 7 Jun 2006 08:03:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2629E430054 for ; Wed, 7 Jun 2006 08:02:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D8709430F6E for ; Wed, 7 Jun 2006 08:02:48 -0700 (PDT) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by hermes.tigertech.net (Postfix) with ESMTP id 83DA6430F6D for ; Wed, 7 Jun 2006 08:02:44 -0700 (PDT) Received: from zidane.cc.vt.edu (IDENT:mirapoint@evil-zidane.cc.vt.edu [10.1.1.13]) by lennier.cc.vt.edu (8.12.11.20060308/8.12.11) with ESMTP id k57F2eK9025894; Wed, 7 Jun 2006 11:02:40 -0400 Received: from [127.0.0.1] (e030168.vtacs.vt.edu [63.164.30.168]) by zidane.cc.vt.edu (MOS 3.8.0-FCS) with ESMTP id FPG74624; Wed, 7 Jun 2006 11:02:42 -0400 (EDT) Message-ID: <4486EAB4.107@cs.umd.edu> Date: Wed, 07 Jun 2006 11:03:16 -0400 From: Charles Clancy User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <4FF84B0BC277FF45AA27FE969DD956A2020373AD@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2020373AD@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Pat Calhoun (pacalhou) wrote: >>Each scenario has its pros and cons... this to me implies >>they should all be supported in the standard, and let users >>pick the one that fits their environment (though that can be >>dangerous when it comes to security). > > Charles, are you stating that DTLS doesn't provide sufficient security > of the data packets, and therefore supplementing DTLS with 802.11i > provides a more secure solution? I suspect I'm interpreting your comment > incorrectly. There are four combinations of crypto over the WTP<->AC link. Let's see if an ASCII-art table can clarify things: sec |AES block |AES block |backhaul security type |ops at WTP |ops at AC | --------+-------------+------------+----------------------------------- none |1 dec |none |none (fine for nonhostile backhaul) | | | 11i |none |1 dec |confidentiality of user data | | |no integrity for CAPWAP header | | | DTLS |1 dec, 1 enc |1 dec |full security | | | 11i+DTLS|1 enc |2 dec |full security | | | Using centralized encryption just shifts 1 dec operation from the WTP to the AC. I agree that things should be simplified. I'm not qualified to recommend one, since I'm not an implementor. All I can do is make sure people know what they're getting in to. How "thin" are these "thin APs" going to be? It seems like that will vary from vendor to vendor. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 11:13:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnzjG-000686-63 for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 11:13:54 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnzjF-0006qQ-Cg for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 11:13:54 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A1C6B4300DC for ; Wed, 7 Jun 2006 08:13:52 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1AA5B430063 for ; Wed, 7 Jun 2006 08:13:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 06B25430F44 for ; Wed, 7 Jun 2006 08:13:23 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by hermes.tigertech.net (Postfix) with ESMTP id C32F0430F9A for ; Wed, 7 Jun 2006 08:13:18 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2006 08:13:19 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="430070054:sNHT82409824" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k57FDHJ2020327; Wed, 7 Jun 2006 08:13:17 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k57FDHCU024962; Wed, 7 Jun 2006 08:13:17 -0700 (PDT) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 08:13:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Jun 2006 08:13:16 -0700 Message-ID: <08A9A3213527A6428774900A80DBD8D8020B0422@xmb-sjc-222.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Encryption Capabilities Thread-Index: AcaJ3Y84crkqQJnUSaC6EDFvApp+RgABmatwAAdfoJAAEMosUA== From: "Nancy Winget (ncamwing)" To: , , "Pat Calhoun (pacalhou)" X-OriginalArrivalTime: 07 Jun 2006 15:13:17.0569 (UTC) FILETIME=[E7A97710:01C68A44] Authentication-Results: sj-dkim-3.cisco.com; header.From=ncamwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Hi Michael, Many thanks for the clarification! Though to reiterate, the "centralized encryption" is only pertinent to the implementation of the packet crypto in 802.11i only and orthogonal to the security of CAPWAP. Nancy. -----Original Message----- From: Michael.G.Williams@nokia.com [mailto:Michael.G.Williams@nokia.com] Sent: Wednesday, June 07, 2006 12:21 AM To: Nancy Winget (ncamwing); clancy@cs.umd.edu; Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: RE: [Capwap] Encryption Capabilities Hi Nancy, Comments inline... -----Original Message----- From: ext Nancy Winget (ncamwing) [mailto:ncamwing@cisco.com] Sent: Tuesday, June 06, 2006 9:43 PM To: Charles Clancy; Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities Charles, I think I agree with you though I'm not sure I understand the full thread. It seems that the current email thread is mixing the securing of different transport layers, e.g. CAPWAP with that of 802.11i. 802.11i is designed to afford protection of the 802.11 transport layer, providing both packet confidentiality and authentication; but it does not address securing the CAPWAP transport layer. An obvious example of this is that the CAPWAP header is not authenticated! So whether the 802.11i crypto is done either at the WTP or AC should be construed as a different feature than that of securing the CAPWAP transport layer. /mgw/ Yes. I read Charles as also agreeing with this. Also, I do not understand what the notion of "centralized" encryption is as the client has no clue of the topology or architecture behind the AP? /mgw/ The centralized comment refers to where the upstream 802.11i decryption is happening. If it is happening at the AC endpoint of the CAPWAP tunnel (centralized), then the WTP is only performing encryption for the CAPWAP tunnel and is not involved in downstream OTA encryption. If the .11i decryption is happening at the WTP, then the WTP is decrypting packets from the STA first, then encrypting to send the clear text packet through the protected CAPWAP tunnel upstream to the AC. >From a threat model, if we are intending to address secure transport of data packets within CAPWAP, doing 802.11i at the AC does not address this requirement, CAPWAP must secure its own encapsulation as well. That is why the draft includes the option of establishing a DTLS tunnel for its data transport. /mgw/ Agreed! Nancy. -----Original Message----- From: Charles Clancy [mailto:clancy@cs.umd.edu] Sent: Tuesday, June 06, 2006 7:53 PM To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities Removing centralized encryption doesn't change the security properties of CAPWAP. HOWEVER, if you really want packets encrypted all the way to the AC, and you remove centralized encryption, your WTPs first have to decrypt the 802.11 packet, and then re-encrypt it for DTLS transport. This seems like a lot of extra processor time for devices that need to be cheap and disposable. For example, OpenSSL on my dual 2.8GHz P4 machine can process AES at roughly 424Mbps [1]. An embedded device with 1/10 my processing power could only keep up with a 21.2 Mbps data flow. [1] openssl speed -elapsed -evp aes-128-cbc -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy Pat Calhoun (pacalhou) wrote: > But what we end up doing is providing two means to do the exact same > thing. I admit that I was surprised when the optional DTLS support was > added for data frames in the CAPWAP draft. However, having thought > through the impact of this change, it actually does address the > previous issues I had raised against centralized 802.11i security, which are: > > 1. By encrypting at the AC, how does one support 802.11e (specifically > frame fragmentation to fit a service period) 2. How does the AC > provide 802.11n A-MPDU/MSDU aggregation? > > So I would propose we define one way, and I prefer the DTLS mechanism > as it doesn't introduce any issues in supporting any 802.11 feature. > > Pat Calhoun > CTO, Wireless Networking Business Unit Cisco Systems > > > > ------------------------------------------------------------------------ > *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] > *Sent:* Monday, June 05, 2006 5:04 PM > *To:* Pat Calhoun (pacalhou) > *Cc:* Michael Montemurro; David T. Perkins; capwap@frascone.com > *Subject:* Re: [Capwap] Encryption Capabilities > > > I do not agree with always requiring the WTP to provide wireless > encryption. The split MAC architecture allows 802.11 > encryption/decryption > at either the WTP or the AC, and this flexibility should be > retained, with use of the > field in question clearly defined. > > Dorothy > > > On 6/5/06, *Pat Calhoun (pacalhou)* > wrote: > > Actually, this field was intended to allow the WTP to > communicate whether it is capable of providing its capabilities, > and therefore allow the AC to determine whether it should > perform centralized encryption. However, with the transition to > DTLS, I propose that we always require the WTP to provide > wireless encryption, and use DTLS between the AC and the WTP. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > ------------------------------------------------------------------------ > *From:* Michael Montemurro > [mailto:montemurro.michael@gmail.com > ] > *Sent:* Saturday, June 03, 2006 12:12 PM > *To:* David T. Perkins > *Cc:* capwap@frascone.com > *Subject:* Re: [Capwap] Encryption Capabilities > > David, > > Would it be sufficient to move Encryption Capabilities from the > WTP Descriptor (Section 4.4.34) to the WTP Radio Information > message element (Section 4.4.39)? > > Mike > > > On 6/3/06, *Michael Montemurro* > wrote: > > David, > > I've created issue 125 to track this issue. > > Mike > > > On 6/1/06, *David T. Perkins* > wrote: > > HI, > > The "(4.4.34)WTP Descriptor" message element has the > subfield "encryption capabilities". What is this used > for? If for radios, then it should be per radio. If > for the user data between the WTP and AC, then > it doesn't seem appropriate to say the value is > defined by "specific binding" definitions because > the WTP can be supporting multiple radios with > some that provide encryption services and some > that don't. > > In general, I don't feel that this subfield is > well defined, and it appears to me that it > should be a per radio attribute. > > Regards, > /david t. perkins > > _________________________________________________________________ > To unsubscribe or modify your subscription options, > please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > ---------------------------------------------------------------------- > -- > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 11:41:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo09U-000389-Ho for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 11:41:00 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo09R-0008UE-FR for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 11:41:00 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C6E0043011D for ; Wed, 7 Jun 2006 08:40:56 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 03476430054 for ; Wed, 7 Jun 2006 08:40:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DF1A1430FD3 for ; Wed, 7 Jun 2006 08:40:05 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id CF953430FCD for ; Wed, 7 Jun 2006 08:40:02 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 07 Jun 2006 08:40:00 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="290677848:sNHT479091440" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k57Fe0Ic004635; Wed, 7 Jun 2006 08:40:00 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k57Fd4l8007670; Wed, 7 Jun 2006 08:40:00 -0700 (PDT) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 08:39:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Jun 2006 08:39:57 -0700 Message-ID: <08A9A3213527A6428774900A80DBD8D8020B0449@xmb-sjc-222.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Encryption Capabilities Thread-Index: AcaKNbPVOCkZOvV7Snme4/pLUaU0AwAD2F2g From: "Nancy Winget (ncamwing)" To: "Charles Clancy" X-OriginalArrivalTime: 07 Jun 2006 15:39:59.0015 (UTC) FILETIME=[A232BB70:01C68A48] Authentication-Results: sj-dkim-1.cisco.com; header.From=ncamwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Hi Charles, Right! I view the 11i security and CAPWAP security as orthogonal. To state whether the 11i is "centralized" or not is different from whether we should protect the CAPWAP data plane...from a security standpoint, the CAPWAP protocol must provide its own security mechanism to ensure that both confidentiality and integrity are provided for its own encapsulation. I agree that letting users pick which one is very dangerous indeed. While the 11i security is not affected by where the 11i crypto is done (within the CAPWAP context), failure to protect the CAPWAP data plane will render it (the CAPWAP data transport) vulnerable to attack. Nancy. -----Original Message----- From: Charles Clancy [mailto:clancy@cs.umd.edu] Sent: Wednesday, June 07, 2006 6:25 AM To: Nancy Winget (ncamwing) Cc: Pat Calhoun (pacalhou); capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities Nancy, You've brought up a good point. Relying on 11i to encrypt data packets between the WTP and AC only provides confidentiality of the data, and does not protect the CAPWAP data transport protocol. Each scenario has its pros and cons... this to me implies they should all be supported in the standard, and let users pick the one that fits their environment (though that can be dangerous when it comes to security). -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy Nancy Winget (ncamwing) wrote: > Charles, > > I think I agree with you though I'm not sure I understand the full > thread. > > It seems that the current email thread is mixing the securing of > different transport layers, e.g. CAPWAP with that of 802.11i. > > 802.11i is designed to afford protection of the 802.11 transport > layer, providing both packet confidentiality and authentication; but > it does not address securing the CAPWAP transport layer. An obvious > example of this is that the CAPWAP header is not authenticated! > > So whether the 802.11i crypto is done either at the WTP or AC should > be construed as a different feature than that of securing the CAPWAP > transport layer. Also, I do not understand what the notion of > "centralized" encryption is as the client has no clue of the topology > or architecture behind the AP? > >>From a threat model, if we are intending to address secure transport >>of > data packets within CAPWAP, doing 802.11i at the AC does not address > this requirement, CAPWAP must secure its own encapsulation as well. > That is why the draft includes the option of establishing a DTLS > tunnel for its data transport. > > Nancy. > > > > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Tuesday, June 06, 2006 7:53 PM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Encryption Capabilities > > Removing centralized encryption doesn't change the security properties > of CAPWAP. > > HOWEVER, if you really want packets encrypted all the way to the AC, > and you remove centralized encryption, your WTPs first have to decrypt > the > 802.11 packet, and then re-encrypt it for DTLS transport. This seems > like a lot of extra processor time for devices that need to be cheap > and disposable. For example, OpenSSL on my dual 2.8GHz P4 machine can > process AES at roughly 424Mbps [1]. An embedded device with 1/10 my > processing power could only keep up with a 21.2 Mbps data flow. > > [1] openssl speed -elapsed -evp aes-128-cbc > > -- > t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy > > Pat Calhoun (pacalhou) wrote: > >>But what we end up doing is providing two means to do the exact same >>thing. I admit that I was surprised when the optional DTLS support was > > >>added for data frames in the CAPWAP draft. However, having thought >>through the impact of this change, it actually does address the >>previous issues I had raised against centralized 802.11i security, > > which are: > >> >>1. By encrypting at the AC, how does one support 802.11e (specifically > > >>frame fragmentation to fit a service period) 2. How does the AC >>provide 802.11n A-MPDU/MSDU aggregation? >> >>So I would propose we define one way, and I prefer the DTLS mechanism >>as it doesn't introduce any issues in supporting any 802.11 feature. >> >>Pat Calhoun >>CTO, Wireless Networking Business Unit Cisco Systems >> >> >> >> > > ---------------------------------------------------------------------- > -- > >> *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] >> *Sent:* Monday, June 05, 2006 5:04 PM >> *To:* Pat Calhoun (pacalhou) >> *Cc:* Michael Montemurro; David T. Perkins; capwap@frascone.com >> *Subject:* Re: [Capwap] Encryption Capabilities >> >> >> I do not agree with always requiring the WTP to provide wireless >> encryption. The split MAC architecture allows 802.11 >> encryption/decryption >> at either the WTP or the AC, and this flexibility should be >> retained, with use of the >> field in question clearly defined. >> >> Dorothy >> >> >> On 6/5/06, *Pat Calhoun (pacalhou)* > > wrote: >> >> Actually, this field was intended to allow the WTP to >> communicate whether it is capable of providing its > > capabilities, > >> and therefore allow the AC to determine whether it should >> perform centralized encryption. However, with the transition > > to > >> DTLS, I propose that we always require the WTP to provide >> wireless encryption, and use DTLS between the AC and the WTP. >> >> >> Pat Calhoun >> CTO, Wireless Networking Business Unit >> Cisco Systems >> >> >> >> > > ---------------------------------------------------------------------- > -- > >> *From:* Michael Montemurro >> [mailto:montemurro.michael@gmail.com >> ] >> *Sent:* Saturday, June 03, 2006 12:12 PM >> *To:* David T. Perkins >> *Cc:* capwap@frascone.com >> *Subject:* Re: [Capwap] Encryption Capabilities >> >> David, >> >> Would it be sufficient to move Encryption Capabilities from > > the > >> WTP Descriptor (Section 4.4.34) to the WTP Radio Information >> message element (Section 4.4.39)? >> >> Mike >> >> >> On 6/3/06, *Michael Montemurro* > > wrote: >> >> David, >> >> I've created issue 125 to track this issue. >> >> Mike >> >> >> On 6/1/06, *David T. Perkins* > > wrote: >> >> HI, >> >> The "(4.4.34)WTP Descriptor" message element has the >> subfield "encryption capabilities". What is this used >> for? If for radios, then it should be per radio. If >> for the user data between the WTP and AC, then >> it doesn't seem appropriate to say the value is >> defined by "specific binding" definitions because >> the WTP can be supporting multiple radios with >> some that provide encryption services and some >> that don't. >> >> In general, I don't feel that this subfield is >> well defined, and it appears to me that it >> should be a per radio attribute. >> >> Regards, >> /david t. perkins >> >> > > _________________________________________________________________ > >> To unsubscribe or modify your subscription options, >> please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> >> Archives: http://lists.frascone.com/pipermail/capwap >> >> >> >> >> >> > _________________________________________________________________ > >> To unsubscribe or modify your subscription options, please > > visit: > >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap >> >> >> >> >>---------------------------------------------------------------------- >>-- >> >>_________________________________________________________________ >>To unsubscribe or modify your subscription options, please visit: >>http://lists.frascone.com/mailman/listinfo/capwap >> >>Archives: http://lists.frascone.com/pipermail/capwap > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 13:17:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1eP-00035H-8g for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 13:17:01 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo1eN-0004rd-Py for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 13:17:01 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D2B2043013D for ; Wed, 7 Jun 2006 10:16:58 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 34E7A430054 for ; Wed, 7 Jun 2006 10:16:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0C38543115A for ; Wed, 7 Jun 2006 10:16:34 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id B3C0B431147 for ; Wed, 7 Jun 2006 10:16:29 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2006 10:16:29 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="1821282143:sNHT44083544" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k57HGSWc018189 for ; Wed, 7 Jun 2006 10:16:28 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k57HG6lA015268 for ; Wed, 7 Jun 2006 10:16:28 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 10:16:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Jun 2006 10:16:28 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC019D8DE0@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New mux header for CAPWAP Thread-Index: AcaJ0/iIUlcV3UUgRz+e4ctlG4c80gAbvxTg From: "Bob O'Hara (boohara)" To: X-OriginalArrivalTime: 07 Jun 2006 17:16:28.0807 (UTC) FILETIME=[1D2EE170:01C68A56] Authentication-Results: sj-dkim-2.cisco.com; header.From=boohara@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Dorothy, This decision to use a mux header is quite different from my recollection of the consensus on this issue. In the spirit of open standards development, can you document the chairs' discussion and how you came to this decision? If this decision is your assessment of rough consensus in the working group, I fear your math is severely flawed and ask that you document those you feel favor this mux header and those your feel do not. -Bob ________________________________ From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] Sent: Tuesday, June 06, 2006 6:45 PM To: capwap@frascone.com Subject: [Capwap] New mux header for CAPWAP The CAPWAP editors have asked the Chairs to resolve the Mux vs Multiport issue # 115, in order to progress the specification. Based on the discussion that has taken place the chairs are in agreement the simplest, cleanest solution for this is to add a Mux header. Barring any unforseen events, we will instruct the editors resolve in favor of a new Mux header. We intend to close this issue by the end of the week, Friday, 6/9. Please review the issue and send any constructive comments to the list by Friday. Best Regards, Dorothy _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 13:54:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2EK-0003FG-AC for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 13:54:08 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo2EI-0001r3-Gt for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 13:54:08 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9D9C743011D for ; Wed, 7 Jun 2006 10:54:05 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 5D525430054 for ; Wed, 7 Jun 2006 10:53:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 479C84311E4 for ; Wed, 7 Jun 2006 10:53:26 -0700 (PDT) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by hermes.tigertech.net (Postfix) with ESMTP id 810E94311E1 for ; Wed, 7 Jun 2006 10:53:21 -0700 (PDT) Received: from vivi.cc.vt.edu (IDENT:mirapoint@evil-vivi.cc.vt.edu [10.1.1.12]) by lennier.cc.vt.edu (8.12.11.20060308/8.12.11) with ESMTP id k57HqeD1001372; Wed, 7 Jun 2006 13:53:16 -0400 Received: from [172.21.128.41] (e030168.vtacs.vt.edu [63.164.30.168]) by vivi.cc.vt.edu (MOS 3.8.0-FCS) with ESMTP id FQD03164; Wed, 7 Jun 2006 13:53:19 -0400 (EDT) Message-ID: <448712B1.5040101@cs.umd.edu> Date: Wed, 07 Jun 2006 13:53:53 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "Nancy Winget (ncamwing)" References: <08A9A3213527A6428774900A80DBD8D8020B0449@xmb-sjc-222.amer.cisco.com> In-Reply-To: <08A9A3213527A6428774900A80DBD8D8020B0449@xmb-sjc-222.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Nancy, I agree they are orthogonal. Each requires processing power to encrypt and decrypt, and we need to make sure we don't overload either the WTPs or ACs. If I recall correctly, the original CAPWAP model assumed an unprotected data plane. The thought being that in order to attack the data plane you need access to the wired network, and if you already have access to the wired network, why do you need to attack CAPWAP to get network connectivity? The desire to support broader backhauls (wireless, Internet, hostile network, etc) of the CAPWAP link has fueled interest in securing the data plane. If people really do want a fully-secured data plane, it does indeed need to flow over a DTLS-protected channel. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Nancy Winget (ncamwing) wrote: > Hi Charles, > > Right! I view the 11i security and CAPWAP security as orthogonal. To > state whether the 11i is "centralized" or not is different from whether > we should protect the CAPWAP data plane...from a security standpoint, > the CAPWAP protocol must provide its own security mechanism to ensure > that both confidentiality and integrity are provided for its own > encapsulation. I agree that letting users pick which one is very > dangerous indeed. > > While the 11i security is not affected by where the 11i crypto is done > (within the CAPWAP context), failure to protect the CAPWAP data plane > will render it (the CAPWAP data transport) vulnerable to attack. > > Nancy. > > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Wednesday, June 07, 2006 6:25 AM > To: Nancy Winget (ncamwing) > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: Re: [Capwap] Encryption Capabilities > > Nancy, > > You've brought up a good point. Relying on 11i to encrypt data packets > between the WTP and AC only provides confidentiality of the data, and > does not protect the CAPWAP data transport protocol. > > Each scenario has its pros and cons... this to me implies they should > all be supported in the standard, and let users pick the one that fits > their environment (though that can be dangerous when it comes to > security). > > -- > t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy > > Nancy Winget (ncamwing) wrote: >> Charles, >> >> I think I agree with you though I'm not sure I understand the full >> thread. >> >> It seems that the current email thread is mixing the securing of >> different transport layers, e.g. CAPWAP with that of 802.11i. >> >> 802.11i is designed to afford protection of the 802.11 transport >> layer, providing both packet confidentiality and authentication; but >> it does not address securing the CAPWAP transport layer. An obvious >> example of this is that the CAPWAP header is not authenticated! >> >> So whether the 802.11i crypto is done either at the WTP or AC should >> be construed as a different feature than that of securing the CAPWAP >> transport layer. Also, I do not understand what the notion of >> "centralized" encryption is as the client has no clue of the topology >> or architecture behind the AP? >> >> >From a threat model, if we are intending to address secure transport >>> of >> data packets within CAPWAP, doing 802.11i at the AC does not address >> this requirement, CAPWAP must secure its own encapsulation as well. >> That is why the draft includes the option of establishing a DTLS >> tunnel for its data transport. >> >> Nancy. >> >> >> >> -----Original Message----- >> From: Charles Clancy [mailto:clancy@cs.umd.edu] >> Sent: Tuesday, June 06, 2006 7:53 PM >> To: Pat Calhoun (pacalhou) >> Cc: capwap@frascone.com >> Subject: Re: [Capwap] Encryption Capabilities >> >> Removing centralized encryption doesn't change the security properties > >> of CAPWAP. >> >> HOWEVER, if you really want packets encrypted all the way to the AC, >> and you remove centralized encryption, your WTPs first have to decrypt > >> the >> 802.11 packet, and then re-encrypt it for DTLS transport. This seems >> like a lot of extra processor time for devices that need to be cheap >> and disposable. For example, OpenSSL on my dual 2.8GHz P4 machine can > >> process AES at roughly 424Mbps [1]. An embedded device with 1/10 my >> processing power could only keep up with a 21.2 Mbps data flow. >> >> [1] openssl speed -elapsed -evp aes-128-cbc >> >> -- >> t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy >> >> Pat Calhoun (pacalhou) wrote: >> >>> But what we end up doing is providing two means to do the exact same >>> thing. I admit that I was surprised when the optional DTLS support was >> >>> added for data frames in the CAPWAP draft. However, having thought >>> through the impact of this change, it actually does address the >>> previous issues I had raised against centralized 802.11i security, >> which are: >> >>> 1. By encrypting at the AC, how does one support 802.11e (specifically >> >>> frame fragmentation to fit a service period) 2. How does the AC >>> provide 802.11n A-MPDU/MSDU aggregation? >>> >>> So I would propose we define one way, and I prefer the DTLS mechanism >>> as it doesn't introduce any issues in supporting any 802.11 feature. >>> >>> Pat Calhoun >>> CTO, Wireless Networking Business Unit Cisco Systems >>> >>> >>> >>> >> ---------------------------------------------------------------------- >> -- >> >>> *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] >>> *Sent:* Monday, June 05, 2006 5:04 PM >>> *To:* Pat Calhoun (pacalhou) >>> *Cc:* Michael Montemurro; David T. Perkins; capwap@frascone.com >>> *Subject:* Re: [Capwap] Encryption Capabilities >>> >>> >>> I do not agree with always requiring the WTP to provide wireless >>> encryption. The split MAC architecture allows 802.11 >>> encryption/decryption >>> at either the WTP or the AC, and this flexibility should be >>> retained, with use of the >>> field in question clearly defined. >>> >>> Dorothy >>> >>> >>> On 6/5/06, *Pat Calhoun (pacalhou)* >> > wrote: >>> >>> Actually, this field was intended to allow the WTP to >>> communicate whether it is capable of providing its >> capabilities, >> >>> and therefore allow the AC to determine whether it should >>> perform centralized encryption. However, with the transition >> to >> >>> DTLS, I propose that we always require the WTP to provide >>> wireless encryption, and use DTLS between the AC and the WTP. >>> >>> >>> Pat Calhoun >>> CTO, Wireless Networking Business Unit >>> Cisco Systems >>> >>> >>> >>> >> ---------------------------------------------------------------------- >> -- >> >>> *From:* Michael Montemurro >>> [mailto:montemurro.michael@gmail.com >>> ] >>> *Sent:* Saturday, June 03, 2006 12:12 PM >>> *To:* David T. Perkins >>> *Cc:* capwap@frascone.com >>> *Subject:* Re: [Capwap] Encryption Capabilities >>> >>> David, >>> >>> Would it be sufficient to move Encryption Capabilities from >> the >> >>> WTP Descriptor (Section 4.4.34) to the WTP Radio Information >>> message element (Section 4.4.39)? >>> >>> Mike >>> >>> >>> On 6/3/06, *Michael Montemurro* >> > wrote: >>> >>> David, >>> >>> I've created issue 125 to track this issue. >>> >>> Mike >>> >>> >>> On 6/1/06, *David T. Perkins* >> > wrote: >>> >>> HI, >>> >>> The "(4.4.34)WTP Descriptor" message element has the >>> subfield "encryption capabilities". What is this used >>> for? If for radios, then it should be per radio. If >>> for the user data between the WTP and AC, then >>> it doesn't seem appropriate to say the value is >>> defined by "specific binding" definitions because >>> the WTP can be supporting multiple radios with >>> some that provide encryption services and some >>> that don't. >>> >>> In general, I don't feel that this subfield is >>> well defined, and it appears to me that it >>> should be a per radio attribute. >>> >>> Regards, >>> /david t. perkins >>> >>> >> _________________________________________________________________ >> >>> To unsubscribe or modify your subscription options, >>> please visit: >>> http://lists.frascone.com/mailman/listinfo/capwap >>> >>> >>> Archives: http://lists.frascone.com/pipermail/capwap >>> >>> >>> >>> >>> >>> >> _________________________________________________________________ >> >>> To unsubscribe or modify your subscription options, please >> visit: >> >>> http://lists.frascone.com/mailman/listinfo/capwap >>> >>> Archives: http://lists.frascone.com/pipermail/capwap >>> >>> >>> >>> >>> ---------------------------------------------------------------------- >>> -- >>> >>> _________________________________________________________________ >>> To unsubscribe or modify your subscription options, please visit: >>> http://lists.frascone.com/mailman/listinfo/capwap >>> >>> Archives: http://lists.frascone.com/pipermail/capwap >> >> >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 13:56:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2Gw-0001f2-5T for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 13:56:50 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo2Gu-0001ww-Kx for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 13:56:50 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 46F0C43012F for ; Wed, 7 Jun 2006 10:56:48 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id C309A430054 for ; Wed, 7 Jun 2006 10:56:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id B01D4398057 for ; Wed, 7 Jun 2006 10:56:24 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id 24ED039800F for ; Wed, 7 Jun 2006 10:56:20 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 07 Jun 2006 10:56:20 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k57HuJep032726; Wed, 7 Jun 2006 10:56:19 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k57HuJCW006785; Wed, 7 Jun 2006 10:56:19 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 10:56:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Jun 2006 10:56:18 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202037507@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Encryption Capabilities Thread-Index: AcaKW0ctJTA14AifQgC1WlGXqhxAGAAAC35A From: "Pat Calhoun (pacalhou)" To: "Charles Clancy" , "Nancy Winget (ncamwing)" X-OriginalArrivalTime: 07 Jun 2006 17:56:19.0443 (UTC) FILETIME=[AE1CFC30:01C68A5B] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 > The desire to support broader backhauls (wireless, Internet, > hostile network, etc) of the CAPWAP link has fueled interest > in securing the data plane. If people really do want a > fully-secured data plane, it does indeed need to flow over a > DTLS-protected channel. And for those environments, one wonders why we need to provide both 802.11i *and* DTLS... Doesn't DTLS provide a superset of 802.11i and therefore covers all cases one would worry about with regards to the latter?? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 14:00:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2K8-0003LQ-3i for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 14:00:08 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo2K6-0002Um-8e for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 14:00:08 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DAFC3430100 for ; Wed, 7 Jun 2006 11:00:05 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2DB86430054 for ; Wed, 7 Jun 2006 10:59:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0EBD2431202 for ; Wed, 7 Jun 2006 10:59:33 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id 04E87431201 for ; Wed, 7 Jun 2006 10:59:30 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 07 Jun 2006 10:59:27 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="290774959:sNHT6818200444" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k57HxRiN017168; Wed, 7 Jun 2006 10:59:27 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k57HxRke028959; Wed, 7 Jun 2006 10:59:27 -0700 (PDT) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 10:59:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Jun 2006 10:59:26 -0700 Message-ID: <08A9A3213527A6428774900A80DBD8D8020B0546@xmb-sjc-222.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Encryption Capabilities Thread-Index: AcaKW0ck1c7/pFY2SIWpge1Abo31ogAAHhVA From: "Nancy Winget (ncamwing)" To: "Charles Clancy" X-OriginalArrivalTime: 07 Jun 2006 17:59:27.0418 (UTC) FILETIME=[1E27B1A0:01C68A5C] Authentication-Results: sj-dkim-1.cisco.com; header.From=ncamwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b Hi Charles, Agreed. I think that is why the inclusion of DTLS for the CAPWAP data plane is included. To your comment of "not overloading" either WTP or AC is the rationale for keeping the DTLS of the data plane optional. Nancy. -----Original Message----- From: Charles Clancy [mailto:clancy@cs.umd.edu] Sent: Wednesday, June 07, 2006 10:54 AM To: Nancy Winget (ncamwing) Cc: Pat Calhoun (pacalhou); capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities Nancy, I agree they are orthogonal. Each requires processing power to encrypt and decrypt, and we need to make sure we don't overload either the WTPs or ACs. If I recall correctly, the original CAPWAP model assumed an unprotected data plane. The thought being that in order to attack the data plane you need access to the wired network, and if you already have access to the wired network, why do you need to attack CAPWAP to get network connectivity? The desire to support broader backhauls (wireless, Internet, hostile network, etc) of the CAPWAP link has fueled interest in securing the data plane. If people really do want a fully-secured data plane, it does indeed need to flow over a DTLS-protected channel. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Nancy Winget (ncamwing) wrote: > Hi Charles, > > Right! I view the 11i security and CAPWAP security as orthogonal. To > state whether the 11i is "centralized" or not is different from whether > we should protect the CAPWAP data plane...from a security standpoint, > the CAPWAP protocol must provide its own security mechanism to ensure > that both confidentiality and integrity are provided for its own > encapsulation. I agree that letting users pick which one is very > dangerous indeed. > > While the 11i security is not affected by where the 11i crypto is done > (within the CAPWAP context), failure to protect the CAPWAP data plane > will render it (the CAPWAP data transport) vulnerable to attack. > > Nancy. > > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Wednesday, June 07, 2006 6:25 AM > To: Nancy Winget (ncamwing) > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: Re: [Capwap] Encryption Capabilities > > Nancy, > > You've brought up a good point. Relying on 11i to encrypt data packets > between the WTP and AC only provides confidentiality of the data, and > does not protect the CAPWAP data transport protocol. > > Each scenario has its pros and cons... this to me implies they should > all be supported in the standard, and let users pick the one that fits > their environment (though that can be dangerous when it comes to > security). > > -- > t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy > > Nancy Winget (ncamwing) wrote: >> Charles, >> >> I think I agree with you though I'm not sure I understand the full >> thread. >> >> It seems that the current email thread is mixing the securing of >> different transport layers, e.g. CAPWAP with that of 802.11i. >> >> 802.11i is designed to afford protection of the 802.11 transport >> layer, providing both packet confidentiality and authentication; but >> it does not address securing the CAPWAP transport layer. An obvious >> example of this is that the CAPWAP header is not authenticated! >> >> So whether the 802.11i crypto is done either at the WTP or AC should >> be construed as a different feature than that of securing the CAPWAP >> transport layer. Also, I do not understand what the notion of >> "centralized" encryption is as the client has no clue of the topology >> or architecture behind the AP? >> >> >From a threat model, if we are intending to address secure transport >>> of >> data packets within CAPWAP, doing 802.11i at the AC does not address >> this requirement, CAPWAP must secure its own encapsulation as well. >> That is why the draft includes the option of establishing a DTLS >> tunnel for its data transport. >> >> Nancy. >> >> >> >> -----Original Message----- >> From: Charles Clancy [mailto:clancy@cs.umd.edu] >> Sent: Tuesday, June 06, 2006 7:53 PM >> To: Pat Calhoun (pacalhou) >> Cc: capwap@frascone.com >> Subject: Re: [Capwap] Encryption Capabilities >> >> Removing centralized encryption doesn't change the security properties > >> of CAPWAP. >> >> HOWEVER, if you really want packets encrypted all the way to the AC, >> and you remove centralized encryption, your WTPs first have to decrypt > >> the >> 802.11 packet, and then re-encrypt it for DTLS transport. This seems >> like a lot of extra processor time for devices that need to be cheap >> and disposable. For example, OpenSSL on my dual 2.8GHz P4 machine can > >> process AES at roughly 424Mbps [1]. An embedded device with 1/10 my >> processing power could only keep up with a 21.2 Mbps data flow. >> >> [1] openssl speed -elapsed -evp aes-128-cbc >> >> -- >> t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy >> >> Pat Calhoun (pacalhou) wrote: >> >>> But what we end up doing is providing two means to do the exact same >>> thing. I admit that I was surprised when the optional DTLS support was >> >>> added for data frames in the CAPWAP draft. However, having thought >>> through the impact of this change, it actually does address the >>> previous issues I had raised against centralized 802.11i security, >> which are: >> >>> 1. By encrypting at the AC, how does one support 802.11e (specifically >> >>> frame fragmentation to fit a service period) 2. How does the AC >>> provide 802.11n A-MPDU/MSDU aggregation? >>> >>> So I would propose we define one way, and I prefer the DTLS mechanism >>> as it doesn't introduce any issues in supporting any 802.11 feature. >>> >>> Pat Calhoun >>> CTO, Wireless Networking Business Unit Cisco Systems >>> >>> >>> >>> >> ---------------------------------------------------------------------- >> -- >> >>> *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] >>> *Sent:* Monday, June 05, 2006 5:04 PM >>> *To:* Pat Calhoun (pacalhou) >>> *Cc:* Michael Montemurro; David T. Perkins; capwap@frascone.com >>> *Subject:* Re: [Capwap] Encryption Capabilities >>> >>> >>> I do not agree with always requiring the WTP to provide wireless >>> encryption. The split MAC architecture allows 802.11 >>> encryption/decryption >>> at either the WTP or the AC, and this flexibility should be >>> retained, with use of the >>> field in question clearly defined. >>> >>> Dorothy >>> >>> >>> On 6/5/06, *Pat Calhoun (pacalhou)* >> > wrote: >>> >>> Actually, this field was intended to allow the WTP to >>> communicate whether it is capable of providing its >> capabilities, >> >>> and therefore allow the AC to determine whether it should >>> perform centralized encryption. However, with the transition >> to >> >>> DTLS, I propose that we always require the WTP to provide >>> wireless encryption, and use DTLS between the AC and the WTP. >>> >>> >>> Pat Calhoun >>> CTO, Wireless Networking Business Unit >>> Cisco Systems >>> >>> >>> >>> >> ---------------------------------------------------------------------- >> -- >> >>> *From:* Michael Montemurro >>> [mailto:montemurro.michael@gmail.com >>> ] >>> *Sent:* Saturday, June 03, 2006 12:12 PM >>> *To:* David T. Perkins >>> *Cc:* capwap@frascone.com >>> *Subject:* Re: [Capwap] Encryption Capabilities >>> >>> David, >>> >>> Would it be sufficient to move Encryption Capabilities from >> the >> >>> WTP Descriptor (Section 4.4.34) to the WTP Radio Information >>> message element (Section 4.4.39)? >>> >>> Mike >>> >>> >>> On 6/3/06, *Michael Montemurro* >> > wrote: >>> >>> David, >>> >>> I've created issue 125 to track this issue. >>> >>> Mike >>> >>> >>> On 6/1/06, *David T. Perkins* >> > wrote: >>> >>> HI, >>> >>> The "(4.4.34)WTP Descriptor" message element has the >>> subfield "encryption capabilities". What is this used >>> for? If for radios, then it should be per radio. If >>> for the user data between the WTP and AC, then >>> it doesn't seem appropriate to say the value is >>> defined by "specific binding" definitions because >>> the WTP can be supporting multiple radios with >>> some that provide encryption services and some >>> that don't. >>> >>> In general, I don't feel that this subfield is >>> well defined, and it appears to me that it >>> should be a per radio attribute. >>> >>> Regards, >>> /david t. perkins >>> >>> >> _________________________________________________________________ >> >>> To unsubscribe or modify your subscription options, >>> please visit: >>> http://lists.frascone.com/mailman/listinfo/capwap >>> >>> >>> Archives: http://lists.frascone.com/pipermail/capwap >>> >>> >>> >>> >>> >>> >> _________________________________________________________________ >> >>> To unsubscribe or modify your subscription options, please >> visit: >> >>> http://lists.frascone.com/mailman/listinfo/capwap >>> >>> Archives: http://lists.frascone.com/pipermail/capwap >>> >>> >>> >>> >>> ---------------------------------------------------------------------- >>> -- >>> >>> _________________________________________________________________ >>> To unsubscribe or modify your subscription options, please visit: >>> http://lists.frascone.com/mailman/listinfo/capwap >>> >>> Archives: http://lists.frascone.com/pipermail/capwap >> >> >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 14:16:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2Zs-0003TX-TN for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 14:16:24 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo2Zr-00044U-GN for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 14:16:24 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 25F6843010B for ; Wed, 7 Jun 2006 11:16:23 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 55E97430064 for ; Wed, 7 Jun 2006 11:15:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4408039801D for ; Wed, 7 Jun 2006 11:15:57 -0700 (PDT) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8647539805A for ; Wed, 7 Jun 2006 11:15:54 -0700 (PDT) Received: from zidane.cc.vt.edu (IDENT:mirapoint@evil-zidane.cc.vt.edu [10.1.1.13]) by lennier.cc.vt.edu (8.12.11.20060308/8.12.11) with ESMTP id k57IFYi3005909; Wed, 7 Jun 2006 14:15:50 -0400 Received: from [172.21.128.41] (e030168.vtacs.vt.edu [63.164.30.168]) by zidane.cc.vt.edu (MOS 3.8.0-FCS) with ESMTP id FPH19481; Wed, 7 Jun 2006 14:15:53 -0400 (EDT) Message-ID: <448717FB.4050700@cs.umd.edu> Date: Wed, 07 Jun 2006 14:16:27 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <4FF84B0BC277FF45AA27FE969DD956A202037507@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A202037507@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.373 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Pat Calhoun (pacalhou) wrote: >> The desire to support broader backhauls (wireless, Internet, >> hostile network, etc) of the CAPWAP link has fueled interest >> in securing the data plane. If people really do want a >> fully-secured data plane, it does indeed need to flow over a >> DTLS-protected channel. > > And for those environments, one wonders why we need to provide > both 802.11i *and* DTLS... Doesn't DTLS provide a superset of 802.11i > and therefore covers all cases one would worry about with regards to > the latter?? Yes, DTLS provides a superset of security, but also triples the computational requirements. My point is that in many cases, the subset of security offered by 11i encryption is sufficient. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 14:17:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2bK-0003ll-WD for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 14:17:55 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo2bK-00046H-98 for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 14:17:54 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 91F0B430110 for ; Wed, 7 Jun 2006 11:17:53 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 66D57430064 for ; Wed, 7 Jun 2006 11:17:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 596D539805A for ; Wed, 7 Jun 2006 11:17:24 -0700 (PDT) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1A08C39805E for ; Wed, 7 Jun 2006 11:17:21 -0700 (PDT) Received: from steiner.cc.vt.edu (IDENT:mirapoint@evil-steiner.cc.vt.edu [10.1.1.14]) by lennier.cc.vt.edu (8.12.11.20060308/8.12.11) with ESMTP id k57I5psM003931; Wed, 7 Jun 2006 14:17:17 -0400 Received: from [172.21.128.41] (e030168.vtacs.vt.edu [63.164.30.168]) by steiner.cc.vt.edu (MOS 3.8.0-FCS) with ESMTP id FLZ09922; Wed, 7 Jun 2006 14:17:18 -0400 (EDT) Message-ID: <44871851.9050408@cs.umd.edu> Date: Wed, 07 Jun 2006 14:17:53 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "Nancy Winget (ncamwing)" References: <08A9A3213527A6428774900A80DBD8D8020B0546@xmb-sjc-222.amer.cisco.com> In-Reply-To: <08A9A3213527A6428774900A80DBD8D8020B0546@xmb-sjc-222.amer.cisco.com> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.373 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 Nancy, Certainly DTLS for the data plane should be left as optional. The question is whether or not to ALSO support 11i encryption to get a subset of the security for a fraction of the processing time. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Nancy Winget (ncamwing) wrote: > Hi Charles, > > Agreed. I think that is why the inclusion of DTLS for the CAPWAP data > plane is included. To your comment of "not overloading" either WTP or > AC is the rationale for keeping the DTLS of the data plane optional. > > Nancy. > > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Wednesday, June 07, 2006 10:54 AM > To: Nancy Winget (ncamwing) > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: Re: [Capwap] Encryption Capabilities > > Nancy, > > I agree they are orthogonal. Each requires processing power to encrypt > and decrypt, and we need to make sure we don't overload either the WTPs > or ACs. > > If I recall correctly, the original CAPWAP model assumed an unprotected > data plane. The thought being that in order to attack the data plane > you need access to the wired network, and if you already have access to > the wired network, why do you need to attack CAPWAP to get network > connectivity? > > The desire to support broader backhauls (wireless, Internet, hostile > network, etc) of the CAPWAP link has fueled interest in securing the > data plane. If people really do want a fully-secured data plane, it > does indeed need to flow over a DTLS-protected channel. > > -- > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > > Nancy Winget (ncamwing) wrote: >> Hi Charles, >> >> Right! I view the 11i security and CAPWAP security as orthogonal. To >> state whether the 11i is "centralized" or not is different from > whether >> we should protect the CAPWAP data plane...from a security standpoint, >> the CAPWAP protocol must provide its own security mechanism to ensure >> that both confidentiality and integrity are provided for its own >> encapsulation. I agree that letting users pick which one is very >> dangerous indeed. >> >> While the 11i security is not affected by where the 11i crypto is done >> (within the CAPWAP context), failure to protect the CAPWAP data plane >> will render it (the CAPWAP data transport) vulnerable to attack. >> >> Nancy. >> >> -----Original Message----- >> From: Charles Clancy [mailto:clancy@cs.umd.edu] >> Sent: Wednesday, June 07, 2006 6:25 AM >> To: Nancy Winget (ncamwing) >> Cc: Pat Calhoun (pacalhou); capwap@frascone.com >> Subject: Re: [Capwap] Encryption Capabilities >> >> Nancy, >> >> You've brought up a good point. Relying on 11i to encrypt data > packets >> between the WTP and AC only provides confidentiality of the data, and >> does not protect the CAPWAP data transport protocol. >> >> Each scenario has its pros and cons... this to me implies they should >> all be supported in the standard, and let users pick the one that fits >> their environment (though that can be dangerous when it comes to >> security). >> >> -- >> t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy >> >> Nancy Winget (ncamwing) wrote: >>> Charles, >>> >>> I think I agree with you though I'm not sure I understand the full >>> thread. >>> >>> It seems that the current email thread is mixing the securing of >>> different transport layers, e.g. CAPWAP with that of 802.11i. >>> >>> 802.11i is designed to afford protection of the 802.11 transport >>> layer, providing both packet confidentiality and authentication; but >>> it does not address securing the CAPWAP transport layer. An obvious >>> example of this is that the CAPWAP header is not authenticated! >>> >>> So whether the 802.11i crypto is done either at the WTP or AC should >>> be construed as a different feature than that of securing the CAPWAP >>> transport layer. Also, I do not understand what the notion of >>> "centralized" encryption is as the client has no clue of the topology > >>> or architecture behind the AP? >>> >>> >From a threat model, if we are intending to address secure transport > >>>> of >>> data packets within CAPWAP, doing 802.11i at the AC does not address >>> this requirement, CAPWAP must secure its own encapsulation as well. >>> That is why the draft includes the option of establishing a DTLS >>> tunnel for its data transport. >>> >>> Nancy. >>> >>> >>> >>> -----Original Message----- >>> From: Charles Clancy [mailto:clancy@cs.umd.edu] >>> Sent: Tuesday, June 06, 2006 7:53 PM >>> To: Pat Calhoun (pacalhou) >>> Cc: capwap@frascone.com >>> Subject: Re: [Capwap] Encryption Capabilities >>> >>> Removing centralized encryption doesn't change the security > properties >>> of CAPWAP. >>> >>> HOWEVER, if you really want packets encrypted all the way to the AC, >>> and you remove centralized encryption, your WTPs first have to > decrypt >>> the >>> 802.11 packet, and then re-encrypt it for DTLS transport. This seems > >>> like a lot of extra processor time for devices that need to be cheap >>> and disposable. For example, OpenSSL on my dual 2.8GHz P4 machine > can >>> process AES at roughly 424Mbps [1]. An embedded device with 1/10 my >>> processing power could only keep up with a 21.2 Mbps data flow. >>> >>> [1] openssl speed -elapsed -evp aes-128-cbc >>> >>> -- >>> t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy >>> >>> Pat Calhoun (pacalhou) wrote: >>> >>>> But what we end up doing is providing two means to do the exact same > >>>> thing. I admit that I was surprised when the optional DTLS support > was >>>> added for data frames in the CAPWAP draft. However, having thought >>>> through the impact of this change, it actually does address the >>>> previous issues I had raised against centralized 802.11i security, >>> which are: >>> >>>> 1. By encrypting at the AC, how does one support 802.11e > (specifically >>>> frame fragmentation to fit a service period) 2. How does the AC >>>> provide 802.11n A-MPDU/MSDU aggregation? >>>> >>>> So I would propose we define one way, and I prefer the DTLS > mechanism >>>> as it doesn't introduce any issues in supporting any 802.11 feature. >>>> >>>> Pat Calhoun >>>> CTO, Wireless Networking Business Unit Cisco Systems >>>> >>>> >>>> >>>> > ---------------------------------------------------------------------- >>> -- >>> >>>> *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] >>>> *Sent:* Monday, June 05, 2006 5:04 PM >>>> *To:* Pat Calhoun (pacalhou) >>>> *Cc:* Michael Montemurro; David T. Perkins; capwap@frascone.com >>>> *Subject:* Re: [Capwap] Encryption Capabilities >>>> >>>> >>>> I do not agree with always requiring the WTP to provide wireless >>>> encryption. The split MAC architecture allows 802.11 >>>> encryption/decryption >>>> at either the WTP or the AC, and this flexibility should be >>>> retained, with use of the >>>> field in question clearly defined. >>>> >>>> Dorothy >>>> >>>> >>>> On 6/5/06, *Pat Calhoun (pacalhou)* >>> > wrote: >>>> >>>> Actually, this field was intended to allow the WTP to >>>> communicate whether it is capable of providing its >>> capabilities, >>> >>>> and therefore allow the AC to determine whether it should >>>> perform centralized encryption. However, with the transition >>> to >>> >>>> DTLS, I propose that we always require the WTP to provide >>>> wireless encryption, and use DTLS between the AC and the WTP. >>>> >>>> >>>> Pat Calhoun >>>> CTO, Wireless Networking Business Unit >>>> Cisco Systems >>>> >>>> >>>> >>>> > ---------------------------------------------------------------------- >>> -- >>> >>>> *From:* Michael Montemurro >>>> [mailto:montemurro.michael@gmail.com >>>> ] >>>> *Sent:* Saturday, June 03, 2006 12:12 PM >>>> *To:* David T. Perkins >>>> *Cc:* capwap@frascone.com >>>> *Subject:* Re: [Capwap] Encryption Capabilities >>>> >>>> David, >>>> >>>> Would it be sufficient to move Encryption Capabilities from >>> the >>> >>>> WTP Descriptor (Section 4.4.34) to the WTP Radio Information >>>> message element (Section 4.4.39)? >>>> >>>> Mike >>>> >>>> >>>> On 6/3/06, *Michael Montemurro* >>> > wrote: >>>> >>>> David, >>>> >>>> I've created issue 125 to track this issue. >>>> >>>> Mike >>>> >>>> >>>> On 6/1/06, *David T. Perkins* >>> > wrote: >>>> >>>> HI, >>>> >>>> The "(4.4.34)WTP Descriptor" message element has the >>>> subfield "encryption capabilities". What is this used >>>> for? If for radios, then it should be per radio. If >>>> for the user data between the WTP and AC, then >>>> it doesn't seem appropriate to say the value is >>>> defined by "specific binding" definitions because >>>> the WTP can be supporting multiple radios with >>>> some that provide encryption services and some >>>> that don't. >>>> >>>> In general, I don't feel that this subfield is >>>> well defined, and it appears to me that it >>>> should be a per radio attribute. >>>> >>>> Regards, >>>> /david t. perkins >>>> >>>> >>> _________________________________________________________________ >>> >>>> To unsubscribe or modify your subscription options, >>>> please visit: >>>> http://lists.frascone.com/mailman/listinfo/capwap >>>> >>>> >>>> Archives: http://lists.frascone.com/pipermail/capwap >>>> >>>> >>>> >>>> >>>> >>>> >>> _________________________________________________________________ >>> >>>> To unsubscribe or modify your subscription options, please >>> visit: >>> >>>> http://lists.frascone.com/mailman/listinfo/capwap >>>> >>>> Archives: http://lists.frascone.com/pipermail/capwap >>>> >>>> >>>> >>>> >>>> > ---------------------------------------------------------------------- >>>> -- >>>> >>>> _________________________________________________________________ >>>> To unsubscribe or modify your subscription options, please visit: >>>> http://lists.frascone.com/mailman/listinfo/capwap >>>> >>>> Archives: http://lists.frascone.com/pipermail/capwap >>> >>> _________________________________________________________________ >>> To unsubscribe or modify your subscription options, please visit: >>> http://lists.frascone.com/mailman/listinfo/capwap >>> >>> Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 14:32:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2p1-0002zH-6R for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 14:32:03 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo2oz-0005JK-P1 for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 14:32:03 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 06D9A4300D0 for ; Wed, 7 Jun 2006 11:32:01 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id C9FF5430054 for ; Wed, 7 Jun 2006 11:31:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id B8A4239805C for ; Wed, 7 Jun 2006 11:31:41 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id D0199398060 for ; Wed, 7 Jun 2006 11:31:38 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 07 Jun 2006 11:31:38 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="290800423:sNHT104577916" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k57IVcM4013328; Wed, 7 Jun 2006 11:31:38 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k57IVXCi016323; Wed, 7 Jun 2006 11:31:37 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 11:31:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Jun 2006 11:31:36 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20203752B@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Encryption Capabilities Thread-Index: AcaKX0kLbsMsqvp/TtS7AXmQvPDMeQAAT7JA From: "Pat Calhoun (pacalhou)" To: "Charles Clancy" X-OriginalArrivalTime: 07 Jun 2006 18:31:37.0265 (UTC) FILETIME=[9C6EFA10:01C68A60] Authentication-Results: sj-dkim-4.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 > Yes, DTLS provides a superset of security, but also triples > the computational requirements. My point is that in many > cases, the subset of security offered by 11i encryption is sufficient. At the expense of disallowing certain standard 802.11 functions from being provided. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 14:48:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo35N-00063S-Fg for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 14:48:57 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo35L-0007ZY-0p for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 14:48:57 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A4B9743013F for ; Wed, 7 Jun 2006 11:48:54 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E83C8430054 for ; Wed, 7 Jun 2006 11:48:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D66CF39801D for ; Wed, 7 Jun 2006 11:48:32 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id D98F039803E for ; Wed, 7 Jun 2006 11:48:28 -0700 (PDT) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 07 Jun 2006 11:48:28 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="290809335:sNHT2354992840" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k57ImR4R016734; Wed, 7 Jun 2006 11:48:27 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k57ImRcL000290; Wed, 7 Jun 2006 11:48:27 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 11:48:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Jun 2006 11:48:26 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202037549@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] How to transmit 802.11 association packet to AC for Localmode Thread-Index: AcaKKMMNa90DLPIOQn+fhUFmHLH1BAAOiirA From: "Pat Calhoun (pacalhou)" To: "zhaoyujin 31390" , X-OriginalArrivalTime: 07 Jun 2006 18:48:27.0470 (UTC) FILETIME=[F69006E0:01C68A62] Authentication-Results: sj-dkim-6.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] How to transmit 802.11 association packet to AC for Localmode X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c That's a good question. The protocol must allow for 802.3 data frames, or 802.11 management frames. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: zhaoyujin 31390 [mailto:zhaoyujin@huawei.com] > Sent: Wednesday, June 07, 2006 4:51 AM > To: capwap@frascone.com > Subject: [Capwap] How to transmit 802.11 association packet > to AC for Localmode > > Dear all: > > In section "11.1.2 Local MAC" defines Local MAC mode architecture. > > And in figure 6 has next process and description: > > 802.11 Association > <---------------------------( - > )-------------------------> > Add Mobile (Clear Text, 802.1X Only) > > <-------------------------> > > o The WTP forwards the 802.11 Authentication and > Association frames > to the AC, which is responsible for responding to the client. > > Because CAPWAP data tunnel maybe only transmit 802.3 frames > for Local MAC mode, I cannot understand how to transmit > 802.11 association frames to AC. > > Best regards > Michael > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 14:50:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo36o-0007rV-Fa for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 14:50:26 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo36n-0007dL-2J for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 14:50:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B68B6430121 for ; Wed, 7 Jun 2006 11:50:24 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 6AF31430063 for ; Wed, 7 Jun 2006 11:50:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 556064312CD for ; Wed, 7 Jun 2006 11:50:03 -0700 (PDT) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by hermes.tigertech.net (Postfix) with ESMTP id 7FD604312CC for ; Wed, 7 Jun 2006 11:50:00 -0700 (PDT) Received: from zidane.cc.vt.edu (IDENT:mirapoint@evil-zidane.cc.vt.edu [10.1.1.13]) by lennier.cc.vt.edu (8.12.11.20060308/8.12.11) with ESMTP id k57Ik9D5011965; Wed, 7 Jun 2006 14:49:56 -0400 Received: from [172.21.128.41] (e030168.vtacs.vt.edu [63.164.30.168]) by zidane.cc.vt.edu (MOS 3.8.0-FCS) with ESMTP id FPH27087; Wed, 7 Jun 2006 14:49:58 -0400 (EDT) Message-ID: <44871FF8.4090205@cs.umd.edu> Date: Wed, 07 Jun 2006 14:50:32 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <4FF84B0BC277FF45AA27FE969DD956A20203752B@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20203752B@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Pat Calhoun (pacalhou) wrote: >> Yes, DTLS provides a superset of security, but also triples >> the computational requirements. My point is that in many >> cases, the subset of security offered by 11i encryption is sufficient. > > At the expense of disallowing certain standard 802.11 functions from > being provided. > ... certainly, that's why like using DTLS, it would be optional. I'm not trying to say we need to keep it. I'm just trying to make sure everyone's aware of the feature it provides. If implementors think getting rid of it is fine, then go for it. Personally, I couldn't care less about computational complexity. Terminating 11i at the WTP and optionally using DTLS makes much more sense in the larger security paradigm. Then everything's clean and modular. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 15:16:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo3WQ-0005mA-Qb for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 15:16:54 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo3WO-0001mu-EO for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 15:16:54 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7D08D4300D0 for ; Wed, 7 Jun 2006 12:16:51 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4D89A430054 for ; Wed, 7 Jun 2006 12:15:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3D84843132F for ; Wed, 7 Jun 2006 12:15:41 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.196]) by hermes.tigertech.net (Postfix) with ESMTP id 90928431330 for ; Wed, 7 Jun 2006 12:15:37 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id t13so168849wxc for ; Wed, 07 Jun 2006 12:15:36 -0700 (PDT) Received: by 10.70.36.1 with SMTP id j1mr1065105wxj; Wed, 07 Jun 2006 12:15:34 -0700 (PDT) Received: by 10.70.133.2 with HTTP; Wed, 7 Jun 2006 12:15:34 -0700 (PDT) Message-ID: <5bfe7a820606071215v764d6ba4o9255c4856a8d3983@mail.gmail.com> Date: Wed, 7 Jun 2006 12:15:34 -0700 From: "Dorothy Stanley" To: "Charles Clancy" In-Reply-To: <44871851.9050408@cs.umd.edu> MIME-Version: 1.0 References: <08A9A3213527A6428774900A80DBD8D8020B0546@xmb-sjc-222.amer.cisco.com> <44871851.9050408@cs.umd.edu> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.6 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2040692575==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 69ad46fbd0e474a7c7f3312d9e320336 --===============2040692575== Content-Type: multipart/alternative; boundary="----=_Part_10270_8499061.1149707734543" ------=_Part_10270_8499061.1149707734543 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Charles, Nancy, Agree completely that DTLS for the data plane should be left as optional. Also agree that the 11i security and CAPWAP security are orthogonal, that is, separate protocols and capabilities. As you mention, 802.11i encryption/decryption at the AC can provide a subset of the security (over the WTP-AC link) for a fraction of the processing time, likely to be a very practical, real concern for WTP devices. In addition, 802.11i encryption/decryption at the AC provides architectural flexibility, enabling CAPWAP compliant solutions to centralize the 802.11i crypto functions in the AC if they wish, reducing dependencies on WTP capabilities (e.g. legacy hardware that only supports TKIP), potentially support a broader range of existing and future applications - even when the primary motivation is not "to secure the WTP-AC data connection". The current ability in the spec to have 802.11i encryption at either the WTP or AC should not be changed. Dorothy On 6/7/06, Charles Clancy wrote: > > Nancy, > > Certainly DTLS for the data plane should be left as optional. > > The question is whether or not to ALSO support 11i encryption to get a > subset of the security for a fraction of the processing time. > > -- > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > > Nancy Winget (ncamwing) wrote: > > Hi Charles, > > > > Agreed. I think that is why the inclusion of DTLS for the CAPWAP data > > plane is included. To your comment of "not overloading" either WTP or > > AC is the rationale for keeping the DTLS of the data plane optional. > > > > Nancy. > > > > -----Original Message----- > > From: Charles Clancy [mailto:clancy@cs.umd.edu] > > Sent: Wednesday, June 07, 2006 10:54 AM > > To: Nancy Winget (ncamwing) > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > Subject: Re: [Capwap] Encryption Capabilities > > > > Nancy, > > > > I agree they are orthogonal. Each requires processing power to encrypt > > and decrypt, and we need to make sure we don't overload either the WTPs > > or ACs. > > > > If I recall correctly, the original CAPWAP model assumed an unprotected > > data plane. The thought being that in order to attack the data plane > > you need access to the wired network, and if you already have access to > > the wired network, why do you need to attack CAPWAP to get network > > connectivity? > > > > The desire to support broader backhauls (wireless, Internet, hostile > > network, etc) of the CAPWAP link has fueled interest in securing the > > data plane. If people really do want a fully-secured data plane, it > > does indeed need to flow over a DTLS-protected channel. > > > > -- > > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > > > > > Nancy Winget (ncamwing) wrote: > >> Hi Charles, > >> > >> Right! I view the 11i security and CAPWAP security as orthogonal. To > >> state whether the 11i is "centralized" or not is different from > > whether > >> we should protect the CAPWAP data plane...from a security standpoint, > >> the CAPWAP protocol must provide its own security mechanism to ensure > >> that both confidentiality and integrity are provided for its own > >> encapsulation. I agree that letting users pick which one is very > >> dangerous indeed. > >> > >> While the 11i security is not affected by where the 11i crypto is done > >> (within the CAPWAP context), failure to protect the CAPWAP data plane > >> will render it (the CAPWAP data transport) vulnerable to attack. > >> > >> Nancy. > >> > >> -----Original Message----- > >> From: Charles Clancy [mailto:clancy@cs.umd.edu] > >> Sent: Wednesday, June 07, 2006 6:25 AM > >> To: Nancy Winget (ncamwing) > >> Cc: Pat Calhoun (pacalhou); capwap@frascone.com > >> Subject: Re: [Capwap] Encryption Capabilities > >> > >> Nancy, > >> > >> You've brought up a good point. Relying on 11i to encrypt data > > packets > >> between the WTP and AC only provides confidentiality of the data, and > >> does not protect the CAPWAP data transport protocol. > >> > >> Each scenario has its pros and cons... this to me implies they should > >> all be supported in the standard, and let users pick the one that fits > >> their environment (though that can be dangerous when it comes to > >> security). > >> > >> -- > >> t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy > >> > >> Nancy Winget (ncamwing) wrote: > >>> Charles, > >>> > >>> I think I agree with you though I'm not sure I understand the full > >>> thread. > >>> > >>> It seems that the current email thread is mixing the securing of > >>> different transport layers, e.g. CAPWAP with that of 802.11i. > >>> > >>> 802.11i is designed to afford protection of the 802.11 transport > >>> layer, providing both packet confidentiality and authentication; but > >>> it does not address securing the CAPWAP transport layer. An obvious > >>> example of this is that the CAPWAP header is not authenticated! > >>> > >>> So whether the 802.11i crypto is done either at the WTP or AC should > >>> be construed as a different feature than that of securing the CAPWAP > >>> transport layer. Also, I do not understand what the notion of > >>> "centralized" encryption is as the client has no clue of the topology > > > >>> or architecture behind the AP? > >>> > >>> >From a threat model, if we are intending to address secure transport > > > >>>> of > >>> data packets within CAPWAP, doing 802.11i at the AC does not address > >>> this requirement, CAPWAP must secure its own encapsulation as well. > >>> That is why the draft includes the option of establishing a DTLS > >>> tunnel for its data transport. > >>> > >>> Nancy. > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Charles Clancy [mailto:clancy@cs.umd.edu] > >>> Sent: Tuesday, June 06, 2006 7:53 PM > >>> To: Pat Calhoun (pacalhou) > >>> Cc: capwap@frascone.com > >>> Subject: Re: [Capwap] Encryption Capabilities > >>> > >>> Removing centralized encryption doesn't change the security > > properties > >>> of CAPWAP. > >>> > >>> HOWEVER, if you really want packets encrypted all the way to the AC, > >>> and you remove centralized encryption, your WTPs first have to > > decrypt > >>> the > >>> 802.11 packet, and then re-encrypt it for DTLS transport. This seems > > > >>> like a lot of extra processor time for devices that need to be cheap > >>> and disposable. For example, OpenSSL on my dual 2.8GHz P4 machine > > can > >>> process AES at roughly 424Mbps [1]. An embedded device with 1/10 my > >>> processing power could only keep up with a 21.2 Mbps data flow. > >>> > >>> [1] openssl speed -elapsed -evp aes-128-cbc > >>> > >>> -- > >>> t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy > >>> > >>> Pat Calhoun (pacalhou) wrote: > >>> > >>>> But what we end up doing is providing two means to do the exact same > > > >>>> thing. I admit that I was surprised when the optional DTLS support > > was > >>>> added for data frames in the CAPWAP draft. However, having thought > >>>> through the impact of this change, it actually does address the > >>>> previous issues I had raised against centralized 802.11i security, > >>> which are: > >>> > >>>> 1. By encrypting at the AC, how does one support 802.11e > > (specifically > >>>> frame fragmentation to fit a service period) 2. How does the AC > >>>> provide 802.11n A-MPDU/MSDU aggregation? > >>>> > >>>> So I would propose we define one way, and I prefer the DTLS > > mechanism > >>>> as it doesn't introduce any issues in supporting any 802.11 feature. > >>>> > >>>> Pat Calhoun > >>>> CTO, Wireless Networking Business Unit Cisco Systems > >>>> > >>>> > >>>> > >>>> > > ---------------------------------------------------------------------- > >>> -- > >>> > >>>> *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] > >>>> *Sent:* Monday, June 05, 2006 5:04 PM > >>>> *To:* Pat Calhoun (pacalhou) > >>>> *Cc:* Michael Montemurro; David T. Perkins; capwap@frascone.com > >>>> *Subject:* Re: [Capwap] Encryption Capabilities > >>>> > >>>> > >>>> I do not agree with always requiring the WTP to provide wireless > >>>> encryption. The split MAC architecture allows 802.11 > >>>> encryption/decryption > >>>> at either the WTP or the AC, and this flexibility should be > >>>> retained, with use of the > >>>> field in question clearly defined. > >>>> > >>>> Dorothy > >>>> > >>>> > >>>> On 6/5/06, *Pat Calhoun (pacalhou)* >>>> > wrote: > >>>> > >>>> Actually, this field was intended to allow the WTP to > >>>> communicate whether it is capable of providing its > >>> capabilities, > >>> > >>>> and therefore allow the AC to determine whether it should > >>>> perform centralized encryption. However, with the transition > >>> to > >>> > >>>> DTLS, I propose that we always require the WTP to provide > >>>> wireless encryption, and use DTLS between the AC and the WTP. > >>>> > >>>> > >>>> Pat Calhoun > >>>> CTO, Wireless Networking Business Unit > >>>> Cisco Systems > >>>> > >>>> > >>>> > >>>> > > ---------------------------------------------------------------------- > >>> -- > >>> > >>>> *From:* Michael Montemurro > >>>> [mailto:montemurro.michael@gmail.com > >>>> ] > >>>> *Sent:* Saturday, June 03, 2006 12:12 PM > >>>> *To:* David T. Perkins > >>>> *Cc:* capwap@frascone.com > >>>> *Subject:* Re: [Capwap] Encryption Capabilities > >>>> > >>>> David, > >>>> > >>>> Would it be sufficient to move Encryption Capabilities from > >>> the > >>> > >>>> WTP Descriptor (Section 4.4.34) to the WTP Radio Information > >>>> message element (Section 4.4.39)? > >>>> > >>>> Mike > >>>> > >>>> > >>>> On 6/3/06, *Michael Montemurro* >>>> > wrote: > >>>> > >>>> David, > >>>> > >>>> I've created issue 125 to track this issue. > >>>> > >>>> Mike > >>>> > >>>> > >>>> On 6/1/06, *David T. Perkins* >>>> > wrote: > >>>> > >>>> HI, > >>>> > >>>> The "(4.4.34)WTP Descriptor" message element has the > >>>> subfield "encryption capabilities". What is this used > >>>> for? If for radios, then it should be per radio. If > >>>> for the user data between the WTP and AC, then > >>>> it doesn't seem appropriate to say the value is > >>>> defined by "specific binding" definitions because > >>>> the WTP can be supporting multiple radios with > >>>> some that provide encryption services and some > >>>> that don't. > >>>> > >>>> In general, I don't feel that this subfield is > >>>> well defined, and it appears to me that it > >>>> should be a per radio attribute. > >>>> > >>>> Regards, > >>>> /david t. perkins > >>>> > >>>> > >>> _________________________________________________________________ > >>> > >>>> To unsubscribe or modify your subscription options, > >>>> please visit: > >>>> http://lists.frascone.com/mailman/listinfo/capwap > >>>> > >>>> > >>>> Archives: http://lists.frascone.com/pipermail/capwap > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> _________________________________________________________________ > >>> > >>>> To unsubscribe or modify your subscription options, please > >>> visit: > >>> > >>>> http://lists.frascone.com/mailman/listinfo/capwap > >>>> > >>>> Archives: http://lists.frascone.com/pipermail/capwap > >>>> > >>>> > >>>> > >>>> > >>>> > > ---------------------------------------------------------------------- > >>>> -- > >>>> > >>>> _________________________________________________________________ > >>>> To unsubscribe or modify your subscription options, please visit: > >>>> http://lists.frascone.com/mailman/listinfo/capwap > >>>> > >>>> Archives: http://lists.frascone.com/pipermail/capwap > >>> > >>> _________________________________________________________________ > >>> To unsubscribe or modify your subscription options, please visit: > >>> http://lists.frascone.com/mailman/listinfo/capwap > >>> > >>> Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_10270_8499061.1149707734543 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Charles, Nancy,

Agree completely that DTLS for the data plane should be left as optional.
Also agree that the 11i security and CAPWAP security are orthogonal, that
is, separate protocols and capabilities.

As you mention, 802.11i encryption/decryption at the AC can
provide a subset of the security (over the WTP-AC link) for a
fraction of the processing time, likely to be a very practical, real
concern for WTP devices.

In addition,  802.11i encryption/decryption at the AC
provides architectural flexibility, enabling CAPWAP compliant solutions to
centralize the 802.11i crypto functions in the AC if they wish, reducing  dependencies on
WTP capabilities (e.g. legacy hardware that only supports TKIP),  potentially support a broader
range of existing and future applications - even when the
primary motivation is not "to secure the WTP-AC data connection".

The current ability in the spec to have 802.11i encryption at either the WTP or
AC should not be changed.

Dorothy

On 6/7/06, Charles Clancy <clancy@cs.umd.edu> wrote:
Nancy,

Certainly DTLS for the data plane should be left as optional.

The question is whether or not to ALSO support 11i encryption to get a
subset of the security for a fraction of the processing time.

--
t. charles clancy, ph.d.  |  tcc@umd.edu  |  www.cs.umd.edu/~clancy


Nancy Winget (ncamwing) wrote:
> Hi Charles,
>
> Agreed.  I think that is why the inclusion of DTLS for the CAPWAP data
> plane is included.  To your comment of "not overloading" either WTP or
> AC is the rationale for keeping the DTLS of the data plane optional.
>
>    Nancy.
>
> -----Original Message-----
> From: Charles Clancy [mailto:clancy@cs.umd.edu]
> Sent: Wednesday, June 07, 2006 10:54 AM
> To: Nancy Winget (ncamwing)
> Cc: Pat Calhoun (pacalhou); capwap@frascone.com
> Subject: Re: [Capwap] Encryption Capabilities
>
> Nancy,
>
> I agree they are orthogonal.  Each requires processing power to encrypt
> and decrypt, and we need to make sure we don't overload either the WTPs
> or ACs.
>
> If I recall correctly, the original CAPWAP model assumed an unprotected
> data plane.  The thought being that in order to attack the data plane
> you need access to the wired network, and if you already have access to
> the wired network, why do you need to attack CAPWAP to get network
> connectivity?
>
> The desire to support broader backhauls (wireless, Internet, hostile
> network, etc) of the CAPWAP link has fueled interest in securing the
> data plane.  If people really do want a fully-secured data plane, it
> does indeed need to flow over a DTLS-protected channel.
>
> --
> t. charles clancy, ph.d.  |  tcc@umd.edu  |  www.cs.umd.edu/~clancy
>
>
> Nancy Winget (ncamwing) wrote:
>> Hi Charles,
>>
>> Right!  I view the 11i security and CAPWAP security as orthogonal.  To
>> state whether the 11i is "centralized" or not is different from
> whether
>> we should protect the CAPWAP data plane...from a security standpoint,
>> the CAPWAP protocol must provide its own security mechanism to ensure
>> that both confidentiality and integrity are provided for its own
>> encapsulation.  I agree that letting users pick which one is very
>> dangerous indeed.
>>
>> While the 11i security is not affected by where the 11i crypto is done
>> (within the CAPWAP context),  failure to protect the CAPWAP data plane
>> will render it (the CAPWAP data transport) vulnerable to attack.
>>
>>      Nancy.
>>
>> -----Original Message-----
>> From: Charles Clancy [mailto: clancy@cs.umd.edu]
>> Sent: Wednesday, June 07, 2006 6:25 AM
>> To: Nancy Winget (ncamwing)
>> Cc: Pat Calhoun (pacalhou); capwap@frascone.com
>> Subject: Re: [Capwap] Encryption Capabilities
>>
>> Nancy,
>>
>> You've brought up a good point.  Relying on 11i to encrypt data
> packets
>> between the WTP and AC only provides confidentiality of the data, and
>> does not protect the CAPWAP data transport protocol.
>>
>> Each scenario has its pros and cons... this to me implies they should
>> all be supported in the standard, and let users pick the one that fits
>> their environment (though that can be dangerous when it comes to
>> security).
>>
>> --
>> t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
>>
>> Nancy Winget (ncamwing) wrote:
>>> Charles,
>>>
>>> I think I agree with you though I'm not sure I understand the full
>>> thread.
>>>
>>> It seems that the current email thread is mixing the securing of
>>> different transport layers, e.g. CAPWAP with that of 802.11i.
>>>
>>> 802.11i is designed to afford protection of the 802.11 transport
>>> layer, providing both packet confidentiality and authentication; but
>>> it does not address securing the CAPWAP transport layer.  An obvious
>>> example of this is that the CAPWAP header is not authenticated!
>>>
>>> So whether the 802.11i crypto is done either at the WTP or AC should
>>> be construed as a different feature than that of securing the CAPWAP
>>> transport layer.  Also, I do not understand what the notion of
>>> "centralized" encryption is as the client has no clue of the topology
>
>>> or architecture behind the AP?
>>>
>>> >From a threat model, if we are intending to address secure transport
>
>>>> of
>>> data packets within CAPWAP, doing 802.11i at the AC does not address
>>> this requirement, CAPWAP must secure its own encapsulation as well.
>>> That is why the draft includes the option of establishing a DTLS
>>> tunnel for its data transport.
>>>
>>>    Nancy.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Charles Clancy [mailto:clancy@cs.umd.edu]
>>> Sent: Tuesday, June 06, 2006 7:53 PM
>>> To: Pat Calhoun (pacalhou)
>>> Cc: capwap@frascone.com
>>> Subject: Re: [Capwap] Encryption Capabilities
>>>
>>> Removing centralized encryption doesn't change the security
> properties
>>> of CAPWAP.
>>>
>>> HOWEVER, if you really want packets encrypted all the way to the AC,
>>> and you remove centralized encryption, your WTPs first have to
> decrypt
>>> the
>>> 802.11 packet, and then re-encrypt it for DTLS transport.  This seems
>
>>> like a lot of extra processor time for devices that need to be cheap
>>> and disposable.  For example, OpenSSL on my dual 2.8GHz P4 machine
> can
>>> process AES at roughly 424Mbps [1].  An embedded device with 1/10 my
>>> processing power could only keep up with a 21.2 Mbps data flow.
>>>
>>> [1] openssl speed -elapsed -evp aes-128-cbc
>>>
>>> --
>>> t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  www.cs.umd.edu/~clancy
>>>
>>> Pat Calhoun (pacalhou) wrote:
>>>
>>>> But what we end up doing is providing two means to do the exact same
>
>>>> thing. I admit that I was surprised when the optional DTLS support
> was
>>>> added for data frames in the CAPWAP draft. However, having thought
>>>> through the impact of this change, it actually does address the
>>>> previous issues I had raised against centralized 802.11i security,
>>> which are:
>>>
>>>> 1. By encrypting at the AC, how does one support 802.11e
> (specifically
>>>> frame fragmentation to fit a service period) 2. How does the AC
>>>> provide 802.11n A-MPDU/MSDU aggregation?
>>>>
>>>> So I would propose we define one way, and I prefer the DTLS
> mechanism
>>>> as it doesn't introduce any issues in supporting any 802.11 feature.
>>>>
>>>> Pat Calhoun
>>>> CTO, Wireless Networking Business Unit Cisco Systems
>>>>
>>>>
>>>>
>>>>
> ----------------------------------------------------------------------
>>> --
>>>
>>>>    *From:* Dorothy Stanley [mailto: dstanley1389@gmail.com]
>>>>    *Sent:* Monday, June 05, 2006 5:04 PM
>>>>    *To:* Pat Calhoun (pacalhou)
>>>>    *Cc:* Michael Montemurro; David T. Perkins; capwap@frascone.com
>>>>    *Subject:* Re: [Capwap] Encryption Capabilities
>>>>
>>>>
>>>>    I do not agree with always requiring the WTP to provide wireless
>>>>    encryption. The split MAC architecture allows 802.11
>>>>    encryption/decryption
>>>>    at either the WTP or the AC, and this flexibility should be
>>>>    retained, with use of the
>>>>    field in question clearly defined.
>>>>
>>>>    Dorothy
>>>>
>>>>
>>>>    On 6/5/06, *Pat Calhoun (pacalhou)* < pcalhoun@cisco.com
>>>>    <mailto:pcalhoun@cisco.com>> wrote:
>>>>
>>>>        Actually, this field was intended to allow the WTP to
>>>>        communicate whether it is capable of providing its
>>> capabilities,
>>>
>>>>        and therefore allow the AC to determine whether it should
>>>>        perform centralized encryption. However, with the transition
>>> to
>>>
>>>>        DTLS, I propose that we always require the WTP to provide
>>>>        wireless encryption, and use DTLS between the AC and the WTP.
>>>>
>>>>
>>>>        Pat Calhoun
>>>>        CTO, Wireless Networking Business Unit
>>>>        Cisco Systems
>>>>
>>>>
>>>>
>>>>
> ----------------------------------------------------------------------
>>> --
>>>
>>>>            *From:* Michael Montemurro
>>>>            [mailto: montemurro.michael@gmail.com
>>>>            <mailto:montemurro.michael@gmail.com>]
>>>>            *Sent:* Saturday, June 03, 2006 12:12 PM
>>>>            *To:* David T. Perkins
>>>>            *Cc:* capwap@frascone.com <mailto:capwap@frascone.com>
>>>>            *Subject:* Re: [Capwap] Encryption Capabilities
>>>>
>>>>        David,
>>>>
>>>>        Would it be sufficient to move Encryption Capabilities from
>>> the
>>>
>>>>        WTP Descriptor (Section 4.4.34) to the WTP Radio Information
>>>>        message element (Section 4.4.39)?
>>>>
>>>>        Mike
>>>>
>>>>
>>>>        On 6/3/06, *Michael Montemurro* <montemurro.michael@gmail.com
>>>>        <mailto: montemurro.michael@gmail.com>> wrote:
>>>>
>>>>            David,
>>>>
>>>>            I've created issue 125 to track this issue.
>>>>
>>>>            Mike
>>>>
>>>>
>>>>            On 6/1/06, *David T. Perkins* <dperkins@dsperkins.com
>>>>            <mailto:dperkins@dsperkins.com>> wrote:
>>>>
>>>>                HI,
>>>>
>>>>                The "(4.4.34)WTP Descriptor" message element has the
>>>>                subfield "encryption capabilities". What is this used
>>>>                for? If for radios, then it should be per radio. If
>>>>                for the user data between the WTP and AC, then
>>>>                it doesn't seem appropriate to say the value is
>>>>                defined by "specific binding" definitions because
>>>>                the WTP can be supporting multiple radios with
>>>>                some that provide encryption services and some
>>>>                that don't.
>>>>
>>>>                In general, I don't feel that this subfield is
>>>>                well defined, and it appears to me that it
>>>>                should be a per radio attribute.
>>>>
>>>>                Regards,
>>>>                /david t. perkins
>>>>
>>>>
>>> _________________________________________________________________
>>>
>>>>                To unsubscribe or modify your subscription options,
>>>>                please visit:
>>>>                http://lists.frascone.com/mailman/listinfo/capwap
>>>>                <http://lists.frascone.com/mailman/listinfo/capwap>
>>>>
>>>>                Archives: http://lists.frascone.com/pipermail/capwap
>>>>                <http://lists.frascone.com/pipermail/capwap >
>>>>
>>>>
>>>>
>>>>
>>>>
>>> _________________________________________________________________
>>>
>>>>        To unsubscribe or modify your subscription options, please
>>> visit:
>>>
>>>>        http://lists.frascone.com/mailman/listinfo/capwap
>>>>
>>>>        Archives: http://lists.frascone.com/pipermail/capwap
>>>>        <http://lists.frascone.com/pipermail/capwap >
>>>>
>>>>
>>>>
>>>>
> ----------------------------------------------------------------------
>>>> --
>>>>
>>>> _________________________________________________________________
>>>> To unsubscribe or modify your subscription options, please visit:
>>>> http://lists.frascone.com/mailman/listinfo/capwap
>>>>
>>>> Archives: http://lists.frascone.com/pipermail/capwap
>>>
>>> _________________________________________________________________
>>> To unsubscribe or modify your subscription options, please visit:
>>> http://lists.frascone.com/mailman/listinfo/capwap
>>>
>>> Archives: http://lists.frascone.com/pipermail/capwap
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_10270_8499061.1149707734543-- --===============2040692575== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============2040692575==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 16:25:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4aM-00070I-Rx for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 16:25:02 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo4aL-00050D-IO for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 16:25:02 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E1274430109 for ; Wed, 7 Jun 2006 13:25:00 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1F4F6430063 for ; Wed, 7 Jun 2006 13:24:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 10C25398062 for ; Wed, 7 Jun 2006 13:24:40 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 42BDE39803B for ; Wed, 7 Jun 2006 13:24:36 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k57KOaF6001184 for ; Wed, 7 Jun 2006 13:24:36 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k57KOZAN001181 for ; Wed, 7 Jun 2006 13:24:35 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 7 Jun 2006 13:24:35 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [Capwap] MTU determination X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad HI, It looks like the MTU Discovery Padding information element (4.4.27) is now no longer used? Is this really the case? Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 16:50:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4zH-0007jq-Mv for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 16:50:47 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo4zG-0001OX-6Q for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 16:50:47 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7FA6B43013F for ; Wed, 7 Jun 2006 13:50:45 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 86984430097 for ; Wed, 7 Jun 2006 13:50:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6D51843148D for ; Wed, 7 Jun 2006 13:50:18 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 132E8431497 for ; Wed, 7 Jun 2006 13:50:14 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k57KoETb008301 for ; Wed, 7 Jun 2006 13:50:14 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k57KoE9D008297 for ; Wed, 7 Jun 2006 13:50:14 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 7 Jun 2006 13:50:14 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [Capwap] Message type and message elements X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 HI, I created a list sorted by the section number of the message element showing the section number of the message type where it is used. I created this from a list of message type (and used message elements). The two lists follow. Is this information correct? (That is, are there no message elements listed where they shouldn't be, and are there no missing message elements where they should be?) (Note 1: I had to add leading zeros to sort the list in the proper order.) (Note 2: message types 5.3 and 5.4 are not included) (Note 3: I'm creating a "sheet cheat" that describes all of the message types (operations). It is a summary of the sections describing the message types. I have found that it would be really handy if the sections put in a standard place the state(s) in which the message could be sent, and the direction of the message. Right now, I have to dig for this info. Here is an example from my cheat sheet. "(6.1)Join Request (Join state) (WTP->AC)" Also, it's a little strange that the code for the message types is in a table in section 4.3.1.1 (and not in the section describing the message), but descriptions of the message elements specifies the message element ID.) Message type and included message element List Type Element 5.1 4.4.19 5.1 4.4.34 5.1 4.4.36 5.1 4.4.38 5.1 4.4.39 5.2 4.4.1 5.2 4.4.4 5.2 4.4.40 5.2 4.4.41 6.1 4.4.26 6.1 4.4.30 6.1 4.4.34 6.1 4.4.37 6.1 4.4.42 6.1 4.4.39 6.2 4.4.29 6.2 4.4.2 6.2 4.4.3 6.2 4.4.30 7.1 none 7.2 none 8.2 4.4.4 8.2 4.4.5 8.2 4.4.28 8.2 4.4.31 8.2 4.4.33 8.2 4.4.44 8.2 4.4.43 8.2 11.10.2 8.2 11.10.6 8.2 11.10.8 8.2 11.10.13 8.2 11.10.14 8.2 11.10.18 8.2 11.10.19 8.2 11.10.24 8.3 4.4.2 8.3 4.4.3 8.3 4.4.10 8.3 4.4.15 8.3 4.4.22 8.3 4.4.35 8.3 11.10.2 8.3 11.10.4 8.3 11.10.6 8.3 11.10.8 8.3 11.10.13 8.3 11.10.14 8.3 11.10.15 8.3 11.10.18 8.3 11.10.22 8.3 11.10.24 8.4 4.4.2 8.4 4.4.3 8.4 4.4.5 8.4 4.4.6 8.4 4.4.7 8.4 4.4.9 8.4 4.4.10 8.4 4.4.11 8.4 4.4.15 8.4 4.4.16 8.4 4.4.18 8.4 4.4.22 8.4 4.4.26 8.4 4.4.28 8.4 4.4.31 8.4 4.4.35 8.4 4.4.42 8.4 11.10.2 8.4 11.10.4 8.4 11.10.6 8.4 11.10.8 8.4 11.10.10 8.4 11.10.13 8.4 11.10.14 8.4 11.10.15 8.4 11.10.18 8.4 11.10.22 8.4 11.10.24 8.5 4.4.29 8.6 4.4.11 8.7 none 8.8 none 9.1 4.4.23 9.1 4.4.24 9.1 4.4.25 9.2 none 9.3 none 9.4 none 9.5 4.4.14 9.5 4.4.20 9.5 4.4.21 9.5 11.10.9 9.5 11.10.16 9.5 11.10.23 9.6 none 9.7 4.4.13 9.7 4.4.12 9.8 none 10.1 4.4.8 10.1 4.4.17 10.1 11.10.11 10.1 11.10.12 10.1 11.10.20 10.1 11.10.25 10.2 4.4.29 11.7.1 11.10.1 11.7.1 11.10.5 11.7.1 11.10.21 11.7.1 11.10.7 11.7.2 11.10.3 List sorted by message element section Type Element 07.01 none 07.02 none 08.07 none 08.08 none 09.02 none 09.03 none 09.04 none 09.06 none 09.07 none 05.02 04.04.01 06.02 04.04.02 08.03 04.04.02 08.04 04.04.02 06.02 04.04.03 08.03 04.04.03 08.04 04.04.03 05.02 04.04.04 08.02 04.04.04 08.02 04.04.05 08.04 04.04.05 08.04 04.04.06 08.04 04.04.07 10.01 04.04.08 08.04 04.04.09 08.03 04.04.10 08.04 04.04.10 08.04 04.04.11 08.06 04.04.11 09.07 04.04.12 09.07 04.04.13 09.05 04.04.14 08.03 04.04.15 08.04 04.04.15 08.04 04.04.16 10.01 04.04.17 08.04 04.04.18 05.01 04.04.19 09.05 04.04.20 09.05 04.04.21 08.03 04.04.22 08.04 04.04.22 09.01 04.04.23 09.01 04.04.24 09.01 04.04.25 06.01 04.04.26 08.04 04.04.26 08.02 04.04.28 08.04 04.04.28 10.02 04.04.29 06.02 04.04.29 08.05 04.04.29 06.01 04.04.30 06.02 04.04.30 08.02 04.04.31 08.04 04.04.31 08.02 04.04.33 05.01 04.04.34 06.01 04.04.34 08.03 04.04.35 08.04 04.04.35 05.01 04.04.36 06.01 04.04.37 05.01 04.04.38 05.01 04.04.39 06.01 04.04.39 05.02 04.04.40 05.02 04.04.41 06.01 04.04.42 08.04 04.04.42 08.02 04.04.43 08.02 04.04.44 11.07.01 11.10.01 08.02 11.10.02 08.03 11.10.02 08.04 11.10.02 11.07.02 11.10.03 08.03 11.10.04 08.04 11.10.04 11.07.01 11.10.05 08.02 11.10.06 08.03 11.10.06 08.04 11.10.06 11.07.01 11.10.07 08.02 11.10.08 08.03 11.10.08 08.04 11.10.08 09.05 11.10.09 08.04 11.10.10 10.01 11.10.11 10.01 11.10.12 08.02 11.10.13 08.03 11.10.13 08.04 11.10.13 08.02 11.10.14 08.03 11.10.14 08.04 11.10.14 08.03 11.10.15 08.04 11.10.15 09.05 11.10.16 08.02 11.10.18 08.03 11.10.18 08.04 11.10.18 08.02 11.10.19 10.01 11.10.20 11.07.01 11.10.21 08.03 11.10.22 08.04 11.10.22 09.05 11.10.23 08.02 11.10.24 08.03 11.10.24 08.04 11.10.24 10.01 11.10.25 Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 17:20:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo5Rg-00044A-RZ for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 17:20:08 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo5Rf-00046C-B0 for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 17:20:08 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B1D88430097 for ; Wed, 7 Jun 2006 14:20:06 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 225BD430097 for ; Wed, 7 Jun 2006 14:19:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0A9614314EB for ; Wed, 7 Jun 2006 14:19:36 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id 4BACA4314D4 for ; Wed, 7 Jun 2006 14:19:32 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 07 Jun 2006 14:19:32 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k57LJVsU014212; Wed, 7 Jun 2006 14:19:31 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k57LJTCs005234; Wed, 7 Jun 2006 14:19:31 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 14:19:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Jun 2006 14:19:25 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20203761E@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Encryption Capabilities Thread-Index: AcaKZvtmQvSuTykPSmOEuCUlpJ5iMwAEOKlQ From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "Charles Clancy" X-OriginalArrivalTime: 07 Jun 2006 21:19:26.0326 (UTC) FILETIME=[0E0FC160:01C68A78] Authentication-Results: sj-dkim-3.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2103892131==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format. --===============2103892131== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68A78.0DC9ED96" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68A78.0DC9ED96 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > As you mention, 802.11i encryption/decryption at the AC can > provide a subset of the security (over the WTP-AC link) for a > fraction of the processing time, likely to be a very practical, real=20 > concern for WTP devices.=20 =20 Dorothy, I don't think that's a very fair statement. There is no 802.11 chipset that is selling today, which I am aware of, that doesn't support hardware crypto. The impact on the WTP's processor is negligible.=20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C68A78.0DC9ED96 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
> As you mention, = 802.11i=20 encryption/decryption at the AC can
>=20 provide a subset of the security (over the WTP-AC link) for = a
> fraction of the processing time, = likely to=20 be a very practical, real
> = concern=20 for WTP devices.
 
Dorothy, I don't think that's a very fair statement. There is = no 802.11=20 chipset that is selling today, which I am aware of, that doesn't support = hardware crypto. The impact on the WTP's processor is negligible.=20

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 
------_=_NextPart_001_01C68A78.0DC9ED96-- --===============2103892131== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============2103892131==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 19:17:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo7Gw-000526-2b for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 19:17:10 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo7Gu-0002Zy-Hr for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 19:17:10 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A07B743010B for ; Wed, 7 Jun 2006 16:17:07 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 312F9430063 for ; Wed, 7 Jun 2006 16:16:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 20421398065 for ; Wed, 7 Jun 2006 16:16:46 -0700 (PDT) Received: from smtpauth08.mail.atl.earthlink.net (smtpauth08.mail.atl.earthlink.net [209.86.89.68]) by zoidberg.tigertech.net (Postfix) with ESMTP id B7347398060 for ; Wed, 7 Jun 2006 16:16:42 -0700 (PDT) Received: from [209.86.224.32] (helo=elwamui-cypress.atl.sa.earthlink.net) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1Fo7GT-0007ej-17; Wed, 07 Jun 2006 19:16:41 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Wed, 7 Jun 2006 19:16:41 -0400 Message-ID: <22429541.1149722201062.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Date: Wed, 7 Jun 2006 19:16:41 -0400 (EDT) From: "Scott G. Kelly" To: "Pat Calhoun (pacalhou)" , Dorothy.Gellert@nokia.com, capwap@frascone.com Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710c368aa5aab96a67a2be52651d7cc5f2e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.32 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Comments inline below... -----Original Message----- >From: "Pat Calhoun (pacalhou)" >Sent: Jun 7, 2006 10:52 AM >To: Dorothy.Gellert@nokia.com, capwap@frascone.com >Subject: Re: [Capwap] New mux header for CAPWAP > >Dorothy, > >I'm somewhat surprised by your conclusion. While some vendors have >claimed that adding the MUX is simpler, folks more familiar with >Ethernet switches and routers than the ones that have come up with this >proposal, including folks that have to deploy them (read: customers), >have stated on this list that this feature will make it very complex to >run CAPWAP in their networks. Hmmm - a contest about who knows how much about which gear? Now there's a rathole, and surely we have more productive things to discuss? Moving on... as for customer testimonials, I think we saw one post claiming that ISPs wouldn't trust customers to do their own QoS marking on their own private WAN links vs one customer who suggested that the multiport approach would be problematic for firewall configuration. Not exactly a groundswell. >So once more, I will state my concern. Let's assume that a branch office >is connected through a WAN. The WTP will mark packets as it sees fit, >but given that all CAPWAP packets are encrypted, there is no way for the Since when are all CAPWAP packets encrypted? Last time I read the draft, only the control PDUs required encryption. If granular QoS is needed for the data channel, then either you don't want to encrypt it, or you want the encryptor to do the marking. >enterprise customer to specify what QoS properties to apply to LWAPP >control, IEEE 802.11 management and data frames on the WAN router. The >only thing one can do is let the WTP apply the labels, but these labels >may be inconsistent with the QoS policies used in all of the other >applications used by the customers. There is no reason why vendors can't provide the configuration knobs for this, so I must be missing something, because it sounds like your concern is that the customer will configure the AC/WTP to apply labels which are inconsistent with his own QoS policies... > The reality is that the CAPWAP >protocol is timing sensitive, especially as it comes to control, and >802.11 management packets. But this raises an interesting point: if it's so sensitive that it may not work right in this configuration, why choose this architecture to begin with? This is not the only option. More below... >So in order to deploy CAPWAP, they have to change their network wide QoS >policies across all of their infrastructure. > >How can this possibly justify taking the easy route? How does this >decision benefit the internet community? There are many ways to build networks, and some work better than others. Obviously, splitting capwap across WAN links that have congestion problems is going to be problematic, and for the reasons you mentioned above (i.e. that the encapsulated data will likely have QoS granularity requirements of its own which cannot be addressed by using a separate UDP port for all data), this sounds like an architecture to be avoided. I spent the morning talking with ISP folks and traffic engineers. The first question that came up was, "do you expect to have congestion problems on that WAN link?", and when I responded "apparently", I was asked "why don't you just add enough bandwidth to resolve this?". When I replied that maybe it was because that would cost too much money, the next question was, "if you are afraid that you'll be losing timing-sensitive capwap packets, what's happening to the application data in your data channel? Don't you need granular QoS on that as well? If your classification is only 5-tuple based, how will you classify those when they all use the same port?" It went on and on like that. The last question I was asked: "Why would you even try to *build* a network like that?" Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 19:27:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo7Qk-0000Ev-LN for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 19:27:18 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo7Qj-0002oP-5K for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 19:27:18 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C1C6043011D for ; Wed, 7 Jun 2006 16:27:16 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id EBB31430063 for ; Wed, 7 Jun 2006 16:26:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D85C143167F for ; Wed, 7 Jun 2006 16:26:50 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.206]) by hermes.tigertech.net (Postfix) with ESMTP id F37F5431679 for ; Wed, 7 Jun 2006 16:26:48 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id t13so208928wxc for ; Wed, 07 Jun 2006 16:26:48 -0700 (PDT) Received: by 10.70.73.4 with SMTP id v4mr1373211wxa; Wed, 07 Jun 2006 16:26:48 -0700 (PDT) Received: by 10.70.133.2 with HTTP; Wed, 7 Jun 2006 16:26:47 -0700 (PDT) Message-ID: <5bfe7a820606071626h1aca4bdei854e75ab1dd4eba3@mail.gmail.com> Date: Wed, 7 Jun 2006 16:26:47 -0700 From: "Dorothy Stanley" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20203761E@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A20203761E@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.6 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1183926622==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a --===============1183926622== Content-Type: multipart/alternative; boundary="----=_Part_13527_25367937.1149722807968" ------=_Part_13527_25367937.1149722807968 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Pat, The text refers to comparing the 802.11 crypto with DTLS crypto, noting that the DTLS crypto would not necessarily re-use the 802.11 hardware engine, and referencing Charles' comment: >Yes, DTLS provides a superset of security, but also triples the >computational requirements. My point is that in many cases, the subset >of security offered by 11i encryption is sufficient. I agree that 802.11 chipsets shipping today support hardware crypto- AES-CCMP, and RC4-TKIP/WEP to be specific. There are also "legacy" devices out there that just support WEP/TKIP in hardware/firmware - one example which would use existing CAPWAP support of 802.11i crypto at the AC to provide AES encryption, independent of the WTP-AC channel security discussion. Dorothy On 6/7/06, Pat Calhoun (pacalhou) wrote: > > > As you mention, 802.11i encryption/decryption at the AC can > > provide a subset of the security (over the WTP-AC link) for a > > fraction of the processing time, likely to be a very practical, real > > concern for WTP devices. > > Dorothy, I don't think that's a very fair statement. There is no 802.11chipset that is selling today, which I am aware of, that doesn't support > hardware crypto. The impact on the WTP's processor is negligible. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > ------=_Part_13527_25367937.1149722807968 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Pat,

The text refers to
comparing the 802.11 crypto with DTLS crypto, noting that the
DTLS crypto would not necessarily re-use the 802.11 hardware
engine, and referencing Charles' comment:

>Yes, DTLS provides a superset of security, but also triples the
>computational requirements.  My point is that in many cases, the subset
>of security offered by 11i encryption is sufficient.

I agree that 802.11 chipsets shipping today support hardware crypto-
AES-CCMP, and RC4-TKIP/WEP to be specific.
There are also "legacy" devices out there that just support
WEP/TKIP in hardware/firmware -  one example which would use
existing CAPWAP support of 802.11i crypto at the AC to provide
AES encryption, independent of the WTP-AC
channel security discussion.

Dorothy

On 6/7/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
> As you mention, 802.11i encryption/decryption at the AC can
> provide a subset of the security (over the WTP-AC link) for a
> fraction of the processing time, likely to be a very practical, real
> concern for WTP devices.
 
Dorothy, I don't think that's a very fair statement. There is no 802.11 chipset that is selling today, which I am aware of, that doesn't support hardware crypto. The impact on the WTP's processor is negligible.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

------=_Part_13527_25367937.1149722807968-- --===============1183926622== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1183926622==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 20:41:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo8aw-0001mN-9O for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 20:41:54 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo8au-0005g7-Rt for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 20:41:54 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 02EC643011F for ; Wed, 7 Jun 2006 17:41:52 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3B999430054 for ; Wed, 7 Jun 2006 17:41:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 29653398042 for ; Wed, 7 Jun 2006 17:41:31 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6F66639805E for ; Wed, 7 Jun 2006 17:41:27 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k580fQgK004655 for ; Wed, 7 Jun 2006 17:41:26 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k580fQT2004651 for ; Wed, 7 Jun 2006 17:41:26 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 7 Jun 2006 17:41:26 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com In-Reply-To: <5bfe7a820606071626h1aca4bdei854e75ab1dd4eba3@mail.gmail.com> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [Capwap] Typo in 4.3.1.1 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 HI, Section 4.3.1 shows the header for control messages, and has a 32 bit field for the message type value, which is described in section 4.3.1.1 shown below. There is a typo in the text. It is marked with the correction. ------------------------- 4.3.1.1. Message Type The Message Type field identifies the function of the CAPWAP control message. The Message Type field is comprised of an IANA Enterprise Number and a message type value field. The first two byte contain ^^^^^^^^ should be "three octets" the IANA Enterprise Number (for example, the IEEE 802.11 IANA Enterprise number is 13277), and the second two bytes contain the ^^^^^^^^^^^^^^^^ should be "last octet" Message Type value. The message type field can be expressed as: Message Type = IANA Enterprise Number * 256 + Message Type Value -------------------------- Note, the above is an OK fix, but I'd change the text to the following to make it clearer. 4.3.1.1. Message Type The Message Type field identifies the function of the CAPWAP control message. The Message Type field is comprised of an IANA Enterprise Number[IANA.enterpriseNumber.ref] and an enterprise specific message type number. The first three octets is the enterprise number in network byte order, with zero being used for CAPWAP generic message types and the IEEE 802.11 IANA assigned enterprise number 13277 being used for IEEE 802.11 technology specific message types. The last octet is the enterprise specific message type number, which has a range from 0 to 255. The value of the message type field can be expressed as: Message type value = IANA Enterprise Number * 256 + enterprise specific message type number -------------------------- And, I'd make the identification of the message elements encoded identically. Thus, I'd change the message element header in section 4.4 to the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Where the value of Type is expressed as: Message Element Type value = IANA Enterprise Number * 256 + enterprise specific type number Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 21:07:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo8ze-00018S-ON for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 21:07:26 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo8zd-0008Es-62 for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 21:07:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C89A7430115 for ; Wed, 7 Jun 2006 18:07:24 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B944E430054 for ; Wed, 7 Jun 2006 18:07:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9D76D398042 for ; Wed, 7 Jun 2006 18:07:02 -0700 (PDT) Received: from smtpauth08.mail.atl.earthlink.net (smtpauth08.mail.atl.earthlink.net [209.86.89.68]) by zoidberg.tigertech.net (Postfix) with ESMTP id B85CB39801D for ; Wed, 7 Jun 2006 18:06:59 -0700 (PDT) Received: from [209.86.224.32] (helo=elwamui-cypress.atl.sa.earthlink.net) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1Fo8zC-0002BY-Py for capwap@frascone.com; Wed, 07 Jun 2006 21:06:58 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Wed, 7 Jun 2006 21:06:58 -0400 Message-ID: <1432608.1149728818821.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Date: Wed, 7 Jun 2006 21:06:58 -0400 (EDT) From: "Scott G. Kelly" To: capwap Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710a7e0d7bb3aa61294dc44e2f47907731d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.32 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 I've been watching this debate with some interest, being quite surprised that an optional feature would suddenly draw such attention and energy. Still, I guess I should comment along with everyone else. First, I agree with Charles on the point that having or not having this feature has no impact on the security properties of the capwap protocol itself. Also, I agree with a number of folks on the point that these two features are orthogonal. AC termination of 802.11 link security does not (indeed, is not intended to) provide for capwap data channel security. However, this feature is not security-neutral - it provides a unique set of security properties that are useful. Before explaining further, here are some pictures, along with some descriptive text (hoping my webmail interface doesn't mangle them): KEY --- # - 802.11 link security boundary % - capwap security boundary Case 1: 802.11 link security terminates at the WTP ##################### # # %%%%%%%%%%%%%%%%%%%%%%% # +------+ +#--%-+ CAPWAP +----+ % # |client|---------| WTP |===========| AC | % # +------+ +#--%-+ +----+ % # # %%%%%%%%%%%%%%%%%%%%%%% ##################### This is the situation when you en/decrypt 802.11 traffic at the WTP. In this case, the client and WTP are within the 802.11 link security boundary. Of course, this picture does not include key establishment, because during that phase, the security boundary is more like the one below, and also, the AAA server (not pictured) is involved. Also, one might choose to include the AC in the 802.11 link security boundary pictured above (even though it doesn't participate in the crypto ops) because it is privy to the 802.11 keying material, but I'm leaving this out because it simplifies the ascii drawing, and will add nothing material to the discussion below. Case 2: 802.11 link security terminates at the AC %%%%%%%%%%%%%%%%% % +-----+ % /-----------------%--| WTP | % | % +--++-+ % | % ||capwap % | % || % | % +---++--+ % | % | | % | %%%%%%%%%%%%%%%%% ##############|############################### # +------+ | | AC | # # |client|----/ 802.11 | | # # +------+ +-------+ # ############################################## Here is the case when you en/decrypt 802.11 at the AC. Note that the WTP is not within the 802.11 link security boundary. It is "out of the loop", so to speak, being little more than a transport provider. Also note that the capwap security boundary is the same as for case 1 - no change. Now, let's get to the questions about whether this is useful or not, and let's keep in mind that since this is an *optional* feature, the "burden of proof" with respect to utility is much lower than it would be if it were mandatory to implement. As noted above, in case 2, the WTP is simply a transport provider. That means that if the WTP were somehow compromised, unless the attacker also compromised one or more of the other security mechanisms as well (802.1x, the AC's credential, etc), he could do little more than effect a DoS attack. In case 1, various methods of WTP compromise could give an attacker access to the data as it is unencrypted and then re-encrypted. In this case, the attacker gets access to the cleartext data via relatively low-cost methods (compared to breaking .11 crypto), essentially attacking the weakest link. In case 2, WTP's can be deployed in hostile territory, and if the attacker can't break the 802.11 crypto, he can't have the same security impact (aside from DoS, which he can have in any event). It's like running 802.11 security over the air - he has to break the crypto. No matter how completely the attacker might compromise a WTP, all he will see is encrypted data. This is good! Of course, there is additional value to the centralized encryption model, as Dorothy Stanley pointed out: architectural flexibility, enabling CAPWAP compliant solutions to centralize the 802.11i crypto functions in the AC if they wish, reducing dependencies on WTP capabilities (e.g. legacy hardware that only supports TKIP), potentially support a broader range of existing and future applications - even when the primary motivation is not 'to secure the WTP-AC data connection'". Some vendors chose this approach to MAC splitting while others chose encryption at the WTP. That's one reason why it should remain optional. --Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 07 21:16:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo987-00089u-3M for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 21:16:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo985-0008Rk-LZ for capwap-archive@lists.ietf.org; Wed, 07 Jun 2006 21:16:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 061C1430063 for ; Wed, 7 Jun 2006 18:16:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C569C430063 for ; Wed, 7 Jun 2006 18:15:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B541D4317D1 for ; Wed, 7 Jun 2006 18:15:48 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 241AC4317CF for ; Wed, 7 Jun 2006 18:15:45 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k581Fjan013650 for ; Wed, 7 Jun 2006 18:15:45 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k581Fjdj013646 for ; Wed, 7 Jun 2006 18:15:45 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 7 Jun 2006 18:15:45 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [Capwap] Message type summary X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a HI, Below is a summary of the message types from my "cheat sheet". Note that I've renamed several of the messages to be consistent with standard terminology used in network protocols. That is request/response - ask to do something, and then get back the result report/ack - provide some info, and get back an acknowledgement that it was received I have issues with several of these messages, which will be sent other emails. However, wanted to provide this list so that all can agree on the state which sent, and the direction. pattern - ()() () () (5.1)Discovery Request(1) (Discovery state) (WTP->AC) (5.2)Discovery Response(2) (no state) (AC->WTP) (5.3)Primary Discovery Request(19) - DISCUSS:remove this (5.4)Primary Discovery Response(20) - DISCUSS:remove this (6.1)Join Request(3) (Join state) (WTP->AC) (6.2)Join Response(4) (Join state) (AC->WTP) (7.1)Echo Request(13) (any normal state) (AC->WTP and WTP->AC) (7.2)Echo Response(14) (any normal state) (WTP->AC and AC->WTP) (8.2)Configuration Status Report(5) (configure state) (WTP->AC) (8.3)Configure Status Ack(6) (configure state) (AC->WTP) (8.4)Configuration Update Request(7) (configure and run states) (AC->WTP) (8.5)Configuration Update Response(8) (configure and run states) (WTP->AC) (8.6)Change State Event Report(11) (configure and run states) (WTP->AC) (8.7)Change State Event Ack(12) (configure and run states) (AC->WTP) (8.8)Clear Config Request(23) (config and run state) (AC->WTP) (9.1a)Image Data Request(15) (join/configure and run states) (WTP->AC) (9.2a)Image Data Response(16) (join/configure and run states) (AC->WTP) (9.1b)Image Data Request(15) (image data state) (AC->WTP) (9.2b)Image Data Response(16) (image data state) (WTP->AC) (9.1c)Image Data Request(15) (run state) (AC->WTP) (9.2c)Image Data Response(16) (run state) (WTP->AC) (9.3)Reset Request(17) (run state) (AC->WTP) (9.4)Reset Response(18) (run state) (WTP->AC) (9.5)WTP Event Report(9) (run state) (WTP->AC) (9.6)WTP Event Ack(10) (run state) (AC->WTP) (9.7)Data Transfer Request(21) (run state) (WTP->AC) (9.8)Data Transfer Response(22) (run state) (AC->WTP) (10.1)Mobile Config Request(24) (run state) (AC->WTP) (10.2)Mobile Config Response(25) (run state) (WTP->AC) (11.7.1)IEEE 802.11 WLAN Config Request(3398912(13277:0)) (run state) (AC->WTP) (11.7.2)IEEE 802.11 WLAN Config Response(3398913(13277:1)) (run state) (WTP->AC) Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 02:07:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoDgT-0003Nn-Vl for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 02:07:57 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoDgS-0001r5-HC for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 02:07:57 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5FE444300FE for ; Wed, 7 Jun 2006 23:07:55 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B36F8430054 for ; Wed, 7 Jun 2006 23:07:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9AD28398033 for ; Wed, 7 Jun 2006 23:07:35 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6B00C398015 for ; Wed, 7 Jun 2006 23:07:33 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5867X2i018725 for ; Wed, 7 Jun 2006 23:07:33 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5867Wq1018721 for ; Wed, 7 Jun 2006 23:07:33 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 7 Jun 2006 23:07:32 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [Capwap] Please re-explain radio MAC address X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 HI, Would someone please explain again for me (since I missed it) why there is a need for the "Radio MAC address" in the CAPWAP header. This seems redundant to me, since I thought there is a one-to-one correspondense between the radio MAC address and the radio ID in a WTP, and the radio ID is specified in the CAPWAP header. Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 04:47:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoGBI-0008Hn-U2 for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 04:47:56 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoGBH-00068C-24 for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 04:47:56 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 154EE430054 for ; Thu, 8 Jun 2006 01:47:54 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6CA46430054 for ; Thu, 8 Jun 2006 01:47:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5879A39802E for ; Thu, 8 Jun 2006 01:47:24 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 788A1398021 for ; Thu, 8 Jun 2006 01:47:22 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k588lLhd022242 for ; Thu, 8 Jun 2006 01:47:21 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k588lLfK022239 for ; Thu, 8 Jun 2006 01:47:21 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 8 Jun 2006 01:47:21 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [Capwap] Proposal for CAPWAP packet format X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 75ac735ede4d089f7192d230671d536e HI, After going through the CAPWAP-01 doc pretty closely, and starting an implementation of a prototype AC and WTP, I would like to submit the following as a replacement for the definition of the CAPWAP packet formats found in CAPWAP-01. -------------------------- Proposal for CAPWAP Packet Format: 7-jun-2007:dtp CAPWAP Packet formats: CAPWAP Unprotected Data Packet: +-----------------------------------------+ | IP | UDP | CAPWAP | CAPWAP | Wireless | | Hdr | Hdr | MUX | Data | Payload | | | | Hdr | Hdr | | +-----------------------------------------+ CAPWAP DTLS Protected Data Packet: +-----------------------------------------------------------+ | IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS | | Hdr | Hdr | MUX | Hdr | Data | Payload | Trailer | | | | Hdr | | Hdr | | | +-----------------------------------------------------------+ \--integrity checked-------------------/ \--encrypted-------------------/ CAPWAP Unprotected Control Packet: +------------------------------------------+ | IP | UDP | CAPWAP | CAPWAP | Message | | Hdr | Hdr | MUX | Control | Elements | | | | Hdr | Hdr | | +------------------------------------------+ CAPWAP DTLS Protected Control Packet: +----------------------------------------------------------+ | IP | UDP | CAPWAP | DTLS | CAPWAP | Message | DTLS | | Hdr | Hdr | MUX | Hdr | Control | Elements | Trailer | | | | Hdr | | Hdr | | | +----------------------------------------------------------+ \--integrity checked-----------------/ \--encrypted-------------------/ UDP: All CAPWAP packets are encapsulated within UDP. CAPWAP MUX Header: All CAPWAP protocol packets use a short header that specifies the version of CAPWAP and the type of the CAPWAP packet. CAPWAP Data Header: This header is used for packets that encapsulate user data. Wireless Payload: A CAPWAP protocol packet that contains a wireless payload is known as a data frame. The CAPWAP protocol does not dictate the format of the wireless payload, which is defined by the appropriate wireless standard. DTLS Header: Protected CAPWAP packets use the DTLS protocol to provide message integrity and encryption services. DTLS Trailer: A field used to provide protection service for security of CAPWAP messages CAPWAP Control Header: The CAPWAP protocol includes a signalling component, known as the CAPWAP control protocol. All CAPWAP control packets include a Control Header. Message Elements: A CAPWAP Control packet includes one or more message elements, which are found immediately following the control header. These message elements are in a type, length, value format. NOTE: A CAPWAP MUX header is needed whether or not the same or different UDP ports are used for CAPWAP control and data messages. This is because both CAPWAP data and control messages can be unprotected or protected by DTLS, and the MUX header is needed to distinguish protected from unprotected. Remember that CAPWAP "discovery requests" and "discovery responses" are unprotected, and that all other CAPWAP control message types are protected. CAPWAP MUX Header: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Version| Type | +-+-+-+-+-+-+-+-+ Version - the version of the CAPWAP protocol (the first is 0) Type - packet type, values are: 0 - CAPWAP Unprotected Data Packet 1 - CAPWAP DTLS Protected Data Packet 2 - CAPWAP Unprotected Control Packet 3 - CAPWAP DTLS Protected Control Packet 4-15 - reserved CAPWAP Data Header: DISCUSS: I removed the version field and moved it to the MUX Header. I also removed the Radio MAC field, since I believe that it is redundant with the RID field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RID | HLEN |F|L|W| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment ID | Frag Offset |Rsv-2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Wireless Specific Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... (optional) Pad | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RID: A 5 bit field which contains the Radio ID number for this packet. WTPs with multiple radios but a single MAC Address range use this field to indicate which radio is associated with the packet. (DISCUSS: I don't understand what this last sentence means. Is there an example?) HLEN: Length of CAPWAP data header in multiples of 4 octets. (Similar to IP header length). This length includes the optional portion. F: The Fragment 'F' bit indicates whether this packet is a fragment. When this bit is one (1), the packet is a fragment and the payload MUST be combined with the payloads of other corresponding fragments to reassemble the complete payload exchanged between the WTP and AC. L: The Not Last 'L' bit is valid only if the 'F' bit is set and indicates whether the packet contains the last fragment of a fragmented exchange between WTP and AC. When this bit is 1, the packet is not the last fragment. When this bit is 0, the packet is the last fragment. W: The Wireless 'W' bit is used to specify whether the optional wireless specific information field is present in the header. A value of one (1) is used to represent the fact that the optional "Wireless Specific Information" field is present. Flags: A set of reserved bits for future flags in the CAPWAP data header. These bits MUST be set to zero. Fragment ID: An 16 bit unsigned integer field whose value is assigned to each group of fragments making up a complete set. The fragment ID space is managed individually for every WTP/AC pair. The value of Fragment ID is incremented with each new set of fragments. The value of Fragment ID wraps to zero after the maximum value has been used to identify a set of fragments. (DISCUSS: what value is used when the packet is not a fragment?) Fragment Offset: A 13 bit field that indicates where in the payload will this payload fragment belong during re-assembly. This field is valid when the 'F' bit is set to 1. The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. Reserved: The 3-bit Reserved-2 field is reserved and set to 0. Wireless Specific Information: This optional field contains technology specific information that may be used to carry per packet wireless information. This field is only present if the 'W' bit is set. The field contains the basic format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wireless ID | Length | Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wireless ID: The wireless binding identifier. The following values are defined: 1 - : IEEE 802.11 Length: The length of the data field Data: Wireless specific information, whose details are defined in the technology specific binding section. Pad: optional octets of zero so that the header will be a multiple of 4 octets Wireless Payload: The format of the wireless payload depends on the encapsulation mode. There are two formats defined, which are: 802.3 Frame - this is the standard IEEE 802.3 frame (DISCUSS: this needs to be defined, since IEEE 802.3 frame means different things to different people) 802.11 native frame - DISCUSS: need some help here CAPWAP Control Header: DISCUSS: I totally removed the old "transport header", since I could not see any use for it in control messages. However, it means that a control message MUST fit in a single UDP message. I don't see that this is a problem. Anyone else see a problem with this limitation? It really simplifies control packet processing! 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Seq Num | Msg ID |res |F| Length of Msg Elements | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type: This field identifies the function of the CAPWAP control message. The Message Type field is comprised of an IANA Enterprise Number and an enterprise specific message type number. The first three octets is the enterprise number in network byte order, with zero being used for CAPWAP generic message types and the IEEE 802.11 IANA assigned enterprise number 13277 being used for IEEE 802.11 technology specific message types. The last octet is the enterprise specific message type number, which has a range from 0 to 255. The value of the message type field can be expressed as: Message type value = IANA Enterprise Number * 256 + enterprise specific message type number Message Sequence Number: This field is used by the message retry layer to match paired messages, which are a response to a request, and a report to an acknowledgement. Each time a request (or report is sent) even for retries, the sequence number is monotonically incremented. After the maximum value is reached, the value wraps back to zero. The paired response (or acknowledgement) returns the value from the request (or report). Note the size is 8-bits, and thus a maximum of 255 paired messages can be concurrently in flight. Message ID: This field is used by the CAPWAP application to match responses (or acknowledgements) with requests (or reports). The value must be monotonically incremented for each unique request (or report). After the maximum value is reached, the value wraps back to zero. The paired response (or acknowledgement) returns the value from the request (or report). Note the size is 6-bits, and thus a maximum of 63 CAPWAP operations can be currently outstanding. F: This bit field indicates if the message is the first or second in a message pair. A value of "1" means first, and "0" means second. There are two types of message pairs, which a request and response, or a report and acknowledgement. Thus, the first is a request or report message (with the F field set to "1"), and the second is a response or acknowledgement (with the F field set to "0"). NOTE: fields "message sequence number", "message ID", and "F" may seem confusing or redundant. However, they are needed to support the required retry mechanism. For example, consider two events, E1 and E2, occurring close together in time on a WTP. Say, the next Message ID value is 10. It would be used in the first report for the message ID value for event E1, and 11 would be used in the report for the second message ID value for event E2. The WTP would remember the E1-10, and the E2-11 pairing. Both messages would be handed off to the layer the provides retry service. The F bit is used so that the retry service does not have to understand the values of the message type, and so the numbers used by the WTP and AC for requests (and reports) do not have to be coordinated. The top layer must tell the retry service if a message to send is the first or second in a message pair. In this example, say, 203 is the next value for message sequence number. Thus, the first report would use 203 for the message sequence number, and the second would use 204. Say the first report was dropped by the network, but the second one was received and acknowledged by the AC. The retry layer would indicate to the WTP that an acknowledgement was received, and the WTP would use the message ID value of 11 to know it was for event E2. Since the first report was dropped, the retry layer would time it out, and send a retry using the next message sequence number of 205. When an acknowledgement came back, it would indicate this to the WTP, which would use the message ID of 10 to know that event E1 was acknowledged. If on the other hand, the network continued dropping the report for E1, the retry layer would indicate to the WTP that the report was not acknowledged by passing message ID 10. The WTP could log this and try to determine if the session was still active, and if so, continue with other operations. DISCUSS: This note may be long, and maybe confusing. However, there is NO information in CAPWAP-01 to explain how retries are suppose to work! The above fields allow the round trip timeout to be dynamically computed, and for a drop of a request/response or report/acknowledgement pair to be handled without blowing away the DTLS session. Also, the retry service saves responses (and acknowledgements) and replies to them without impacting the upper level (that is, without causing the upper level to reprocess the operation.) Res: The Res field is currently unused and must be set to zero. Length of Message Elements: This field indicates in octets the length of the message elements field, which contains zero, one, or more message elements. The field is 14 bits wide, and thus the maximum size that can be specified 16K. However, the effective maximum size is the UDP packet max, minus the overhead of the CAPWAP and DTLS headers. Message Elements: The message elements field contains, zero, one, or more message element field, which has the following format: Message Element: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Element Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Value .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Message Element Type: This field identifies a message element of a CAPWAP control message. The Message Element Type field is comprised of an IANA Enterprise Number and an enterprise specific message element type number. The first three octets is the enterprise number in network byte order, with zero being used for CAPWAP generic message types and the IEEE 802.11 IANA assigned enterprise number 13277 being used for IEEE 802.11 technology specific message element types. The last octet is the enterprise specific message element type number, which has a range from 0 to 255. The value of the message element type field can be expressed as: Message element type value = IANA Enterprise Number * 256 + enterprise specific message element type number -------------------------- Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 12:45:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoNdr-0001vH-Ao for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 12:45:55 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoNdp-0004xU-JE for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 12:45:55 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BCBD543006C for ; Thu, 8 Jun 2006 09:45:52 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 36CC743006C for ; Thu, 8 Jun 2006 09:45:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 28F3839804E for ; Thu, 8 Jun 2006 09:45:28 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by zoidberg.tigertech.net (Postfix) with ESMTP id 56BD839800C for ; Thu, 8 Jun 2006 09:45:24 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 08 Jun 2006 09:45:24 -0700 X-IronPort-AV: i="4.05,220,1146466800"; d="scan'208"; a="430276985:sNHT52732028" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k58GjNt4016625; Thu, 8 Jun 2006 09:45:23 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k58GjLAI008570; Thu, 8 Jun 2006 09:45:23 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 09:45:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Jun 2006 09:45:18 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202037883@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Encryption Capabilities Thread-Index: AcaKidoPgDI6Q1zjSQafGZcQwh7wXQAeFjKw From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" X-OriginalArrivalTime: 08 Jun 2006 16:45:19.0410 (UTC) FILETIME=[ED594920:01C68B1A] Authentication-Results: sj-dkim-4.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 > The text refers to > comparing the 802.11 crypto with DTLS crypto, noting that the > DTLS crypto would not necessarily re-use the 802.11 hardware > engine, and referencing Charles' comment: >>Yes, DTLS provides a superset of security, but also triples the >>computational requirements. My point is that in many cases, the subset >>of security offered by 11i encryption is sufficient. True, but Charles also stated: > Terminating 11i at the WTP and optionally using DTLS makes much more > sense in the larger security paradigm. Then everything's clean and > modular. > I agree that 802.11 chipsets shipping today support hardware crypto- > AES-CCMP, and RC4-TKIP/WEP to be specific. > There are also "legacy" devices out there that just support > WEP/TKIP in hardware/firmware - one example which would use > existing CAPWAP support of 802.11i crypto at the AC to provide > AES encryption, independent of the WTP-AC > channel security discussion. I agree, but would claim that the devices you claim are *really* old - and I would even wonder whether they would be capable of supporting many other CAPWAP features, such as multiple SSIDs, 802.11e, etc. Further, AES capable APs appeared in the market as early as 2002 (maybe earlier, but this is the first reference I can find quickly) - that's four years ago. I think those customers have had a good return on their investment already. Not clear we need to optimize today's protocol for those devices. So I'll return to the original question, how does "centralized encryption" Allow CAPWAP WTPs to NOT BREAK the 802.11 protocol and provide: 1. 802.11e frame fragmentation (fragment to fit a TXOP) 2. 802.11n A-MSDU aggregation (even though we may opt to not include 802.11n support in the first version, going out of our way to not support the protocol seems like a bad idea) Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 12:56:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoNoU-0005nX-LP for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 12:56:54 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoNoT-0006Ei-5T for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 12:56:54 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 76BD04300EF for ; Thu, 8 Jun 2006 09:56:52 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D6FCE430076 for ; Thu, 8 Jun 2006 09:56:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B9F604306F7 for ; Thu, 8 Jun 2006 09:56:29 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id 86664430715 for ; Thu, 8 Jun 2006 09:56:25 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 08 Jun 2006 09:56:22 -0700 X-IronPort-AV: i="4.05,220,1146466800"; d="scan'208"; a="1822126395:sNHT34790520" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k58GuMpF008554; Thu, 8 Jun 2006 09:56:22 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k58GuGkk029869; Thu, 8 Jun 2006 09:56:22 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 09:56:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Jun 2006 09:56:18 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2020378A1@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New mux header for CAPWAP Thread-Index: AcaKiIX/iWgD7jBTSRWtSoZ6FZGtGQAgzwmQ From: "Pat Calhoun (pacalhou)" To: "Scott G. Kelly" , , X-OriginalArrivalTime: 08 Jun 2006 16:56:19.0461 (UTC) FILETIME=[76C51350:01C68B1C] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe > Since when are all CAPWAP packets encrypted? Last time I read > the draft, only the control PDUs required encryption. If > granular QoS is needed for the data channel, then either you > don't want to encrypt it, or you want the encryptor to do the marking. If packets are traversing a WAN, they may need to be - even if it's 802.11i... > There is no reason why vendors can't provide the > configuration knobs for this, so I must be missing something, > because it sounds like your concern is that the customer will > configure the AC/WTP to apply labels which are inconsistent > with his own QoS policies... ... In which case there's no way for the WTP to even know what's inside the packet, ergo it can't even do any packet classification. The best it can do is management vs. data. Many customers want/expect to be able to provide some classification of packets based on applications. However, if we want to allow the WTP to perform packet classification, we have more protocol work to do. > There are many ways to build networks, and some work better > than others. Obviously, splitting capwap across WAN links > that have congestion problems is going to be problematic, and > for the reasons you mentioned above (i.e. that the > encapsulated data will likely have QoS granularity > requirements of its own which cannot be addressed by using a > separate UDP port for all data), this sounds like an > architecture to be avoided. WAN links do get congested. These are not fiber links. There's frequently more data than bandwidth available... > I spent the morning talking with ISP folks and traffic > engineers. The first question that came up was, "do you > expect to have congestion problems on that WAN link?", and > when I responded "apparently", I was asked "why don't you > just add enough bandwidth to resolve this?". When I replied > that maybe it was because that would cost too much money, the > next question was, "if you are afraid that you'll be losing > timing-sensitive capwap packets, what's happening to the > application data in your data channel? Don't you need > granular QoS on that as well? If your classification is only > 5-tuple based, how will you classify those when they all use > the same port?" So your premise appears to be "If we can't do it perfectly, it is not worth doing at all". An interesting approach, but let's look at the side effect here. If the data frames are dropped, then it's the station's responsibility to retransmit - inconvenient, but not critical. However, if the CAPWAP control frames are dropped, then the whole CAPWAP session drops. That's an expensive price to pay for taking the easy way out. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 13:02:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoNtz-0006Z8-GF for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 13:02:35 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoNty-0007Kg-1z for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 13:02:35 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id AD6DF430097 for ; Thu, 8 Jun 2006 10:02:33 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 65E3043006C for ; Thu, 8 Jun 2006 10:02:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4F42B39806B for ; Thu, 8 Jun 2006 10:02:08 -0700 (PDT) X-Greylist-Status: Sender first seen 4 mons 14 days 01:14:22 ago Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6842B39804E for ; Thu, 8 Jun 2006 10:02:03 -0700 (PDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k58Gx1Hg013322 for ; Thu, 8 Jun 2006 12:59:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Jun 2006 11:02:01 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 67 Location Announcement Thread-Index: AcaLGxI8T7kesNI/TNuNgpxVJy6yywAAg7Gw From: "Mani, Mahalingam (Mani)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [Capwap] FW: IETF 67 Location Announcement X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Fyi- For those planning ahead for IETF67... -mani -----Original Message----- From: IETF Administrative Director [mailto:iad@ietf.org] Sent: Thursday, June 08, 2006 8:53 AM To: Working Group Chairs Subject: IETF 67 Location Announcement The IETF is pleased to announce its selection of San Diego, California, USA and the Sheraton San Diego Hotel & Marina as the site of IETF 67 being held November 5 - 10, 2006. As we celebrate IETF's 20th year we return to the city where IETF 01 (with 21 attendees) was held, as well as IETFs' 9, 23, 49, and 60. The Sheraton has added another 18,000 sq ft of meeting space for us to use. There are other conferences being held in San Diego so we encourage you to reserve your hotel rooms right away. We have arrangements on Harbor Island with: Sheraton San Diego Hotel & Marina for 770 rooms at different prices starting at $179 and 50 rooms at the Hilton San Diego Airport/Marina at $189, both properties with free Internet in the rooms. More information can be found at: http://www.ietf.org/meetings/hotels_67.html Registration for San Diego will open July 12th. We are looking forward to San Diego in November, but until then we will see you in Montreal in 31 days! And speaking of Montreal, Early Bird registration with its $550 registration fee expires at 1600 GMT on 30 June! If you have not registered yet, delay no longer! http://www.ietf.org/meetings/IETF-66.html Ray Pelletier IETF Administrative Director _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 13:21:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoOC4-0005ha-QL for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 13:21:16 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoOC3-0000TT-A7 for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 13:21:16 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A57434300EA for ; Thu, 8 Jun 2006 10:21:14 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id ADBD7430071 for ; Thu, 8 Jun 2006 10:20:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9550F430807 for ; Thu, 8 Jun 2006 10:20:52 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id D0CF1430815 for ; Thu, 8 Jun 2006 10:20:49 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 08 Jun 2006 10:20:49 -0700 X-IronPort-AV: i="4.05,220,1146466800"; d="scan'208"; a="1822145622:sNHT50240718" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k58HKnrb020601; Thu, 8 Jun 2006 10:20:49 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k58HKmcL010546; Thu, 8 Jun 2006 10:20:49 -0700 (PDT) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 10:20:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Jun 2006 10:20:48 -0700 Message-ID: <08A9A3213527A6428774900A80DBD8D8020B093F@xmb-sjc-222.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Encryption Capabilities Thread-Index: AcaKYz0CxWMN1oZnSzS6eQ4CZuKtJQAvDq2Q From: "Nancy Winget (ncamwing)" To: "Charles Clancy" , "Pat Calhoun (pacalhou)" X-OriginalArrivalTime: 08 Jun 2006 17:20:48.0568 (UTC) FILETIME=[E26D0380:01C68B1F] Authentication-Results: sj-dkim-5.cisco.com; header.From=ncamwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Hi Charles, I think we have to be very careful when assertions of .11i providing CAPWAP protection (unless I misunderstood you). Since CAPWAP allows both 802.3 and 802.11 to be tunneled with CAPWAP, I believe we are only confusing matters by implying that .11i could be sufficient....that statement requires a lot of qualification that I think will get missed by many. Nancy. -----Original Message----- From: Charles Clancy [mailto:clancy@cs.umd.edu] Sent: Wednesday, June 07, 2006 11:51 AM To: Pat Calhoun (pacalhou) Cc: Nancy Winget (ncamwing); capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities Pat Calhoun (pacalhou) wrote: >> Yes, DTLS provides a superset of security, but also triples the >> computational requirements. My point is that in many cases, the >> subset of security offered by 11i encryption is sufficient. > > At the expense of disallowing certain standard 802.11 functions from > being provided. > ... certainly, that's why like using DTLS, it would be optional. I'm not trying to say we need to keep it. I'm just trying to make sure everyone's aware of the feature it provides. If implementors think getting rid of it is fine, then go for it. Personally, I couldn't care less about computational complexity. Terminating 11i at the WTP and optionally using DTLS makes much more sense in the larger security paradigm. Then everything's clean and modular. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 13:31:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoOMK-0004s0-Ko for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 13:31:52 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoOMJ-0001LP-8I for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 13:31:52 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E1334430110 for ; Thu, 8 Jun 2006 10:31:50 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C26C8430076 for ; Thu, 8 Jun 2006 10:31:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B09FE430847 for ; Thu, 8 Jun 2006 10:31:31 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 263D743085B for ; Thu, 8 Jun 2006 10:31:28 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k58HVRVe012318 for ; Thu, 8 Jun 2006 10:31:27 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k58HVR77012314 for ; Thu, 8 Jun 2006 10:31:27 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 8 Jun 2006 10:31:27 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: Re: [Capwap] Proposal for CAPWAP packet format X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 HI, For the wireless payload, I just cut and pasted from the CAPWAP-01 document. I defer to others for the details. On Thu, 8 Jun 2006 Michael.G.Williams@nokia.com wrote: > David, > > In the 'wireless payload" can you elaborate how much of the wireless > standard's frame is included in that? I don't think there are any > wireless standards that specify how much of their frames are to be > carried by CAPWAP ;^) > BR, > Michael Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 14:38:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoPOx-0005dA-Rk for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 14:38:39 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoPOw-0000L1-Cl for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 14:38:39 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8324B430097 for ; Thu, 8 Jun 2006 11:38:37 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 326AA430076 for ; Thu, 8 Jun 2006 11:38:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1D04539806D for ; Thu, 8 Jun 2006 11:38:14 -0700 (PDT) Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4791B398020 for ; Thu, 8 Jun 2006 11:38:09 -0700 (PDT) Received: from [192.168.4.125] (really [24.75.172.194]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060608183806.MMQG12693.mta10.adelphia.net@[192.168.4.125]>; Thu, 8 Jun 2006 14:38:06 -0400 Message-ID: <44886EB0.5020808@cs.umd.edu> Date: Thu, 08 Jun 2006 14:38:40 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "Nancy Winget (ncamwing)" References: <08A9A3213527A6428774900A80DBD8D8020B093F@xmb-sjc-222.amer.cisco.com> In-Reply-To: <08A9A3213527A6428774900A80DBD8D8020B093F@xmb-sjc-222.amer.cisco.com> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.373 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Nancy, ... and in the future, hopefully CAPWAP will encapsulate other wireless standards as well. All of which may or may not encrypt their packets. Just to clarify my thoughts on this thread: 0. When I say "centralized encryption" I mean terminating the RSN security at the AC in the 802.11 CAPWAP binding. 1. Removing centralized encryption doesn't change the security of the CAPWAP protocol, as it has nothing to do with the CAPWAP headers. 2. Centralized encryption can be used in deployments where the backhaul threat model only requires data plane confidentiality, and in this case can save processing time on the WTP as per-packet DTLS does not have to be done. If implementors find this useful, then they may want to consider keeping it around. 3. In my personal, non-security-advisor, non-normative, humble opinion (IM-PNSANN-HO for short), I think terminating encryption at the WTP is the most aesthetic from a protocol standpoint. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Nancy Winget (ncamwing) wrote: > Hi Charles, > > I think we have to be very careful when assertions of .11i providing > CAPWAP protection (unless I misunderstood you). Since CAPWAP allows > both 802.3 and 802.11 to be tunneled with CAPWAP, I believe we are only > confusing matters by implying that .11i could be sufficient....that > statement requires a lot of qualification that I think will get missed > by many. > > Nancy. > > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Wednesday, June 07, 2006 11:51 AM > To: Pat Calhoun (pacalhou) > Cc: Nancy Winget (ncamwing); capwap@frascone.com > Subject: Re: [Capwap] Encryption Capabilities > > Pat Calhoun (pacalhou) wrote: >>> Yes, DTLS provides a superset of security, but also triples the >>> computational requirements. My point is that in many cases, the >>> subset of security offered by 11i encryption is sufficient. >> At the expense of disallowing certain standard 802.11 functions from >> being provided. >> > > ... certainly, that's why like using DTLS, it would be optional. > > I'm not trying to say we need to keep it. I'm just trying to make sure > everyone's aware of the feature it provides. If implementors think > getting rid of it is fine, then go for it. > > Personally, I couldn't care less about computational complexity. > Terminating 11i at the WTP and optionally using DTLS makes much more > sense in the larger security paradigm. Then everything's clean and > modular. > > -- > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 15:08:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoPrW-000316-Nt for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 15:08:10 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoPrU-0003P3-AA for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 15:08:10 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id ED8754300D0 for ; Thu, 8 Jun 2006 12:08:07 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id CE86F430076 for ; Thu, 8 Jun 2006 12:07:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B0AB2430A17 for ; Thu, 8 Jun 2006 12:07:47 -0700 (PDT) Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by hermes.tigertech.net (Postfix) with ESMTP id E5AE0430A16 for ; Thu, 8 Jun 2006 12:07:44 -0700 (PDT) Received: from [192.168.4.125] (really [24.75.172.194]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060608190743.OXXN21801.mta9.adelphia.net@[192.168.4.125]>; Thu, 8 Jun 2006 15:07:43 -0400 Message-ID: <448875A3.7020800@cs.umd.edu> Date: Thu, 08 Jun 2006 15:08:19 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Dorothy.Gellert@nokia.com References: <893AE265F4ADF94AB7FB26D31A788E4102295E7E@mvebe101.NOE.Nokia.com> In-Reply-To: <893AE265F4ADF94AB7FB26D31A788E4102295E7E@mvebe101.NOE.Nokia.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d For the record, personally I'm in favor of MUX headers. While I agree that QoS is an issue, I think NAT traversal is a bigger issue. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Dorothy.Gellert@nokia.com wrote: > > The CAPWAP editors have asked the Chairs to resolve the Mux vs Multiport > issue # 115, in order to progress the specification. Based on the > discussion that has taken place the chairs are in agreement the > simplest, cleanest solution for this is to add a Mux header. Barring > any unforseen events, we will instruct the editors resolve in favor of a > new Mux header. > > We intend to close this issue by the end of the week, Friday, 6/9. > Please review the issue and send any constructive comments to the list > by Friday. > > Best Regards, > Dorothy > > > > > > ------------------------------------------------------------------------ > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 15:17:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoQ0v-0006j6-QL for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 15:17:53 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoQ0v-0004PA-NX for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 15:17:53 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoQ0t-0005cU-OU for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 15:17:53 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 44B364300D9 for ; Thu, 8 Jun 2006 12:17:50 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 41979430076 for ; Thu, 8 Jun 2006 12:17:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 23AA5430A44 for ; Thu, 8 Jun 2006 12:17:19 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.202]) by hermes.tigertech.net (Postfix) with ESMTP id C32CD430A3B for ; Thu, 8 Jun 2006 12:17:16 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id t13so367071wxc for ; Thu, 08 Jun 2006 12:17:15 -0700 (PDT) Received: by 10.70.74.14 with SMTP id w14mr2468916wxa; Thu, 08 Jun 2006 12:17:15 -0700 (PDT) Received: by 10.70.133.2 with HTTP; Thu, 8 Jun 2006 12:17:15 -0700 (PDT) Message-ID: <5bfe7a820606081217p7aba47d5g507b6f2645af33b2@mail.gmail.com> Date: Thu, 8 Jun 2006 12:17:15 -0700 From: "Dorothy Stanley" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A202037883@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A202037883@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.0 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Cc: capwap@frascone.com Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0073879980==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -1.8 (-) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f --===============0073879980== Content-Type: multipart/alternative; boundary="----=_Part_28615_26881644.1149794235166" ------=_Part_28615_26881644.1149794235166 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Pat, Comments inline. Thanks, Dorothy On 6/8/06, Pat Calhoun (pacalhou) wrote: > > > The text refers to > > comparing the 802.11 crypto with DTLS crypto, noting that the > > DTLS crypto would not necessarily re-use the 802.11 hardware > > engine, and referencing Charles' comment: > > >>Yes, DTLS provides a superset of security, but also triples the > >>computational requirements. My point is that in many cases, the > subset > >>of security offered by 11i encryption is sufficient. > > True, but Charles also stated: > > Terminating 11i at the WTP and optionally using DTLS makes much more > > sense in the larger security paradigm. Then everything's clean and > > modular. I disagree with this additional statement. Terminating .11i at the WTP and then using DTLS is one option. Depending on one's goals and constraints, it may or may not be the right security paradigm of the the desired solution. See Scott's post on the two scenarios, which have their pros and cons, and should both remain in the spec. > I agree that 802.11 chipsets shipping today support hardware crypto- > > AES-CCMP, and RC4-TKIP/WEP to be specific. > > There are also "legacy" devices out there that just support > > WEP/TKIP in hardware/firmware - one example which would use > > existing CAPWAP support of 802.11i crypto at the AC to provide > > AES encryption, independent of the WTP-AC > > channel security discussion. > > I agree, but would claim that the devices you claim are *really* old - > and > I would even wonder whether they would be capable of supporting many > other > CAPWAP features, such as multiple SSIDs, 802.11e, etc. Further, AES > capable > APs appeared in the market as early as 2002 (maybe earlier, but this is > the > first reference I can find quickly) - that's four years ago. I think > those > customers have had a good return on their investment already. Not clear > we > need to optimize today's protocol for those devices. We are not optimizing for those devices. We are allowing, in an optional configuration for support of those kind of devices and applications, and not closing the door on flexibility in the protocol, and architecural flexibility. There is still a fair amount of legacy equipment out there for this example, WPA testing is still required for Wi-Fi certification for this reason. So I'll return to the original question, how does "centralized > encryption" > Allow CAPWAP WTPs to NOT BREAK the 802.11 protocol and provide: > 1. 802.11e frame fragmentation (fragment to fit a TXOP) > 2. 802.11n A-MSDU aggregation (even though we may opt to not include > 802.11n > support in the first version, going out of our way to not support the > protocol > seems like a bad idea) Providing centralized encryption has a wide range of pros and cons. Providing encryption at the WTP has a wide range of pros and cons. The feature needs of the application and specific vendor choices will dictate which one is used. Tthe CAPWAP protocol as currently written can support both cases and should continue to do so. Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > ------=_Part_28615_26881644.1149794235166 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Pat,

Comments inline.

Thanks,

Dorothy

On 6/8/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
> The text refers to
> comparing the 802.11 crypto with DTLS crypto, noting that the
> DTLS crypto would not necessarily re-use the 802.11 hardware
> engine, and referencing Charles' comment:

>>Yes, DTLS provides a superset of security, but also triples the
>>computational requirements.  My point is that in many cases, the
subset
>>of security offered by 11i encryption is sufficient.

True, but Charles also stated:
> Terminating 11i at the WTP and optionally using DTLS makes much more
> sense in the larger security paradigm. Then everything's clean and
> modular.

I disagree with this additional statement. Terminating .11i at the WTP
and then using DTLS is one option. Depending on one's goals and
constraints, it may or may not be the right security paradigm of the
the desired solution. See Scott's post on the two scenarios, which have their
pros and cons, and should both remain in the spec.

> I agree that 802.11 chipsets shipping today support hardware crypto-
> AES-CCMP, and RC4-TKIP/WEP to be specific.
> There are also "legacy" devices out there that just support
> WEP/TKIP in hardware/firmware -  one example which would use
> existing CAPWAP support of 802.11i crypto at the AC to provide
> AES encryption, independent of the WTP-AC
> channel security discussion.

I agree, but would claim that the devices you claim are *really* old -
and
I would even wonder whether they would be capable of supporting many
other
CAPWAP features, such as multiple SSIDs, 802.11e, etc. Further, AES
capable
APs appeared in the market as early as 2002 (maybe earlier, but this is
the
first reference I can find quickly) - that's four years ago. I think
those
customers have had a good return on their investment already. Not clear
we
need to optimize today's protocol for those devices.

We are not optimizing for those devices. We are allowing, in an optional
configuration for support of those kind of devices and applications, and not
closing the door on flexibility in the protocol, and architecural flexibility.
There is still a fair amount of legacy equipment out there for this example,
WPA testing is still required for Wi-Fi certification for this reason.


So I'll return to the original question, how does "centralized
encryption"
Allow CAPWAP WTPs to NOT BREAK the 802.11 protocol and provide:
1. 802.11e frame fragmentation (fragment to fit a TXOP)
2. 802.11n A-MSDU aggregation (even though we may opt to not include
802.11n
support in the first version, going out of our way to not support the
protocol
seems like a bad idea)

Providing centralized encryption has a wide range of pros and cons. Providing
encryption at the WTP has a wide range of pros and cons. The feature
needs of the application and specific vendor choices will dictate which one is used.
Tthe CAPWAP protocol as currently written can support both cases and should
continue to do so.


Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

------=_Part_28615_26881644.1149794235166-- --===============0073879980== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0073879980==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 17:33:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoS7y-000773-NM for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 17:33:18 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoS7x-0006fC-6H for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 17:33:18 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 696E34300EC for ; Thu, 8 Jun 2006 14:33:16 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 9E576430076 for ; Thu, 8 Jun 2006 14:32:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7BD0E39805B for ; Thu, 8 Jun 2006 14:32:53 -0700 (PDT) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9BAF839806E for ; Thu, 8 Jun 2006 14:32:48 -0700 (PDT) Received: from india-core-1.cisco.com ([64.104.129.221]) by ind-iport-1.cisco.com with ESMTP; 09 Jun 2006 03:24:09 -0700 X-IronPort-AV: i="4.05,221,1146466800"; d="scan'208"; a="68585796:sNHT44422624" Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k58LWeqZ014319; Thu, 8 Jun 2006 21:32:42 GMT Received: from xmb-blr-416.apac.cisco.com ([64.104.140.145]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 9 Jun 2006 03:02:41 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jun 2006 03:02:39 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New mux header for CAPWAP Thread-Index: AcaLLump+wYE+WP7QJGt0VXCpsfoGwADh/Xg From: "Rohit Suri (rsuri)" To: "Charles Clancy" , X-OriginalArrivalTime: 08 Jun 2006 21:32:41.0264 (UTC) FILETIME=[124B6B00:01C68B43] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc I have been reading through the conversations on this and I think there is a bigger issue that has not been considered. Not allowing separation of data and control plane by using easy to recognize method such as UDP ports would restrict system scaling. Consider for the moment the fact that because we are bundling the channels into a single crypto stream, it will become impossible to separate the control and data planes. I understand that this is not currently in the protocol, the reality is that creating such a restriction today will dictate future systems. The side effect I believe is being lost is that an AC can only be as fast as a single DTLS crypto accelerator. As faster 802.11 technologies come around, such as 802.11n, there will be a need for bigger and faster systems. In order to solve this, we will in the future have to remove the MUX and allow for the separation. I think system scaling is much bigger issue than NAT, which can be addressed by adding an keepalive mechanism in the data plane. We can also do this only when we detect a NAT is in play (look at outer IP address vs. a message element in the protocol). So we can have our cake and eat it too. Therefore, I personally feel very uncomfortable crippling future products to up front protocol development time. Regards Rohit -----Original Message----- From: Charles Clancy [mailto:clancy@cs.umd.edu] Sent: Thursday, June 08, 2006 12:08 PM To: Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: Re: [Capwap] New mux header for CAPWAP For the record, personally I'm in favor of MUX headers. While I agree that QoS is an issue, I think NAT traversal is a bigger issue. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Dorothy.Gellert@nokia.com wrote: > > The CAPWAP editors have asked the Chairs to resolve the Mux vs > Multiport issue # 115, in order to progress the specification. Based > on the discussion that has taken place the chairs are in agreement the > simplest, cleanest solution for this is to add a Mux header. Barring > any unforseen events, we will instruct the editors resolve in favor of > a new Mux header. > > We intend to close this issue by the end of the week, Friday, 6/9. > Please review the issue and send any constructive comments to the list > by Friday. > > Best Regards, > Dorothy > > > > > > ---------------------------------------------------------------------- > -- > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 17:43:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoSHS-00005x-EC for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 17:43:06 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoSHQ-0007ST-Tw for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 17:43:06 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8D9BF430115 for ; Thu, 8 Jun 2006 14:43:04 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 18BC5430071 for ; Thu, 8 Jun 2006 14:42:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 09FEA398015 for ; Thu, 8 Jun 2006 14:42:43 -0700 (PDT) Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by zoidberg.tigertech.net (Postfix) with ESMTP id E6FF739806D for ; Thu, 8 Jun 2006 14:42:39 -0700 (PDT) Received: from [192.168.4.125] (really [24.75.172.194]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060608214234.GSYA10985.mta13.adelphia.net@[192.168.4.125]>; Thu, 8 Jun 2006 17:42:34 -0400 Message-ID: <448899EE.8070308@cs.umd.edu> Date: Thu, 08 Jun 2006 17:43:10 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "Rohit Suri (rsuri)" References: In-Reply-To: X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.373 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS X-Spam-Level: Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Quick comment: There is not a 1-to-1 correlation between UDP port and DTLS session. We would still have two different crypto streams when using the MUX header. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Rohit Suri (rsuri) wrote: > > I have been reading through the conversations on this and I think there > is a bigger issue that has not been considered. Not allowing separation > of data and control plane by using easy to recognize method such as UDP > ports would restrict system scaling. Consider for the moment the fact > that because we are bundling the channels into a single crypto stream, > it will become impossible to separate the control and data planes. > > I understand that this is not currently in the protocol, the reality is > that creating such a restriction today will dictate future systems. The > side effect I believe is being lost is that an AC can only be as fast as > a single DTLS crypto accelerator. As faster 802.11 technologies come > around, such as 802.11n, there will be a need for bigger and faster > systems. In order to solve this, we will in the future have to remove > the MUX and allow for the separation. > > I think system scaling is much bigger issue than NAT, which can be > addressed by adding an keepalive mechanism in the data plane. We can > also do this only when we detect a NAT is in play (look at outer IP > address vs. a message element in the protocol). So we can have our cake > and eat it too. > > Therefore, I personally feel very uncomfortable crippling future > products to up front protocol development time. > > Regards > Rohit > > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Thursday, June 08, 2006 12:08 PM > To: Dorothy.Gellert@nokia.com > Cc: capwap@frascone.com > Subject: Re: [Capwap] New mux header for CAPWAP > > For the record, personally I'm in favor of MUX headers. While I agree > that QoS is an issue, I think NAT traversal is a bigger issue. > > -- > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > > Dorothy.Gellert@nokia.com wrote: >> The CAPWAP editors have asked the Chairs to resolve the Mux vs >> Multiport issue # 115, in order to progress the specification. Based >> on the discussion that has taken place the chairs are in agreement the > >> simplest, cleanest solution for this is to add a Mux header. Barring >> any unforseen events, we will instruct the editors resolve in favor of > >> a new Mux header. >> >> We intend to close this issue by the end of the week, Friday, 6/9. >> Please review the issue and send any constructive comments to the list > >> by Friday. >> >> Best Regards, >> Dorothy >> >> >> >> >> >> ---------------------------------------------------------------------- >> -- >> >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 18:08:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoSgV-0007Dr-1f for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 18:08:59 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoSgT-0001SW-K9 for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 18:08:59 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 00C0343010D for ; Thu, 8 Jun 2006 15:08:56 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 92352430071 for ; Thu, 8 Jun 2006 15:08:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7EF9539805B for ; Thu, 8 Jun 2006 15:08:36 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id EFCCC39800B for ; Thu, 8 Jun 2006 15:08:32 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k58M8WrD028635; Thu, 8 Jun 2006 15:08:32 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k58M8Wjd028632; Thu, 8 Jun 2006 15:08:32 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 8 Jun 2006 15:08:32 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Rohit Suri (rsuri)" In-Reply-To: Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 HI, Did you see and understand the following from my message from "Thu, 8 Jun 2006 01:47:21 -0700 (PDT)" with subject "[Capwap] Proposal for CAPWAP packet format": NOTE: A CAPWAP MUX header is needed whether or not the same or different UDP ports are used for CAPWAP control and data messages. This is because both CAPWAP data and control messages can be unprotected or protected by DTLS, and the MUX header is needed to distinguish protected from unprotected. Remember that CAPWAP "discovery requests" and "discovery responses" are unprotected, and that all other CAPWAP control message types are protected. It does not look like it was factored into your argument. On Fri, 9 Jun 2006, Rohit Suri (rsuri) wrote: > I have been reading through the conversations on this and I think there > is a bigger issue that has not been considered. Not allowing separation > of data and control plane by using easy to recognize method such as UDP > ports would restrict system scaling. Consider for the moment the fact > that because we are bundling the channels into a single crypto stream, > it will become impossible to separate the control and data planes. > > I understand that this is not currently in the protocol, the reality is > that creating such a restriction today will dictate future systems. The > side effect I believe is being lost is that an AC can only be as fast as > a single DTLS crypto accelerator. As faster 802.11 technologies come > around, such as 802.11n, there will be a need for bigger and faster > systems. In order to solve this, we will in the future have to remove > the MUX and allow for the separation. > > I think system scaling is much bigger issue than NAT, which can be > addressed by adding an keepalive mechanism in the data plane. We can > also do this only when we detect a NAT is in play (look at outer IP > address vs. a message element in the protocol). So we can have our cake > and eat it too. > > Therefore, I personally feel very uncomfortable crippling future > products to up front protocol development time. > > Regards > Rohit Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 18:19:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoSqe-0002Y3-Hr for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 18:19:28 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoSqd-0002Ox-4B for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 18:19:28 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C4CCF4300F2 for ; Thu, 8 Jun 2006 15:19:26 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4D99B430076 for ; Thu, 8 Jun 2006 15:19:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 423E6398061 for ; Thu, 8 Jun 2006 15:19:04 -0700 (PDT) Received: from exprod8og51.obsmtp.com (exprod8og51.obsmtp.com [64.18.3.84]) by zoidberg.tigertech.net (Postfix) with SMTP id 6F88539803E for ; Thu, 8 Jun 2006 15:19:00 -0700 (PDT) Received: from source ([151.145.63.124]) by exprod8ob51.obsmtp.com ([64.18.7.12]) with SMTP; Thu, 08 Jun 2006 15:19:00 PDT X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Jun 2006 17:18:59 -0500 Message-ID: <89525CB1203D7346BBBDFCE9CECB47CF02B539A6@exchange-USR31> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: QoS for Control Messages Clarity Thread-Index: AcaLSTX/IPPAPpaGQ7qKKB7dOf7BAwAAE3OA From: "Kraus, Michael" To: X-OriginalArrivalTime: 08 Jun 2006 22:18:59.0802 (UTC) FILETIME=[8A6EABA0:01C68B49] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=-0.001 tagged_above=-999 required=7 tests=SPF_HELO_PASS X-Spam-Level: Subject: [Capwap] QoS for Control Messages Clarity X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 There does appear to be a slight discrepancy between 4.3.2 and 11.6. 11.6 specifies a different IP Prec/DSCP value for probe requests, where 4.3.2 does not. 4.3.2. Control Message Quality of Service It is recommended that CAPWAP control messages be sent by both the AC and the WTP with an appropriate Quality of Service precedence value, ensuring that congestion in the network minimizes occurrences of CAPWAP control channel disconnects. Therefore, a Quality of Service enabled CAPWAP device should use the following values: 802.1P: The precedence value of 7 SHOULD be used. DSCP: The DSCP tag value of 46 SHOULD be used. 11.6. Quality of Service for Control Messages It is recommended that IEEE 802.11 MAC management frames be sent by both the AC and the WTP with appropriate Quality of Service values, ensuring that congestion in the network minimizes occurrences of packet loss. Therefore, a Quality of Service enabled CAPWAP device should use: 802.1P: The precedence value of 6 SHOULD be used for all IEEE 802.11 MAC management frames, except for Probe Requests which SHOULD use 4. DSCP: The DSCP tag value of 46 SHOULD be used for all IEEE 802.11 MAC management frames, except for Probe Requests which SHOULD use 34. Mike Kraus Sr. Network Engineer Applied Information Systems Cellular Phone (314) 575-0968 Nextel direct connect: 140*1*31368 Providing solutions for ABI, Brewing Operations & Technology, Engineering The information transmitted (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is intended only for the person(s) or entity/entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 18:33:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoT4Y-0003nY-7U for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 18:33:50 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoT4W-0004xR-Kd for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 18:33:50 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id ED230430106 for ; Thu, 8 Jun 2006 15:33:47 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 8F9CB430076 for ; Thu, 8 Jun 2006 15:33:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7F83039800B for ; Thu, 8 Jun 2006 15:33:26 -0700 (PDT) Received: from smtpauth08.mail.atl.earthlink.net (smtpauth08.mail.atl.earthlink.net [209.86.89.68]) by zoidberg.tigertech.net (Postfix) with ESMTP id 557F439803E for ; Thu, 8 Jun 2006 15:33:22 -0700 (PDT) Received: from [209.86.224.34] (helo=elwamui-hound.atl.sa.earthlink.net) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1FoT44-0005YJ-Iz; Thu, 08 Jun 2006 18:33:20 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Thu, 8 Jun 2006 18:33:20 -0400 Message-ID: <11478424.1149806000512.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> Date: Thu, 8 Jun 2006 15:33:20 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "Rohit Suri (rsuri)" , Charles Clancy , Dorothy.Gellert@nokia.com Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff7100d250f0ffecd36d213f0deed21c9d2d1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.34 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Hi Rohit! >I have been reading through the conversations on this and I think there >is a bigger issue that has not been considered. Not allowing separation >of data and control plane by using easy to recognize method such as UDP >ports would restrict system scaling. Consider for the moment the fact >that because we are bundling the channels into a single crypto stream, >it will become impossible to separate the control and data planes. I think you may have misunderstood: the data and control channels will not be bundled into a single crypto stream (not ever, in my view). Even if someone implements data channel encryption, it will almost certainly have to be independent of control channel encryption in all cases. My gut feeling is that there would be serious operational issues otherwise in terms of anti-replay and other channel interactions. I suppose it's possible that there is *some* scenario where you could combine the two - but I don't currentlly believe this could be done in general for capwap. > I understand that this is not currently in the protocol, the reality is >that creating such a restriction today will dictate future systems. The >side effect I believe is being lost is that an AC can only be as fast as >a single DTLS crypto accelerator. As faster 802.11 technologies come >around, such as 802.11n, there will be a need for bigger and faster >systems. In order to solve this, we will in the future have to remove >the MUX and allow for the separation. Like I said, the channels won't be bundled together. Also, this and previous posts make me think there's a fundamental misunderstanding about DTLS. This is really important to understand: DTLS does not care what sort of transport is underneath. It is oblivious to whether it runs over UDP, GRE, TCP, SMTP (yes, you could even send dtls records in emails), or CAPWAP... whatever. It is completely transport-agnostic. That means you could multiplex virtually any number of DTLS sessions over the same transport session (e.g. using the same UDP port), and then demultiplex them at the receiving side. This is true whether your transport is UDP or even ethernet, for that matter. Any DTLS crypto accelerator will have to be able to handle mutliple simultaneous DTLS sessions (just like SSL/TLS accelerators). Some will be capable of doing their own session lookup based on the record header, but even for the cheapest ones (which ostensibly would not be used in high end systems), it is a simple matter for the receiving AC to distribute independent dtls streams to parallel crypto accelerators, and contrary to what we've heard on this list, software, fpga's, and network processors are all well-suited to and commonly used for such tasks. Also, FPGAs and network processors which can be used for this purpose are commonly included in ACs available on the market today. >I think system scaling is much bigger issue than NAT, which can be >addressed by adding an keepalive mechanism in the data plane. We can >also do this only when we detect a NAT is in play (look at outer IP >address vs. a message element in the protocol). So we can have our cake >and eat it too. > >Therefore, I personally feel very uncomfortable crippling future >products to up front protocol development time. I don't know. I get the impression that what we are actually being asked is to cripple the protocol in order to match up with past products (i.e. those legacy switching products that can only classify based on ports). I must admit, I'm kind of surprised by such arguments, given the rich classification capabilities described by NBAR. Anyway, I don't think there really are scaling issues, unless we are constrained to combining AC functionality with legacy switching gear. Otherwise, there is nothing to prevent us from building systems which meet our needs as throughput climbs. And as someone else pointed out in a related discussion, "the purpose of capwap is not to make cheaper" - I substituted ACs for APs, but I don't think anything is lost in translation. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 18:36:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoT79-0005TY-Cu for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 18:36:31 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoT77-0005b9-Of for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 18:36:31 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 69812430111 for ; Thu, 8 Jun 2006 15:36:29 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B9313430076 for ; Thu, 8 Jun 2006 15:36:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A46001448013 for ; Thu, 8 Jun 2006 15:36:00 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by hermes.tigertech.net (Postfix) with ESMTP id D2D7D1448004 for ; Thu, 8 Jun 2006 15:35:56 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 08 Jun 2006 15:35:57 -0700 X-IronPort-AV: i="4.05,221,1146466800"; d="scan'208,217"; a="430316722:sNHT60567962" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k58MZuW0013565; Thu, 8 Jun 2006 15:35:56 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k58MZuCY010709; Thu, 8 Jun 2006 15:35:56 -0700 (PDT) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 15:35:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Jun 2006 15:35:50 -0700 Message-ID: <08A9A3213527A6428774900A80DBD8D8020B0AEE@xmb-sjc-222.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New mux header for CAPWAP Thread-Index: AcaJ0/iIUlcV3UUgRz+e4ctlG4c80gBTFGmQ From: "Nancy Winget (ncamwing)" To: , X-OriginalArrivalTime: 08 Jun 2006 22:35:51.0852 (UTC) FILETIME=[E5A93EC0:01C68B4B] Authentication-Results: sj-dkim-3.cisco.com; header.From=ncamwing@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_40_50, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1284010227==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 This is a multi-part message in MIME format. --===============1284010227== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68B4B.E573AA0B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68B4B.E573AA0B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dorothy, =20 As stated already by others, this decision will present serious issues, QoS as a for instance in using a MUX versus UDP. I will also restate that there will be security implications as we use the MUX and how that interacts with the DTLS encapsulation. If we believe the MUX is used to differentiate between data and control plane, then we need to make sure that it doesn't impede or lend any new vulnerabilities on how we apply DTLS. Having a single secure tunnel for both data and control plane will at minimum restrict the CAPWAP architecture and present potential packet ordering issues between the two to make the security work.=20 =20 There is greater merit in keeping the separation via the use of distinct UDP ports. Nancy. ________________________________ From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com]=20 Sent: Tuesday, June 06, 2006 6:45 PM To: capwap@frascone.com Subject: [Capwap] New mux header for CAPWAP The CAPWAP editors have asked the Chairs to resolve the Mux vs Multiport issue # 115, in order to progress the specification. Based on the discussion that has taken place the chairs are in agreement the simplest, cleanest solution for this is to add a Mux header. Barring any unforseen events, we will instruct the editors resolve in favor of a new Mux header. We intend to close this issue by the end of the week, Friday, 6/9. Please review the issue and send any constructive comments to the list by Friday.=20 Best Regards,=20 Dorothy=20 ------_=_NextPart_001_01C68B4B.E573AA0B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New mux header for CAPWAP
Hi Dorothy,
 
As stated already by others, this decision will = present=20 serious issues, QoS as a for instance in using a MUX versus UDP.  I = will=20 also restate that there will be security implications as we use the MUX = and how=20 that interacts with the DTLS encapsulation.  If we believe the MUX = is used=20 to differentiate between data and control plane, then we need to make = sure that=20 it doesn't impede or lend any new vulnerabilities on how we apply = DTLS. =20 Having a single secure tunnel for both data and control plane will at = minimum=20 restrict the CAPWAP architecture and present potential packet ordering = issues=20 between the two to make the security work. 
 
There is greater merit in keeping the = separation via the=20 use of distinct UDP ports.

    = Nancy.

From: Dorothy.Gellert@nokia.com=20 [mailto:Dorothy.Gellert@nokia.com]
Sent: Tuesday, June 06, = 2006 6:45=20 PM
To: capwap@frascone.com
Subject: [Capwap] New mux = header=20 for CAPWAP


The CAPWAP editors have asked the Chairs = to resolve=20 the Mux vs Multiport issue # 115, in order to progress the = specification. =20 Based on the discussion that has taken place the chairs are in agreement = the=20 simplest, cleanest solution for this is to add a Mux header.  = Barring any=20 unforseen events, we will instruct the editors resolve in favor of a new = Mux=20 header.

We intend to close this issue by the end = of the week,=20 Friday, 6/9.  Please review the issue and send any constructive = comments to=20 the list by Friday.

Best Regards,
Dorothy




------_=_NextPart_001_01C68B4B.E573AA0B-- --===============1284010227== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1284010227==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 18:38:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoT9L-0006Zq-2v for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 18:38:47 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoT9J-0005eL-FO for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 18:38:47 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 210BF430122 for ; Thu, 8 Jun 2006 15:38:45 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A99AC43008C for ; Thu, 8 Jun 2006 15:38:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9E1A539800B for ; Thu, 8 Jun 2006 15:38:19 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by zoidberg.tigertech.net (Postfix) with ESMTP id 43B3139802F for ; Thu, 8 Jun 2006 15:38:15 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 08 Jun 2006 15:38:15 -0700 X-IronPort-AV: i="4.05,221,1146466800"; d="scan'208"; a="430317230:sNHT48247684" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k58McFjB028601; Thu, 8 Jun 2006 15:38:15 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k58McFCU013892; Thu, 8 Jun 2006 15:38:15 -0700 (PDT) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 15:38:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Jun 2006 15:38:13 -0700 Message-ID: <08A9A3213527A6428774900A80DBD8D8020B0AF4@xmb-sjc-222.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Encryption Capabilities Thread-Index: AcaKl+3pdBE3N9zERhWnU+ICmwmPngAiCm3g From: "Nancy Winget (ncamwing)" To: "Scott G. Kelly" , "capwap" X-OriginalArrivalTime: 08 Jun 2006 22:38:14.0913 (UTC) FILETIME=[3AEE9F10:01C68B4C] Authentication-Results: sj-dkim-1.cisco.com; header.From=ncamwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c While it is true that the originating 802.11 data payload will be obscured, it is not clear to me that we can construe it as "good". Since there is no protection of the CAPWAP encapsulation, it is still susceptible to attack, as is the entire CAPWAP encapsulation (should we choose not to protect it). Thus, in my view, it does not help a whole lot. Sure, if we believe the system is uncompromised then you are correct that the data is not readily discernible but can we trust that the data has not been compromised anyway? No, not until it has gone up to the AC and by that point, it is not clear whether the attack occurred at the link between STA and WTP or WTP to AC. Nancy. -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: Wednesday, June 07, 2006 6:07 PM To: capwap Subject: Re: [Capwap] Encryption Capabilities I've been watching this debate with some interest, being quite surprised that an optional feature would suddenly draw such attention and energy. Still, I guess I should comment along with everyone else. First, I agree with Charles on the point that having or not having this feature has no impact on the security properties of the capwap protocol itself. Also, I agree with a number of folks on the point that these two features are orthogonal. AC termination of 802.11 link security does not (indeed, is not intended to) provide for capwap data channel security. However, this feature is not security-neutral - it provides a unique set of security properties that are useful. Before explaining further, here are some pictures, along with some descriptive text (hoping my webmail interface doesn't mangle them): KEY --- # - 802.11 link security boundary % - capwap security boundary Case 1: 802.11 link security terminates at the WTP ##################### # # %%%%%%%%%%%%%%%%%%%%%%% # +------+ +#--%-+ CAPWAP +----+ % # |client|---------| WTP |===========| AC | % # +------+ +#--%-+ +----+ % # # %%%%%%%%%%%%%%%%%%%%%%% ##################### This is the situation when you en/decrypt 802.11 traffic at the WTP. In this case, the client and WTP are within the 802.11 link security boundary. Of course, this picture does not include key establishment, because during that phase, the security boundary is more like the one below, and also, the AAA server (not pictured) is involved. Also, one might choose to include the AC in the 802.11 link security boundary pictured above (even though it doesn't participate in the crypto ops) because it is privy to the 802.11 keying material, but I'm leaving this out because it simplifies the ascii drawing, and will add nothing material to the discussion below. Case 2: 802.11 link security terminates at the AC %%%%%%%%%%%%%%%%% % +-----+ % /-----------------%--| WTP | % | % +--++-+ % | % ||capwap % | % || % | % +---++--+ % | % | | % | %%%%%%%%%%%%%%%%% ##############|############################### # +------+ | | AC | # # |client|----/ 802.11 | | # # +------+ +-------+ # ############################################## Here is the case when you en/decrypt 802.11 at the AC. Note that the WTP is not within the 802.11 link security boundary. It is "out of the loop", so to speak, being little more than a transport provider. Also note that the capwap security boundary is the same as for case 1 - no change. Now, let's get to the questions about whether this is useful or not, and let's keep in mind that since this is an *optional* feature, the "burden of proof" with respect to utility is much lower than it would be if it were mandatory to implement. As noted above, in case 2, the WTP is simply a transport provider. That means that if the WTP were somehow compromised, unless the attacker also compromised one or more of the other security mechanisms as well (802.1x, the AC's credential, etc), he could do little more than effect a DoS attack. In case 1, various methods of WTP compromise could give an attacker access to the data as it is unencrypted and then re-encrypted. In this case, the attacker gets access to the cleartext data via relatively low-cost methods (compared to breaking .11 crypto), essentially attacking the weakest link. In case 2, WTP's can be deployed in hostile territory, and if the attacker can't break the 802.11 crypto, he can't have the same security impact (aside from DoS, which he can have in any event). It's like running 802.11 security over the air - he has to break the crypto. No matter how completely the attacker might compromise a WTP, all he will see is encrypted data. This is good! Of course, there is additional value to the centralized encryption model, as Dorothy Stanley pointed out: architectural flexibility, enabling CAPWAP compliant solutions to centralize the 802.11i crypto functions in the AC if they wish, reducing dependencies on WTP capabilities (e.g. legacy hardware that only supports TKIP), potentially support a broader range of existing and future applications - even when the primary motivation is not 'to secure the WTP-AC data connection'". Some vendors chose this approach to MAC splitting while others chose encryption at the WTP. That's one reason why it should remain optional. --Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 18:47:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoTHL-0004rO-La for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 18:47:03 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoTHK-00074F-7t for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 18:47:03 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7FF564300F9 for ; Thu, 8 Jun 2006 15:47:01 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 510FB430097 for ; Thu, 8 Jun 2006 15:46:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 30DEB144801C for ; Thu, 8 Jun 2006 15:46:41 -0700 (PDT) Received: from smtpauth08.mail.atl.earthlink.net (smtpauth08.mail.atl.earthlink.net [209.86.89.68]) by hermes.tigertech.net (Postfix) with ESMTP id 4A6D81448009 for ; Thu, 8 Jun 2006 15:46:38 -0700 (PDT) Received: from [209.86.224.34] (helo=elwamui-hound.atl.sa.earthlink.net) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1FoTGu-0004uQ-UD; Thu, 08 Jun 2006 18:46:36 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Thu, 8 Jun 2006 18:46:36 -0400 Message-ID: <27218472.1149806796942.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> Date: Thu, 8 Jun 2006 15:46:36 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "Nancy Winget (ncamwing)" , Dorothy.Gellert@nokia.com, capwap@frascone.com Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710d11cbeac5e96ddee0bb338a2a15bca66350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.34 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hi Nancy, -----Original Message----- >From: "Nancy Winget (ncamwing)" >Sent: Jun 8, 2006 3:35 PM >To: Dorothy.Gellert@nokia.com, capwap@frascone.com >Subject: Re: [Capwap] New mux header for CAPWAP > >Hi Dorothy, > >As stated already by others, this decision will present serious issues, >QoS as a for instance in using a MUX versus UDP. I will also restate >that there will be security implications as we use the MUX and how that >interacts with the DTLS encapsulation. If we believe the MUX is used to >differentiate between data and control plane, then we need to make sure >that it doesn't impede or lend any new vulnerabilities on how we apply >DTLS. Having a single secure tunnel for both data and control plane >will at minimum restrict the CAPWAP architecture and present potential >packet ordering issues between the two to make the security work. > >There is greater merit in keeping the separation via the use of distinct >UDP ports. > Nancy. This is sheer and utter nonsense. DTLS is entirely oblivious to the transport encapuslation. There are no security implications to consider based on the choice of UDP vs any other transport. You guys keep talking about a single tunnel for data and control, but you are the only ones talking about this - it is not in the draft, and it has never been proposed. Bundling capwap control and data together is not and *cannot be* the plan. Let it go. I hope this doesn't sound rude, because I don't mean it that way - but I do mean to forcefully convey that we are wasting our time and energy debating a non-existent issue. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 19:19:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoTn1-000771-50 for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 19:19:47 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoTmz-0002Oy-KR for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 19:19:47 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C796B43013C for ; Thu, 8 Jun 2006 16:19:44 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 69BF643008C for ; Thu, 8 Jun 2006 16:19:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4BB75398041 for ; Thu, 8 Jun 2006 16:19:23 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8076A39800B for ; Thu, 8 Jun 2006 16:19:20 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 08 Jun 2006 16:19:20 -0700 X-IronPort-AV: i="4.05,221,1146466800"; d="scan'208"; a="291842386:sNHT40947820" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k58NJKug007187; Thu, 8 Jun 2006 16:19:20 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k58NJJCU019941; Thu, 8 Jun 2006 16:19:19 -0700 (PDT) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 16:19:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Jun 2006 16:19:18 -0700 Message-ID: <08A9A3213527A6428774900A80DBD8D8020B0B3C@xmb-sjc-222.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New mux header for CAPWAP Thread-Index: AcaLTWcVS5lA+32MQYat7OySOpn2vgAA5tlQ From: "Nancy Winget (ncamwing)" To: "Scott G. Kelly" , , X-OriginalArrivalTime: 08 Jun 2006 23:19:19.0819 (UTC) FILETIME=[F8216DB0:01C68B51] Authentication-Results: sj-dkim-4.cisco.com; header.From=ncamwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c I disagree....if it is independent of transport encapsulation then why for example is it DTLS vs. TLS? We chose DTLS because it uses the UDP model....we are now tweaking this by introducing the concept of a MUX. Having lived through the WEP debacle, I am merely stating that there may be repercusions that need further analysis. I do not believe this is a non-existant issue, nor is it nonsense to those trying to analyze the security behind CAPWAP. It is something I'm highlighting as complicating the analysis....maybe not for you, but it will to those analyzing the security of this. Nancy. -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: Thursday, June 08, 2006 3:47 PM To: Nancy Winget (ncamwing); Dorothy.Gellert@nokia.com; capwap@frascone.com Subject: Re: [Capwap] New mux header for CAPWAP Hi Nancy, -----Original Message----- >From: "Nancy Winget (ncamwing)" >Sent: Jun 8, 2006 3:35 PM >To: Dorothy.Gellert@nokia.com, capwap@frascone.com >Subject: Re: [Capwap] New mux header for CAPWAP > >Hi Dorothy, > >As stated already by others, this decision will present serious issues, >QoS as a for instance in using a MUX versus UDP. I will also restate >that there will be security implications as we use the MUX and how that >interacts with the DTLS encapsulation. If we believe the MUX is used >to differentiate between data and control plane, then we need to make >sure that it doesn't impede or lend any new vulnerabilities on how we >apply DTLS. Having a single secure tunnel for both data and control >plane will at minimum restrict the CAPWAP architecture and present >potential packet ordering issues between the two to make the security work. > >There is greater merit in keeping the separation via the use of >distinct UDP ports. > Nancy. This is sheer and utter nonsense. DTLS is entirely oblivious to the transport encapuslation. There are no security implications to consider based on the choice of UDP vs any other transport. You guys keep talking about a single tunnel for data and control, but you are the only ones talking about this - it is not in the draft, and it has never been proposed. Bundling capwap control and data together is not and *cannot be* the plan. Let it go. I hope this doesn't sound rude, because I don't mean it that way - but I do mean to forcefully convey that we are wasting our time and energy debating a non-existent issue. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 19:25:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoTsK-0005Qy-8Z for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 19:25:16 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoTsI-0002YT-NI for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 19:25:16 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5EF52430138 for ; Thu, 8 Jun 2006 16:25:14 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A1FE943008C for ; Thu, 8 Jun 2006 16:24:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 838E839800B for ; Thu, 8 Jun 2006 16:24:48 -0700 (PDT) Received: from exprod8og54.obsmtp.com (exprod8og54.obsmtp.com [64.18.3.90]) by zoidberg.tigertech.net (Postfix) with SMTP id C65BA398009 for ; Thu, 8 Jun 2006 16:24:42 -0700 (PDT) Received: from source ([151.145.63.123]) by exprod8ob54.obsmtp.com ([64.18.7.12]) with SMTP; Thu, 08 Jun 2006 16:24:42 PDT X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Jun 2006 18:24:41 -0500 Message-ID: <89525CB1203D7346BBBDFCE9CECB47CF02B539CB@exchange-USR31> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Capwap] New mux header for CAPWAP Thread-Index: AcaLUreE17bhveF4TJ2aETCPYLCiIQ== From: "Kraus, Michael" To: X-OriginalArrivalTime: 08 Jun 2006 23:24:41.0976 (UTC) FILETIME=[B826AF80:01C68B52] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=-0.001 tagged_above=-999 required=7 tests=SPF_HELO_PASS X-Spam-Level: Cc: s.kelly@ix.netcom.com, Dorothy.Gellert@nokia.com Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Greetings! Before saying that going to a mux header is the simplest/cleanest, I would suggest reviewing the original objectives of this WG. From 5.1.2 of the objectives: > Protocol Requirement: > > The CAPWAP Protocol MUST define transport control messages such that > the transport of control messages is separate from the transport of > data messages. How is transport defined? To me, a mux header merely identifies control vs. data but does not provide a separate transport mechanism (more on this below). > Motivation and Protocol Benefits: > > The aim of separating data and control aspects of the protocol is to > simplify the protocol. This is where a MUX header makes sense, since it mitigates the NAT traversal concern (rather than adding a keep alive type of functionality, which would somewhat increase overhead/complexity). > It also allows for the flexibility of addressing each type of traffic in the most appropriate manner. With a MUX header, the network devices will not be able to remark DSCP values of data traffic, perform traffic engineering (policy-based routing), or apply different security requirements. For security/DoS/network optimization, it does not always make sense for control and data traffic for applications to take the same network path, have the same access, and receive the same priority. By requiring the same port, and a mux header the control and data traffic must take the same network path. If manufacturers provide classification within the WTP, this would help alleviate the QoS concerns, but network traffic engineering/security is still a concern. Deep packet inspection techniques (NBAR) are slow in coming across vendors, slow in market adoption, and complex/costly to implement. Proliferation of this technology/protocol is dependent upon the cost effectiveness of the solution. Upgrading access points to a CAPWAP solution provides some potential cost savings, through centralized policy and management. But, if you say to do it "right" you need to also upgrade your entire network infrastructure to support deep packet inspection techniques, this quickly becomes too costly of a solution to implement. Current project I'm working on, it costs roughly $3M to do all wireless access points. But, to upgrade all network infrastructure to support NBAR, I'd is estimate is at $40M. Some corners of the network here still have 10Base2 hubs! The reason 802.11 has been success is because it has been inexpensive, creating a dependency of the wireless network on the wired network would hamper further proliferation. > Furthermore, this requirement will help remotely located WTPs to > handle data traffic in alternative ways without the need for > forwarding them across a wide network to the WLAN controller. WLAN Controller should be renamed to AC here. > Separation of WTP control and data also aids in the secure > realization of shared WLAN deployments. Security should not be limited to whether the control data is being encrypted, while the data may or may not be. It is more far reaching. Perhaps you want to have an network segment act as a transit area for control data, but not for data traffic. Logical network segmentation of traffic for security (DoS) prevention is something that is present in certain environments (especially manufacturing and high security). > Relation to Problem Statement: > > Broadly, this objective relates to the challenge of managing > complexity in large-scale WLANs. The requirement for traffic > separation simplifies control as this is separated from the task of > data transport. The way I interpret this, by using a MUX header, a truly separate transport of control and data messages cannot be fully realized. I can see how it simplifies the protocol (NAT Traversal), so this does provide merit as a viable option. However, if this is the path that is chosen, we lose some flexibility (traffic engineering). In conclusion, should a MUX header be chosen, I would suggest that the objectives need to also be reviewed/updated to reflect that the spirit of this protocol requirement has changed. In particular, stating that a true separate transport for data and control messages are not going to be achieved by this WG, but rather an internal identification of data and control messages so that AC and WTPs can treat data and control messages differently. Mike Dorothy.Gellert@nokia.com wrote: > > The CAPWAP editors have asked the Chairs to resolve the Mux vs > Multiport issue # 115, in order to progress the specification. Based > on the discussion that has taken place the chairs are in agreement the > simplest, cleanest solution for this is to add a Mux header. Barring > any unforseen events, we will instruct the editors resolve in favor of > a new Mux header. > > We intend to close this issue by the end of the week, Friday, 6/9. > Please review the issue and send any constructive comments to the list > by Friday. > > Best Regards, > Dorothy Mike Kraus Sr. Network Engineer Applied Information Systems Cellular Phone (314) 575-0968 Nextel direct connect: 140*1*31368 Providing solutions for ABI, Brewing Operations & Technology, Engineering The information transmitted (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is intended only for the person(s) or entity/entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 19:42:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoU9T-0001HY-Ce for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 19:42:59 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoU9Q-0006OI-Tg for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 19:42:59 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 87F4F43015E for ; Thu, 8 Jun 2006 16:42:56 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id CA07943008C for ; Thu, 8 Jun 2006 16:42:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id BE535398009 for ; Thu, 8 Jun 2006 16:42:36 -0700 (PDT) Received: from smtpauth08.mail.atl.earthlink.net (smtpauth08.mail.atl.earthlink.net [209.86.89.68]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1218939802F for ; Thu, 8 Jun 2006 16:42:31 -0700 (PDT) Received: from [209.86.224.34] (helo=elwamui-hound.atl.sa.earthlink.net) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1FoU90-0007N8-GO; Thu, 08 Jun 2006 19:42:30 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Thu, 8 Jun 2006 19:42:30 -0400 Message-ID: <29030010.1149810150458.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> Date: Thu, 8 Jun 2006 16:42:30 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "Nancy Winget (ncamwing)" , Dorothy.Gellert@nokia.com, capwap@frascone.com Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710bee328f3ca760f4c33688f66eff40aac350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.34 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Hi Nanciy, >I disagree....if it is independent of transport encapsulation then why >for example is it DTLS vs. TLS? We chose DTLS because it uses the UDP >model....we are now tweaking this by introducing the concept of a MUX. >Having lived through the WEP debacle, I am merely stating that there may >be repercusions that need further analysis. It is DTLS precisely because it is *not* dependent on the underlying transport, whereas TLS *is*. That's why TLS is not an option, but DTLS is. We chose DTLS because it uses the *connectionless* (or datagram) model - not UDP in particular. And adding a PDU type identifier is simply another layered datagram protocol. There are no security implications introduced by this modification. >I do not believe this is a non-existant issue, nor is it nonsense to >those trying to analyze the security behind CAPWAP. It is something I'm >highlighting as complicating the analysis....maybe not for you, but it >will to those analyzing the security of this. If you do such an analysis, I think you will find that one elegant feature of DTLS is that it does not matter what you wrap it in. It can be wrapped in connection-oriented or connectionless protocols, and it can even be multiplexed across both simultaneously - I have actually implemented this. It's very cool in that regard. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 21:41:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoW0A-0006YK-8s for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 21:41:30 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoW07-0004Yj-Bc for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 21:41:30 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2EF17430106 for ; Thu, 8 Jun 2006 18:41:26 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3EB364300EB for ; Thu, 8 Jun 2006 18:40:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2A6E1144802E for ; Thu, 8 Jun 2006 18:40:49 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by hermes.tigertech.net (Postfix) with ESMTP id 97F57144803A for ; Thu, 8 Jun 2006 18:40:45 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id c39so689600pyd for ; Thu, 08 Jun 2006 18:40:44 -0700 (PDT) Received: by 10.35.89.10 with SMTP id r10mr3202403pyl; Thu, 08 Jun 2006 18:40:44 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Thu, 8 Jun 2006 18:40:44 -0700 (PDT) Message-ID: <26140d940606081840j6936d0f1j28752e0dc08de352@mail.gmail.com> Date: Thu, 8 Jun 2006 21:40:44 -0400 From: "Michael Montemurro" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201FC086E@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A201FC086E@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] New issue - Correct Clause 11 Message Naming, Clean-up terminology X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2038285505==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 --===============2038285505== Content-Type: multipart/alternative; boundary="----=_Part_25957_25745939.1149817244439" ------=_Part_25957_25745939.1149817244439 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree with Pat. The last paragraph must not be deleted. It allows for optional tunnelling in Local MAC mode. On 6/6/06, Pat Calhoun (pacalhou) wrote: > > 2. 11.1.2 Local MAC - Last paragraph describes optionally tunnelling > data frames to the AC, which > is not consistent with Local MAC. > > Recommended change: Delete the last paragraph > > This text was requested by folks on the list, as well as by the > evaluation team, which was to allow for optional tunneling in local MAC > mode, using 802.3 frame format. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > ________________________________ > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > Sent: Tuesday, April 11, 2006 9:48 AM > To: capwap > Subject: [Capwap] New issue - Correct Clause 11 Message > Naming,Clean-up terminology > > > All, > > Some suggested, largely editorial changes, throughout Clause 11: > > 1. Figures 5,7,8 show examples of message Flow and Roaming, and > show > "Add Mobile" as the message exchanged between the AC and WTP. > But "Add Mobile" is the message element, not the message - > the Mobile Config Request, changing to "Mobile Station Config > Request" is the message name. > > Recommended change: Change "Add Mobile" to "Mobile Station > Config Request[Add Mobile...]" > > > 3. 11.3.1 Wording change: > From: > The CAPWAP protocol defines the data frame, which allows a > wireless payload to be encapsulated. > to: > The CAPWAP protocol defines CAPWAP data packets, which are used > to encapsulate an IEEE 802.11 payload. > > 4. 11.1.1 and 11.1.2 - Clarity > In the function lists, change from > Probe Response > to > Generate Probe Response > > 5. 11.1.1 Split MAC, first paragraph below the figure > > The Distribution and Integration services reside on the AC, and > therefore all user data is tunneled between the WTP and the AC. > As noted above, all real-time 802.11 services, including the > control protocol and the beacon and probe response frames, are handled > on the WTP. > > "control protocol" usually refers to the CAPWAP control > protocol. > > Change to > > The Distribution and Integration services reside on the AC, and > all user data is tunneled between the WTP and the AC. All real-time IEEE > 802.11 services, > including the IEEE 802.11 control frames, such as the Beacon and > Probe Response frames, are handled on the WTP. > > 6. 11.3 - Correct use of terms > > 11.3 Transport specific bindings > > "All CAPWAP transports have the following IEEE 802.11 specific > bindings:" > > Section 3, "CAPWAP Transport" talks about UDP with IPv4 or IPv6, > rather than the payload encapsulation and status and WLANs field > > Suggest > > 11.3 IEEE 802.11 bindings for the CAPWAP Protocol > > This section defines the IEEE 802.11 specific bindings used with > the CAPWAP protocol. > > 7. I1.2, First sentence in the second paragraph, change "access > point" to "WTP". > > Comments please. > > Thanks, > > Dorothy > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_25957_25745939.1149817244439 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree with Pat. The last paragraph must not be deleted. It allows for optional tunnelling in Local MAC mode.

On 6/6/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
2. 11.1.2 Local MAC - Last paragraph describes optionally tunnelling
data frames to the AC, which
is not consistent with Local MAC.

Recommended change: Delete the last paragraph

<PRC> This text was requested by folks on the list, as well as by the
evaluation team, which was to allow for optional tunneling in local MAC
mode, using 802.3 frame format.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems




________________________________

       From: Dorothy Stanley [mailto: dstanley1389@gmail.com]
       Sent: Tuesday, April 11, 2006 9:48 AM
       To: capwap
       Subject: [Capwap] New issue - Correct Clause 11 Message
Naming,Clean-up terminology


       All,

       Some suggested, largely editorial changes, throughout Clause 11:

       1. Figures 5,7,8 show examples of message Flow and Roaming, and
show
       "Add Mobile" as the message exchanged between the AC and WTP.
But "Add Mobile" is the message element, not the message -
       the Mobile Config Request, changing to "Mobile Station Config
Request" is the message name.

       Recommended change: Change  "Add Mobile" to "Mobile Station
Config Request[Add Mobile...]"


       3. 11.3.1 Wording change:
       From:
       The CAPWAP protocol defines the data frame, which allows a
wireless payload to be encapsulated.
       to:
       The CAPWAP protocol defines CAPWAP data packets, which are used
to  encapsulate an IEEE 802.11 payload.

       4. 11.1.1 and 11.1.2 - Clarity
       In the function lists, change from
       Probe Response
       to
       Generate Probe Response

       5. 11.1.1 Split MAC, first paragraph below the figure

       The Distribution and Integration services reside on the AC, and
therefore all user data is tunneled between the WTP and the AC.
       As noted above, all real-time 802.11 services, including the
control protocol and the beacon and probe response frames, are handled
on the WTP.

       "control protocol" usually refers to the CAPWAP control
protocol.

       Change to

       The Distribution and Integration services reside on the AC, and
all user data is tunneled between the WTP and the AC. All real-time IEEE
802.11 services,
       including the IEEE 802.11 control frames, such as the Beacon and
Probe Response frames, are handled on the WTP.

       6. 11.3 - Correct use of terms

       11.3 Transport specific bindings

       "All CAPWAP transports have the following IEEE 802.11 specific
bindings:"

       Section 3, "CAPWAP Transport" talks about UDP with IPv4 or IPv6,
rather than the payload encapsulation and status and WLANs field

       Suggest

       11.3 IEEE 802.11 bindings for the CAPWAP Protocol

       This section defines the IEEE 802.11 specific bindings used with
the CAPWAP protocol.

       7. I1.2, First sentence in the second paragraph, change "access
point" to "WTP".

       Comments please.

       Thanks,

       Dorothy


_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_25957_25745939.1149817244439-- --===============2038285505== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============2038285505==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 21:45:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoW3y-0004ts-IA for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 21:45:26 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoW3w-0004eF-UU for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 21:45:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 93A3243017B for ; Thu, 8 Jun 2006 18:45:24 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3E4DA4300EE for ; Thu, 8 Jun 2006 18:44:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 249D61448035 for ; Thu, 8 Jun 2006 18:44:53 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by hermes.tigertech.net (Postfix) with ESMTP id 0F999144802E for ; Thu, 8 Jun 2006 18:44:48 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so768635pyu for ; Thu, 08 Jun 2006 18:44:48 -0700 (PDT) Received: by 10.35.93.19 with SMTP id v19mr1790142pyl; Thu, 08 Jun 2006 18:44:48 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Thu, 8 Jun 2006 18:44:48 -0700 (PDT) Message-ID: <26140d940606081844jcf38acu6f884813bbe12034@mail.gmail.com> Date: Thu, 8 Jun 2006 21:44:48 -0400 From: "Michael Montemurro" To: "Dorothy Stanley" In-Reply-To: <5bfe7a820606061115w545e6b3bhbc2eb71e29fb44f1@mail.gmail.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A201FC0873@xmb-sjc-235.amer.cisco.com> <5bfe7a820606061115w545e6b3bhbc2eb71e29fb44f1@mail.gmail.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_50_60, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] New Issue - Local MAC MUST vs MAY forward associationrequest messages X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1955728404==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 --===============1955728404== Content-Type: multipart/alternative; boundary="----=_Part_25977_19567411.1149817488073" ------=_Part_25977_19567411.1149817488073 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I've captured this as issue 134. Cheers, Mike On 6/6/06, Dorothy Stanley wrote: > > Pat, David, > > Your comments are consistent with those received back in April, when > this mail was sent out - thus > I did not make, and had not planned to make the proposed change. > > Thanks, > > Dorothy > > > On 6/6/06, David T. Perkins wrote: > > > > HI, > > > > ABSOLUTELY agree with Pat. That is the AC MUST know what STAs > > are be serviced by the WTPs, and MUST decide which STAs are > > allowed to associate and send traffic. > > This is the fundamental difference between a CAPWAP network > > and a collection of APs. > > > > Regards, > > /david t. perkins > > > > On Tue, 6 Jun 2006, Pat Calhoun (pacalhou) wrote: > > > > > I disagree with this change request. The AC MUST know what STAs are > > > being serviced by WTPs. The term MUST cannot be changed to MAY. > > > > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit > > > Cisco Systems > > > > > > > > > > > > > > > ________________________________ > > > > > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > > > Sent: Tuesday, April 11, 2006 11:41 AM > > > To: capwap > > > Subject: [Capwap] New Issue - Local MAC MUST vs MAY forward > > > associationrequest messages > > > > > > > > > All, > > > > > > Section 11.1.2 Local MAC describes the Local MAC operation. It > > > currently states > > > (second paragraph below Figure 6): > > > > > > While the MAC is terminated on the WTP, it is necessary for the > > > AC to be aware of mobility events within the WTPs. > > > As a consequence, the WTP MUST forward the IEEE 802.11 > > > Association Requests to the AC, and the AC MAY reply > > > with a failed Association Response if it deems it necessary. > > > > > > > > > Since this is the Local MAC case, it seems that a MAY should be > > > sufficient. > > > > > > Recommended change: > > > > > > The MAC is terminated on the WTP, but the AC may need to be > > > aware of mobility events within the WTPs. > > > As a consequence, the WTP MAY forward the IEEE 802.11 > > > Association Requests to the AC, and the AC MAY reply > > > with a failed Association Response. > > > > > > Comments? > > > > > > Thanks, > > > > > > Dorothy > > > > > > > > > > > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_25977_19567411.1149817488073 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I've captured this as issue 134.
 
Cheers,
 
Mike


 
On 6/6/06, Dorothy Stanley <dstanley1389@gmail.com> wrote:
Pat, David,
 
Your comments are consistent with those received back in April, when
this mail was sent out - thus
I did not make, and had not planned to make the proposed change.
 
Thanks,
 
Dorothy

 
On 6/6/06, David T. Perkins <dperkins@dsperkins.com > wrote:
HI,

ABSOLUTELY agree with Pat. That is the AC MUST know what STAs
are be serviced by the WTPs, and MUST decide which STAs are
allowed to associate and send traffic.
This is the fundamental difference between a CAPWAP network
and a collection of APs.

Regards,
/david t. perkins

On Tue, 6 Jun 2006, Pat Calhoun (pacalhou) wrote:

> I disagree with this change request. The AC MUST know what STAs are
> being serviced by WTPs. The term MUST cannot be changed to MAY.
>
>
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
>
>
>
>
> ________________________________
>
>       From: Dorothy Stanley [mailto: dstanley1389@gmail.com]
>       Sent: Tuesday, April 11, 2006 11:41 AM
>       To: capwap
>       Subject: [Capwap] New Issue - Local MAC MUST vs MAY forward
> associationrequest messages
>
>
>       All,
>
>       Section 11.1.2 Local MAC describes the Local MAC operation. It
> currently states
>       (second paragraph below Figure 6):
>
>       While the MAC is terminated on the WTP, it is necessary for the
> AC to be aware of mobility events within the WTPs.
>       As a consequence, the WTP MUST forward the IEEE 802.11
> Association Requests to the AC, and the AC MAY reply
>       with a failed Association Response if it deems it necessary.
>
>
>       Since this is the Local MAC case, it seems that a MAY should be
>       sufficient.
>
>       Recommended change:
>
>       The MAC is terminated on the WTP, but the AC may need to be
> aware of mobility events within the WTPs.
>       As a consequence, the WTP MAY forward the IEEE 802.11
> Association Requests to the AC, and the AC MAY reply
>       with a failed Association Response.
>
>       Comments?
>
>       Thanks,
>
>       Dorothy
>
>
>



_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


------=_Part_25977_19567411.1149817488073-- --===============1955728404== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1955728404==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 21:47:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoW5W-0006jx-Lq for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 21:47:02 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoW5V-0004jc-3M for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 21:47:02 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B4EDD43016B for ; Thu, 8 Jun 2006 18:47:00 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id DCA394300EF for ; Thu, 8 Jun 2006 18:46:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C992D144803C for ; Thu, 8 Jun 2006 18:46:28 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by hermes.tigertech.net (Postfix) with ESMTP id 53047144802E for ; Thu, 8 Jun 2006 18:46:26 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x31so814556pye for ; Thu, 08 Jun 2006 18:46:25 -0700 (PDT) Received: by 10.35.99.5 with SMTP id b5mr3251051pym; Thu, 08 Jun 2006 18:46:25 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Thu, 8 Jun 2006 18:46:25 -0700 (PDT) Message-ID: <26140d940606081846r3125fec9gf707e50b1b4c6cbb@mail.gmail.com> Date: Thu, 8 Jun 2006 21:46:25 -0400 From: "Michael Montemurro" To: "Charles Clancy" In-Reply-To: <44863A61.7010202@cs.umd.edu> MIME-Version: 1.0 References: <013d01c68996$c0b1df20$791fa8c0@corp.devicescape.com> <44863A61.7010202@cs.umd.edu> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com, Margaret Wasserman Subject: Re: [Capwap] RC4 Encryption? X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1026566494==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --===============1026566494== Content-Type: multipart/alternative; boundary="----=_Part_25989_7140657.1149817585463" ------=_Part_25989_7140657.1149817585463 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I've capture this as issue 135 On 6/6/06, Charles Clancy wrote: > > Are you suggesting adding DTLS ciphersuites such as > TLS_RSA_WITH_RC4_128_SHA and TLS_PSK_WITH_RC4_128_SHA? > > There's a fundamental problem when using RC4 with DTLS (that > incidentally does not appear to be addressed in RFC 4279). In > particular, we seed the KDF and use its never-ending output to encrypt > data by XORing it with the plaintext packets. However in DTLS, we can > lose packets. This means gaps in the keystream, and the key states > become out of sync. The only way to fix this is to do what WEP did, > with per-packet IVs, and then you get all the same problems found in WEP. > > So, as-is, RC4 ciphersuites don't work well with DTLS, and if we fix > them, we introduce security problems. > > -- > t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy > > Margaret Wasserman wrote: > > Hi All, > > > > I tried to send a message to the list on this topic a while back, but I > > don't think it ever went out... Sorry if this is a duplicate. > > > > I have a possible application for CAPWAP that involves running the WTP > > portion on a DSP-only device. In that situation, it will be very > difficult > > to support AES encryption, due to the processing overhead. > > > > Would the WG consider supporting a lighter weight algorithm for > encryption, > > such as RC4? We could state that AES is preferred when possible, but > make > > RC4 an accepted option in cases where the hardware would not support the > > processing overhead of AES encryption. > > > > Thoughts? > > > > Margaret > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_25989_7140657.1149817585463 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I've capture this as issue 135

On 6/6/06, Charles Clancy <clancy@cs.umd.edu> wrote:
Are you suggesting adding DTLS ciphersuites such as
TLS_RSA_WITH_RC4_128_SHA and TLS_PSK_WITH_RC4_128_SHA?

There's a fundamental problem when using RC4 with DTLS (that
incidentally does not appear to be addressed in RFC 4279).  In
particular, we seed the KDF and use its never-ending output to encrypt
data by XORing it with the plaintext packets.  However in DTLS, we can
lose packets.  This means gaps in the keystream, and the key states
become out of sync.  The only way to fix this is to do what WEP did,
with per-packet IVs, and then you get all the same problems found in WEP.

So, as-is, RC4 ciphersuites don't work well with DTLS, and if we fix
them, we introduce security problems.

--
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>   www.cs.umd.edu/~clancy

Margaret Wasserman wrote:
> Hi All,
>
> I tried to send a message to the list on this topic a while back, but I
> don't think it ever went out...  Sorry if this is a duplicate.
>
> I have a possible application for CAPWAP that involves running the WTP
> portion on a DSP-only device.  In that situation, it will be very difficult
> to support AES encryption, due to the processing overhead.
>
> Would the WG consider supporting a lighter weight algorithm for encryption,
> such as RC4?  We could state that AES is preferred when possible, but make
> RC4 an accepted option in cases where the hardware would not support the
> processing overhead of AES encryption.
>
> Thoughts?
>
> Margaret
>
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_25989_7140657.1149817585463-- --===============1026566494== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1026566494==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 21:55:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoWDN-0004XA-9B for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 21:55:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoVHe-0006MG-6M for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 20:55:30 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoV3R-0004MW-Mp for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 20:40:52 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5A121430128 for ; Thu, 8 Jun 2006 17:40:48 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 2BD61430071 for ; Thu, 8 Jun 2006 17:40:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 16A56398041 for ; Thu, 8 Jun 2006 17:40:22 -0700 (PDT) Received: from smtpauth08.mail.atl.earthlink.net (smtpauth08.mail.atl.earthlink.net [209.86.89.68]) by zoidberg.tigertech.net (Postfix) with ESMTP id AB315398061 for ; Thu, 8 Jun 2006 17:40:18 -0700 (PDT) Received: from [209.86.224.34] (helo=elwamui-hound.atl.sa.earthlink.net) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1FoV2s-0001NJ-HX; Thu, 08 Jun 2006 20:40:17 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Thu, 8 Jun 2006 20:40:14 -0400 Message-ID: <841517.1149813614363.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> Date: Thu, 8 Jun 2006 17:40:14 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "Kraus,Michael" , capwap@frascone.com Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710b8cfab96e9e935d1cd51f7a891deab2e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.34 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: s.kelly@ix.netcom.com, Dorothy.Gellert@nokia.com Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Hi Michael, >Greetings! > >Before saying that going to a mux header is the simplest/cleanest, I would >suggest reviewing the original objectives of this WG. From 5.1.2 of the >objectives: > >> Protocol Requirement: >> >> The CAPWAP Protocol MUST define transport control messages such that >> the transport of control messages is separate from the transport of >> data messages. > >How is transport defined? To me, a mux header merely identifies control vs. >data but does not provide a separate transport mechanism (more on this below). I looked at that objective some time ago and went through the same thought process, so I think I understand your concern. I think it's very important to recognize that virtually any protocol can be used as a transport - the Internet works for just this reason. Following is an example of a transport protocol: [ethernet][IP][UDP][data being transported] Here's another one: [ethernet][IP][UDP][PDU type][data being transported] >From the perspective of the application consuming the data, these are indistinguishable, assuming appropriate send/recv APIs are provided. Hence, strictly speaking, the objective you cite has been met. >> Motivation and Protocol Benefits: >> >> The aim of separating data and control aspects of the protocol is to >> simplify the protocol. > >This is where a MUX header makes sense, since it mitigates the NAT traversal >concern (rather than adding a keep alive type of functionality, which would >somewhat increase overhead/complexity). > >> It also allows for the flexibility of addressing each type of traffic in the >most appropriate manner. > >With a MUX header, the network devices will not be able to remark DSCP values of >data traffic, perform traffic engineering (policy-based routing), or apply >different security requirements. It sounds like we're talking about an enterprise LAN here. In any event, we know that all QoS bets are off if the Internet is one of the hops, so let's eliminate that from the discussion. And let's be clear here: the claim is that on an enterprise LAN, intermediate gear will need to remark DSCP values, and that it can *only* do this based on the UDP ports, that any deeper packet inspection is too expensive. We noted here earlier that a direct consequence of this is that the data channel would be an opaque blob to such a system, and the applications within it would be treated the same - they would have no QoS. In this case, you would essentially have two classes: control (the "haves") and data (" the have-nots"). This actually violates another objective in the same document you referred to. In any event, I don't think this is a realistic scenario, but even if it were, wouldn't this problem be better solved by using a different VLAN tag for the control packets than the data packets? > For security/DoS/network optimization, it does >not always make sense for control and data traffic for applications to take the >same network path, have the same access, and receive the same priority. By >requiring the same port, and a mux header the control and data traffic must take >the same network path. If manufacturers provide classification within the WTP, >this would help alleviate the QoS concerns, but network traffic >engineering/security is still a concern. Again, what network are we talking about here? When you mention security and DoS optimizations with respect to the wired network, I'm thinking the Internet may be involved - is that what you mean? > Deep packet inspection techniques >(NBAR) are slow in coming across vendors, slow in market adoption, and >complex/costly to implement. Proliferation of this technology/protocol is >dependent upon the cost effectiveness of the solution. Upgrading access points >to a CAPWAP solution provides some potential cost savings, through centralized >policy and management. But, if you say to do it "right" you need to also >upgrade your entire network infrastructure to support deep packet inspection >techniques, this quickly becomes too costly of a solution to implement. Current >project I'm working on, it costs roughly $3M to do all wireless access points. >But, to upgrade all network infrastructure to support NBAR, I'd is estimate is >at $40M. Some corners of the network here still have 10Base2 hubs! The reason >802.11 has been success is because it has been inexpensive, creating a >dependency of the wireless network on the wired network would hamper further >proliferation. I don't think you need to add fancy classification tools to make this work. I think the AC and WTP have all the information they need. But the fact is that if you *don't* have fancy classification tools, then any re-marking will either be a one-to-one mapping that favors control traffic, and ignores the QoS granularity requirements of the data. That can't really be good from an operational perspective, can it? >> Furthermore, this requirement will help remotely located WTPs to >> handle data traffic in alternative ways without the need for >> forwarding them across a wide network to the WLAN controller. > >WLAN Controller should be renamed to AC here. > >> Separation of WTP control and data also aids in the secure >> realization of shared WLAN deployments. > >Security should not be limited to whether the control data is being encrypted, >while the data may or may not be. It is more far reaching. Perhaps you want to >have an network segment act as a transit area for control data, but not for data >traffic. Logical network segmentation of traffic for security (DoS) prevention >is something that is present in certain environments (especially manufacturing >and high security). The same thing can be realized with vlan tagging, can't it? But if the only thing you have for realizing this is (an unauthenticated) tuple-based packet filter (or a vlan tag, for that matter), we don't really expect that to be *secure*, do we? I'm not sure exactly what was meant by this clause, but I think we need to be careful to avoid imparting a "scriptural" aura to the objectives document. >> Relation to Problem Statement: >> >> Broadly, this objective relates to the challenge of managing >> complexity in large-scale WLANs. The requirement for traffic >> separation simplifies control as this is separated from the task of >> data transport. > >The way I interpret this, by using a MUX header, a truly separate transport of >control and data messages cannot be fully realized. I can see how it simplifies >the protocol (NAT Traversal), so this does provide merit as a viable option. >However, if this is the path that is chosen, we lose some flexibility (traffic >engineering). I think that adding a capwap layer header (call it a PDU identifier, a capwap frame type, a mux header, whatever) is a separate transport layer, and meets the objective fully. I think we should be careful about loaded terms like "truly" in the same way as we should be careful not to assume the objectives document is scripture. Layering in this manner does not ignore this objective. >In conclusion, should a MUX header be chosen, I would suggest that the >objectives need to also be reviewed/updated to reflect that the spirit of this >protocol requirement has changed. In particular, stating that a true separate >transport for data and control messages are not going to be achieved by this WG, >but rather an internal identification of data and control messages so that AC >and WTPs can treat data and control messages differently. No need to modify it in any event - it's really a historical document. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 21:59:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoWHU-0007Fj-F9 for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 21:59:24 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoWHR-0006nB-Nx for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 21:59:24 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 60BF94300DF for ; Thu, 8 Jun 2006 18:59:21 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id ACEE3430071 for ; Thu, 8 Jun 2006 18:58:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 971A4398013 for ; Thu, 8 Jun 2006 18:58:45 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by zoidberg.tigertech.net (Postfix) with ESMTP id A8428398009 for ; Thu, 8 Jun 2006 18:58:42 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so771823pyu for ; Thu, 08 Jun 2006 18:58:42 -0700 (PDT) Received: by 10.35.129.19 with SMTP id g19mr1804994pyn; Thu, 08 Jun 2006 18:52:09 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Thu, 8 Jun 2006 18:52:09 -0700 (PDT) Message-ID: <26140d940606081852j4bab37a2kb4b3f80a2f4e51d@mail.gmail.com> Date: Thu, 8 Jun 2006 21:52:09 -0400 From: "Michael Montemurro" To: "David T. Perkins" In-Reply-To: MIME-Version: 1.0 References: <5bfe7a820606071626h1aca4bdei854e75ab1dd4eba3@mail.gmail.com> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.198 tagged_above=-999 required=7 tests=HTML_50_60, HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Typo in 4.3.1.1 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2010491312==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 --===============2010491312== Content-Type: multipart/alternative; boundary="----=_Part_26061_14057176.1149817929173" ------=_Part_26061_14057176.1149817929173 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I've captured this as issue 136. I will fix in -02 On 6/7/06, David T. Perkins wrote: > > HI, > > Section 4.3.1 shows the header for control messages, and has > a 32 bit field for the message type value, which is described > in section 4.3.1.1 shown below. There is a typo in the text. > It is marked with the correction. > > ------------------------- > 4.3.1.1. Message Type > > The Message Type field identifies the function of the CAPWAP control > message. The Message Type field is comprised of an IANA Enterprise > Number and a message type value field. The first two byte contain > ^^^^^^^^ > should be "three octets" > the IANA Enterprise Number (for example, the IEEE 802.11 IANA > Enterprise number is 13277), and the second two bytes contain the > ^^^^^^^^^^^^^^^^ > should be "last octet" > Message Type value. The message type field can be expressed as: > > Message Type = IANA Enterprise Number * 256 + Message Type Value > -------------------------- > > Note, the above is an OK fix, but I'd change the text to the > following to make it clearer. > > 4.3.1.1. Message Type > > The Message Type field identifies the function of the CAPWAP control > message. The Message Type field is comprised of an IANA Enterprise > Number[IANA.enterpriseNumber.ref] and an enterprise specific message > type number. The first three octets is the enterprise number in > network byte order, with zero being used for CAPWAP generic > message types and the IEEE 802.11 IANA assigned enterprise > number 13277 being used for IEEE 802.11 technology specific > message types. The last octet is the enterprise specific > message type number, which has a range from 0 to 255. > > The value of the message type field can be expressed as: > > Message type value = IANA Enterprise Number * 256 + > enterprise specific message type number > > -------------------------- > And, I'd make the identification of the message elements encoded > identically. Thus, I'd change the message element header > in section 4.4 to the following format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length | Value ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > Where the value of Type is expressed as: > > Message Element Type value = IANA Enterprise Number * 256 + > enterprise specific type number > > Regards, > /david t. perkins > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_26061_14057176.1149817929173 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I've captured this as issue 136.
 
I will fix in -02

 
On 6/7/06, David T. Perkins <dperkins@dsperkins.com> wrote:
HI,

Section 4.3.1 shows the header for control messages, and has
a 32 bit field for the message type value, which is described
in section 4.3.1.1 shown below. There is a typo in the text.
It is marked with the correction.

-------------------------
4.3.1.1.  Message Type

  The Message Type field identifies the function of the CAPWAP control
  message.  The Message Type field is comprised of an IANA Enterprise
  Number and a message type value field.  The first two byte contain
                                                    ^^^^^^^^
                                            should be "three octets"
  the IANA Enterprise Number (for example, the IEEE 802.11 IANA
  Enterprise number is 13277), and the second two bytes contain the
                                       ^^^^^^^^^^^^^^^^
                                       should be "last octet"
  Message Type value.  The message type field can be expressed as:

  Message Type = IANA Enterprise Number * 256 + Message Type Value
--------------------------

Note, the above is an OK fix, but I'd change the text to the
following to make it clearer.

4.3.1.1.  Message Type

  The Message Type field identifies the function of the CAPWAP control
  message.  The Message Type field is comprised of an IANA Enterprise
  Number[IANA.enterpriseNumber.ref] and an enterprise specific message
  type number.  The first three octets is the enterprise number in
  network byte order, with zero being used for CAPWAP generic
  message types and the IEEE 802.11 IANA assigned enterprise
  number 13277 being used for IEEE 802.11 technology specific
  message types. The last octet is the enterprise specific
  message type number, which has a range from 0 to 255.

  The value of the message type field can be expressed as:

  Message type value = IANA Enterprise Number * 256 +
                             enterprise specific message type number

--------------------------
And, I'd make the identification of the message elements encoded
identically. Thus, I'd change the message element header
in section 4.4 to the following format:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Length                      |  Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Where the value of Type is expressed as:

Message Element Type value = IANA Enterprise Number * 256 +
                                enterprise specific type number

Regards,
/david t. perkins

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_26061_14057176.1149817929173-- --===============2010491312== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============2010491312==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 22:14:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoWWT-0003f5-2W for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 22:14:53 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoWWR-00089U-DT for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 22:14:53 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A812043012D for ; Thu, 8 Jun 2006 19:14:50 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1E10B430071 for ; Thu, 8 Jun 2006 19:14:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0CB48144801D for ; Thu, 8 Jun 2006 19:14:21 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by hermes.tigertech.net (Postfix) with ESMTP id F3EFC1448004 for ; Thu, 8 Jun 2006 19:14:18 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so775373pyu for ; Thu, 08 Jun 2006 19:14:18 -0700 (PDT) Received: by 10.35.17.12 with SMTP id u12mr1854028pyi; Thu, 08 Jun 2006 19:14:18 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Thu, 8 Jun 2006 19:14:18 -0700 (PDT) Message-ID: <26140d940606081914x2c27ffa9vb43515465bbaa7a0@mail.gmail.com> Date: Thu, 8 Jun 2006 22:14:18 -0400 From: "Michael Montemurro" To: "Kraus, Michael" In-Reply-To: <89525CB1203D7346BBBDFCE9CECB47CF02B539A6@exchange-USR31> MIME-Version: 1.0 References: <89525CB1203D7346BBBDFCE9CECB47CF02B539A6@exchange-USR31> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] QoS for Control Messages Clarity X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0405655574==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c --===============0405655574== Content-Type: multipart/alternative; boundary="----=_Part_26397_33010271.1149819258293" ------=_Part_26397_33010271.1149819258293 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Michael, This was captured earler in as issue 100. I updated the text in -02 to make 11.6 consistent with 4.3.2. However section 4.3.2 refers to CAPWAP control frames and section 11.6refers to 802.11 Management frames, which are treated as CAPWAP data frames. Cheers, Mike On 6/8/06, Kraus, Michael wrote: > > > There does appear to be a slight discrepancy between 4.3.2 and 11.6. 11.6 > specifies a different IP Prec/DSCP value for probe requests, where 4.3.2does > not. > > 4.3.2. Control Message Quality of Service > > It is recommended that CAPWAP control messages be sent by both the AC > and the WTP with an appropriate Quality of Service precedence value, > ensuring that congestion in the network minimizes occurrences of > CAPWAP control channel disconnects. Therefore, a Quality of Service > enabled CAPWAP device should use the following values: > > 802.1P: The precedence value of 7 SHOULD be used. > > DSCP: The DSCP tag value of 46 SHOULD be used. > > > 11.6. Quality of Service for Control Messages > > It is recommended that IEEE 802.11 MAC management frames be sent by > both the AC and the WTP with appropriate Quality of Service values, > ensuring that congestion in the network minimizes occurrences of > packet loss. Therefore, a Quality of Service enabled CAPWAP device > should use: > > 802.1P: The precedence value of 6 SHOULD be used for all IEEE 802.11 > MAC management frames, except for Probe Requests which SHOULD use > 4. > > DSCP: The DSCP tag value of 46 SHOULD be used for all IEEE 802.11 > MAC management frames, except for Probe Requests which SHOULD use > 34. > > > > > Mike Kraus > Sr. Network Engineer > Applied Information Systems > Cellular Phone (314) 575-0968 > Nextel direct connect: 140*1*31368 > Providing solutions for ABI, Brewing Operations & Technology, Engineering > > > > The information transmitted (including attachments) is > covered by the Electronic Communications Privacy Act, > 18 U.S.C. 2510-2521, is intended only for the person(s) or > entity/entities to which it is addressed and may contain > confidential and/or privileged material. Any review, > retransmission, dissemination or other use of, or taking > of any action in reliance upon, this information by persons > or entities other than the intended recipient(s) is prohibited. > If you received this in error, please contact the sender and > delete the material from any computer. > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_26397_33010271.1149819258293 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Michael,
 
This was captured earler in as issue 100. I updated the text in -02 to make 11.6 consistent with 4.3.2.
 
However section 4.3.2 refers to CAPWAP control frames and section 11.6 refers to 802.11 Management frames, which are treated as CAPWAP data frames.
 
Cheers,
 
Mike


 
On 6/8/06, Kraus, Michael <Michael.Kraus@anheuser-busch.com> wrote:

There does appear to be a slight discrepancy between 4.3.2 and 11.6.  11.6
specifies a different IP Prec/DSCP value for probe requests, where 4.3.2 does
not.

4.3.2.  Control Message Quality of Service

  It is recommended that CAPWAP control messages be sent by both the AC
  and the WTP with an appropriate Quality of Service precedence value,
  ensuring that congestion in the network minimizes occurrences of
  CAPWAP control channel disconnects.  Therefore, a Quality of Service
  enabled CAPWAP device should use the following values:

  802.1P:  The precedence value of 7 SHOULD be used.

  DSCP:  The DSCP tag value of 46 SHOULD be used.


11.6.  Quality of Service for Control Messages

  It is recommended that IEEE 802.11 MAC management frames be sent by
  both the AC and the WTP with appropriate Quality of Service values,
  ensuring that congestion in the network minimizes occurrences of
  packet loss.  Therefore, a Quality of Service enabled CAPWAP device
  should use:

  802.1P:  The precedence value of 6 SHOULD be used for all IEEE 802.11
     MAC management frames, except for Probe Requests which SHOULD use
     4.

  DSCP:  The DSCP tag value of 46 SHOULD be used for all IEEE 802.11
     MAC management frames, except for Probe Requests which SHOULD use
     34.




Mike Kraus
Sr. Network Engineer
Applied Information Systems
Cellular Phone (314) 575-0968
Nextel direct connect: 140*1*31368
Providing solutions for ABI, Brewing Operations & Technology, Engineering



The information transmitted (including attachments) is
covered by the Electronic Communications Privacy Act,
18 U.S.C. 2510-2521, is intended only for the person(s) or
entity/entities to which it is addressed and may contain
confidential and/or privileged material. Any review,
retransmission, dissemination or other use of, or taking
of any action in reliance upon, this information by persons
or entities other than the intended recipient(s) is prohibited.
If you received this in error, please contact the sender and
delete the material from any computer.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_26397_33010271.1149819258293-- --===============0405655574== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0405655574==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 22:15:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoWXP-0005cQ-4I for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 22:15:51 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoWXN-0008AV-KH for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 22:15:51 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 44EF043012D for ; Thu, 8 Jun 2006 19:15:49 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 94555430109 for ; Thu, 8 Jun 2006 19:14:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8101E1448009 for ; Thu, 8 Jun 2006 19:14:37 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by hermes.tigertech.net (Postfix) with ESMTP id 36C72144801D for ; Thu, 8 Jun 2006 19:14:33 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so775373pyu for ; Thu, 08 Jun 2006 19:14:33 -0700 (PDT) Received: by 10.35.37.18 with SMTP id p18mr1844037pyj; Thu, 08 Jun 2006 19:07:30 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Thu, 8 Jun 2006 19:07:30 -0700 (PDT) Message-ID: <26140d940606081907p1ac7a16dp897596b0e323a845@mail.gmail.com> Date: Thu, 8 Jun 2006 22:07:30 -0400 From: "Michael Montemurro" To: "David T. Perkins" In-Reply-To: MIME-Version: 1.0 References: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Proposal for CAPWAP packet format X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0955710502==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 --===============0955710502== Content-Type: multipart/alternative; boundary="----=_Part_26281_21490886.1149818850243" ------=_Part_26281_21490886.1149818850243 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline David, I've captured this as Issue 137 Cheers, Mike On 6/8/06, David T. Perkins wrote: > > HI, > > For the wireless payload, I just cut and pasted from > the CAPWAP-01 document. I defer to others for the > details. > > On Thu, 8 Jun 2006 Michael.G.Williams@nokia.com wrote: > > David, > > > > In the 'wireless payload" can you elaborate how much of the wireless > > standard's frame is included in that? I don't think there are any > > wireless standards that specify how much of their frames are to be > > carried by CAPWAP ;^) > > BR, > > Michael > > Regards, > /david t. perkins > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_26281_21490886.1149818850243 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
David,
 
I've captured this as Issue 137
 
Cheers,
 
 Mike

 
On 6/8/06, David T. Perkins <dperkins@dsperkins.com> wrote:
HI,

For the wireless payload, I just cut and pasted from
the CAPWAP-01 document. I defer to others for the
details.

On Thu, 8 Jun 2006 Michael.G.Williams@nokia.com wrote:
> David,
>
> In the 'wireless payload" can you elaborate how much of the wireless
> standard's frame is included in that? I don't think there are any
> wireless standards that specify how much of their frames are to be
> carried by CAPWAP ;^)
> BR,
> Michael

Regards,
/david t. perkins


_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_26281_21490886.1149818850243-- --===============0955710502== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0955710502==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 22:53:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoX7M-0000FH-5q for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 22:53:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoWGe-0006Gx-F1 for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 21:58:32 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoVu9-00066C-Tu for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 21:35:23 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 15A1C430106 for ; Thu, 8 Jun 2006 18:35:17 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B664F4300AB for ; Thu, 8 Jun 2006 18:34:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 98A051448038 for ; Thu, 8 Jun 2006 18:34:44 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by hermes.tigertech.net (Postfix) with ESMTP id 6A273144802E for ; Thu, 8 Jun 2006 18:34:39 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id m51so774356pye for ; Thu, 08 Jun 2006 18:34:39 -0700 (PDT) Received: by 10.35.109.2 with SMTP id l2mr3191395pym; Thu, 08 Jun 2006 18:34:39 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Thu, 8 Jun 2006 18:34:39 -0700 (PDT) Message-ID: <26140d940606081834r307e6785kc650feed165ae985@mail.gmail.com> Date: Thu, 8 Jun 2006 21:34:39 -0400 From: "Michael Montemurro" To: Dorothy.Gellert@nokia.com, capwap@frascone.com In-Reply-To: <448875A3.7020800@cs.umd.edu> MIME-Version: 1.0 References: <893AE265F4ADF94AB7FB26D31A788E4102295E7E@mvebe101.NOE.Nokia.com> <448875A3.7020800@cs.umd.edu> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0168641833==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.5 (--) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 --===============0168641833== Content-Type: multipart/alternative; boundary="----=_Part_25857_30003189.1149816879221" ------=_Part_25857_30003189.1149816879221 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline First of all, I'd like to comment that one of the CAPWAP editors was not even consulted on the request to the chairs to resolve this issue. :-( So basically, the MUX header makes NAT Traversal easier to support. The use of separate UDP ports for control and data traffic allows for greater flexibility for deployment and implementation. I think you could probably argue back and forth on this one, but I don't see one option over the other presenting a clear advantage. The only compelling reason I could think of to go with separate UDP ports is that a network element classifying the packet does not have to read deep into the packet to distinguish CAPWAP control from data. That might be an advantage over a MUX if there are no security issues with exposing control and data UDP ports. Based on my review of this email thread. I fail to see a clear consensus on this issue. With that in mind, we really should consider a compromise scenario which Scott documented as his third option in his email on May 18th. That is, to quote him, "use multiple ports with separate data and control channels, but when NAT is detected, do what IPsec does, i.e. shift onto a single UDP channel, bundling control and data together; that is, have an optional nat-t encapsulation mechanism.". In that way, everybody is unhappy, but we have consensus on that. :-) Cheers, Mike On 6/8/06, Charles Clancy wrote: > > For the record, personally I'm in favor of MUX headers. While I agree > that QoS is an issue, I think NAT traversal is a bigger issue. > > -- > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > > Dorothy.Gellert@nokia.com wrote: > > > > The CAPWAP editors have asked the Chairs to resolve the Mux vs Multiport > > > issue # 115, in order to progress the specification. Based on the > > discussion that has taken place the chairs are in agreement the > > simplest, cleanest solution for this is to add a Mux header. Barring > > any unforseen events, we will instruct the editors resolve in favor of a > > new Mux header. > > > > We intend to close this issue by the end of the week, Friday, 6/9. > > Please review the issue and send any constructive comments to the list > > by Friday. > > > > Best Regards, > > Dorothy > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_25857_30003189.1149816879221 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
First of all, I'd like to comment that one of the CAPWAP editors was not even consulted on the request to the chairs to resolve this issue. :-(
 
So basically, the MUX header makes NAT Traversal easier to support. The use of separate UDP ports for control and data traffic allows for greater flexibility for deployment and implementation. I think you could probably argue back and forth on this one, but I don't see one option over the other presenting a clear advantage.
 
The only compelling reason I could think of to go with separate UDP ports is that a network element classifying the packet does not have to read deep into the packet to distinguish CAPWAP control from data. That might be an advantage over a MUX if there are no security issues with exposing control and data UDP ports. 
 
Based on my review of this email thread. I fail to see a clear consensus on this issue. With that in mind, we really should consider a compromise scenario which Scott documented as his third option in his email on May 18th. That is, to quote him, "use multiple ports with separate data and control channels, but when NAT is detected, do what IPsec does, i.e. shift onto a single UDP channel, bundling control and data together; that is, have an optional nat-t encapsulation mechanism.".
 
In that way, everybody is unhappy, but we have consensus on that. :-)
 
Cheers,
    Mike
On 6/8/06, Charles Clancy <clancy@cs.umd.edu > wrote:
For the record, personally I'm in favor of MUX headers.  While I agree
that QoS is an issue, I think NAT traversal is a bigger issue.

--
t. charles clancy, ph.d.  |  tcc@umd.edu  |   www.cs.umd.edu/~clancy


Dorothy.Gellert@nokia.com wrote:
>
> The CAPWAP editors have asked the Chairs to resolve the Mux vs Multiport
> issue # 115, in order to progress the specification.  Based on the
> discussion that has taken place the chairs are in agreement the
> simplest, cleanest solution for this is to add a Mux header.  Barring
> any unforseen events, we will instruct the editors resolve in favor of a
> new Mux header.
>
> We intend to close this issue by the end of the week, Friday, 6/9.
> Please review the issue and send any constructive comments to the list
> by Friday.
>
> Best Regards,
> Dorothy
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_25857_30003189.1149816879221-- --===============0168641833== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0168641833==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 08 23:10:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoXNz-0005vx-Bx for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 23:10:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoXHk-0007xU-Vm for capwap-archive@lists.ietf.org; Thu, 08 Jun 2006 23:03:47 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DAD56430122 for ; Thu, 8 Jun 2006 20:03:43 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E113543006C for ; Thu, 8 Jun 2006 20:03:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B80431448004 for ; Thu, 8 Jun 2006 20:03:20 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id CA5A2144801D for ; Thu, 8 Jun 2006 20:03:17 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 08 Jun 2006 20:03:17 -0700 X-IronPort-AV: i="4.05,221,1146466800"; d="scan'208"; a="291933683:sNHT41190688" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5933H7T014068; Thu, 8 Jun 2006 20:03:17 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5933Gke014805; Thu, 8 Jun 2006 20:03:16 -0700 (PDT) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 20:03:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Jun 2006 20:03:15 -0700 Message-ID: <08A9A3213527A6428774900A80DBD8D8020B0BD5@xmb-sjc-222.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New mux header for CAPWAP Thread-Index: AcaLVTh19aXR3iKmTZOOXclIJP63VAAG33hA From: "Nancy Winget (ncamwing)" To: "Scott G. Kelly" , , X-OriginalArrivalTime: 09 Jun 2006 03:03:16.0460 (UTC) FILETIME=[40FE22C0:01C68B71] Authentication-Results: sj-dkim-4.cisco.com; header.From=ncamwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Ah, but DTLS is instantiated with an application in mind and that is where the analysis becomes interesting....that is, how it is applied to the application, in our case, CAPWAP. I've no doubt you have a workable implementation, but implementation does not provide for good security or means to analyze the general security of the protocol. Nancy. -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: Thursday, June 08, 2006 4:43 PM To: Nancy Winget (ncamwing); Dorothy.Gellert@nokia.com; capwap@frascone.com Subject: RE: [Capwap] New mux header for CAPWAP Hi Nanciy, >I disagree....if it is independent of transport encapsulation then why >for example is it DTLS vs. TLS? We chose DTLS because it uses the UDP >model....we are now tweaking this by introducing the concept of a MUX. >Having lived through the WEP debacle, I am merely stating that there >may be repercusions that need further analysis. It is DTLS precisely because it is *not* dependent on the underlying transport, whereas TLS *is*. That's why TLS is not an option, but DTLS is. We chose DTLS because it uses the *connectionless* (or datagram) model - not UDP in particular. And adding a PDU type identifier is simply another layered datagram protocol. There are no security implications introduced by this modification. >I do not believe this is a non-existant issue, nor is it nonsense to >those trying to analyze the security behind CAPWAP. It is something >I'm highlighting as complicating the analysis....maybe not for you, but >it will to those analyzing the security of this. If you do such an analysis, I think you will find that one elegant feature of DTLS is that it does not matter what you wrap it in. It can be wrapped in connection-oriented or connectionless protocols, and it can even be multiplexed across both simultaneously - I have actually implemented this. It's very cool in that regard. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 01:05:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoZBe-0000p1-MS for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 01:05:34 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoZBb-0004e2-4i for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 01:05:34 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3C685430110 for ; Thu, 8 Jun 2006 22:05:30 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3F46E430071 for ; Thu, 8 Jun 2006 22:05:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 258601448025 for ; Thu, 8 Jun 2006 22:05:08 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 77B51144800C for ; Thu, 8 Jun 2006 22:05:05 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k59554tQ027573; Thu, 8 Jun 2006 22:05:04 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k59553Ef027563; Thu, 8 Jun 2006 22:05:04 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 8 Jun 2006 22:05:03 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Michael Montemurro In-Reply-To: <26140d940606081834r307e6785kc650feed165ae985@mail.gmail.com> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 HI, This is the 3rd or 4th message that has just not read my message from "Thu, 8 Jun 2006 01:47:21 -0700 (PDT)" with subject "[Capwap] Proposal for CAPWAP packet format": In it I showed the packet formats and made the following observation. NOTE: A CAPWAP MUX header is needed whether or not the same or different UDP ports are used for CAPWAP control and data messages. This is because both CAPWAP data and control messages can be unprotected or protected by DTLS, and the MUX header is needed to distinguish protected from unprotected. Remember that CAPWAP "discovery requests" and "discovery responses" are unprotected, and that all other CAPWAP control message types are protected. Also note that "deep packet inspection" is not needed. Whether it's a control or data packet isw simply a matter of looking at the second octet in the UDP data. Here is the updated version of what was called "MUX header" in the email, but is now called "CAPWAP Pkt Header" CAPWAP Pkt Header: 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version - the version of the CAPWAP protocol (the first is 0) DISCUSS: should this be split into major and minor, and if so, what are the implications of an increment of the major or minor part? Type - packet type, values are: 1 - CAPWAP Unprotected Data Packet 2 - CAPWAP DTLS Protected Data Packet 3 - CAPWAP Unprotected Control Packet 4 - CAPWAP DTLS Protected Control Packet 0,5-15 - reserved With this as the first two octets, it's pretty easy to do classification. So, it looks to me like there is an aweful lot of arguing over a false assumption. Can we do activities that result in forward progress? If the WG is not making progress, I'm sure the ADs will be happy to terminate the WG. On Thu, 8 Jun 2006, Michael Montemurro wrote: > First of all, I'd like to comment that one of the CAPWAP editors was not > even consulted on the request to the chairs to resolve this issue. :-( > > So basically, the MUX header makes NAT Traversal easier to support. The use > of separate UDP ports for control and data traffic allows for greater > flexibility for deployment and implementation. I think you could probably > argue back and forth on this one, but I don't see one option over the other > presenting a clear advantage. > > The only compelling reason I could think of to go with separate UDP ports is > that a network element classifying the packet does not have to read deep > into the packet to distinguish CAPWAP control from data. That might be an > advantage over a MUX if there are no security issues with exposing control > and data UDP ports. > > Based on my review of this email thread. I fail to see a clear consensus on > this issue. With that in mind, we really should consider a compromise > scenario which Scott documented as his third option in his email on May > 18th. That is, to quote him, "use multiple ports with separate data and > control channels, but when NAT is detected, do what IPsec does, i.e. shift > onto a single UDP channel, bundling control and data together; that is, have > an optional nat-t encapsulation mechanism.". > > In that way, everybody is unhappy, but we have consensus on that. :-) > > Cheers, > Mike > On 6/8/06, Charles Clancy wrote: > > > > For the record, personally I'm in favor of MUX headers. While I agree > > that QoS is an issue, I think NAT traversal is a bigger issue. > > > > -- > > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > > > > > Dorothy.Gellert@nokia.com wrote: > > > > > > The CAPWAP editors have asked the Chairs to resolve the Mux vs Multiport > > > > > issue # 115, in order to progress the specification. Based on the > > > discussion that has taken place the chairs are in agreement the > > > simplest, cleanest solution for this is to add a Mux header. Barring > > > any unforseen events, we will instruct the editors resolve in favor of a > > > new Mux header. > > > > > > We intend to close this issue by the end of the week, Friday, 6/9. > > > Please review the issue and send any constructive comments to the list > > > by Friday. > > > > > > Best Regards, > > > Dorothy Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 07:57:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FofcD-0007xF-CA for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 07:57:25 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FofcA-0002cU-LR for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 07:57:25 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 71DBF43011D for ; Fri, 9 Jun 2006 04:57:21 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D35B6430059 for ; Fri, 9 Jun 2006 04:56:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C36A4398028 for ; Fri, 9 Jun 2006 04:56:53 -0700 (PDT) Received: from exprod8og54.obsmtp.com (exprod8og54.obsmtp.com [64.18.3.90]) by zoidberg.tigertech.net (Postfix) with SMTP id D8E54398008 for ; Fri, 9 Jun 2006 04:56:47 -0700 (PDT) Received: from source ([151.145.63.124]) by exprod8ob54.obsmtp.com ([64.18.7.12]) with SMTP; Fri, 09 Jun 2006 04:56:47 PDT X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jun 2006 06:56:46 -0500 Message-ID: <89525CB1203D7346BBBDFCE9CECB47CF02B53A03@exchange-USR31> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New mux header for CAPWAP Thread-Index: AcaLXUidzuQtfl+pRIq1bgLyziB28AAXMjdg From: "Kraus, Michael" To: "Scott G. Kelly" , X-OriginalArrivalTime: 09 Jun 2006 11:56:46.0645 (UTC) FILETIME=[C88CBE50:01C68BBB] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=-0.001 tagged_above=-999 required=7 tests=SPF_HELO_PASS X-Spam-Level: Cc: Dorothy.Gellert@nokia.com Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Scott, Thanks for the response! In general, security/DoS concerns are not limited to the internet, but also to the LAN. This eminates from the fact there are more and more untrusted users on the LAN (outsourced support agreements, "guest wireless access", etc.) So, you can't necessarily trust all LAN segments. I feel this may be somewhat of a tangent, so I'll stop there. In general, I believe I understand your points, and agree that there are ways to accomplish all challenges I've described with using the mux header. For me, when you use the same port number, the AC/WTP would typically need to be involved to modify traffic flows (regardless of purpose: security, QoS, traffic engineering). If you use separate port number, you have the option to modify traffic flows by also [legacy lan] network infrastructure. I like to have the options, but can see how it would also be beneficial for the protocol to sacrifice that flexibility for simplicity of the protocol. All in all, I think that the WG has a good understanding of this issue from my perspective, so I have no further input. Thanks, Mike -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: Thursday, June 08, 2006 7:40 PM To: Kraus, Michael; capwap@frascone.com Cc: Bob O'Hara (boohara); pcalhoun@cisco.com; Dorothy.Gellert@nokia.com; s.kelly@ix.netcom.com Subject: Re: [Capwap] New mux header for CAPWAP Hi Michael, >Greetings! > >Before saying that going to a mux header is the simplest/cleanest, I >would suggest reviewing the original objectives of this WG. From 5.1.2 >of the >objectives: > >> Protocol Requirement: >> >> The CAPWAP Protocol MUST define transport control messages such that >> the transport of control messages is separate from the transport of >> data messages. > >How is transport defined? To me, a mux header merely identifies control vs. >data but does not provide a separate transport mechanism (more on this below). I looked at that objective some time ago and went through the same thought process, so I think I understand your concern. I think it's very important to recognize that virtually any protocol can be used as a transport - the Internet works for just this reason. Following is an example of a transport protocol: [ethernet][IP][UDP][data being transported] Here's another one: [ethernet][IP][UDP][PDU type][data being transported] >From the perspective of the application consuming the data, these are indistinguishable, assuming appropriate send/recv APIs are provided. Hence, strictly speaking, the objective you cite has been met. >> Motivation and Protocol Benefits: >> >> The aim of separating data and control aspects of the protocol is to >> simplify the protocol. > >This is where a MUX header makes sense, since it mitigates the NAT >traversal concern (rather than adding a keep alive type of >functionality, which would somewhat increase overhead/complexity). > >> It also allows for the flexibility of addressing each type of >> traffic in the >most appropriate manner. > >With a MUX header, the network devices will not be able to remark DSCP >values of data traffic, perform traffic engineering (policy-based >routing), or apply different security requirements. It sounds like we're talking about an enterprise LAN here. In any event, we know that all QoS bets are off if the Internet is one of the hops, so let's eliminate that from the discussion. And let's be clear here: the claim is that on an enterprise LAN, intermediate gear will need to remark DSCP values, and that it can *only* do this based on the UDP ports, that any deeper packet inspection is too expensive. We noted here earlier that a direct consequence of this is that the data channel would be an opaque blob to such a system, and the applications within it would be treated the same - they would have no QoS. In this case, you would essentially have two classes: control (the "haves") and data (" the have-nots"). This actually violates another objective in the same document you referred to. In any event, I don't think this is a realistic scenario, but even if it were, wouldn't this problem be better solved by using a different VLAN tag for the control packets than the data packets? > For security/DoS/network optimization, it does not always make sense >for control and data traffic for applications to take the same network >path, have the same access, and receive the same priority. By >requiring the same port, and a mux header the control and data traffic >must take the same network path. If manufacturers provide >classification within the WTP, this would help alleviate the QoS >concerns, but network traffic engineering/security is still a concern. Again, what network are we talking about here? When you mention security and DoS optimizations with respect to the wired network, I'm thinking the Internet may be involved - is that what you mean? > Deep packet inspection techniques >(NBAR) are slow in coming across vendors, slow in market adoption, and >complex/costly to implement. Proliferation of this technology/protocol >is dependent upon the cost effectiveness of the solution. Upgrading >access points to a CAPWAP solution provides some potential cost >savings, through centralized policy and management. But, if you say to >do it "right" you need to also upgrade your entire network >infrastructure to support deep packet inspection techniques, this >quickly becomes too costly of a solution to implement. Current project I'm working on, it costs roughly $3M to do all wireless access points. >But, to upgrade all network infrastructure to support NBAR, I'd is >estimate is at $40M. Some corners of the network here still have >10Base2 hubs! The reason >802.11 has been success is because it has been inexpensive, creating a >dependency of the wireless network on the wired network would hamper >further proliferation. I don't think you need to add fancy classification tools to make this work. I think the AC and WTP have all the information they need. But the fact is that if you *don't* have fancy classification tools, then any re-marking will either be a one-to-one mapping that favors control traffic, and ignores the QoS granularity requirements of the data. That can't really be good from an operational perspective, can it? >> Furthermore, this requirement will help remotely located WTPs to >> handle data traffic in alternative ways without the need for >> forwarding them across a wide network to the WLAN controller. > >WLAN Controller should be renamed to AC here. > >> Separation of WTP control and data also aids in the secure >> realization of shared WLAN deployments. > >Security should not be limited to whether the control data is being >encrypted, while the data may or may not be. It is more far reaching. >Perhaps you want to have an network segment act as a transit area for >control data, but not for data traffic. Logical network segmentation >of traffic for security (DoS) prevention is something that is present >in certain environments (especially manufacturing and high security). The same thing can be realized with vlan tagging, can't it? But if the only thing you have for realizing this is (an unauthenticated) tuple-based packet filter (or a vlan tag, for that matter), we don't really expect that to be *secure*, do we? I'm not sure exactly what was meant by this clause, but I think we need to be careful to avoid imparting a "scriptural" aura to the objectives document. >> Relation to Problem Statement: >> >> Broadly, this objective relates to the challenge of managing >> complexity in large-scale WLANs. The requirement for traffic >> separation simplifies control as this is separated from the task of >> data transport. > >The way I interpret this, by using a MUX header, a truly separate >transport of control and data messages cannot be fully realized. I can >see how it simplifies the protocol (NAT Traversal), so this does provide merit as a viable option. >However, if this is the path that is chosen, we lose some flexibility >(traffic engineering). I think that adding a capwap layer header (call it a PDU identifier, a capwap frame type, a mux header, whatever) is a separate transport layer, and meets the objective fully. I think we should be careful about loaded terms like "truly" in the same way as we should be careful not to assume the objectives document is scripture. Layering in this manner does not ignore this objective. >In conclusion, should a MUX header be chosen, I would suggest that the >objectives need to also be reviewed/updated to reflect that the spirit >of this protocol requirement has changed. In particular, stating that a >true separate transport for data and control messages are not going to >be achieved by this WG, but rather an internal identification of data >and control messages so that AC and WTPs can treat data and control messages differently. No need to modify it in any event - it's really a historical document. Scott The information transmitted (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is intended only for the person(s) or entity/entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 09:28:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foh2o-0000Aw-8a for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 09:28:58 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Foguc-00053E-6s for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 09:20:31 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 751D3430129 for ; Fri, 9 Jun 2006 06:20:29 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 9B63B430059 for ; Fri, 9 Jun 2006 06:20:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8B861398022 for ; Fri, 9 Jun 2006 06:20:10 -0700 (PDT) Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [204.127.192.84]) by zoidberg.tigertech.net (Postfix) with ESMTP id DD1C9398023 for ; Fri, 9 Jun 2006 06:20:06 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (rwcrmhc14) with ESMTP id <20060609132005m1400di25ge>; Fri, 9 Jun 2006 13:20:05 +0000 Message-ID: <44897585.4040008@hyperthought.com> Date: Fri, 09 Jun 2006 06:20:05 -0700 From: Scott G Kelly User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "Nancy Winget (ncamwing)" References: <08A9A3213527A6428774900A80DBD8D8020B0BD5@xmb-sjc-222.amer.cisco.com> In-Reply-To: <08A9A3213527A6428774900A80DBD8D8020B0BD5@xmb-sjc-222.amer.cisco.com> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi Nancy, Nancy Winget (ncamwing) wrote: > Ah, but DTLS is instantiated with an application in mind and that is > where the analysis becomes interesting....that is, how it is applied to > the application, in our case, CAPWAP. I've no doubt you have a workable > implementation, but implementation does not provide for good security or > means to analyze the general security of the protocol. Let's not debate what could or might be. Rather, please do your analysis and provide us with your results. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 09:32:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foh6P-0003Hg-Rb for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 09:32:41 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Foh6O-0006K7-8x for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 09:32:41 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E6AEA4300D6 for ; Fri, 9 Jun 2006 06:32:39 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B9BE0430059 for ; Fri, 9 Jun 2006 06:32:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A2EF81448023 for ; Fri, 9 Jun 2006 06:32:10 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id B443B1448004 for ; Fri, 9 Jun 2006 06:32:07 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 09 Jun 2006 06:32:07 -0700 X-IronPort-AV: i="4.05,224,1146466800"; d="scan'208"; a="1822869211:sNHT34796816" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k59DW6kK017268; Fri, 9 Jun 2006 06:32:06 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k59DW5Cw022026; Fri, 9 Jun 2006 06:32:06 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Jun 2006 06:31:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jun 2006 06:31:55 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202037BD2@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New mux header for CAPWAP Thread-Index: AcaLSCedt4YNtXMgSEOyobjL64fRnwAgNm7w From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" , "Rohit Suri (rsuri)" X-OriginalArrivalTime: 09 Jun 2006 13:31:57.0017 (UTC) FILETIME=[14325C90:01C68BC9] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc I don't believe this argument. It is being made to justify the MUX. The LWAPP protocol defined two UDP ports and no MUX. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Thursday, June 08, 2006 3:09 PM > To: Rohit Suri (rsuri) > Cc: capwap@frascone.com > Subject: Re: [Capwap] New mux header for CAPWAP > > HI, > > Did you see and understand the following from my message from > "Thu, 8 Jun 2006 01:47:21 -0700 (PDT)" with subject "[Capwap] > Proposal for CAPWAP packet format": > > NOTE: A CAPWAP MUX header is needed whether or not the same or > different UDP ports are used for CAPWAP control and > data messages. This is because both CAPWAP data and > control messages can be unprotected or protected by > DTLS, and the MUX header is needed to distinguish > protected from unprotected. Remember that CAPWAP > "discovery requests" and "discovery responses" are > unprotected, and that all other CAPWAP control > message types are protected. > > It does not look like it was factored into your argument. > > On Fri, 9 Jun 2006, Rohit Suri (rsuri) wrote: > > I have been reading through the conversations on this and I think > > there is a bigger issue that has not been considered. Not allowing > > separation of data and control plane by using easy to > recognize method > > such as UDP ports would restrict system scaling. Consider for the > > moment the fact that because we are bundling the channels into a > > single crypto stream, it will become impossible to separate > the control and data planes. > > > > I understand that this is not currently in the protocol, > the reality > > is that creating such a restriction today will dictate > future systems. > > The side effect I believe is being lost is that an AC can > only be as > > fast as a single DTLS crypto accelerator. As faster 802.11 > > technologies come around, such as 802.11n, there will be a need for > > bigger and faster systems. In order to solve this, we will in the > > future have to remove the MUX and allow for the separation. > > > > I think system scaling is much bigger issue than NAT, which can be > > addressed by adding an keepalive mechanism in the data > plane. We can > > also do this only when we detect a NAT is in play (look at outer IP > > address vs. a message element in the protocol). So we can have our > > cake and eat it too. > > > > Therefore, I personally feel very uncomfortable crippling future > > products to up front protocol development time. > > > > Regards > > Rohit > > Regards, > /david t. perkins > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 09:33:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foh7F-0003WI-Hl for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 09:33:33 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Foh7E-0006fo-4C for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 09:33:33 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BEB4143012B for ; Fri, 9 Jun 2006 06:33:31 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 973B54300D0 for ; Fri, 9 Jun 2006 06:32:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 89BBC398034 for ; Fri, 9 Jun 2006 06:32:23 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [12.129.211.51]) by zoidberg.tigertech.net (Postfix) with ESMTP id BF915398023 for ; Fri, 9 Jun 2006 06:32:20 -0700 (PDT) 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 <0J0L00C66HGNOO@usaga01-in.huawei.com> for capwap@frascone.com; Fri, 09 Jun 2006 06:29:12 -0700 (PDT) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0L00DTQHGM1N@usaga01-in.huawei.com> for capwap@frascone.com; Fri, 09 Jun 2006 06:29:11 -0700 (PDT) Received: from [172.24.1.24] (Forwarded-For: [10.18.7.115]) by szxmc01-in.huawei.com (mshttpd); Fri, 09 Jun 2006 18:32:17 +0500 Date: Fri, 09 Jun 2006 18:32:17 +0500 From: zhaoyujin 31390 To: "Pat Calhoun (pacalhou)" Message-id: <2533a1257bff.257bff2533a1@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-language: zh-CN Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: [Capwap] Issue 134 RE:RE: How to transmit 802.11 association packet to AC for Localmode X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 I find there is another issue 134 which is same as this problem. I suggestion there are two methods for this issue: 1. Based on Local MAC. The WTP device is parimary and AC is secondary. WTP finishes station 802.11 data link negotiation and notifies AC that the station succesfully negotiate 802.11 data link with WLAN. Based on this event notify, AC can create data forwarding table for station. This is mentioned in issue 134. 2. Can we change the Local MAC architecture? Define a new control message for transmitting 802.11 association and authentication frames to AC. The association and authenticaiton process is on AC same as split MAC. If design like this, CAPWAP data tunnel will be simplicity which will be easy to be supported by Hardware. Best regards Michael From: "Pat Calhoun (pacalhou)" Subject: RE: [Capwap] How to transmit 802.11 association packet to AC for Localmode > That's a good question. The protocol must allow for 802.3 data frames, > or 802.11 management frames. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: zhaoyujin 31390 [zhaoyujin@huawei.com] > > Sent: Wednesday, June 07, 2006 4:51 AM > > To: capwap@frascone.com > > Subject: [Capwap] How to transmit 802.11 association packet > > to AC for Localmode > > > > Dear all: > > > > In section "11.1.2 Local MAC" defines Local MAC mode > architecture.> > > And in figure 6 has next process and description: > > > > 802.11 Association > > <---------------------------( - > > )-------------------------> > > Add Mobile (Clear Text, 802.1X Only) > > > > <-------------------------> > > > > o The WTP forwards the 802.11 Authentication and > > Association frames > > to the AC, which is responsible for responding to the client. > > > > Because CAPWAP data tunnel maybe only transmit 802.3 frames > > for Local MAC mode, I cannot understand how to transmit > > 802.11 association frames to AC. > > > > Best regards > > Michael > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 09:48:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FohLg-0005t6-PK for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 09:48:28 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FohLf-0000QU-56 for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 09:48:28 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C9E7643011E for ; Fri, 9 Jun 2006 06:48:26 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id DA7FE430059 for ; Fri, 9 Jun 2006 06:47:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C17461448006 for ; Fri, 9 Jun 2006 06:47:58 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id C3E4F1448009 for ; Fri, 9 Jun 2006 06:47:56 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 09 Jun 2006 06:47:55 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k59DltrQ003556; Fri, 9 Jun 2006 06:47:55 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k59Dls9s003973; Fri, 9 Jun 2006 06:47:55 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Jun 2006 06:47:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jun 2006 06:47:53 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202037BD9@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New mux header for CAPWAP Thread-Index: AcaLS6BI+C/aYU+lTpCLKk7D/pBHfgAfa4pQ From: "Pat Calhoun (pacalhou)" To: "Scott G. Kelly" , "Rohit Suri (rsuri)" , "Charles Clancy" , X-OriginalArrivalTime: 09 Jun 2006 13:47:54.0506 (UTC) FILETIME=[4EE796A0:01C68BCB] Authentication-Results: sj-dkim-3.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Thanks for the clarification, Scott. That is helpful. Let me ask a separate question. The protocol currently allows the CAPWAP control and data flows to be sent to separate devices. While I admit that the protocol isn't complete in this area, and is probably something that would need to be worked out in a future version of the CAPWAP protocol. However, the MUX implies (at least to me) that the destination of both the control and the data plane MUST terminate on the same device. This is particularly troubling as 802.11N is coming our next year, and if one believes that APs will be able to deliver up to 400Mbps, then scaling will quickly become a problem. As service providers and large enterprises deploy this technology, the expectations of a high AP count supported on an AC (with minimal oversubscription) will become expected, but I feel we are creating a protocol that forces vendors to make changes to the protocol that pushes it in way that it isn't compatible with the specification in order to deal with the market expectations. I think this expands on the scaling issues raised by Rohit. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > Sent: Thursday, June 08, 2006 3:33 PM > To: Rohit Suri (rsuri); Charles Clancy; Dorothy.Gellert@nokia.com > Cc: capwap@frascone.com > Subject: Re: [Capwap] New mux header for CAPWAP > > Hi Rohit! > > >I have been reading through the conversations on this and I > think there > >is a bigger issue that has not been considered. Not allowing > separation > >of data and control plane by using easy to recognize method > such as UDP > >ports would restrict system scaling. Consider for the moment > the fact > >that because we are bundling the channels into a single > crypto stream, > >it will become impossible to separate the control and data planes. > > I think you may have misunderstood: the data and control > channels will not be bundled into a single crypto stream (not > ever, in my view). Even if someone implements data channel > encryption, it will almost certainly have to be independent > of control channel encryption in all cases. My gut feeling is > that there would be serious operational issues otherwise in > terms of anti-replay and other channel interactions. I > suppose it's possible that there is *some* scenario where you > could combine the two - but I don't currentlly believe this > could be done in general for capwap. > > > I understand that this is not currently in the protocol, > the reality > >is that creating such a restriction today will dictate > future systems. > >The side effect I believe is being lost is that an AC can only be as > >fast as a single DTLS crypto accelerator. As faster 802.11 > technologies > >come around, such as 802.11n, there will be a need for bigger and > >faster systems. In order to solve this, we will in the > future have to > >remove the MUX and allow for the separation. > > Like I said, the channels won't be bundled together. Also, > this and previous posts make me think there's a fundamental > misunderstanding about DTLS. This is really important to > understand: DTLS does not care what sort of transport is > underneath. It is oblivious to whether it runs over UDP, GRE, > TCP, SMTP (yes, you could even send dtls records in emails), > or CAPWAP... whatever. It is completely transport-agnostic. > > That means you could multiplex virtually any number of DTLS > sessions over the same transport session (e.g. using the same > UDP port), and then demultiplex them at the receiving side. > This is true whether your transport is UDP or even ethernet, > for that matter. > > Any DTLS crypto accelerator will have to be able to handle > mutliple simultaneous DTLS sessions (just like SSL/TLS > accelerators). Some will be capable of doing their own > session lookup based on the record header, but even for the > cheapest ones (which ostensibly would not be used in high end > systems), it is a simple matter for the receiving AC to > distribute independent dtls streams to parallel crypto > accelerators, and contrary to what we've heard on this list, > software, fpga's, and network processors are all well-suited > to and commonly used for such tasks. Also, FPGAs and network > processors which can be used for this purpose are commonly > included in ACs available on the market today. > > >I think system scaling is much bigger issue than NAT, which can be > >addressed by adding an keepalive mechanism in the data plane. We can > >also do this only when we detect a NAT is in play (look at outer IP > >address vs. a message element in the protocol). So we can > have our cake > >and eat it too. > > > >Therefore, I personally feel very uncomfortable crippling future > >products to up front protocol development time. > > I don't know. I get the impression that what we are actually > being asked is to cripple the protocol in order to match up > with past products (i.e. those legacy switching products that > can only classify based on ports). I must admit, I'm kind of > surprised by such arguments, given the rich classification > capabilities described by NBAR. > > Anyway, I don't think there really are scaling issues, unless > we are constrained to combining AC functionality with legacy > switching gear. Otherwise, there is nothing to prevent us > from building systems which meet our needs as throughput > climbs. And as someone else pointed out in a related > discussion, "the purpose of capwap is not to make > cheaper" - I substituted ACs for APs, but I don't think > anything is lost in translation. > > Scott > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 09:55:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FohSb-00024H-Ju for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 09:55:37 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FohSa-00022K-UQ for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 09:55:37 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E320D4300C6 for ; Fri, 9 Jun 2006 06:55:35 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3F5DE430059 for ; Fri, 9 Jun 2006 06:55:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 30104398041 for ; Fri, 9 Jun 2006 06:55:09 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id 24B7039802B for ; Fri, 9 Jun 2006 06:55:05 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 09 Jun 2006 06:55:05 -0700 X-IronPort-AV: i="4.05,224,1146466800"; d="scan'208"; a="1822885751:sNHT268966726" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k59Dt53O031609; Fri, 9 Jun 2006 06:55:05 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k59Dt59s009148; Fri, 9 Jun 2006 06:55:05 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Jun 2006 06:55:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jun 2006 06:55:04 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202037BDD@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Encryption Capabilities Thread-Index: AcaKl+3pdBE3N9zERhWnU+ICmwmPngAiCm3gACrTz6A= From: "Pat Calhoun (pacalhou)" To: "Nancy Winget (ncamwing)" , "Scott G. Kelly" , "capwap" X-OriginalArrivalTime: 09 Jun 2006 13:55:05.0461 (UTC) FILETIME=[4FC61A50:01C68BCC] Authentication-Results: sj-dkim-4.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a I agree with Nancy. It's almost like CAPWAP products would need to ship a "security requirements table", and allow the customer to pick and choose from what they think they need, and then enable the various features. Why not simply support a single mechanism that is a superset of all features and call it a day? We seem to be contradicting ourselves here. In some threads we are arguing for protocol simplicity, then in others we seem to accept complexity (and, yes, I view multiple options that provide similar features are adding complexity, because in the end we all have to implement them, and leave it to the customer to deal with the issue). To date, other than stating that "we need to support it", no one has been able to state how 802.11i packet encryption services in the AC allows an AC/WTP to actually support the complete 802.11 protocol. However, the MUX issue has raised another interesting problem, which was raised by Scott, which is that in order for the WTP to perform packet classification, and tagging, it needs to have access to the data frames in the clear, which is not possible with this feature. so I see this as just adding yet another option for end users to deal with. BTW, if we need the WTP to do packet classification, we need to create a new issue because the protocol does not have the means to push down rules. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Nancy Winget (ncamwing) > Sent: Thursday, June 08, 2006 3:38 PM > To: Scott G. Kelly; capwap > Subject: Re: [Capwap] Encryption Capabilities > > While it is true that the originating 802.11 data payload > will be obscured, it is not clear to me that we can construe > it as "good". > Since there is no protection of the CAPWAP encapsulation, it > is still susceptible to attack, as is the entire CAPWAP > encapsulation (should we choose not to protect it). Thus, in > my view, it does not help a whole lot. Sure, if we believe > the system is uncompromised then you are correct that the > data is not readily discernible but can we trust that the > data has not been compromised anyway? No, not until it has > gone up to the AC and by that point, it is not clear whether > the attack occurred at the link between STA and WTP or WTP to AC. > > Nancy. > > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > Sent: Wednesday, June 07, 2006 6:07 PM > To: capwap > Subject: Re: [Capwap] Encryption Capabilities > > I've been watching this debate with some interest, being > quite surprised that an optional feature would suddenly draw > such attention and energy. > > Still, I guess I should comment along with everyone else. > First, I agree with Charles on the point that having or not > having this feature has no impact on the security properties > of the capwap protocol itself. Also, I agree with a number of > folks on the point that these two features are orthogonal. AC > termination of 802.11 link security does not (indeed, is not > intended to) provide for capwap data channel security. > However, this feature is not security-neutral - it provides a > unique set of security properties that are useful. Before > explaining further, here are some pictures, along with some > descriptive text (hoping my webmail interface doesn't mangle them): > > KEY > --- > # - 802.11 link security boundary > > % - capwap security boundary > > > > Case 1: 802.11 link security terminates at the WTP > > ##################### > # # %%%%%%%%%%%%%%%%%%%%%%% > # +------+ +#--%-+ CAPWAP +----+ % > # |client|---------| WTP |===========| AC | % > # +------+ +#--%-+ +----+ % > # # %%%%%%%%%%%%%%%%%%%%%%% > ##################### > > > This is the situation when you en/decrypt 802.11 traffic at > the WTP. In this case, the client and WTP are within the > 802.11 link security boundary. Of course, this picture does > not include key establishment, because during that phase, the > security boundary is more like the one below, and also, the > AAA server (not pictured) is involved. Also, one might choose > to include the AC in the 802.11 link security boundary > pictured above (even though it doesn't participate in the > crypto ops) because it is privy to the 802.11 keying > material, but I'm leaving this out because it simplifies the > ascii drawing, and will add nothing material to the discussion below. > > > Case 2: 802.11 link security terminates at the AC > > > %%%%%%%%%%%%%%%%% > % +-----+ % > /-----------------%--| WTP | % > | % +--++-+ % > | % ||capwap % > | % || % > | % +---++--+ % > | % | | % > | %%%%%%%%%%%%%%%%% > ##############|############################### > # +------+ | | AC | # > # |client|----/ 802.11 | | # > # +------+ +-------+ # > ############################################## > > > Here is the case when you en/decrypt 802.11 at the AC. Note > that the WTP is not within the 802.11 link security boundary. > It is "out of the loop", so to speak, being little more than > a transport provider. Also note that the capwap security > boundary is the same as for case 1 - no change. > > Now, let's get to the questions about whether this is useful > or not, and let's keep in mind that since this is an > *optional* feature, the "burden of proof" with respect to > utility is much lower than it would be if it were mandatory > to implement. > > As noted above, in case 2, the WTP is simply a transport > provider. That means that if the WTP were somehow > compromised, unless the attacker also compromised one or more > of the other security mechanisms as well (802.1x, the AC's > credential, etc), he could do little more than effect a DoS attack. > > In case 1, various methods of WTP compromise could give an > attacker access to the data as it is unencrypted and then > re-encrypted. In this case, the attacker gets access to the > cleartext data via relatively low-cost methods (compared to > breaking .11 crypto), essentially attacking the weakest link. > > In case 2, WTP's can be deployed in hostile territory, and if > the attacker can't break the 802.11 crypto, he can't have the > same security impact (aside from DoS, which he can have in > any event). It's like running 802.11 security over the air - > he has to break the crypto. No matter how completely the > attacker might compromise a WTP, all he will see is encrypted > data. This is good! > > Of course, there is additional value to the centralized > encryption model, as Dorothy Stanley pointed out: > architectural flexibility, enabling CAPWAP compliant > solutions to centralize the 802.11i crypto functions in the > AC if they wish, reducing dependencies on WTP capabilities > (e.g. legacy hardware that only supports TKIP), potentially > support a broader range of existing and future applications > - even when the primary motivation is not 'to secure the > WTP-AC data connection'". Some vendors chose this approach to > MAC splitting while others chose encryption at the WTP. > That's one reason why it should remain optional. > > --Scott > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 10:18:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fohoi-000053-BL for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 10:18:28 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fohof-00048m-UH for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 10:18:28 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 363A34300E0 for ; Fri, 9 Jun 2006 07:18:25 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 72691430059 for ; Fri, 9 Jun 2006 07:18:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 592D539802B for ; Fri, 9 Jun 2006 07:18:05 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.152]) by zoidberg.tigertech.net (Postfix) with ESMTP id A122E39802F for ; Fri, 9 Jun 2006 07:18:02 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (rwcrmhc12) with ESMTP id <20060609141801m1200o73jje>; Fri, 9 Jun 2006 14:18:02 +0000 Message-ID: <44898318.3040608@hyperthought.com> Date: Fri, 09 Jun 2006 07:18:00 -0700 From: Scott G Kelly User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <4FF84B0BC277FF45AA27FE969DD956A202037BD9@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A202037BD9@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi Pat, Pat Calhoun (pacalhou) wrote: > Thanks for the clarification, Scott. That is helpful. Let me ask a > separate > question. The protocol currently allows the CAPWAP control and data > flows > to be sent to separate devices. While I admit that the protocol isn't > complete > in this area, and is probably something that would need to be worked out > in > a future version of the CAPWAP protocol. > > However, the MUX implies (at least to me) that the destination of both > the > control and the data plane MUST terminate on the same device. This is > particularly > troubling as 802.11N is coming our next year, and if one believes that > APs > will be able to deliver up to 400Mbps, then scaling will quickly become > a > problem. I don't see how this is implied. Assuming you had the backend signalling in place, I think the two cases are equivalent. Am I missing something? Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 10:21:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FohrD-0000AL-7l for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 10:21:03 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FohrB-0004DQ-R5 for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 10:21:03 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 59160430121 for ; Fri, 9 Jun 2006 07:21:01 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 07B4343006D for ; Fri, 9 Jun 2006 07:20:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id EABD8398028 for ; Fri, 9 Jun 2006 07:20:37 -0700 (PDT) Received: from mgw-ext12.nokia.com (mgw-ext12.nokia.com [131.228.20.171]) by zoidberg.tigertech.net (Postfix) with ESMTP id EE4BE398023 for ; Fri, 9 Jun 2006 07:20:34 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k59EKTrp032561; Fri, 9 Jun 2006 17:20:31 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 17:20:30 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 09:20:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jun 2006 07:20:24 -0700 Message-ID: <8A76136424391244A5CF01653370853701AD3A4F@mvebe101.NOE.Nokia.com> In-Reply-To: <44897585.4040008@hyperthought.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New mux header for CAPWAP Thread-Index: AcaLyKVmWTXVEnKLTfGTYc9wK1pPhQABkehQ From: To: , X-OriginalArrivalTime: 09 Jun 2006 14:20:27.0461 (UTC) FILETIME=[DAF4DF50:01C68BCF] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.178 tagged_above=-999 required=7 tests=NO_REAL_NAME X-Spam-Level: Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Hi Scott, Did you see any trouble with control frames having high(er) latency when running several VoIP calls through the WTPs with the MUX? Best Regards, Michael -----Original Message----- From: ext Scott G Kelly [mailto:scott@hyperthought.com] Sent: Friday, June 09, 2006 6:20 AM To: Nancy Winget (ncamwing) Cc: capwap@frascone.com; Gellert Dorothy (Nokia-ES/MtView) Subject: Re: [Capwap] New mux header for CAPWAP Hi Nancy, Nancy Winget (ncamwing) wrote: > Ah, but DTLS is instantiated with an application in mind and that is > where the analysis becomes interesting....that is, how it is applied > to the application, in our case, CAPWAP. I've no doubt you have a > workable implementation, but implementation does not provide for good > security or means to analyze the general security of the protocol. Let's not debate what could or might be. Rather, please do your analysis and provide us with your results. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 11:19:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoilW-0006mZ-17 for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 11:19:14 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoilU-0003PL-Ig for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 11:19:14 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7DFA443011B for ; Fri, 9 Jun 2006 08:19:11 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B2FA1430085 for ; Fri, 9 Jun 2006 08:18:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9076E1448030 for ; Fri, 9 Jun 2006 08:18:10 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 292B51448023 for ; Fri, 9 Jun 2006 08:18:03 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k59FI35L011719; Fri, 9 Jun 2006 08:18:03 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k59FI3hl011716; Fri, 9 Jun 2006 08:18:03 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 9 Jun 2006 08:18:03 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A202037BD2@xmb-sjc-235.amer.cisco.com> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 HI, LWAPP (and SNMPv3, which I know quite well) don't have a packet header to distingush between protected and unprotected payloads because the payload type is outside the encrypted portion. In CAPWAP, the use of DTLS has the packet type in the encrypted portion, and thus a packet header is needed before the encrypted portion that specifies what follows. I thought this was quite clear with the diagrams. Could you provide some suggestions to the disagrams or the packet formats that I sent in the mail message to help make sure that this is clear. Regards, /david t. perkins On Fri, 9 Jun 2006, Pat Calhoun (pacalhou) wrote: > I don't believe this argument. It is being made to justify > the MUX. The LWAPP protocol defined two UDP ports and no > MUX. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > Sent: Thursday, June 08, 2006 3:09 PM > > To: Rohit Suri (rsuri) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] New mux header for CAPWAP > > > > HI, > > > > Did you see and understand the following from my message from > > "Thu, 8 Jun 2006 01:47:21 -0700 (PDT)" with subject "[Capwap] > > Proposal for CAPWAP packet format": > > > > NOTE: A CAPWAP MUX header is needed whether or not the same or > > different UDP ports are used for CAPWAP control and > > data messages. This is because both CAPWAP data and > > control messages can be unprotected or protected by > > DTLS, and the MUX header is needed to distinguish > > protected from unprotected. Remember that CAPWAP > > "discovery requests" and "discovery responses" are > > unprotected, and that all other CAPWAP control > > message types are protected. > > > > It does not look like it was factored into your argument. > > > > On Fri, 9 Jun 2006, Rohit Suri (rsuri) wrote: > > > I have been reading through the conversations on this and I think > > > there is a bigger issue that has not been considered. Not allowing > > > separation of data and control plane by using easy to > > recognize method > > > such as UDP ports would restrict system scaling. Consider for the > > > moment the fact that because we are bundling the channels into a > > > single crypto stream, it will become impossible to separate > > the control and data planes. > > > > > > I understand that this is not currently in the protocol, > > the reality > > > is that creating such a restriction today will dictate > > future systems. > > > The side effect I believe is being lost is that an AC can > > only be as > > > fast as a single DTLS crypto accelerator. As faster 802.11 > > > technologies come around, such as 802.11n, there will be a need for > > > bigger and faster systems. In order to solve this, we will in the > > > future have to remove the MUX and allow for the separation. > > > > > > I think system scaling is much bigger issue than NAT, which can be > > > addressed by adding an keepalive mechanism in the data > > plane. We can > > > also do this only when we detect a NAT is in play (look at outer IP > > > address vs. a message element in the protocol). So we can have our > > > cake and eat it too. > > > > > > Therefore, I personally feel very uncomfortable crippling future > > > products to up front protocol development time. > > > > > > Regards > > > Rohit > > > > Regards, > > /david t. perkins > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 11:34:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foj0M-0001Id-Ra for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 11:34:34 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Foj0L-0004YP-7j for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 11:34:34 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BB7F14300FE for ; Fri, 9 Jun 2006 08:34:32 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 78E14430059 for ; Fri, 9 Jun 2006 08:34:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 58CB4144802A for ; Fri, 9 Jun 2006 08:34:08 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by hermes.tigertech.net (Postfix) with ESMTP id 4AC281448023 for ; Fri, 9 Jun 2006 08:34:06 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 09 Jun 2006 08:34:07 -0700 X-IronPort-AV: i="4.05,224,1146466800"; d="scan'208"; a="324660406:sNHT33919728" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k59FY5L8003636; Fri, 9 Jun 2006 08:34:05 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k59FY5kg008452; Fri, 9 Jun 2006 08:34:05 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Jun 2006 08:34:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jun 2006 08:34:03 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202037C16@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New mux header for CAPWAP Thread-Index: AcaL1+ea52HtMmYORe6GX+Tp4hjP9gAANxfw From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" X-OriginalArrivalTime: 09 Jun 2006 15:34:04.0699 (UTC) FILETIME=[23D5E6B0:01C68BDA] Authentication-Results: sj-dkim-3.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Dave, The proposal you have made relies on a bit in the header, but the issue here is that the CAPWAP header is actually encrypted when DTLS is on - so I don't see how we can rely on that bit. Perhaps I am missing something fundamental in your point, though, and if so I apologize in advance. What I've been trying to state is that UDP *is* a multiplexor technology. We already have a method of differentiating the control and/or data using UDP. My revised diagram: CAPWAP Pkt Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP Header | DTLS Header | CAPWAP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ *optional header* What confuses me at this point is that if UDP can provide the exact same functions as the MUX header, why is Scott stating that DTLS can run over any arbitrary underlying transport without any complexity - yet is pushing back that doing this over two UDP ports is complex? The only issue that I am aware of that is additional complexity with dual ports is the have some form of keepalive on the data plane to handle NATed environments. This Is a very simply problem to solve. Otherwise, to Scott's point, DTLS doesn't care what it runs over. Hence my confusion. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Friday, June 09, 2006 8:18 AM > To: Pat Calhoun (pacalhou) > Cc: Rohit Suri (rsuri); capwap@frascone.com > Subject: RE: [Capwap] New mux header for CAPWAP > > HI, > > LWAPP (and SNMPv3, which I know quite well) don't have a > packet header to distingush between protected and unprotected > payloads because the payload type is outside the encrypted > portion. In CAPWAP, the use of DTLS has the packet type in > the encrypted portion, and thus a packet header is needed > before the encrypted portion that specifies what follows. > > I thought this was quite clear with the diagrams. > Could you provide some suggestions to the disagrams or the > packet formats that I sent in the mail message to help make > sure that this is clear. > > Regards, > /david t. perkins > > On Fri, 9 Jun 2006, Pat Calhoun (pacalhou) wrote: > > > I don't believe this argument. It is being made to justify the MUX. > > The LWAPP protocol defined two UDP ports and no MUX. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > -----Original Message----- > > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > > Sent: Thursday, June 08, 2006 3:09 PM > > > To: Rohit Suri (rsuri) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] New mux header for CAPWAP > > > > > > HI, > > > > > > Did you see and understand the following from my message > from "Thu, > > > 8 Jun 2006 01:47:21 -0700 (PDT)" with subject "[Capwap] > Proposal for > > > CAPWAP packet format": > > > > > > NOTE: A CAPWAP MUX header is needed whether or not the same or > > > different UDP ports are used for CAPWAP control and > > > data messages. This is because both CAPWAP data and > > > control messages can be unprotected or protected by > > > DTLS, and the MUX header is needed to distinguish > > > protected from unprotected. Remember that CAPWAP > > > "discovery requests" and "discovery responses" are > > > unprotected, and that all other CAPWAP control > > > message types are protected. > > > > > > It does not look like it was factored into your argument. > > > > > > On Fri, 9 Jun 2006, Rohit Suri (rsuri) wrote: > > > > I have been reading through the conversations on this > and I think > > > > there is a bigger issue that has not been considered. > Not allowing > > > > separation of data and control plane by using easy to > > > recognize method > > > > such as UDP ports would restrict system scaling. > Consider for the > > > > moment the fact that because we are bundling the > channels into a > > > > single crypto stream, it will become impossible to separate > > > the control and data planes. > > > > > > > > I understand that this is not currently in the protocol, > > > the reality > > > > is that creating such a restriction today will dictate > > > future systems. > > > > The side effect I believe is being lost is that an AC can > > > only be as > > > > fast as a single DTLS crypto accelerator. As faster 802.11 > > > > technologies come around, such as 802.11n, there will be a need > > > > for bigger and faster systems. In order to solve this, > we will in > > > > the future have to remove the MUX and allow for the separation. > > > > > > > > I think system scaling is much bigger issue than NAT, > which can be > > > > addressed by adding an keepalive mechanism in the data > > > plane. We can > > > > also do this only when we detect a NAT is in play (look > at outer > > > > IP address vs. a message element in the protocol). So > we can have > > > > our cake and eat it too. > > > > > > > > Therefore, I personally feel very uncomfortable > crippling future > > > > products to up front protocol development time. > > > > > > > > Regards > > > > Rohit > > > > > > Regards, > > > /david t. perkins > > > > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 11:44:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FojAG-0003cV-Ny for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 11:44:48 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FojAE-0005y1-9X for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 11:44:48 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E637D430121 for ; Fri, 9 Jun 2006 08:44:45 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A9E4B430085 for ; Fri, 9 Jun 2006 08:44:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 94F47398023 for ; Fri, 9 Jun 2006 08:44:23 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8B525398041 for ; Fri, 9 Jun 2006 08:44:19 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k59FiDQp019104; Fri, 9 Jun 2006 08:44:13 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k59FiCmI019100; Fri, 9 Jun 2006 08:44:13 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 9 Jun 2006 08:44:12 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A202037BD9@xmb-sjc-235.amer.cisco.com> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac HI, On the below..... First, I believe the packet diagrams show quite clearly that a packet header is needed to distingush between a protected and unprotected payload. This is independent from the transport address used on data vs control traffic. Secondly, I sent out email sometime back that compared a localMAC to a splitMAC (where the splitMAC uses a different transport for control and data). I think this was not understood. The issue is that when you put in the instrumentation for the user traffic (with the plan of making the attributes available via an SNMP agent on the AC), where do you put the instrumentation. If the instrumentation is NOT on the AC, then you have to provide a mechanism for the values generated by the instrumentation to be transported to the AC. The CAPWAP protocol supports transportation of values from WTPs to ACs. However, it doesn't currently have a mechanism to transport the values for the termination of a arbitary transport endpoint of a "data tunnel". Thus, to support both localMAC and splitMAC(where the the data tunnel is terminated at a transport different than the control transport), we need to define additional message elements transport the values from instrumentation in WTPs. On Fri, 9 Jun 2006, Pat Calhoun (pacalhou) wrote: > Thanks for the clarification, Scott. That is helpful. Let me ask a > separate > question. The protocol currently allows the CAPWAP control and data > flows > to be sent to separate devices. While I admit that the protocol isn't > complete > in this area, and is probably something that would need to be worked out > in > a future version of the CAPWAP protocol. > > However, the MUX implies (at least to me) that the destination of both > the > control and the data plane MUST terminate on the same device. This is > particularly > troubling as 802.11N is coming our next year, and if one believes that > APs > will be able to deliver up to 400Mbps, then scaling will quickly become > a > problem. > > As service providers and large enterprises deploy this technology, the > expectations > of a high AP count supported on an AC (with minimal oversubscription) > will become expected, but I feel we are creating a protocol that forces > vendors > to make changes to the protocol that pushes it in way that it isn't > compatible with > the specification in order to deal with the market expectations. > > I think this expands on the scaling issues raised by Rohit. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 11:47:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FojCV-0004ch-78 for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 11:47:07 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FojCT-0006VJ-Lp for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 11:47:07 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5171543011E for ; Fri, 9 Jun 2006 08:47:05 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 0C40F43006D for ; Fri, 9 Jun 2006 08:46:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CCA381448029 for ; Fri, 9 Jun 2006 08:46:41 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id 08F2A1448023 for ; Fri, 9 Jun 2006 08:46:37 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 09 Jun 2006 08:46:38 -0700 X-IronPort-AV: i="4.05,224,1146466800"; d="scan'208"; a="1822953973:sNHT33436516" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k59Fkblg013728; Fri, 9 Jun 2006 08:46:37 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k59Fkb9s018283; Fri, 9 Jun 2006 08:46:37 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Jun 2006 08:46:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jun 2006 08:46:35 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202037C22@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New mux header for CAPWAP Thread-Index: AcaLz5W2xhYiU32xSp6gbJjsRdBx6wACpRug From: "Pat Calhoun (pacalhou)" To: "Scott G Kelly" X-OriginalArrivalTime: 09 Jun 2006 15:46:37.0205 (UTC) FILETIME=[E45D3450:01C68BDB] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db > I don't see how this is implied. Assuming you had the backend > signalling in place, I think the two cases are equivalent. Am > I missing something? I am pulling some text from a previous post you had sent, which implies that both control and data MUST terminate on the same system, which is the point I tried to make in my scaling argument. I presume your assessment that one cannot split them up remains. > If we go with separate ports, there are a number of unpleasant consequences: > - there will certainly be issues with NAT traversal; you now need to > run keepalives over two channels, and even at that, the behavior will > not be deterministic; busy NAT devices throw out existing dgram sessions > when they need the resources, and this will result in one channel up, and > one down; Which I claim is really not that hard to provide. We can define a NULL 802.11 packet, for instance - or even something more generic by defining a bit in the header. This is really trivial. > - channel binding is ambiguous; it is not clear what data channel goes > with what control channel unless we add explicit signalling, and this > adds considerable complexity to the protocol. This point you had previously made specifically states that one cannot separate both the control and the data channel. This said, this is also not not very complex to deal with. A WTP has a specific MAC address, called a BSSID, which is present in the CAPWAP header, and is used to perform the correlation between the control and data plane. > - all of the added corner and race conditions and error handling requirements > add *significant* complexity to the state machines in both ends of the > connection. That's bad. I think it wouldn't hurt to go through the exercise to determine exactly what this really means so we can all be on the same page. Right now we have no concrete proof this is true. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Scott G Kelly [mailto:scott@hyperthought.com] > Sent: Friday, June 09, 2006 7:18 AM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com; Dorothy.Gellert@nokia.com > Subject: Re: [Capwap] New mux header for CAPWAP > > Hi Pat, > > Pat Calhoun (pacalhou) wrote: > > Thanks for the clarification, Scott. That is helpful. Let me ask a > > separate question. The protocol currently allows the CAPWAP control > > and data flows to be sent to separate devices. While I > admit that the > > protocol isn't complete in this area, and is probably > something that > > would need to be worked out in a future version of the CAPWAP > > protocol. > > > > However, the MUX implies (at least to me) that the > destination of both > > the control and the data plane MUST terminate on the same > device. This > > is particularly troubling as 802.11N is coming our next > year, and if > > one believes that APs will be able to deliver up to 400Mbps, then > > scaling will quickly become a problem. > > > Scott > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 11:59:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FojOl-00029e-Sr for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 11:59:47 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FojOk-0008Os-CH for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 11:59:47 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9DF1343010B for ; Fri, 9 Jun 2006 08:59:45 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2799143006D for ; Fri, 9 Jun 2006 08:59:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CA677144800A for ; Fri, 9 Jun 2006 08:59:22 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id DB6051448029 for ; Fri, 9 Jun 2006 08:59:20 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k59FxKEg023522; Fri, 9 Jun 2006 08:59:20 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k59FxJYo023513; Fri, 9 Jun 2006 08:59:19 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 9 Jun 2006 08:59:19 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A202037C16@xmb-sjc-235.amer.cisco.com> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede HI, Thanks for the note. It looks like what you are calling CAPWAP Pkt header differs from my use of that term. Here are my diagrams.... CAPWAP Packet formats: CAPWAP Unprotected Data Packet: +-----------------------------------------+ | IP | UDP | CAPWAP | CAPWAP | Wireless | | Hdr | Hdr | Pkt | Data | Payload | | | | Hdr | Hdr | | +-----------------------------------------+ CAPWAP DTLS Protected Data Packet: +-----------------------------------------------------------+ | IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS | | Hdr | Hdr | Pkt | Hdr | Data | Payload | Trailer | | | | Hdr | | Hdr | | | +-----------------------------------------------------------+ \--integrity checked---------/ \--encrypted-------------------/ CAPWAP Unprotected Control Packet: +------------------------------------------+ | IP | UDP | CAPWAP | CAPWAP | Message | | Hdr | Hdr | Pkt | Control | Elements | | | | Hdr | Hdr | | +------------------------------------------+ CAPWAP DTLS Protected Control Packet: +----------------------------------------------------------+ | IP | UDP | CAPWAP | DTLS | CAPWAP | Message | DTLS | | Hdr | Hdr | Pkt | Hdr | Control | Elements | Trailer | | | | Hdr | | Hdr | | | +----------------------------------------------------------+ \--integrity checked-------/ \--encrypted-------------------/ As you can see above there is ALWAYs a 2 octet "CAPWAP Pkt Hdr" in EVERY CAPWAP packet. The format is: CAPWAP Pkt Header: 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version - the version of the CAPWAP protocol (the first is 0) DISCUSS: should this be split into major and minor, and if so, what are the implications of an increment of the major or minor part? Type - packet type, values are: 1 - CAPWAP Unprotected Data Packet 2 - CAPWAP DTLS Protected Data Packet 3 - CAPWAP Unprotected Control Packet 4 - CAPWAP DTLS Protected Control Packet 0,5-15 - reserved This is needed because if CAPWAP packets have the format that you show below, the it is ambiguous whether or not a DTLS header is present. (Note, I've actually looked at having packets in that format. To do so would meen that a CAPWAP header would have the syntax of a DTLS header, but use types not yet used, and have the TLS/DTLS spec reserve those type values for applications. This is doable, but I feel, would be the leading FAQ. I hope this is clearer. (If not, call me) Note, if we were using UDP, we would need 4 ports (see the 4 types above). On Fri, 9 Jun 2006, Pat Calhoun (pacalhou) wrote: > Dave, > > The proposal you have made relies on a bit in the header, but the > issue here is that the CAPWAP header is actually encrypted when > DTLS is on - so I don't see how we can rely on that bit. Perhaps I > am missing something fundamental in your point, though, and if so > I apologize in advance. > > What I've been trying to state is that UDP *is* a multiplexor > technology. We already have a method of differentiating the > control and/or data using UDP. > > My revised diagram: > > CAPWAP Pkt Header: > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | UDP Header | DTLS Header | CAPWAP Header | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > *optional header* > > What confuses me at this point is that if UDP can provide the exact > same functions as the MUX header, why is Scott stating that DTLS > can run over any arbitrary underlying transport without any > complexity - yet is pushing back that doing this over two UDP > ports is complex? The only issue that I am aware of that is > additional complexity with dual ports is the have some form of > keepalive on the data plane to handle NATed environments. This > Is a very simply problem to solve. Otherwise, to Scott's point, > DTLS doesn't care what it runs over. > > Hence my confusion. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 12:07:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FojWK-0002lE-NB for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 12:07:36 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FojWK-0000cw-3n for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 12:07:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BF08C430106 for ; Fri, 9 Jun 2006 09:07:35 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 675B3430085 for ; Fri, 9 Jun 2006 09:07:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 50D30144802E for ; Fri, 9 Jun 2006 09:07:09 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id AE1711448023 for ; Fri, 9 Jun 2006 09:07:06 -0700 (PDT) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 09 Jun 2006 09:07:06 -0700 X-IronPort-AV: i="4.05,224,1146466800"; d="scan'208"; a="292330350:sNHT34406516" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k59G75NZ014279; Fri, 9 Jun 2006 09:07:05 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k59G75Iu006140; Fri, 9 Jun 2006 09:07:05 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Jun 2006 09:07:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jun 2006 09:07:04 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202037C34@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New mux header for CAPWAP Thread-Index: AcaL3bEYX/y7bIBdSIKeg6w2969wmwAAGWug From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" X-OriginalArrivalTime: 09 Jun 2006 16:07:05.0325 (UTC) FILETIME=[C06171D0:01C68BDE] Authentication-Results: sj-dkim-6.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Wow - I'm embarassed I missed your point, I see what you are stating now. > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version | Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Version - the version of the CAPWAP protocol (the first is 0) > DISCUSS: should this be split into major and minor, > and if so, what are the implications of > an increment of the major or minor part? > > Type - packet type, values are: > 1 - CAPWAP Unprotected Data Packet > 2 - CAPWAP DTLS Protected Data Packet > 3 - CAPWAP Unprotected Control Packet > 4 - CAPWAP DTLS Protected Control Packet > 0,5-15 - reserved There has never been a mention that the control plane would be in the clear, so I believe we can remove that element. The issue I have with this proposal is that fields in the CAPWAP header are not protected. > Note, if we were using UDP, we would need 4 ports (see the 4 > types above). Actually, I disagree. First of all, relying on a bit that states whether the data frame is encrypted or not is irrelevant because the AC (and WTP, for that matter) will probably rely on the policy negotiated during the control plane setup more than the bit. For instance, if the AC stated that DTLS was required on the data plane, would it accept a packet in the clear? No, so I don't think we need to signal that the data plane is explicitely encrypted. If it doesn't comply to the negotiated mode of operation, it is dropped. For that matter, only 2 ports are needed. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Friday, June 09, 2006 8:59 AM > To: Pat Calhoun (pacalhou) > Cc: Rohit Suri (rsuri); capwap@frascone.com > Subject: RE: [Capwap] New mux header for CAPWAP > > HI, > > Thanks for the note. It looks like what you are calling > CAPWAP Pkt header differs from my use of that term. > Here are my diagrams.... > CAPWAP Packet formats: > > > CAPWAP Unprotected Data Packet: > +-----------------------------------------+ > | IP | UDP | CAPWAP | CAPWAP | Wireless | > | Hdr | Hdr | Pkt | Data | Payload | > | | | Hdr | Hdr | | > +-----------------------------------------+ > > > CAPWAP DTLS Protected Data Packet: > +-----------------------------------------------------------+ > | IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS | > | Hdr | Hdr | Pkt | Hdr | Data | Payload | Trailer | > | | | Hdr | | Hdr | | | > +-----------------------------------------------------------+ > \--integrity checked---------/ > \--encrypted-------------------/ > > > CAPWAP Unprotected Control Packet: > +------------------------------------------+ > | IP | UDP | CAPWAP | CAPWAP | Message | > | Hdr | Hdr | Pkt | Control | Elements | > | | | Hdr | Hdr | | > +------------------------------------------+ > > > CAPWAP DTLS Protected Control Packet: > +----------------------------------------------------------+ > | IP | UDP | CAPWAP | DTLS | CAPWAP | Message | DTLS | > | Hdr | Hdr | Pkt | Hdr | Control | Elements | Trailer | > | | | Hdr | | Hdr | | | > +----------------------------------------------------------+ > \--integrity checked-------/ > \--encrypted-------------------/ > > As you can see above there is ALWAYs a 2 octet "CAPWAP Pkt > Hdr" in EVERY CAPWAP packet. The format is: > CAPWAP Pkt Header: > 1 > > On Fri, 9 Jun 2006, Pat Calhoun (pacalhou) wrote: > > Dave, > > > > The proposal you have made relies on a bit in the header, but the > > issue here is that the CAPWAP header is actually encrypted > when DTLS > > is on - so I don't see how we can rely on that bit. Perhaps I am > > missing something fundamental in your point, though, and if so I > > apologize in advance. > > > > What I've been trying to state is that UDP *is* a multiplexor > > technology. We already have a method of differentiating the control > > and/or data using UDP. > > > > My revised diagram: > > > > CAPWAP Pkt Header: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | UDP Header | DTLS Header | CAPWAP Header | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > *optional header* > > > > What confuses me at this point is that if UDP can provide the exact > > same functions as the MUX header, why is Scott stating that > DTLS can > > run over any arbitrary underlying transport without any > complexity - > > yet is pushing back that doing this over two UDP ports is > complex? The > > only issue that I am aware of that is additional complexity > with dual > > ports is the have some form of keepalive on the data plane > to handle > > NATed environments. This Is a very simply problem to solve. > Otherwise, > > to Scott's point, DTLS doesn't care what it runs over. > > > > Hence my confusion. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 12:19:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FojhZ-00020R-J4 for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 12:19:13 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FojhW-0001XM-K6 for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 12:19:13 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3E3974300D6 for ; Fri, 9 Jun 2006 09:19:10 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id EC2FD43006D for ; Fri, 9 Jun 2006 09:18:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C22BD144802B for ; Fri, 9 Jun 2006 09:18:33 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 54C861448028 for ; Fri, 9 Jun 2006 09:18:29 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k59GISdw029053; Fri, 9 Jun 2006 09:18:28 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k59GIS5b029048; Fri, 9 Jun 2006 09:18:28 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 9 Jun 2006 09:18:28 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A202037C34@xmb-sjc-235.amer.cisco.com> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 HI, DISCOVERY request/response are control and have to be in the clear. Otherwise, all other control traffic is protected. On data traffic, one might want to encrypt some data streams from a WTP and not encrypt other streams. (For example, why encrypt data using an "open SSID"?) So, when add it all up, there are 4 types of CAPWAP traffic as specific by the type field below. Regards, /david t. perkins On Fri, 9 Jun 2006, Pat Calhoun (pacalhou) wrote: > Wow - I'm embarassed I missed your point, I see what you are stating > now. > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Version | Type | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Version - the version of the CAPWAP protocol (the first is 0) > > DISCUSS: should this be split into major and minor, > > and if so, what are the implications of > > an increment of the major or minor part? > > > > Type - packet type, values are: > > 1 - CAPWAP Unprotected Data Packet > > 2 - CAPWAP DTLS Protected Data Packet > > 3 - CAPWAP Unprotected Control Packet > > 4 - CAPWAP DTLS Protected Control Packet > > 0,5-15 - reserved > > There has never been a mention that the control plane would be in the > clear, so I believe we can remove that element. The issue I have > with this proposal is that fields in the CAPWAP header are not > protected. > > > Note, if we were using UDP, we would need 4 ports (see the 4 > > types above). > > Actually, I disagree. First of all, relying on a bit that states > whether the data frame is encrypted or not is irrelevant because > the AC (and WTP, for that matter) will probably rely on the policy > negotiated during the control plane setup more than the bit. > > For instance, if the AC stated that DTLS was required on the data > plane, would it accept a packet in the clear? No, so I don't think > we need to signal that the data plane is explicitely encrypted. If > it doesn't comply to the negotiated mode of operation, it is dropped. > > For that matter, only 2 ports are needed. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > -----Original Message----- > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > Sent: Friday, June 09, 2006 8:59 AM > > To: Pat Calhoun (pacalhou) > > Cc: Rohit Suri (rsuri); capwap@frascone.com > > Subject: RE: [Capwap] New mux header for CAPWAP > > > > HI, > > > > Thanks for the note. It looks like what you are calling > > CAPWAP Pkt header differs from my use of that term. > > Here are my diagrams.... > > CAPWAP Packet formats: > > > > > > CAPWAP Unprotected Data Packet: > > +-----------------------------------------+ > > | IP | UDP | CAPWAP | CAPWAP | Wireless | > > | Hdr | Hdr | Pkt | Data | Payload | > > | | | Hdr | Hdr | | > > +-----------------------------------------+ > > > > > > CAPWAP DTLS Protected Data Packet: > > +-----------------------------------------------------------+ > > | IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS | > > | Hdr | Hdr | Pkt | Hdr | Data | Payload | Trailer | > > | | | Hdr | | Hdr | | | > > +-----------------------------------------------------------+ > > \--integrity checked---------/ > > \--encrypted-------------------/ > > > > > > CAPWAP Unprotected Control Packet: > > +------------------------------------------+ > > | IP | UDP | CAPWAP | CAPWAP | Message | > > | Hdr | Hdr | Pkt | Control | Elements | > > | | | Hdr | Hdr | | > > +------------------------------------------+ > > > > > > CAPWAP DTLS Protected Control Packet: > > +----------------------------------------------------------+ > > | IP | UDP | CAPWAP | DTLS | CAPWAP | Message | DTLS | > > | Hdr | Hdr | Pkt | Hdr | Control | Elements | Trailer | > > | | | Hdr | | Hdr | | | > > +----------------------------------------------------------+ > > \--integrity checked-------/ > > \--encrypted-------------------/ > > > > As you can see above there is ALWAYs a 2 octet "CAPWAP Pkt > > Hdr" in EVERY CAPWAP packet. The format is: > > CAPWAP Pkt Header: > > 1 > > > > On Fri, 9 Jun 2006, Pat Calhoun (pacalhou) wrote: > > > Dave, > > > > > > The proposal you have made relies on a bit in the header, but the > > > issue here is that the CAPWAP header is actually encrypted > > when DTLS > > > is on - so I don't see how we can rely on that bit. Perhaps I am > > > missing something fundamental in your point, though, and if so I > > > apologize in advance. > > > > > > What I've been trying to state is that UDP *is* a multiplexor > > > technology. We already have a method of differentiating the control > > > and/or data using UDP. > > > > > > My revised diagram: > > > > > > CAPWAP Pkt Header: > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | UDP Header | DTLS Header | CAPWAP Header | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > *optional header* > > > > > > What confuses me at this point is that if UDP can provide the exact > > > same functions as the MUX header, why is Scott stating that > > DTLS can > > > run over any arbitrary underlying transport without any > > complexity - > > > yet is pushing back that doing this over two UDP ports is > > complex? The > > > only issue that I am aware of that is additional complexity > > with dual > > > ports is the have some form of keepalive on the data plane > > to handle > > > NATed environments. This Is a very simply problem to solve. > > Otherwise, > > > to Scott's point, DTLS doesn't care what it runs over. > > > > > > Hence my confusion. > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 14:06:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FolNE-0000Zg-J6 for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 14:06:20 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FolND-0007tp-4h for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 14:06:20 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id AA83C4300C7 for ; Fri, 9 Jun 2006 11:06:18 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id EBEAC430059 for ; Fri, 9 Jun 2006 11:05:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D855F144800A for ; Fri, 9 Jun 2006 11:05:55 -0700 (PDT) Received: from germanium.prioritynetworks.net (germanium.prioritynetworks.net [128.64.162.100]) by hermes.tigertech.net (Postfix) with ESMTP id 0E7671448031 for ; Fri, 9 Jun 2006 11:05:53 -0700 (PDT) Received: from [128.64.168.104] (128-64-168-104.prioritynetworks.net [128.64.168.104]) by germanium.prioritynetworks.net (Postfix) with ESMTP id E2E2CE2A2 for ; Fri, 9 Jun 2006 14:05:47 -0400 (EDT) Message-ID: <4489B85B.4050209@sysnetinc.com> Date: Fri, 09 Jun 2006 14:05:15 -0400 From: Chris Stradtman User-Agent: Thunderbird 1.5.0.2 (X11/20060521) MIME-Version: 1.0 To: capwap@frascone.com References: <4469C8CE.6040909@hyperthought.com> In-Reply-To: <4469C8CE.6040909@hyperthought.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=-0.0 tagged_above=-999.0 required=7.0 tests=SPF_PASS X-Spam-Level: Subject: Re: [Capwap] mux redux X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 I have been asked by some folks to expoudn on this a little. So here it goes. -I work for a service provider that does temporary small and large scale hospitality networks. Think of what the NOC volunteers do for the IETF meetings but often on a much larger scale. We deal with hotels, convention centers, arenas, and some outdoor venues from an service provider point of view I can think of 2 off the top of my head. 1. A service provider may not choose to trustingly pass through the QOS markings and may wish to rewrite the QOS markings based on other policies internal to the service provider. -We make it a standard practice to prioritize our management traffic over the customer transit data. Most of the time it doesn't really affect anything, but with the advent of a new Windows virus or worm the ability to get into our devices to help mitigate or control the spread is worth it's weight in gold. (Because of the tradeshow floor nature we have VERY little control over what the users bring onto the tradeshow floor until after it's there) 2. The service provider may wish to send the data and control channels down different physical paths based on economic factors. -we usually have several paths into and out of a facility. Some of them may have significantly different costs and/or path characteristics. Likewise above in the case of a outbreak problem at a remote center we may send all of the management data down a slower less congested backup link so we can work on controlling the virus/worm and taking the load off of fully congested primary transit link. If the streams are muxed then the service provider need to have equipment in the middle that understands the capwap protocol out of the gate (although some gear can use explicit bitstrings and offsets into the packet). This is unlikely to happen and in my opinion would slow down the adoption and implementation of the protocol in the "real world". -Indeed some of our gear does have the capability to do the bitstring offset matching for policy but far from all of our gear does. So for adoption for us we would probably have to wait until 1) we upgrade all of our core switches to do the bitstring matching. 2) all of our core switches get code updates to understand the CAPWAP mux header. -I wouldn't have any problems with doing the bitstring matching, but I'm not sure some of our level 1 NOC folks we be able to do it correctly. I've also read mention of the concept of separating the data and control by putting it on two different VLANs. In may ways that would be even easier for us implement/manage. We already use that approach with our fat/thick AP installations to accomplish the division. Anyway, that's my two cents. :-) Chris Stradtman _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 16:01:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FonAM-0006GZ-Jd for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 16:01:10 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FonAL-0006Gj-6S for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 16:01:10 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2AD214300C9 for ; Fri, 9 Jun 2006 13:01:08 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id BAA25430059 for ; Fri, 9 Jun 2006 13:00:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A432C144800A for ; Fri, 9 Jun 2006 13:00:45 -0700 (PDT) X-Greylist-Status: Sender first seen 2 mons 18 days 02:26:43 ago Received: from sinett.com (63-197-255-151.ded.pacbell.net [63.197.255.151]) by hermes.tigertech.net (Postfix) with ESMTP id E932D1448026 for ; Fri, 9 Jun 2006 13:00:40 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 9 Jun 2006 13:00:39 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New mux header for CAPWAP Thread-Index: AcaL3bEYX/y7bIBdSIKeg6w2969wmwAAGWugAAgT7EA= From: "Abhijit Choudhury" To: "Pat Calhoun (pacalhou)" , "David T. Perkins" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Pat wrote: Actually, I disagree. First of all, relying on a bit that states whether the data frame is encrypted or not is irrelevant because the AC (and WTP, for that matter) will probably rely on the policy negotiated during the control plane setup more than the bit. For instance, if the AC stated that DTLS was required on the data plane, would it accept a packet in the clear? No, so I don't think we need to signal that the data plane is explicitely encrypted. If it doesn't comply to the negotiated mode of operation, it is dropped. For that matter, only 2 ports are needed. This is quite restrictive. An AC can have some data traffic from a remote office and require DTLS on that traffic, as well as some traffic coming from within the local premises for which it may not require DTLS in the data plane. DTLS on the data plane should be a property of the specific tunnel. This needs to supported. In general, it is a better design to have the packet fields clearly indicate that what the nature of the payload is, rather than depend on lookups of policy tables to decide how to parse the packet. So, I think Dave's proposal of the header have encodings to indicate DTLS-encrypted payload or not is a good idea. This is still orthogonal to whether we use one UDP port or two. Abhijit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 17:20:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FooPQ-0001tK-H2 for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 17:20:48 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FooPO-0008M5-1B for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 17:20:48 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E0DFC4300DA for ; Fri, 9 Jun 2006 14:20:44 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 63AE0430059 for ; Fri, 9 Jun 2006 14:20:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5B1BE39803C for ; Fri, 9 Jun 2006 14:20:18 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8B670398041 for ; Fri, 9 Jun 2006 14:20:16 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 09 Jun 2006 14:20:16 -0700 X-IronPort-AV: i="4.05,224,1146466800"; d="scan'208"; a="292487168:sNHT33908514" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k59LKGgL014668; Fri, 9 Jun 2006 14:20:16 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k59LKEkk019786; Fri, 9 Jun 2006 14:20:15 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Jun 2006 14:20:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jun 2006 14:20:14 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202037DEE@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New mux header for CAPWAP Thread-Index: AcaL3bEYX/y7bIBdSIKeg6w2969wmwAAGWugAAgT7EAAAvduIA== From: "Pat Calhoun (pacalhou)" To: "Abhijit Choudhury" , "David T. Perkins" X-OriginalArrivalTime: 09 Jun 2006 21:20:15.0011 (UTC) FILETIME=[7FE7FF30:01C68C0A] Authentication-Results: sj-dkim-1.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] New mux header for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c > This is quite restrictive. An AC can have some data traffic > from a remote office and require DTLS on that traffic, as > well as some traffic coming from within the local premises > for which it may not require DTLS in the data plane. DTLS on > the data plane should be a property of the specific tunnel. > This needs to supported. Perhaps I wasn't clear, this is done on a per WTP basis. I can't imagine some traffic being in the clear, and some not. I see the decision to encrypt the data plane, on a per WTP basis, as a binary decision. > In general, it is a better design to have the packet fields > clearly indicate that what the nature of the payload is, > rather than depend on lookups of policy tables to decide how > to parse the packet. The reality is that you have to do the policy lookup anyhow. You don't want to accept an unencrypted packet, when the policy requires it to be. So you can't avoid this lookup. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Abhijit Choudhury [mailto:Abhijit@sinett.com] > Sent: Friday, June 09, 2006 1:01 PM > To: Pat Calhoun (pacalhou); David T. Perkins > Cc: capwap@frascone.com > Subject: RE: [Capwap] New mux header for CAPWAP > > Pat wrote: > > Actually, I disagree. First of all, relying on a bit that states > > whether the data frame is encrypted or not is irrelevant because > > the AC (and WTP, for that matter) will probably rely on > the policy > negotiated during the control plane setup more than the bit. > > For instance, if the AC stated that DTLS was required > on the data > plane, would it accept a packet in the clear? No, so I > don't think > we need to signal that the data plane is explicitely encrypted. > If > it doesn't comply to the negotiated mode of operation, > it is dropped. > > For that matter, only 2 ports are needed. > > > > > Abhijit > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 18:14:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FopFE-0001q1-17 for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 18:14:20 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FopFC-0007AU-8T for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 18:14:20 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 893714300D0 for ; Fri, 9 Jun 2006 15:14:17 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 00C6E430059 for ; Fri, 9 Jun 2006 15:13:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id DC37F398031 for ; Fri, 9 Jun 2006 15:13:53 -0700 (PDT) Received: from smtpauth08.mail.atl.earthlink.net (smtpauth08.mail.atl.earthlink.net [209.86.89.68]) by zoidberg.tigertech.net (Postfix) with ESMTP id AAADC39803A for ; Fri, 9 Jun 2006 15:13:49 -0700 (PDT) Received: from [209.86.224.53] (helo=elwamui-wigeon.atl.sa.earthlink.net) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1FopEi-0002SW-SB for capwap@frascone.com; Fri, 09 Jun 2006 18:13:48 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Fri, 9 Jun 2006 18:13:48 -0400 Message-ID: <14673401.1149891228945.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Date: Fri, 9 Jun 2006 15:13:48 -0700 (GMT-07:00) From: "Scott G. Kelly" To: capwap Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710ac918578847d0d86d4d9ceebb42612bc350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.53 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [Capwap] capwap transport analysis: QoS vs multiport X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac We've been debating the transport facility for capwap for months now, and have yet to reach closure. We, as a working group, need to choose one of these approaches and move on. My preference is that we choose the one that makes the most sense technically, but many years of IETF experience suggest that this is not always the way these things work out. Still, I think we should try to do the right thing here since we basically have a clean slate right now, and we will never have this opportunity again. To that end, I will once more attempt to review the salient arguments on either side. If I am missing something, please bonk me over the head and show me what it is, and I will gladly modify my position accordingly - I really do want to choose the approach that best serves the broadest range of customers. I am not irrevocably committed to the single port approach, but detailed analysis has persuaded me that it's the best approach, and that the two-port approach simply does not accomplish what is claimed. If you can specifically show that the analysis is flawed, I will accept this and adapt my thinking accordingly. I'll share some more of that analysis here, but I won't replicate the previous text - you can flip back through the archives for that. Here I will talk about QoS only. This will be part of the record of our considerations and decision making process, so please read it, think carefully, and comment constructively. On behalf of the two-port approach, the primary argument pertains to traffic engineering, the starting premises being (1) intermediate network elements between the WTP and AC must be able to re-mark packets (2) in particular, they need to ensure that control traffic is treated at a higher priority than data traffic (3) some customers will want to send control down a different path than data to achieve this (or some other) objective (4) many of these elements can only classify traffic based on 5-tuples; they apparently cannot use VLAN tags or 1:1 mappings of DSCP/802.1q/802.1d mappings Based on these premises, the claim is that using separate ports for control and data will provide a solution. Let's assume that the various premises and claim are correct, and see where it leads us. We can start by taking a closer look at the traffic in question: Control Channel Content ---------------------------- - Session establishment messages (discover, dtls handshake, join) - configuration changes (includes config updates, radio up/down) - echo request/replies - periodic stats/status updates If we expect the network to be stable (the average or common case if we've done our jobs), then capwap session establishment is a miniscule fraction of total control traffic, as are firmware updates and other config changes. Once the capwap session is established and the WTP is configured (steady state), control channel traffic will be relatively sparse, compared to data traffic. Echo requests/replies probably wouldn't be more frequent than one per second per WTP (and in many cases will be much less frequent than this), and stats updates should be much less frequent than echoes (but it depends on the implementation). The cost of control packet loss depends upon contiguous sequential echo req/rsp losses exceeding the NeighborDeadInterval timer. If you lose one or both of the echo req/rsp packets in every exchange over one of these entire intervals, the capwap "connection" will be considered lost, and will be reset. Note the tuning ability this provides. Also note that if this is happening, your wlan-to-wired applications are faring quite poorly regardless of whether this connection is reset, although a reset is definitely to be avoided if possible - but unless this is an anomaly, you have a longer-term problem to solve anyway, because users will not be happy with a jerky, bumpy, unreliable network like the one we're describing. With respect to control channel QoS, the most important thing is to prevent the channel from being incorrectly diagnosed as "dead" when in fact it is not. With two ports, you could conceivably give the control channel a higher priority so that this happens less frequently on a highly-congested network, but then what happens to all of the QoS granularity in the data channel? Data Channel Content ------------------------- - 802.11 management frames - probes (usually not sent to AC, so let's ignore for now) - association - authentication - client data - voice - file transfers - netbios chatter - other broadcast traffic - video streaming - web surfing - imap/email - instant messaging - (etc) Since you only have a single port (and the claim is that it's too hard to look deeper into the packets), then you will be effectively "clipping" the QoS level of any data streams requiring a higher priority than you are re-marking with, and "promoting" any data with a lower priority. Notice that some of the 802.11 messages (in particular, association messages) are quite timing critical. Also, what about *voice* packets? Am I the only one who thinks this is broken? One of our objectives (resource control objective) is to coordinate quality across wireless and wired segments. I won't quote chapter and verse (like I said, it's not scripture or anything), but I think we all agree that this is an important objective. We are throwing that to the wind here, and this will definitely have an adverse impact on the applications in the data channel (or, put slightly differently, on the quality of the products we provide). In order to meet the resource control objective, and perhaps more importantly, provide customers with WLANs that really work for timing-sensitive applications, we have to support granular QoS between the WTPs and ACs which more or less matches the over-air QoS. Using a single port as one-size-fits-all QoS classifier for the data channel is diametrically opposed to this objective. There is no question that there are QoS problems we have yet to solve, but using a port for control and a port for data simply does not do what we are asking of it. So, what else can we do? One option is to provide a separate data channel port per QoS class, but given the channel binding issues, nat traversal issues, firewall issues, and associated implementation complexity, this is going from bad to worse. Over the air, packets may be marked (e.g. via WMM, 802.11e), and in order to match these service levels on the wired segment, the AC or WTP can map these markings to the outer header of the individual data channel packets, either as 802.1q/d, or DSCP values, but this (like any other scheme we come up with) requires agreement between the WTP/AC and the owner(s) of the media between them. And of course, you have to "trust" the applications not to lie, and self-promote. As for the first issue (agreement), this is facilitated by providing the appropriate knobs on the AC/WTP. As for the second issue (self-promotion), while it sounds very negative, it is not really very likely, and maybe not even worth the cost of prevention. However, if applications were innocently using the "wrong" markings because they didn't know any better, this could be remedied by providing granular classification at the WTP or AC, or maybe even per-client re-marking (or perhaps via buying applications that work "right"). Still, it doesn't seem worth it to spend many cycles on what should be a rare problem. A third alternative is to use granular classification in the cloud between the AC and WTP, but clearly, this requires deep packet inspection (which we accepted as not being available in our premises above). No matter what, the original claim (that two capwap ports will resolve the QoS issues) is clearly wrong. There are other solutions, but none of them are perfect. Multiple ports (one per QoS class) is a possibility, but I shudder to think of it. AC/WTP marking seems like the obvious solution and the only other alternative I can see is in-the-cloud deep packet inspection. Either of the more viable solutions favors the single-port approach, given the complexity reduction, built-in nat traversal, firewall rule reduction it entails, and all other things being equal. --Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 19:49:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoqjD-0002eA-Dy for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 19:49:23 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoqjB-0001Wl-FG for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 19:49:23 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6F8B84300D9 for ; Fri, 9 Jun 2006 16:49:20 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D28F1430059 for ; Fri, 9 Jun 2006 16:48:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BDEFD144802F for ; Fri, 9 Jun 2006 16:48:07 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id B651F1448017 for ; Fri, 9 Jun 2006 16:48:05 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 09 Jun 2006 16:48:05 -0700 X-IronPort-AV: i="4.05,225,1146466800"; d="scan'208"; a="292547443:sNHT55856198" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k59Nm48X028613 for ; Fri, 9 Jun 2006 16:48:04 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k59Nm4CU028483 for ; Fri, 9 Jun 2006 16:48:04 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Jun 2006 16:48:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jun 2006 16:48:03 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC01A24DBD@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] capwap transport analysis: QoS vs multiport Thread-Index: AcaMEgZpXfRg8u6rQHmAT7UPPdlIWQACxmNA From: "Bob O'Hara (boohara)" To: "capwap" X-OriginalArrivalTime: 09 Jun 2006 23:48:04.0471 (UTC) FILETIME=[26843070:01C68C1F] Authentication-Results: sj-dkim-3.cisco.com; header.From=boohara@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] capwap transport analysis: QoS vs multiport X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e Scott, *BONK* Yes, you are missing everything. Your argument appears to be "if I = can't do perfect QoS, it is not worth trying to do any QoS at all." Perhap= s you hadn't yet realized that this is where your arguments were taking you= . I hope this email helps to clarify that. = This line of argument, of course, leads one to conclude that a single port = is all that is needed for CAPWAP, since perfect QoS on the data and control= packets of CAPWAP can't be done anyway. The only apparent solution to thi= s is to use as many ports as there are different levels of QoS needed for t= he CAPWAP control and for the 802.11 data tunneled in CAPWAP data packets, = as Scott described below. That, of course, is absurd and I agree with Scot= t. The line of argument presented below is an attempt at reductio ad absurdum.= Given some set of absurd conditions, the method of using multiple ports f= alls apart. You use this to justify your conclusion that two ports are not= useful. = Simply because we can't do something perfectly, is no reason not to do the = best that we can. Certainly we can agree that some QoS is better than none= , which is what the two port solution gets us. Also, please see my specific comments, below. = -Bob = -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] = Sent: Friday, June 09, 2006 3:14 PM To: capwap Subject: [Capwap] capwap transport analysis: QoS vs multiport [snipped to prevent the killing of more bits than absolutely necessary] On behalf of the two-port approach, the primary argument pertains to traffi= c engineering, the starting premises being (1) intermediate network elements between the WTP and AC must be able to re= -mark packets (2) in particular, they need to ensure that control traffic is treated at a= higher priority than data traffic (3) some customers will want to send control down a different path than dat= a to achieve this (or some other) objective (4) many of these elements can only classify traffic based on 5-tuples; the= y apparently cannot use VLAN tags or 1:1 mappings of DSCP/802.1q/802.1d map= pings Bob>> The statement has been made by several posters not that the equipment= cannot do this, but that it will not do it, because the source of any QoS = marking at the WTP may not be trusted. The reason for this is that the sou= rce of this QoS marking is the client, not the WTP and the client is not tr= usted to mark QoS properly. Therefore any mapping of that QoS by the WTP c= annot be trusted, either. More on this, below. Based on these premises, the claim is that using separate ports for control= and data will provide a solution. Let's assume that the various premises a= nd claim are correct, and see where it leads us. We can start by taking a c= loser look at the traffic in question: Control Channel Content ---------------------------- - Session establishment messages (discover, dtls handshake, join) - configuration changes (includes config updates, radio up/down) - echo request/replies - periodic stats/status updates If we expect the network to be stable (the average or common case if we've = done our jobs), then capwap session establishment is a miniscule fraction o= f total control traffic, as are firmware updates and other config changes. = Once the capwap session is established and the WTP is configured (steady st= ate), control channel traffic will be relatively sparse, compared to data t= raffic. Echo requests/replies probably wouldn't be more frequent than one p= er second per WTP (and in many cases will be much less frequent than this),= and stats updates should be much less frequent than echoes (but it depends= on the implementation). The cost of control packet loss depends upon contiguous sequential echo req= /rsp losses exceeding the NeighborDeadInterval timer. If you lose one or bo= th of the echo req/rsp packets in every exchange over one of these entire i= ntervals, the capwap "connection" will be considered lost, and will be rese= t. Note the tuning ability this provides. Bob>> Correct, there is tuning that can be done here. This is apparently a= n allusion to the fact that one can make this timer value as large as one w= ants to be able to live with as many lost echo packets as one can conceive.= This is true. The cost of that is that one also has to live with that sa= me length of time before a truly lost connection is recognized and the WTP = can make an attempt to find another AC. So, the cost of losing the ability= to reduce the probability of losing these packets by differential QoS is a= longer network outage for all users when the connection to the AC is truly= gone. Also note that if this is happening, your wlan-to-wired applications are fa= ring quite poorly regardless of whether this connection is reset, although = a reset is definitely to be avoided if possible - but unless this is an ano= maly, you have a longer-term problem to solve anyway, because users will no= t be happy with a jerky, bumpy, unreliable network like the one we're descr= ibing. Bob>> Apparently this argument is that no network connection for the client= devices is better than one that is not perfect. I would take issue with t= hat. Getting some data through the network may not be able to support all = applications. But, it will support some. This is certainly better than ha= ving a device with no network connection at al. With respect to control channel QoS, the most important thing is to prevent= the channel from being incorrectly diagnosed as "dead" when in fact it is = not. With two ports, you could conceivably give the control channel a highe= r priority so that this happens less frequently on a highly-congested netwo= rk, but then what happens to all of the QoS granularity in the data channel= ? = Data Channel Content ------------------------- - 802.11 management frames - probes (usually not sent to AC, so let's ignore for now) - association - authentication - client data - voice - file transfers - netbios chatter - other broadcast traffic - video streaming - web surfing - imap/email - instant messaging - (etc) Since you only have a single port (and the claim is that it's too hard to l= ook deeper into the packets), then you will be effectively "clipping" the Q= oS level of any data streams requiring a higher priority than you are re-ma= rking with, and "promoting" any data with a lower priority. = Bob>> This is no different from the QoS provided to the data packets when u= sing the mux header. Given that the frame for this discussion is that the = equipment between the WTP and AC does not trust the WTP marking of the QoS,= how could it be any different? Notice that some of the 802.11 messages (in particular, association message= s) are quite timing critical. Also, what about *voice* packets? Am I the only one who thinks this is broken? One of our objectives (resourc= e control objective) is to coordinate quality across wireless and wired seg= ments. I won't quote chapter and verse (like I said, it's not scripture or = anything), but I think we all agree that this is an important objective. We= are throwing that to the wind here, and this will definitely have an adver= se impact on the applications in the data channel (or, put slightly differe= ntly, on the quality of the products we provide). Bob>>What is claimed here is that this two-port method is broken, when the = single-port method that provides even less differentiation for CAPWAP packe= ts is claimed to not be broken. It would be quite interesting to understan= d how this could be so, again given that the same constraints are applied t= o both. In order to meet the resource control objective, and perhaps more important= ly, provide customers with WLANs that really work for timing-sensitive appl= ications, we have to support granular QoS between the WTPs and ACs which mo= re or less matches the over-air QoS. Using a single port as one-size-fits-a= ll QoS classifier for the data channel is diametrically opposed to this obj= ective. = Bob>>I see you have finally argued yourself into the corner. Let me quote = you: "using a single port as one-size-fits-all QoS classifier" is exactly w= hat your preferred solution does to an even greater degree than the two-por= t solution. There is no question that there are QoS problems we have yet to solve, but = using a port for control and a port for data simply does not do what we are= asking of it. So, what else can we do? One option is to provide a separate= data channel port per QoS class, but given the channel binding issues, nat= traversal issues, firewall issues, and associated implementation complexit= y, this is going from bad to worse. Over the air, packets may be marked (e.g. via WMM, 802.11e), and in order t= o match these service levels on the wired segment, the AC or WTP can map th= ese markings to the outer header of the individual data channel packets, ei= ther as 802.1q/d, or DSCP values, but this (like any other scheme we come u= p with) requires agreement between the WTP/AC and the owner(s) of the media= between them. And of course, you have to "trust" the applications not to l= ie, and self-promote. = Bob>>Exactly the point. Trusting the applications is precisely the problem= . In a perfect world, we would have no worries about an application self-p= romoting its own QoS at the expense of other applications or other users of= the network. Unfortunately, that perfect world is a pipe dream. The real= world, the world we need to design our protocol for must live with the fac= t that the applications' markings for QoS will not be trusted by the networ= k. Period. Anything else on our part is extremely na=EFve. As for the first issue (agreement), this is facilitated by providing the ap= propriate knobs on the AC/WTP. As for the second issue (self-promotion), wh= ile it sounds very negative, it is not really very likely, and maybe not ev= en worth the cost of prevention. = Bob>> This is much too na=EFve. Next thing you will be advocating is that = we don't need strong authentication or encryption, because the users and th= eir machines can be trusted not to lie about who they are. Why is this tru= st issue any different? However, if applications were innocently using the "wrong" markings because= they didn't know any better, this could be remedied by providing granular = classification at the WTP or AC, or maybe even per-client re-marking (or pe= rhaps via buying applications that work "right"). Still, it doesn't seem wo= rth it to spend many cycles on what should be a rare problem. A third alter= native is to use granular classification in the cloud between the AC and WT= P, but clearly, this requires deep packet inspection (which we accepted as = not being available in our premises above). Bob>> Well, this might be an option, if one could see the data in the 802.1= 1 frame. Unfortunately, a CAPWAP option allows all of that to be obscured = from all of the infrastructure, except for the AC. Utilizing centralized e= ncryption negates either of the two alternatives described above. Neither = the WTP nor the equipment between the WTP and the AC can classify the packe= t based on the content of the payload (the now-encrypted 802.11 frame). No matter what, the original claim (that two capwap ports will resolve the = QoS issues) is clearly wrong. There are other solutions, but none of them a= re perfect. Multiple ports (one per QoS class) is a possibility, but I shud= der to think of it. AC/WTP marking seems like the obvious solution and the = only other alternative I can see is in-the-cloud deep packet inspection. Ei= ther of the more viable solutions favors the single-port approach, given th= e complexity reduction, built-in nat traversal, firewall rule reduction it = entails, and all other things being equal. Bob>> As has been shown by the arguments from the original email arguments = above, everything claimed that is better than using separate ports for cont= rol and for data is actually worse, including using a single port and a mux= header. --Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 20:16:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1For9H-00062f-UT for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 20:16:20 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1For9G-0004he-DX for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 20:16:19 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id F3C6B4300E3 for ; Fri, 9 Jun 2006 17:16:17 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 44CB8430059 for ; Fri, 9 Jun 2006 17:15:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 24F1C398041 for ; Fri, 9 Jun 2006 17:15:40 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by zoidberg.tigertech.net (Postfix) with ESMTP id 53B29398022 for ; Fri, 9 Jun 2006 17:15:37 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-3.cisco.com with ESMTP; 09 Jun 2006 17:15:36 -0700 X-IronPort-AV: i="4.05,225,1146466800"; d="scan'208"; a="430451156:sNHT31788420" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k5A0FaKB012572; Fri, 9 Jun 2006 17:15:36 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5A0FaIu003870; Fri, 9 Jun 2006 17:15:36 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Jun 2006 17:15:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jun 2006 17:15:35 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC01A24DCC@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Process in CAPWAP Thread-Index: AcaMIv6al2wcs/e8TvuwY5RhhPusZA== From: "Bob O'Hara (boohara)" To: "Dan Romascanu (E-mail)" X-OriginalArrivalTime: 10 Jun 2006 00:15:36.0418 (UTC) FILETIME=[FF274C20:01C68C22] Authentication-Results: sj-dkim-7.cisco.com; header.From=boohara@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: [Capwap] Process in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Dan, A few days ago Dorothy Gellert sent an email to the working group on behalf= of the chairs, announcing a decision on a technical issue in the working g= roup. Specifically, she declared that the chairs decided the discussion of= the use of a mux header vs. the use of separate ports for the differentiat= ion of control and data traffic in the protocol to be over. She also indic= ated that the chairs had chosen the mux header as the method to be used in = the protocol and set a deadline of today for closing the issue. As soon as I read her email, I replied and asked that she document the proc= ess that the chairs used to arrive at their decision. My background is in = the IEEE, where the process is clear, transparent, and open to all particip= ants. CAPWAP is my first IETF working group. My understanding of decision= -making in IETF is that it is based on rough consensus and that the chairs = have responsibility to determine that consensus. With that understanding, = I asked Dorothy to document what the chairs used as evidence of rough conse= nsus on that issue, since I see evidence in the postings to the list that t= here is more support for separate ports than there is for the mux header. = At a minimum, there is no consensus on this issue. Since sending that email two days ago, neither chair has responded. I find= that quite disturbing for several reasons. = First, this is an issue that has been debated extensively (and still is bei= ng debated, regardless of the pronouncement from the chairs). The working = group deserves to know how this technical issue was resolved. = Second, standardization by fiat of the chair does not seem to be in keeping= with the open process requirements of the IETF. Perhaps I am being na=EFv= e, but I don't believe there is a feted inner core (FIC) that is actually d= eveloping all the IETF standards. = Third, the time allowed for any response to the email was only three days. = This is an absurdly short time, given that it is the start of the summer v= acation period in the northern hemisphere. It is quite possible that many = participants will not even see her email until after the deadline expires. = Finally, if there is no consensus on the issue, the chairs are expressing a= n engineering opinion and should be required to justify that opinion just a= s any other member of the working group. I don't believe that the IETF ano= ints the chairs of any working group as expert and able to make technical d= ecisions for the working group. I would appreciate your thoughts, as the AD, and response on these items. Best regards, -Bob Bob O'Hara _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 20:36:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ForTF-0003yG-SL for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 20:36:57 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ForTD-0007Fb-By for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 20:36:57 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D1B4943006D for ; Fri, 9 Jun 2006 17:36:54 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 72AD7430059 for ; Fri, 9 Jun 2006 17:36:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6248839803C for ; Fri, 9 Jun 2006 17:36:35 -0700 (PDT) Received: from smtpauth08.mail.atl.earthlink.net (smtpauth08.mail.atl.earthlink.net [209.86.89.68]) by zoidberg.tigertech.net (Postfix) with ESMTP id 57D14398041 for ; Fri, 9 Jun 2006 17:36:31 -0700 (PDT) Received: from [209.86.224.53] (helo=elwamui-wigeon.atl.sa.earthlink.net) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1ForSo-0004qa-QZ; Fri, 09 Jun 2006 20:36:30 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Fri, 9 Jun 2006 20:36:30 -0400 Message-ID: <32466258.1149899790789.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Date: Fri, 9 Jun 2006 17:36:30 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "Bob O'Hara (boohara)" , capwap Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710e6458fd253d70838a6b195cfa10f1a97350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.53 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: Re: [Capwap] capwap transport analysis: QoS vs multiport X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Hi Bob, >*BONK* Yes, you are missing everything. Your argument appears to be "if I can't do perfect QoS, it is not > worth trying to do any QoS at all." Perhaps you hadn't yet realized that this is where your arguments were > taking you. I hope this email helps to clarify that. No, the argument is nothing of the kind - it is simply that the multiport approach does nothing for QoS that WTP/AC marking cannot. If you trust the ports (which the WTP and AC fill in), why can't you trust the QoS markings that you've configured them to provide? Set aside the client marking concerns you have (assume we won't trust clients to mark), and instead assume the WTP uses two markers, one for control and one for data. How is this different or worse than separate ports from a QoS perspective? It is clearly far better than two ports from an operational and implemenational complexity perspective. >This line of argument, of course, leads one to conclude that a single port is all that is needed for CAPWAP, since perfect QoS on the data and control packets of CAPWAP can't be done anyway. The only apparent solution to this is to use as many ports as there are different levels of QoS needed for the CAPWAP control and for the 802.11 data tunneled in CAPWAP data packets, as Scott described below. That, of course, is absurd and I agree with Scott. > It's not that it can't be done - it's that you have the same problem with one or two ports, and *that* is the problem we should be expending energy on, not justifying an approach whose intended function really has nothing to do with QoS. I'm sorry it's not the answer you wanted, but the facts seem pretty clear, and I don't think you're effectively refuting them. >The line of argument presented below is an attempt at reductio ad absurdum. Given some set of absurd conditions, the method of using multiple ports falls apart. You use this to justify your conclusion that two ports are not useful. > Actually, I agree that it does reduce the two-port approach _as a proposed QoS solution_ to be... well, I wouldn't have used the term absurd - but I might say detrimental. >Simply because we can't do something perfectly, is no reason not to do the best that we can. > Certainly we can agree that some QoS is better than none, which is what the two port solution > gets us. I agree that some is better than none, and I think it's clear that we can do better. I think that is explained at the end of the post. I tried to avoid writing a book about it, but I think there's enough there. >Also, please see my specific comments, below. Yes, I read them, and I think it would be less than productive to do a blow-by-blow reply. You clearly feel quite strongly about this. Let's let everyone else review the post on their own, and see what they think. Chill out, have a nice weekend, and we can discuss on Monday. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 09 20:43:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ForZq-0000l4-Jf for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 20:43:46 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ForZq-0000PB-Hg for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 20:43:46 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ForM7-0002Eq-Ug for capwap-archive@lists.ietf.org; Fri, 09 Jun 2006 20:29:37 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 53CF74300C5 for ; Fri, 9 Jun 2006 17:29:34 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6257B430059 for ; Fri, 9 Jun 2006 17:28:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 55D20398041 for ; Fri, 9 Jun 2006 17:28:56 -0700 (PDT) Received: from mgw-ext11.nokia.com (mgw-ext11.nokia.com [131.228.20.170]) by zoidberg.tigertech.net (Postfix) with ESMTP id 287E539803E for ; Fri, 9 Jun 2006 17:28:50 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5A0SiHh008232; Sat, 10 Jun 2006 03:28:46 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Jun 2006 03:28:45 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 19:28:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jun 2006 17:28:41 -0700 Message-ID: <893AE265F4ADF94AB7FB26D31A788E41022DEF57@mvebe101.NOE.Nokia.com> In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC01A24DCC@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Process in CAPWAP Thread-Index: AcaMIv6al2wcs/e8TvuwY5RhhPusZAAAKi/g From: To: , X-OriginalArrivalTime: 10 Jun 2006 00:28:43.0041 (UTC) FILETIME=[D4047110:01C68C24] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.178 tagged_above=-999 required=7 tests=NO_REAL_NAME X-Spam-Level: Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com Subject: Re: [Capwap] Process in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Bob- I've been holding off on responding to discuss results with Mani. As far as your email.. I think you are under the impression that decisions= in IETF are based on polling. They are not. We are trying to judge conse= nsus and when there is none, the chairs come to an educated conclusion to k= eep the work of the group moving. There is no inner core, there is no conspiracy and there is no favoritism. = However, the chairs and ADs are able to restrict Mailing list access to tho= se that are disruptive to the WG. = Dorothy Gellert = -----Original Message----- From: ext Bob O'Hara (boohara) [mailto:boohara@cisco.com] = Sent: Friday, June 09, 2006 5:16 PM To: Dan Romascanu (E-mail) Cc: capwap Subject: [Capwap] Process in CAPWAP Dan, A few days ago Dorothy Gellert sent an email to the working group on behalf= of the chairs, announcing a decision on a technical issue in the working g= roup. Specifically, she declared that the chairs decided the discussion of= the use of a mux header vs. the use of separate ports for the differentiat= ion of control and data traffic in the protocol to be over. She also indic= ated that the chairs had chosen the mux header as the method to be used in = the protocol and set a deadline of today for closing the issue. As soon as I read her email, I replied and asked that she document the proc= ess that the chairs used to arrive at their decision. My background is in = the IEEE, where the process is clear, transparent, and open to all particip= ants. CAPWAP is my first IETF working group. My understanding of decision= -making in IETF is that it is based on rough consensus and that the chairs = have responsibility to determine that consensus. With that understanding, = I asked Dorothy to document what the chairs used as evidence of rough conse= nsus on that issue, since I see evidence in the postings to the list that t= here is more support for separate ports than there is for the mux header. = At a minimum, there is no consensus on this issue. Since sending that email two days ago, neither chair has responded. I find= that quite disturbing for several reasons. = First, this is an issue that has been debated extensively (and still is bei= ng debated, regardless of the pronouncement from the chairs). The working = group deserves to know how this technical issue was resolved. = Second, standardization by fiat of the chair does not seem to be in keeping= with the open process requirements of the IETF. Perhaps I am being na=EFv= e, but I don't believe there is a feted inner core (FIC) that is actually d= eveloping all the IETF standards. = Third, the time allowed for any response to the email was only three days. = This is an absurdly short time, given that it is the start of the summer v= acation period in the northern hemisphere. It is quite possible that many = participants will not even see her email until after the deadline expires. = Finally, if there is no consensus on the issue, the chairs are expressing a= n engineering opinion and should be required to justify that opinion just a= s any other member of the working group. I don't believe that the IETF ano= ints the chairs of any working group as expert and able to make technical d= ecisions for the working group. I would appreciate your thoughts, as the AD, and response on these items. Best regards, -Bob Bob O'Hara _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From lehmalau@katun.com Fri Jun 09 21:09:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foryf-0003d9-NJ for capwap-archive@ietf.org; Fri, 09 Jun 2006 21:09:25 -0400 Received: from adsl-67-126-138-201.dsl.irvnca.pacbell.net ([67.126.138.201] helo=katun.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Forye-0003Ko-A1 for capwap-archive@ietf.org; Fri, 09 Jun 2006 21:09:25 -0400 Message-ID: <000001c68c2a$753e2580$15d0a8c0@eku76> Reply-To: "Laurie Lehman" From: "Laurie Lehman" To: capwap-archive@ietf.org Subject: Re: hikia refnace Date: Fri, 9 Jun 2006 18:09:01 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68BEF.C8DF4D80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68BEF.C8DF4D80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, $ y 20 n 0,0 s 00 L v oa n n for o b nl q y $ e 82 e 7 month.=20 BA m D C w RE j DI v T O g k v v is q it the s r it s e =20 _____ =20 southerly course and the Mountain receded again, and at last, late in the day the shores grew rocky, the river gathered all its wandering waters together into a deep and rapid flood, and they swept along at great speed. ------=_NextPart_000_0001_01C68BEF.C8DF4D80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

$ y 20 n 0,0 s 00 L v oa n n for o b nl q y $ e 82 e 7 month.

BA m D C w RE j DI v T O g k v v is q it the s r it s e

southerly course and the Mountain = receded again, and at last, late in
the day the shores grew rocky, the river gathered all its wandering
waters together into a deep and rapid flood, and they swept along at
great speed.
------=_NextPart_000_0001_01C68BEF.C8DF4D80-- From spe@aviogroup.com Sat Jun 10 03:49:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoyDv-0000sg-Ai for capwap-archive@ietf.org; Sat, 10 Jun 2006 03:49:35 -0400 Received: from 84.95.76.111.cable.012.net.il ([84.95.76.111] helo=aviogroup.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FoyDt-00018c-NT for capwap-archive@ietf.org; Sat, 10 Jun 2006 03:49:35 -0400 Message-ID: <000001c68c62$5dcb0e30$2e9aa8c0@rkl94> Reply-To: "Lyndsey Speidel" From: "Lyndsey Speidel" To: capwap-archive@ietf.org Subject: test ryjo Date: Sat, 10 Jun 2006 00:49:13 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68C27.B16C3630" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68C27.B16C3630 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, VA eg LlUM from on kn ly $ li 1,2 vt 1 Ambie zt n Me sq ridia Proza qs c Levit jg ra So sy ma Xan vd ax V lb lAGRA from on zu ly $ kl 3,3 we 3 ClA qv LlS from onl zr y $ tm 3,7 hj 5 all 50 gm % o bm ff http://www.manekans.com _____ =20 our friend and fellow conspirator, this most excellent and audacious=20 hobbit-may the hair on his toes never fall out! all praise to his wine=20 and ale!- He paused for breath and for a polite remark from the=20 hob-bit, but the compliments were quite lost on-poor Bilbo Baggins, who=20 was wagging his mouth in protest at being called audacious and worst of=20 all fellow conspirator, though no noise came out, he was so flummoxed.=20 ------=_NextPart_000_0001_01C68C27.B16C3630 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

VA eg LlUM from on kn ly $ li 1,2 vt 1
Ambie zt n
Me sq ridia
Proza qs c
Levit jg ra
So sy ma
Xan vd ax
V lb lAGRA from on zu ly $ kl 3,3 we 3
ClA qv LlS from onl zr y $ tm 3,7 hj 5


all 50 gm % o bm ff http://www.manekans.com

our friend and fellow = conspirator, this most excellent and audacious
hobbit-may the hair = on his toes never fall out! all praise to his wine
and ale!- He = paused for breath and for a polite remark from the
hob-bit, but the = compliments were quite lost on-poor Bilbo Baggins, who
was wagging = his mouth in protest at being called audacious and worst of
all = fellow conspirator, though no noise came out, he was so flummoxed. =
------=_NextPart_000_0001_01C68C27.B16C3630-- From clifte@adtransport.com Sun Jun 11 02:55:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpJqv-0005iG-2t for capwap-archive@ietf.org; Sun, 11 Jun 2006 02:55:17 -0400 Received: from [200.87.18.247] (helo=adtransport.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FpJqa-00076V-Dw for capwap-archive@ietf.org; Sun, 11 Jun 2006 02:55:17 -0400 Message-ID: <000001c68d23$cc36e800$1a35a8c0@ati21> Reply-To: "Agatha Clift" From: "Agatha Clift" To: capwap-archive@ietf.org Subject: test ruho Date: Sat, 10 Jun 2006 23:53:51 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68CE9.1FD81000" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.2 (++++) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68CE9.1FD81000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Pr mz ozac VA pv LlUM from on du ly $ as 1,2 fh 1 Le hw vitra Meridi bs a X vt anax Cl jn ALlS from o nz nly $ uo 3,7 jp 5 VlAGR qs A from o hh nly $ aw 3,3 xt 3 Ambie be n Som hu a all 5 gg 0% of dm f http://www.epronneci.com _____ =20 uncanny fire. If a spark got in their coats it stuck and burned into=20 them, and unless they rolled over quick they were soon all in flames.=20 Very soon all about the glade wolves were rolling over and over to put=20 out the sparks on their backs, while those that were burning were=20 running about howling and setting others alight, till their own friends=20 chased them away and they fled off down the slopes crying and yammering=20 ------=_NextPart_000_0001_01C68CE9.1FD81000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

Pr mz ozac
VA pv LlUM from on du ly $ as 1,2 fh 1
Le hw vitra
Meridi bs a
X vt anax
Cl jn ALlS from o nz nly $ uo 3,7 jp 5
VlAGR qs A from o hh nly $ aw 3,3 xt 3
Ambie be n
Som hu a


all 5 gg 0% of dm f http://www.epronneci.com

uncanny fire. If a = spark got in their coats it stuck and burned into
them, and unless = they rolled over quick they were soon all in flames.
Very soon all = about the glade wolves were rolling over and over to put
out the = sparks on their backs, while those that were burning were
running = about howling and setting others alight, till their own friends =
chased them away and they fled off down the slopes crying and = yammering
------=_NextPart_000_0001_01C68CE9.1FD81000-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Jun 11 09:09:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpPhJ-0008Ab-Tw for capwap-archive@lists.ietf.org; Sun, 11 Jun 2006 09:09:45 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpPhI-0002C9-ER for capwap-archive@lists.ietf.org; Sun, 11 Jun 2006 09:09:45 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 34E214300E7 for ; Sun, 11 Jun 2006 06:09:43 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4F1144300D8 for ; Sun, 11 Jun 2006 06:09:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2C360431088 for ; Sun, 11 Jun 2006 06:09:01 -0700 (PDT) X-Greylist-Status: Sender first seen 00:22:38 ago Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by hermes.tigertech.net (Postfix) with ESMTP id 4AA75431084 for ; Sun, 11 Jun 2006 06:08:57 -0700 (PDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5BCh3vH027269 for ; Sun, 11 Jun 2006 08:43:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 11 Jun 2006 15:46:14 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Process in CAPWAP Thread-Index: AcaMIv6al2wcs/e8TvuwY5RhhPusZABLgvjQ From: "Romascanu, Dan (Dan)" To: "Bob O'Hara (boohara)" X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Process in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Bob, Thank you for the mail. = You probably refer to the mail from Dorothy Gellert sent to the list on Tue= sday 6/6 (US time): 'The CAPWAP editors have asked the Chairs to resolve the Mux vs Multiport i= ssue # 115, in order to progress the specification. Based on the discussio= n that has taken place the chairs are in agreement the simplest, cleanest s= olution for this is to add a Mux header. Barring any unforseen events, we = will instruct the editors resolve in favor of a new Mux header. We intend to close this issue by the end of the week, Friday, 6/9. Please = review the issue and send any constructive comments to the list by Friday.' I am looking together with my co-Area Director, David Kessens into the issu= es that you are raising and we shall respond in a matter of days. In the meantime I would encourage the working group, the editors and the ch= airs to continue to work and seek consensus, in the best possible cooperati= on spirit. According to the traffic on the list during the last few days I = agree that there still seem to be open issues and it does not seem to be co= nsensus in the Working Group. Dan = = > -----Original Message----- > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] = > Sent: Saturday, June 10, 2006 3:16 AM > To: Romascanu, Dan (Dan) > Cc: capwap > Subject: Process in CAPWAP > = > Dan, > = > A few days ago Dorothy Gellert sent an email to the working = > group on behalf of the chairs, announcing a decision on a = > technical issue in the working group. Specifically, she = > declared that the chairs decided the discussion of the use of = > a mux header vs. the use of separate ports for the = > differentiation of control and data traffic in the protocol = > to be over. She also indicated that the chairs had chosen = > the mux header as the method to be used in the protocol and = > set a deadline of today for closing the issue. > = > As soon as I read her email, I replied and asked that she = > document the process that the chairs used to arrive at their = > decision. My background is in the IEEE, where the process is = > clear, transparent, and open to all participants. CAPWAP is = > my first IETF working group. My understanding of = > decision-making in IETF is that it is based on rough = > consensus and that the chairs have responsibility to = > determine that consensus. With that understanding, I asked = > Dorothy to document what the chairs used as evidence of rough = > consensus on that issue, since I see evidence in the postings = > to the list that there is more support for separate ports = > than there is for the mux header. At a minimum, there is no = > consensus on this issue. > = > Since sending that email two days ago, neither chair has = > responded. I find that quite disturbing for several reasons. = > = > First, this is an issue that has been debated extensively = > (and still is being debated, regardless of the pronouncement = > from the chairs). The working group deserves to know how = > this technical issue was resolved. = > = > Second, standardization by fiat of the chair does not seem to = > be in keeping with the open process requirements of the IETF. = > Perhaps I am being na=EFve, but I don't believe there is a = > feted inner core (FIC) that is actually developing all the = > IETF standards. = > = > Third, the time allowed for any response to the email was = > only three days. This is an absurdly short time, given that = > it is the start of the summer vacation period in the northern = > hemisphere. It is quite possible that many participants will = > not even see her email until after the deadline expires. = > = > Finally, if there is no consensus on the issue, the chairs = > are expressing an engineering opinion and should be required = > to justify that opinion just as any other member of the = > working group. I don't believe that the IETF anoints the = > chairs of any working group as expert and able to make = > technical decisions for the working group. > = > I would appreciate your thoughts, as the AD, and response on = > these items. > = > Best regards, > -Bob > = > Bob O'Hara > = _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 12 10:09:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpn73-0001wi-22 for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 10:09:53 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpn71-0002WA-8e for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 10:09:53 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5F3E743016B for ; Mon, 12 Jun 2006 07:09:50 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C8E214300A2 for ; Mon, 12 Jun 2006 07:09:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8FB911448007 for ; Mon, 12 Jun 2006 07:09:05 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.200]) by hermes.tigertech.net (Postfix) with ESMTP id 630B21448003 for ; Mon, 12 Jun 2006 07:09:03 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id t13so859256wxc for ; Mon, 12 Jun 2006 07:09:02 -0700 (PDT) Received: by 10.70.28.4 with SMTP id b4mr6442846wxb; Mon, 12 Jun 2006 07:09:02 -0700 (PDT) Received: by 10.70.133.2 with HTTP; Mon, 12 Jun 2006 07:09:02 -0700 (PDT) Message-ID: <5bfe7a820606120709q7fd414ehc7348750c21e27bd@mail.gmail.com> Date: Mon, 12 Jun 2006 07:09:02 -0700 From: "Dorothy Stanley" To: "Michael Montemurro" MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.6 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: [Capwap] Proposed Resolution to Issue 134/wasRe: New Issue - Local MAC MUST vs MAY forward associationrequest messages X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2055373418==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af --===============2055373418== Content-Type: multipart/alternative; boundary="----=_Part_69155_23632565.1150121342339" ------=_Part_69155_23632565.1150121342339 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Pat, David, Agree that the AC must be notified. However the text also states that " the AC MAY reply with a failed Association Response if it deems it necessary. " introducing a race condition, when the WTP may have already responded to the Association Request with an Association Response (success), before it receives the "failed Association Response" from the AC. Proposed resolution of Issue 134: Change from: While the MAC is terminated on the WTP, it is necessary for the AC to be aware of mobility events within the WTPs. As a consequence, the WTP MUST forward the IEEE 802.11 Association Requests to the AC, and the AC MAY reply with a failed Association Response if it deems it necessary. to While the MAC is terminated on the WTP, it is necessary for the AC to be aware of mobility events within the WTPs. As a consequence, the WTP MUST forward the IEEE 802.11 Association Requests to the AC. The AC MAY reply with a failed Association Response if it deems it necessary, and upon receipt of a failed Association Response from the AC, the WTP must send a Disassociation frame to the mobile station. Thanks, Dorothy On 6/8/06, Michael Montemurro wrote: > > I've captured this as issue 134. > > Cheers, > > Mike > > > > On 6/6/06, Dorothy Stanley wrote: > > > Pat, David, > > Your comments are consistent with those received back in April, when > this mail was sent out - thus > I did not make, and had not planned to make the proposed change. > > Thanks, > > Dorothy > > > On 6/6/06, David T. Perkins wrote: > > > > HI, > > > > ABSOLUTELY agree with Pat. That is the AC MUST know what STAs > > are be serviced by the WTPs, and MUST decide which STAs are > > allowed to associate and send traffic. > > This is the fundamental difference between a CAPWAP network > > and a collection of APs. > > > > Regards, > > /david t. perkins > > > > On Tue, 6 Jun 2006, Pat Calhoun (pacalhou) wrote: > > > > > I disagree with this change request. The AC MUST know what STAs are > > > being serviced by WTPs. The term MUST cannot be changed to MAY. > > > > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit > > > Cisco Systems > > > > > > > > > > > > > > > ________________________________ > > > > > > From: Dorothy Stanley [mailto: dstanley1389@gmail.com] > > > Sent: Tuesday, April 11, 2006 11:41 AM > > > To: capwap > > > Subject: [Capwap] New Issue - Local MAC MUST vs MAY forward > > > associationrequest messages > > > > > > > > > All, > > > > > > Section 11.1.2 Local MAC describes the Local MAC operation. It > > > currently states > > > (second paragraph below Figure 6): > > > > > > While the MAC is terminated on the WTP, it is necessary for the > > > AC to be aware of mobility events within the WTPs. > > > As a consequence, the WTP MUST forward the IEEE 802.11 > > > Association Requests to the AC, and the AC MAY reply > > > with a failed Association Response if it deems it necessary. > > > > > > > > > Since this is the Local MAC case, it seems that a MAY should be > > > sufficient. > > > > > > Recommended change: > > > > > > The MAC is terminated on the WTP, but the AC may need to be > > > aware of mobility events within the WTPs. > > > As a consequence, the WTP MAY forward the IEEE 802.11 > > > Association Requests to the AC, and the AC MAY reply > > > with a failed Association Response. > > > > > > Comments? > > > > > > Thanks, > > > > > > Dorothy > > > > > > > > > > > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > > ------=_Part_69155_23632565.1150121342339 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Pat, David,

Agree that the AC must be notified. However the text also states that
" the AC MAY reply
 with a failed Association Response if it deems it necessary. "

introducing a race condition, when the WTP may have already responded to the
Association Request with an Association Response (success), before it
receives the "failed Association Response" from the AC.

Proposed resolution of Issue 134:

Change from:

While the MAC is terminated on the WTP, it is necessary for the
AC to be aware of mobility events within the WTPs.
As a consequence, the WTP MUST forward the IEEE 802.11
Association Requests to the AC, and the AC MAY reply
 with a failed Association Response if it deems it necessary.

to

While the MAC is terminated on the WTP, it is necessary for the
AC to be aware of mobility events within the WTPs.
As a consequence, the WTP MUST forward the IEEE 802.11
Association Requests to the AC. The AC MAY reply
with a failed Association Response if it deems it necessary, and upon
receipt of a failed Association Response from the AC,  the
WTP must send a Disassociation frame to the mobile station.

Thanks,

Dorothy

On 6/8/06, Michael Montemurro <montemurro.michael@gmail.com> wrote:
I've captured this as issue 134.
 
Cheers,
 
Mike


 
On 6/6/06, Dorothy Stanley < dstanley1389@gmail.com> wrote:
Pat, David,
 
Your comments are consistent with those received back in April, when
this mail was sent out - thus
I did not make, and had not planned to make the proposed change.
 
Thanks,
 
Dorothy

 
On 6/6/06, David T. Perkins <dperkins@dsperkins.com > wrote:
HI,

ABSOLUTELY agree with Pat. That is the AC MUST know what STAs
are be serviced by the WTPs, and MUST decide which STAs are
allowed to associate and send traffic.
This is the fundamental difference between a CAPWAP network
and a collection of APs.

Regards,
/david t. perkins

On Tue, 6 Jun 2006, Pat Calhoun (pacalhou) wrote:

> I disagree with this change request. The AC MUST know what STAs are
> being serviced by WTPs. The term MUST cannot be changed to MAY.
>
>
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
>
>
>
>
> ________________________________
>
>       From: Dorothy Stanley [mailto: dstanley1389@gmail.com]
>       Sent: Tuesday, April 11, 2006 11:41 AM
>       To: capwap
>       Subject: [Capwap] New Issue - Local MAC MUST vs MAY forward
> associationrequest messages
>
>
>       All,
>
>       Section 11.1.2 Local MAC describes the Local MAC operation. It
> currently states
>       (second paragraph below Figure 6):
>
>       While the MAC is terminated on the WTP, it is necessary for the
> AC to be aware of mobility events within the WTPs.
>       As a consequence, the WTP MUST forward the IEEE 802.11
> Association Requests to the AC, and the AC MAY reply
>       with a failed Association Response if it deems it necessary.
>
>
>       Since this is the Local MAC case, it seems that a MAY should be
>       sufficient.
>
>       Recommended change:
>
>       The MAC is terminated on the WTP, but the AC may need to be
> aware of mobility events within the WTPs.
>       As a consequence, the WTP MAY forward the IEEE 802.11
> Association Requests to the AC, and the AC MAY reply
>       with a failed Association Response.
>
>       Comments?
>
>       Thanks,
>
>       Dorothy
>
>
>



_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap



------=_Part_69155_23632565.1150121342339-- --===============2055373418== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============2055373418==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 12 10:13:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpnA8-0003Bu-Cg for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 10:13:04 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpnA7-0002ic-MW for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 10:13:04 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 276D0430199 for ; Mon, 12 Jun 2006 07:13:03 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C15424300A2 for ; Mon, 12 Jun 2006 07:12:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AD8A71448010 for ; Mon, 12 Jun 2006 07:12:14 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by hermes.tigertech.net (Postfix) with ESMTP id 610131448003 for ; Mon, 12 Jun 2006 07:12:12 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id t13so859710wxc for ; Mon, 12 Jun 2006 07:12:11 -0700 (PDT) Received: by 10.70.26.1 with SMTP id 1mr6462133wxz; Mon, 12 Jun 2006 07:12:11 -0700 (PDT) Received: by 10.70.133.2 with HTTP; Mon, 12 Jun 2006 07:12:03 -0700 (PDT) Message-ID: <5bfe7a820606120712t6663ae5epd3f220e09783ce95@mail.gmail.com> Date: Mon, 12 Jun 2006 07:12:03 -0700 From: "Dorothy Stanley" To: "Romascanu, Dan (Dan)" In-Reply-To: MIME-Version: 1.0 References: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.6 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com, young Subject: Re: [Capwap] Issue 105 - Reset IEEE 802.11 statistics/was Re: somesuggestion for 802.11 binding TLV X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1029531780==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 --===============1029531780== Content-Type: multipart/alternative; boundary="----=_Part_69183_5389517.1150121523582" ------=_Part_69183_5389517.1150121523582 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, Proposed resolution to Issue 105: Reject, with the reason that: When using statistics objects in order to understand 'the real state of the network' an administrator MUST NOT rely on the absolute values of statistic objects (typically counters), but on the delta values of successive readings, correlated with the timestamp of the reading. with no change to the text. Thanks, Dorothy On 6/6/06, Romascanu, Dan (Dan) wrote: > > I do not believe that a "reset IEEE 802.11 Statistics" TLV is useful. > Actually it may be harmful. > > When using statistics objects in order to understand 'the real state of > the network' an administrator MUST NOT rely on the absolute values of > statistic objects (typically counters), but on the delta values of > successive readings, correlated with the timestamp of the reading. > > > Dan > > > > > > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Tuesday, June 06, 2006 3:55 AM > > To: Dorothy Stanley; young > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 105 - Reset IEEE 802.11 > > statistics/was Re: somesuggestion for 802.11 binding TLV > > > > Dorothy, Here is text from the original post: > > > > 1) New TLV "reset IEEE 802.11 Statistics" > > > > a) Why we need it? > > > > Now, the draft defines "IEEE 802.11 Statistics" to report > > Multicast Tx Count, Multiple Retry Count and so on. As AP > > keep updating the statistic value, after some time, the > > statistic value will become very great, and it could not > > reflect the real state of network. So administrator need a > > method to reset IEEE 802.11 Statistics" > > > > b) The TLV could be carried in the "Configure Update request" > > > > c) The TLV format is as follow: > > > > 0 1 2 3 4 5 6 7 > > > > +-+-+-+-+-+-+-+-+ > > > > | Radio ID | > > > > +-+-+-+-+-+-+-+-+ > > > > When AP side get radio id from TLV, it will reset the > > radio as per radio ID. > > > > d) Other suggestion: > > > > Whether it needs a "Reset interval" element? By this way, > > user could configure after how many time (seconds) AP will > > reset Statistics for a specific radio. > > > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > > ________________________________ > > > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > > Sent: Wednesday, May 24, 2006 11:33 AM > > To: young > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > Subject: Issue 105 - Reset IEEE 802.11 statistics/was Re: > > [Capwap] some suggestion for 802.11 binding TLV > > > > > > All, > > > > I would like to develop text to resolve Issue 105, but > > need some more information as to exactly what the > > issue is. Input please. The discussion on issue 105 > > to date is listed below. > > > > Thanks, > > > > Dorothy > > > > > > > > > > On 4/19/06, young wrote: > > > > Dear all: > > > > > > > > I have some suggestion about CAPWAP > > draft, please kindly discuss it. > > > > 1) For IEEE 802.11 Statistics > > > > I suggest we should add new TLV for "reset IEEE > > 802.11 Statistics" > > > > > > Issue 105 has been opened for item (1). > > > > Can you provide suggested text for a > > description of the proposed TLV? This will enable a more > > informed discussion, and > > give insight into the problem that is being solved. > > Is this a boolean, which when set causes the > > WTP to reset all of its statistics collection counters? > > Is it included in the statistics message > > element? A new message element? In which message elements > > and messages would it be included? > > > > > > > > > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > ------=_Part_69183_5389517.1150121523582 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline All,

Proposed resolution to Issue 105: Reject,

with the reason that:
When using statistics objects in order to understand 'the real state of
the network' an administrator MUST NOT rely on the absolute values of
statistic objects (typically counters), but on the delta values of
successive readings, correlated with the timestamp of the reading.

with no change to the text.

Thanks,

Dorothy

On 6/6/06, Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:
I do not believe that a "reset IEEE 802.11 Statistics" TLV is useful.
Actually it may be harmful.

When using statistics objects in order to understand 'the real state of
the network' an administrator MUST NOT rely on the absolute values of
statistic objects (typically counters), but on the delta values of
successive readings, correlated with the timestamp of the reading.


Dan






> -----Original Message-----
> From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com]
> Sent: Tuesday, June 06, 2006 3:55 AM
> To: Dorothy Stanley; young
> Cc: capwap@frascone.com
> Subject: Re: [Capwap] Issue 105 - Reset IEEE 802.11
> statistics/was Re: somesuggestion for 802.11 binding TLV
>
> Dorothy, Here is text from the original post:
>
> 1) New TLV "reset IEEE 802.11 Statistics"
>
> a) Why we need it?
>
> Now, the draft defines "IEEE 802.11 Statistics" to report
> Multicast Tx Count, Multiple Retry Count and so on. As AP
> keep updating the statistic value, after some time, the
> statistic value will become very great, and it could not
> reflect the real state of network. So administrator need a
> method to reset IEEE 802.11 Statistics"
>
> b) The TLV could be carried in the "Configure Update request"
>
> c) The TLV format is as follow:
>
>       0 1 2 3 4 5 6 7
>
>      +-+-+-+-+-+-+-+-+
>
>      |   Radio ID   |
>
>      +-+-+-+-+-+-+-+-+
>
>    When AP side get radio id from TLV, it will reset the
> radio as per radio ID.
>
> d) Other suggestion:
>
> Whether it needs a "Reset interval" element? By this way,
> user could configure after how many time (seconds) AP will
> reset Statistics for a specific radio.
>
>
>
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
>
>
>
>
> ________________________________
>
>       From: Dorothy Stanley [mailto:dstanley1389@gmail.com]
>       Sent: Wednesday, May 24, 2006 11:33 AM
>       To: young
>       Cc: Pat Calhoun (pacalhou); capwap@frascone.com
>       Subject: Issue 105 - Reset IEEE 802.11 statistics/was Re:
> [Capwap] some suggestion for 802.11 binding TLV
>
>
>       All,
>
>       I would like to develop text to resolve Issue 105, but
> need some more information as to exactly what the
>       issue is.  Input please.  The discussion on issue 105
> to date is listed below.
>
>       Thanks,
>
>       Dorothy
>
>
>
>
>               On 4/19/06, young <young@huawei-3com.com> wrote:
>
>                       Dear all:
>
>
>
>                       I have some suggestion about CAPWAP
> draft, please kindly discuss it.
>
>                       1) For IEEE 802.11 Statistics
>
>                       I suggest we should add new TLV for "reset IEEE
> 802.11 Statistics"
>
>
>               Issue 105 has been opened for item (1).
>
>               Can you provide suggested text for a
> description of the proposed TLV?  This will enable a more
> informed discussion, and
>               give insight into the problem that is being solved.
>               Is this a boolean, which when set causes the
> WTP to reset all of its statistics collection counters?
>               Is it included in the statistics message
> element? A new message element?  In which message elements
> and messages would it be included?
>
>
>
>
>
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
>

------=_Part_69183_5389517.1150121523582-- --===============1029531780== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1029531780==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 12 10:43:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpndX-0005fc-EX for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 10:43:27 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpndV-000663-BA for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 10:43:27 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A5DB4430114 for ; Mon, 12 Jun 2006 07:43:24 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 484FB4300A2 for ; Mon, 12 Jun 2006 07:42:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 31D5A1448008 for ; Mon, 12 Jun 2006 07:42:34 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.204]) by hermes.tigertech.net (Postfix) with ESMTP id 51AFB1448018 for ; Mon, 12 Jun 2006 07:42:30 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id t13so864531wxc for ; Mon, 12 Jun 2006 07:42:20 -0700 (PDT) Received: by 10.70.31.1 with SMTP id e1mr6434195wxe; Mon, 12 Jun 2006 07:42:18 -0700 (PDT) Received: by 10.70.133.2 with HTTP; Mon, 12 Jun 2006 07:42:17 -0700 (PDT) Message-ID: <5bfe7a820606120742l4195e4a3ie27c42d196b8d944@mail.gmail.com> Date: Mon, 12 Jun 2006 07:42:18 -0700 From: "Dorothy Stanley" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A202037BDD@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A202037BDD@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.6 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0629033034==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01 --===============0629033034== Content-Type: multipart/alternative; boundary="----=_Part_69624_26204282.1150123338190" ------=_Part_69624_26204282.1150123338190 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I support Mike's suggestion for solving the original issue raised by David: move Encryption Capabilities from the WTP Descriptor (Section 4.4.34) to the WTP Radio Information message element (Section 4.4.39) On 6/9/06, Pat Calhoun (pacalhou) wrote: > > I agree with Nancy. It's almost like CAPWAP products would need to > ship a "security requirements table", and allow the customer to pick > and choose from what they think they need, and then enable the various > features. Why not simply support a single mechanism that is a superset > of all features and call it a day? There isn't a single mechanism to support all features. One feature is to decrypt at the AC. This enables capwap implementations to provide functionality not available at the WTP. Another feature is to protect data over the WTP/AC link. These are not the same. We seem to be contradicting ourselves here. In some threads we are > arguing for protocol simplicity, then in others we seem to accept > complexity (and, yes, I view multiple options that provide similar > features are adding complexity, because in the end we all have to > implement them, and leave it to the customer to deal with the issue). In the case we are discussing here, implementation of 802.11 crypto at the AC is an optional feature. It is not required, and need not be implemented. To date, other than stating that "we need to support it", no one has > been able to state how 802.11i packet encryption services in the AC > allows an AC/WTP to actually support the complete 802.11 protocol. There are mandatory and optional portions of the 802.11 protocol. For example, both security and QOS are optional portions of the protocol, and the QOS services that are typically supported are WMM based, not 802.11(e) based. 802.11i packet encryption services in the AC allow the AC to support, for example AES encryption for WTPs which do not support it, and allows vendor flexibility. It is an option that is currently in the draft - do not have to implement if you don't want to, e.g. an AC implementation that supports local MAC only does not have to do this. However, the MUX issue has raised another interesting problem, which > was raised by Scott, which is that in order for the WTP to perform > packet classification, and tagging, it needs to have access to the > data frames in the clear, which is not possible with this feature. The WTP can perform marking by mapping the WMM or 802.11e header info into DSCP/.1q/.1d markings Access to data frames in the clear is not needed. so I see this as just adding yet another option for end users to deal > with. BTW, if we need the WTP to do packet classification, we need > to create a new issue because the protocol does not have the means > to push down rules. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Nancy Winget (ncamwing) > > Sent: Thursday, June 08, 2006 3:38 PM > > To: Scott G. Kelly; capwap > > Subject: Re: [Capwap] Encryption Capabilities > > > > While it is true that the originating 802.11 data payload > > will be obscured, it is not clear to me that we can construe > > it as "good". > > Since there is no protection of the CAPWAP encapsulation, it > > is still susceptible to attack, as is the entire CAPWAP > > encapsulation (should we choose not to protect it). Thus, in > > my view, it does not help a whole lot. Sure, if we believe > > the system is uncompromised then you are correct that the > > data is not readily discernible but can we trust that the > > data has not been compromised anyway? No, not until it has > > gone up to the AC and by that point, it is not clear whether > > the attack occurred at the link between STA and WTP or WTP to AC. > > > > Nancy. > > > > -----Original Message----- > > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > > Sent: Wednesday, June 07, 2006 6:07 PM > > To: capwap > > Subject: Re: [Capwap] Encryption Capabilities > > > > I've been watching this debate with some interest, being > > quite surprised that an optional feature would suddenly draw > > such attention and energy. > > > > Still, I guess I should comment along with everyone else. > > First, I agree with Charles on the point that having or not > > having this feature has no impact on the security properties > > of the capwap protocol itself. Also, I agree with a number of > > folks on the point that these two features are orthogonal. AC > > termination of 802.11 link security does not (indeed, is not > > intended to) provide for capwap data channel security. > > However, this feature is not security-neutral - it provides a > > unique set of security properties that are useful. Before > > explaining further, here are some pictures, along with some > > descriptive text (hoping my webmail interface doesn't mangle them): > > > > KEY > > --- > > # - 802.11 link security boundary > > > > % - capwap security boundary > > > > > > > > Case 1: 802.11 link security terminates at the WTP > > > > ##################### > > # # %%%%%%%%%%%%%%%%%%%%%%% > > # +------+ +#--%-+ CAPWAP +----+ % > > # |client|---------| WTP |===========| AC | % > > # +------+ +#--%-+ +----+ % > > # # %%%%%%%%%%%%%%%%%%%%%%% > > ##################### > > > > > > This is the situation when you en/decrypt 802.11 traffic at > > the WTP. In this case, the client and WTP are within the > > 802.11 link security boundary. Of course, this picture does > > not include key establishment, because during that phase, the > > security boundary is more like the one below, and also, the > > AAA server (not pictured) is involved. Also, one might choose > > to include the AC in the 802.11 link security boundary > > pictured above (even though it doesn't participate in the > > crypto ops) because it is privy to the 802.11 keying > > material, but I'm leaving this out because it simplifies the > > ascii drawing, and will add nothing material to the discussion below. > > > > > > Case 2: 802.11 link security terminates at the AC > > > > > > %%%%%%%%%%%%%%%%% > > % +-----+ % > > /-----------------%--| WTP | % > > | % +--++-+ % > > | % ||capwap % > > | % || % > > | % +---++--+ % > > | % | | % > > | %%%%%%%%%%%%%%%%% > > ##############|############################### > > # +------+ | | AC | # > > # |client|----/ 802.11 | | # > > # +------+ +-------+ # > > ############################################## > > > > > > Here is the case when you en/decrypt 802.11 at the AC. Note > > that the WTP is not within the 802.11 link security boundary. > > It is "out of the loop", so to speak, being little more than > > a transport provider. Also note that the capwap security > > boundary is the same as for case 1 - no change. > > > > Now, let's get to the questions about whether this is useful > > or not, and let's keep in mind that since this is an > > *optional* feature, the "burden of proof" with respect to > > utility is much lower than it would be if it were mandatory > > to implement. > > > > As noted above, in case 2, the WTP is simply a transport > > provider. That means that if the WTP were somehow > > compromised, unless the attacker also compromised one or more > > of the other security mechanisms as well (802.1x, the AC's > > credential, etc), he could do little more than effect a DoS attack. > > > > In case 1, various methods of WTP compromise could give an > > attacker access to the data as it is unencrypted and then > > re-encrypted. In this case, the attacker gets access to the > > cleartext data via relatively low-cost methods (compared to > > breaking .11 crypto), essentially attacking the weakest link. > > > > In case 2, WTP's can be deployed in hostile territory, and if > > the attacker can't break the 802.11 crypto, he can't have the > > same security impact (aside from DoS, which he can have in > > any event). It's like running 802.11 security over the air - > > he has to break the crypto. No matter how completely the > > attacker might compromise a WTP, all he will see is encrypted > > data. This is good! > > > > Of course, there is additional value to the centralized > > encryption model, as Dorothy Stanley pointed out: > > architectural flexibility, enabling CAPWAP compliant > > solutions to centralize the 802.11i crypto functions in the > > AC if they wish, reducing dependencies on WTP capabilities > > (e.g. legacy hardware that only supports TKIP), potentially > > support a broader range of existing and future applications > > - even when the primary motivation is not 'to secure the > > WTP-AC data connection'". Some vendors chose this approach to > > MAC splitting while others chose encryption at the WTP. > > That's one reason why it should remain optional. > > > > --Scott > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_69624_26204282.1150123338190 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I support Mike's suggestion for solving the original issue raised by David:

move Encryption Capabilities from the WTP Descriptor (Section 4.4.34) to the WTP Radio Information message element (Section 4.4.39)

On 6/9/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
I agree with Nancy. It's almost like CAPWAP products would need to
ship a "security requirements table", and allow the customer to pick
and choose from what they think they need, and then enable the various
features. Why not simply support a single mechanism that is a superset
of all features and call it a day?

There isn't a single mechanism to support all features. One feature
is to decrypt at the AC. This enables capwap implementations to
provide functionality not available at the WTP. Another feature is to
protect data over the WTP/AC link. These are not the same.

We seem to be contradicting ourselves here. In some threads we are
arguing for protocol simplicity, then in others we seem to accept
complexity (and, yes, I view multiple options that provide similar
features are adding complexity, because in the end we all have to
implement them, and leave it to the customer to deal with the issue).

 In the case
we are discussing here, implementation of 802.11 crypto at the
AC is an optional feature. It is not required, and need not be implemented.

To date, other than stating that "we need to support it", no one has
been able to state how 802.11i packet encryption services in the AC
allows an AC/WTP to actually support the complete 802.11 protocol.

There are mandatory and optional portions of the 802.11 protocol.
For example,  both security and QOS are optional portions of the
protocol, and the QOS services that are typically supported are WMM based,
not 802.11(e) based. 802.11i packet encryption services in the AC
allow the AC to support, for example AES encryption for WTPs which
do not support it, and allows vendor flexibility. It is an option that is
currently in the draft - do not have to implement if you don't want to, e.g.
an AC implementation that supports local MAC only does not have to do this.


However, the MUX issue has raised another interesting problem, which
was raised by Scott, which is that in order for the WTP to perform
packet classification, and tagging, it needs to have access to the
data frames in the clear, which is not possible with this feature.

The WTP can perform marking by
mapping the WMM or 802.11e header info into DSCP/.1q/.1d markings
Access to data frames in the clear is not needed.

so I see this as just adding yet another option for end users to deal
with. BTW, if we need the WTP to do packet classification, we need
to create a new issue because the protocol does not have the means
to push down rules.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems



> -----Original Message-----
> From: Nancy Winget (ncamwing)
> Sent: Thursday, June 08, 2006 3:38 PM
> To: Scott G. Kelly; capwap
> Subject: Re: [Capwap] Encryption Capabilities
>
> While it is true that the originating 802.11 data payload
> will be obscured, it is not clear to me that we can construe
> it as "good".
> Since there is no protection of the CAPWAP encapsulation, it
> is still susceptible to attack, as is the entire CAPWAP
> encapsulation (should we choose not to protect it).  Thus, in
> my view, it does not help a whole lot.  Sure, if we believe
> the system is uncompromised then you are correct that the
> data is not readily discernible but can we trust that the
> data has not been compromised anyway?  No, not until it has
> gone up to the AC and by that point, it is not clear whether
> the attack occurred at the link between STA and WTP or WTP to AC.
>
>       Nancy.
>
> -----Original Message-----
> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com]
> Sent: Wednesday, June 07, 2006 6:07 PM
> To: capwap
> Subject: Re: [Capwap] Encryption Capabilities
>
> I've been watching this debate with some interest, being
> quite surprised that an optional feature would suddenly draw
> such attention and energy.
>
> Still, I guess I should comment along with everyone else.
> First, I agree with Charles on the point that having or not
> having this feature has no impact on the security properties
> of the capwap protocol itself. Also, I agree with a number of
> folks on the point that these two features are orthogonal. AC
> termination of 802.11 link security does not (indeed, is not
> intended to) provide for capwap data channel security.
> However, this feature is not security-neutral - it provides a
> unique set of security properties that are useful. Before
> explaining further, here are some pictures, along with some
> descriptive text (hoping my webmail interface doesn't mangle them):
>
> KEY
> ---
>    # - 802.11 link security boundary
>
>    % - capwap security boundary
>
>
>
> Case 1: 802.11 link security terminates at the WTP
>
>    #####################
>    #                   #  %%%%%%%%%%%%%%%%%%%%%%%
>    # +------+         +#--%-+   CAPWAP  +----+  %
>    # |client|---------| WTP |===========| AC |  %
>    # +------+         +#--%-+           +----+  %
>    #                   #  %%%%%%%%%%%%%%%%%%%%%%%
>    #####################
>
>
> This is the situation when you en/decrypt 802.11 traffic at
> the WTP. In this case, the client and WTP are within the
> 802.11 link security boundary. Of course, this picture does
> not include key establishment, because during that phase, the
> security boundary is more like the one below, and also, the
> AAA server (not pictured) is involved. Also, one might choose
> to include the AC in the 802.11 link security boundary
> pictured above (even though it doesn't participate in the
> crypto ops) because it is privy to the 802.11 keying
> material, but I'm leaving this out because it simplifies the
> ascii drawing, and will add nothing material to the discussion below.
>
>
> Case 2: 802.11 link security terminates at the AC
>
>
>                                    %%%%%%%%%%%%%%%%%
>                                    %  +-----+      %
>                  /-----------------%--| WTP |      %
>                  |                 %  +--++-+      %
>                  |                 %     ||capwap  %
>                  |                 %     ||        %
>                  |                 % +---++--+     %
>                  |                 % |       |     %
>                  |                 %%%%%%%%%%%%%%%%%
>    ##############|###############################
>    # +------+    |                   |   AC  |  #
>    # |client|----/   802.11          |       |  #
>    # +------+                        +-------+  #
>    ##############################################
>
>
> Here is the case when you en/decrypt 802.11 at the AC. Note
> that the WTP is not within the 802.11 link security boundary.
> It is "out of the loop", so to speak, being little more than
> a transport provider. Also note that the capwap security
> boundary is the same as for case 1 - no change.
>
> Now, let's get to the questions about whether this is useful
> or not, and let's keep in mind that since this is an
> *optional* feature, the "burden of proof" with respect to
> utility is much lower than it would be if it were mandatory
> to implement.
>
> As noted above, in case 2, the WTP is simply a transport
> provider. That means that if the WTP were somehow
> compromised, unless the attacker also compromised one or more
> of the other security mechanisms as well (802.1x, the AC's
> credential, etc), he could do little more than effect a DoS attack.
>
> In case 1, various methods of WTP compromise could give an
> attacker access to the data as it is unencrypted and then
> re-encrypted. In this case, the attacker gets access to the
> cleartext data via relatively low-cost methods (compared to
> breaking .11 crypto), essentially attacking the weakest link.
>
> In case 2, WTP's can be deployed in hostile territory, and if
> the attacker can't break the 802.11 crypto, he can't have the
> same security impact (aside from DoS, which he can have in
> any event). It's like running 802.11 security over the air -
> he has to break the crypto. No matter how completely the
> attacker might compromise a WTP, all he will see is encrypted
> data. This is good!
>
> Of course, there is additional value to the centralized
> encryption model, as Dorothy Stanley pointed out:
> architectural flexibility, enabling CAPWAP compliant
> solutions to centralize the 802.11i crypto functions in the
> AC if they wish, reducing dependencies on WTP capabilities
> (e.g. legacy hardware that only supports TKIP), potentially
> support a broader range of existing and future applications
> - even when the primary motivation is not 'to secure the
> WTP-AC data connection'". Some vendors chose this approach to
> MAC splitting while others chose encryption at the WTP.
> That's one reason why it should remain optional.
>
> --Scott
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_69624_26204282.1150123338190-- --===============0629033034== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0629033034==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 12 11:04:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpnyM-0003Rb-7X for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 11:04:58 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpnyM-0000t5-4p for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 11:04:58 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FpnyK-0001I4-20 for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 11:04:58 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A796F430108 for ; Mon, 12 Jun 2006 08:04:54 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 402194300A2 for ; Mon, 12 Jun 2006 08:04:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2A5861448005 for ; Mon, 12 Jun 2006 08:04:10 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by hermes.tigertech.net (Postfix) with ESMTP id 5AD881448024 for ; Mon, 12 Jun 2006 08:04:07 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 12 Jun 2006 08:04:06 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k5CF46Mf022762; Mon, 12 Jun 2006 08:04:06 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5CF46ke020201; Mon, 12 Jun 2006 08:04:06 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 08:04:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 Jun 2006 08:04:05 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20203802C@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Encryption Capabilities Thread-Index: AcaOLnf00KvKSdI/SNqQ63ZC0PezqgAAtEsw From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" X-OriginalArrivalTime: 12 Jun 2006 15:04:06.0537 (UTC) FILETIME=[73496790:01C68E31] Authentication-Results: sj-dkim-1.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0083759465==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.5 (--) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 This is a multi-part message in MIME format. --===============0083759465== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68E31.7316B5EB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68E31.7316B5EB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable However, the MUX issue has raised another interesting problem, which was raised by Scott, which is that in order for the WTP to perform=20 packet classification, and tagging, it needs to have access to the data frames in the clear, which is not possible with this feature. The WTP can perform marking by mapping the WMM or 802.11e header info into DSCP/.1q/.1d markings=20 Access to data frames in the clear is not needed. As raised a few times, one cannot trust a client's marking. Centralized 802.11i encryption does not allow the WTP to inspect packets for TSPEC conformance. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C68E31.7316B5EB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
However, the MUX issue has = raised another=20 interesting problem, which
was raised by Scott, which is that in = order for=20 the WTP to perform
packet classification, and tagging, it needs to = have=20 access to the
data frames in the clear, which is not possible with = this=20 feature.

The WTP can perform = marking=20 by
mapping the WMM or 802.11e header info into DSCP/.1q/.1d markings=20
Access to data frames in the clear is not needed.
As=20 raised a few times, one cannot trust a client's marking.=20 Centralized
802.11i encryption does not allow the WTP to inspect packets = for=20 TSPEC
conformance.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 
------_=_NextPart_001_01C68E31.7316B5EB-- --===============0083759465== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0083759465==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 12 11:06:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpnzh-0003lk-BM for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 11:06:21 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpnzg-000156-F1 for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 11:06:21 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 17C0F43013B for ; Mon, 12 Jun 2006 08:06:20 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1E1FF430126 for ; Mon, 12 Jun 2006 08:04:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 03EDB1448003 for ; Mon, 12 Jun 2006 08:04:39 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id 80418144801F for ; Mon, 12 Jun 2006 08:04:35 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 12 Jun 2006 08:04:34 -0700 X-IronPort-AV: i="4.05,229,1146466800"; d="scan'208,217"; a="293146930:sNHT58847172" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5CF4Y8Q029998; Mon, 12 Jun 2006 08:04:34 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5CF4Yke020403; Mon, 12 Jun 2006 08:04:34 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 08:04:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 Jun 2006 08:04:33 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20203802D@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 105 - Reset IEEE 802.11 statistics/was Re: somesuggestion for 802.11 binding TLV Thread-Index: AcaOKjXUFb3DNk7PSJ6e0JjBNNU4BAAB0few From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "Romascanu, Dan (Dan)" X-OriginalArrivalTime: 12 Jun 2006 15:04:34.0427 (UTC) FILETIME=[83E914B0:01C68E31] Authentication-Results: sj-dkim-4.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com, young Subject: Re: [Capwap] Issue 105 - Reset IEEE 802.11 statistics/was Re: somesuggestion for 802.11 binding TLV X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0791061983==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: da36eda0a3266ed30a56c496b15b76c7 This is a multi-part message in MIME format. --===============0791061983== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68E31.83B67B75" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68E31.83B67B75 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with this proposed solution. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Monday, June 12, 2006 7:12 AM To: Romascanu, Dan (Dan) Cc: Pat Calhoun (pacalhou); young; capwap@frascone.com Subject: Re: [Capwap] Issue 105 - Reset IEEE 802.11 statistics/was Re: somesuggestion for 802.11 binding TLV =09 =09 All, =09 Proposed resolution to Issue 105: Reject,=20 =09 with the reason that: When using statistics objects in order to understand 'the real state of the network' an administrator MUST NOT rely on the absolute values of statistic objects (typically counters), but on the delta values of successive readings, correlated with the timestamp of the reading. =09 with no change to the text. =09 Thanks, =09 Dorothy =09 =09 On 6/6/06, Romascanu, Dan (Dan) wrote:=20 I do not believe that a "reset IEEE 802.11 Statistics" TLV is useful. Actually it may be harmful. =09 When using statistics objects in order to understand 'the real state of the network' an administrator MUST NOT rely on the absolute values of=20 statistic objects (typically counters), but on the delta values of successive readings, correlated with the timestamp of the reading. =09 =09 Dan =09 =09 =09 =09 =09 =09 > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com] > Sent: Tuesday, June 06, 2006 3:55 AM > To: Dorothy Stanley; young > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 105 - Reset IEEE 802.11 > statistics/was Re: somesuggestion for 802.11 binding TLV > > Dorothy, Here is text from the original post: > > 1) New TLV "reset IEEE 802.11 Statistics" > > a) Why we need it?=20 > > Now, the draft defines "IEEE 802.11 Statistics" to report > Multicast Tx Count, Multiple Retry Count and so on. As AP > keep updating the statistic value, after some time, the > statistic value will become very great, and it could not=20 > reflect the real state of network. So administrator need a > method to reset IEEE 802.11 Statistics" > > b) The TLV could be carried in the "Configure Update request" > > c) The TLV format is as follow:=20 > > 0 1 2 3 4 5 6 7 > > +-+-+-+-+-+-+-+-+ > > | Radio ID | > > +-+-+-+-+-+-+-+-+ > > When AP side get radio id from TLV, it will reset the=20 > radio as per radio ID. > > d) Other suggestion: > > Whether it needs a "Reset interval" element? By this way, > user could configure after how many time (seconds) AP will > reset Statistics for a specific radio. > > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > ________________________________=20 > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > Sent: Wednesday, May 24, 2006 11:33 AM > To: young > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: Issue 105 - Reset IEEE 802.11 statistics/was Re: > [Capwap] some suggestion for 802.11 binding TLV > > > All,=20 > > I would like to develop text to resolve Issue 105, but > need some more information as to exactly what the > issue is. Input please. The discussion on issue 105 > to date is listed below.=20 > > Thanks, > > Dorothy > > > > > On 4/19/06, young wrote: > > Dear all: > > > > I have some suggestion about CAPWAP > draft, please kindly discuss it. > > 1) For IEEE 802.11 Statistics > > I suggest we should add new TLV for "reset IEEE > 802.11 Statistics" > > > Issue 105 has been opened for item (1). > > Can you provide suggested text for a=20 > description of the proposed TLV? This will enable a more > informed discussion, and > give insight into the problem that is being solved. > Is this a boolean, which when set causes the > WTP to reset all of its statistics collection counters? > Is it included in the statistics message > element? A new message element? In which message elements > and messages would it be included? > > > > > > > _________________________________________________________________=20 > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > =09 ------_=_NextPart_001_01C68E31.83B67B75 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 agree with this proposed solution.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Monday, June 12, 2006 = 7:12=20 AM
To: Romascanu, Dan (Dan)
Cc: Pat Calhoun = (pacalhou);=20 young; capwap@frascone.com
Subject: Re: [Capwap] Issue 105 - = Reset=20 IEEE 802.11 statistics/was Re: somesuggestion for 802.11 binding=20 TLV

All,

Proposed resolution to Issue 105: Reject, =

with=20 the reason that:
When using statistics objects in order to = understand 'the=20 real state of
the network' an administrator MUST NOT rely on the = absolute=20 values of
statistic objects (typically counters), but on the delta = values=20 of
successive readings, correlated with the timestamp of the=20 reading.

with no change to the=20 text.

Thanks,

Dorothy

On 6/6/06, Romascanu,=20 Dan (Dan) <dromasca@avaya.com> = wrote:
I=20 do not believe that a "reset IEEE 802.11 Statistics" TLV is=20 useful.
Actually it may be harmful.

When using statistics = objects=20 in order to understand 'the real state of
the network' an = administrator=20 MUST NOT rely on the absolute values of
statistic objects = (typically=20 counters), but on the delta values of
successive readings, = correlated=20 with the timestamp of the=20 reading.


Dan






> = -----Original=20 Message-----
> From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com]
> = Sent:=20 Tuesday, June 06, 2006 3:55 AM
> To: Dorothy Stanley; = young
>=20 Cc: capwap@frascone.com
>=20 Subject: Re: [Capwap] Issue 105 - Reset IEEE 802.11
> = statistics/was=20 Re: somesuggestion for 802.11 binding TLV
>
> Dorothy, = Here is=20 text from the original post:
>
> 1) New TLV "reset IEEE = 802.11=20 Statistics"
>
> a) Why we need it?
>
> Now, = the=20 draft defines "IEEE 802.11 Statistics" to report
> Multicast = Tx Count,=20 Multiple Retry Count and so on. As AP
> keep updating the = statistic=20 value, after some time, the
> statistic value will become very = great,=20 and it could not
> reflect the real state of network. So=20 administrator need a
> method to reset IEEE 802.11=20 Statistics"
>
> b) The TLV could be carried in the = "Configure=20 Update request"
>
> c) The TLV format is as follow:=20
>
>       0 1 2 3 4 5 6=20 = 7
>
>      +-+-+-+-+-+-+-+-+>
>      |  =20 Radio ID  =20 = |
>
>      +-+-+-+-+-+-+-+-+>
>    When=20 AP side get radio id from TLV, it will reset the
> radio as = per radio=20 ID.
>
> d) Other suggestion:
>
> Whether it = needs a=20 "Reset interval" element? By this way,
> user could configure = after=20 how many time (seconds) AP will
> reset Statistics for a = specific=20 radio.
>
>
>
> Pat Calhoun
> CTO, = Wireless=20 Networking Business Unit
> Cisco=20 Systems
>
>
>
>
>=20 ________________________________=20
>
>       From: Dorothy = Stanley=20 [mailto:dstanley1389@gmail.com]
>= ;      =20 Sent: Wednesday, May 24, 2006 11:33=20 AM
>       To:=20 young
>       Cc: Pat Calhoun=20 (pacalhou); capwap@frascone.com
> =      =20 Subject: Issue 105 - Reset IEEE 802.11 statistics/was Re:
> = [Capwap]=20 some suggestion for 802.11 binding=20 TLV
>
>
>       All, =
>
>       I would like to = develop=20 text to resolve Issue 105, but
> need some more information as = to=20 exactly what the
>       issue=20 is.  Input please.  The discussion on issue = 105
>=20 to date is listed below.=20
>
>      =20 Thanks,
>
>      =20 = Dorothy
>
>
>
>
>    &n= bsp;         =20 On 4/19/06, young <young@huawei-3com.com>=20 = wrote:
>
>        &nb= sp;           &nbs= p; =20 Dear=20 = all:
>
>
>
>      &= nbsp;           &n= bsp;   =20 I have some suggestion about CAPWAP
> draft, please kindly = discuss=20 = it.
>
>         =             &= nbsp;=20 1) For IEEE 802.11=20 = Statistics
>
>        = ;            =   =20 I suggest we should add new TLV for "reset IEEE
> 802.11=20 = Statistics"
>
>
>      &n= bsp;       =20 Issue 105 has been opened for item=20 = (1).
>
>         = ;     =20 Can you provide suggested text for a
> description of the = proposed=20 TLV?  This will enable a more
> informed discussion, = = and
>          &n= bsp;   =20 give insight into the problem that is being=20 = solved.
>         &nbs= p;    =20 Is this a boolean, which when set causes the
> WTP to reset = all of its=20 statistics collection=20 = counters?
>         &n= bsp;    =20 Is it included in the statistics message
> element? A new = message=20 element?  In which message elements
> and messages = would it=20 be included?
>
>
>
>
>
>
> = _________________________________________________________________ =
>=20 To unsubscribe or modify your subscription options, please = visit:
> http://lists.f= rascone.com/mailman/listinfo/capwap
>
>=20 Archives: http://lists.frascone= .com/pipermail/capwap
>

= ------_=_NextPart_001_01C68E31.83B67B75-- --===============0791061983== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0791061983==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 12 11:07:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpo0U-00045D-N5 for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 11:07:10 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpo0T-0001Nx-PG for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 11:07:10 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5F4D443016B for ; Mon, 12 Jun 2006 08:07:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id DC32C4300A2 for ; Mon, 12 Jun 2006 08:05:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B8B601448005 for ; Mon, 12 Jun 2006 08:05:35 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by hermes.tigertech.net (Postfix) with ESMTP id 983AF1448018 for ; Mon, 12 Jun 2006 08:05:32 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 12 Jun 2006 08:05:31 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5CF5W9t011136; Mon, 12 Jun 2006 08:05:32 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5CF5W9s013584; Mon, 12 Jun 2006 08:05:32 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 08:05:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 Jun 2006 08:05:31 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202038030@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 134/wasRe: New Issue - LocalMAC MUST vs MAY forward associationrequest messages Thread-Index: AcaOKeihi7Rqizl7SyaJy21X5C9LVQAB7o0Q From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "Michael Montemurro" X-OriginalArrivalTime: 12 Jun 2006 15:05:32.0176 (UTC) FILETIME=[A654E100:01C68E31] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Proposed Resolution to Issue 134/wasRe: New Issue - LocalMAC MUST vs MAY forward associationrequest messages X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0853884561==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: b6e18fadcfab41fa5e7faede753de4c2 This is a multi-part message in MIME format. --===============0853884561== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68E31.A6226ED5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68E31.A6226ED5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable yup - that works for me. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Monday, June 12, 2006 7:09 AM To: Michael Montemurro Cc: capwap Subject: [Capwap] Proposed Resolution to Issue 134/wasRe: New Issue - LocalMAC MUST vs MAY forward associationrequest messages =09 =09 Pat, David, =09 Agree that the AC must be notified. However the text also states that=20 " the AC MAY reply with a failed Association Response if it deems it necessary. " =09 introducing a race condition, when the WTP may have already responded to the Association Request with an Association Response (success), before it receives the "failed Association Response" from the AC.=20 =09 Proposed resolution of Issue 134: =09 Change from: =09 While the MAC is terminated on the WTP, it is necessary for the=20 AC to be aware of mobility events within the WTPs. As a consequence, the WTP MUST forward the IEEE 802.11 Association Requests to the AC, and the AC MAY reply with a failed Association Response if it deems it necessary.=20 =09 to =09 While the MAC is terminated on the WTP, it is necessary for the=20 AC to be aware of mobility events within the WTPs. As a consequence, the WTP MUST forward the IEEE 802.11 Association Requests to the AC. The AC MAY reply with a failed Association Response if it deems it necessary, and upon=20 receipt of a failed Association Response from the AC, the WTP must send a Disassociation frame to the mobile station. =09 Thanks, =09 Dorothy =09 =09 On 6/8/06, Michael Montemurro wrote:=20 I've captured this as issue 134. =20 Cheers, =20 Mike =20 On 6/6/06, Dorothy Stanley < dstanley1389@gmail.com > wrote:=20 =09 Pat, David, =20 Your comments are consistent with those received back in April, when this mail was sent out - thus I did not make, and had not planned to make the proposed change.=20 =20 Thanks, =09 =20 Dorothy =09 =20 =09 On 6/6/06, David T. Perkins wrote:=20 HI, =09 ABSOLUTELY agree with Pat. That is the AC MUST know what STAs are be serviced by the WTPs, and MUST decide which STAs are=20 allowed to associate and send traffic. This is the fundamental difference between a CAPWAP network and a collection of APs. =09 Regards, /david t. perkins =09 On Tue, 6 Jun 2006, Pat Calhoun (pacalhou) wrote:=20 =09 > I disagree with this change request. The AC MUST know what STAs are > being serviced by WTPs. The term MUST cannot be changed to MAY. > > > Pat Calhoun > CTO, Wireless Networking Business Unit=20 > Cisco Systems > > > > > ________________________________ > > From: Dorothy Stanley [mailto: dstanley1389@gmail.com ] > Sent: Tuesday, April 11, 2006 11:41 AM=20 > To: capwap > Subject: [Capwap] New Issue - Local MAC MUST vs MAY forward > associationrequest messages >=20 > > All, > > Section 11.1.2 Local MAC describes the Local MAC operation. It=20 > currently states > (second paragraph below Figure 6): > > While the MAC is terminated on the WTP, it is necessary for the=20 > AC to be aware of mobility events within the WTPs. > As a consequence, the WTP MUST forward the IEEE 802.11 > Association Requests to the AC, and the AC MAY reply > with a failed Association Response if it deems it necessary.=20 > > > Since this is the Local MAC case, it seems that a MAY should be > sufficient. > > Recommended change: > > The MAC is terminated on the WTP, but the AC may need to be=20 > aware of mobility events within the WTPs. > As a consequence, the WTP MAY forward the IEEE 802.11 > Association Requests to the AC, and the AC MAY reply > with a failed Association Response.=20 > > Comments? > > Thanks, > > Dorothy > > > =09 =09 =09 _________________________________________________________________=20 To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap=20 =09 Archives: http://lists.frascone.com/pipermail/capwap =09 =09 ------_=_NextPart_001_01C68E31.A6226ED5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
yup -=20 that works for me.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Monday, June 12, 2006 = 7:09=20 AM
To: Michael Montemurro
Cc: = capwap
Subject:=20 [Capwap] Proposed Resolution to Issue 134/wasRe: New Issue - LocalMAC = MUST vs=20 MAY forward associationrequest messages

Pat, David,

Agree that the AC must be notified. = However the=20 text also states that
" the AC=20 MAY reply
 with a failed Association Response if it deems it=20 necessary. "

introducing a race condition, when the WTP may = have=20 already responded to the
Association Request with an Association = Response=20 (success), before it
receives the "failed Association Response" = from the=20 AC.

Proposed resolution of Issue = 134:

Change=20 from:

While the = MAC is=20 terminated on the WTP, it is necessary for the
AC to be aware of = mobility=20 events within the WTPs.
As a consequence, the WTP MUST forward the = IEEE=20 802.11
Association Requests to the AC, and the AC MAY = reply
 with a=20 failed Association Response if it deems it necessary.=20

to

While the MAC is terminated on the = WTP, it is=20 necessary for the
AC to be aware of mobility events within the = WTPs.
As=20 a consequence, the WTP MUST forward the IEEE 802.11
Association = Requests to=20 the AC. The AC MAY reply
with a failed Association Response if it = deems it=20 necessary, and upon
receipt of a failed Association Response from = the=20 AC,  the
WTP must send a Disassociation frame to the mobile=20 station.

Thanks,

Dorothy

On 6/8/06, Michael=20 Montemurro <montemurro.michael@gmail.com= >=20 wrote:
I've captured this as issue 134.
 
Cheers,
 
Mike


 
On=20 6/6/06, Dorothy Stanley <=20 dstanley1389@gmail.com> wrote:
Pat, David,
 
Your comments are consistent with those received back in April, = when
this mail was sent out - thus
I did not make, and had not planned to make the proposed = change.
 
Thanks,
 
Dorothy

 
On 6/6/06, David T.=20 Perkins <dperkins@dsperkins.com=20 > wrote:=20
HI,

ABSOLUTELY=20 agree with Pat. That is the AC MUST know what STAs
are be = serviced by=20 the WTPs, and MUST decide which STAs are
allowed to associate = and send=20 traffic.
This is the fundamental difference between a CAPWAP=20 network
and a collection of APs.

Regards,
/david t.=20 perkins

On Tue, 6 Jun 2006, Pat Calhoun (pacalhou) wrote:=20

> I disagree with this change request. The AC MUST know = what=20 STAs are
> being serviced by WTPs. The term MUST cannot be = changed=20 to MAY.
>
>
> Pat Calhoun
> CTO, Wireless=20 Networking Business Unit
> Cisco=20 Systems
>
>
>
>
>=20 = ________________________________
>
>    &= nbsp; =20 From: Dorothy Stanley [mailto:=20 = dstanley1389@gmail.com]
>      =20 Sent: Tuesday, April 11, 2006 11:41 AM=20
>       To:=20 capwap
>       Subject: = [Capwap] New=20 Issue - Local MAC MUST vs MAY forward
> associationrequest=20 messages
> =
>
>      =20 All,
>
>       Section = 11.1.2=20 Local MAC describes the Local MAC operation. It
> currently = states
>       (second = paragraph below=20 Figure 6):
>
>       = While the=20 MAC is terminated on the WTP, it is necessary for the
> AC = to be=20 aware of mobility events within the=20 WTPs.
>       As a = consequence, the=20 WTP MUST forward the IEEE 802.11
> Association Requests to = the AC,=20 and the AC MAY reply
>       = with a=20 failed Association Response if it deems it necessary.=20
>
>
>       Since = this is=20 the Local MAC case, it seems that a MAY should=20 be
>      =20 sufficient.
>
>      =20 Recommended = change:
>
>      =20 The MAC is terminated on the WTP, but the AC may need to be =
> aware=20 of mobility events within the=20 WTPs.
>       As a = consequence, the=20 WTP MAY forward the IEEE 802.11
> Association Requests to = the AC,=20 and the AC MAY reply
>       = with a=20 failed Association Response.=20
>
>      =20 Comments?
>
>      =20 Thanks,
>
>      =20 = Dorothy
>
>
>



=
_________________________________________________________________=20
To unsubscribe or modify your subscription options, please = visit:
http://lists.frascone.com/mailman/listinfo/capwap=20

Archives: http://lists.frascone.com/pipermail/capwap



------_=_NextPart_001_01C68E31.A6226ED5-- --===============0853884561== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0853884561==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 12 11:43:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpoZs-0003kU-Hk for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 11:43:44 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpoZr-0006N8-30 for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 11:43:44 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7026C4301A7 for ; Mon, 12 Jun 2006 08:43:42 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 76A094300EC for ; Mon, 12 Jun 2006 08:42:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 633A3430AA7 for ; Mon, 12 Jun 2006 08:42:16 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by hermes.tigertech.net (Postfix) with ESMTP id C7214430AA2 for ; Mon, 12 Jun 2006 08:42:13 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 12 Jun 2006 08:42:13 -0700 X-IronPort-AV: i="4.05,229,1146466800"; d="scan'208"; a="430614228:sNHT37138132" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5CFgDW4016724 for ; Mon, 12 Jun 2006 08:42:13 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5CFgD9s008214 for ; Mon, 12 Jun 2006 08:42:13 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 08:42:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 Jun 2006 08:42:11 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC01A24F95@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] capwap transport analysis: QoS vs multiport Thread-Index: AcaMJe9FO1fqSIwcQ7CQnsvy8fSdcwCCx2wQ From: "Bob O'Hara (boohara)" To: "capwap" X-OriginalArrivalTime: 12 Jun 2006 15:42:13.0250 (UTC) FILETIME=[C6461E20:01C68E36] Authentication-Results: sj-dkim-3.cisco.com; header.From=boohara@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] capwap transport analysis: QoS vs multiport X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Scott, Of course you can't respond to my specific arguments, because they show your line of reasoning to be without any merit. Let's just leave it at that. -Bob -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: Friday, June 09, 2006 5:37 PM To: Bob O'Hara (boohara); capwap Subject: Re: [Capwap] capwap transport analysis: QoS vs multiport >Also, please see my specific comments, below. Yes, I read them, and I think it would be less than productive to do a blow-by-blow reply. You clearly feel quite strongly about this. Let's let everyone else review the post on their own, and see what they think. Chill out, have a nice weekend, and we can discuss on Monday. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 12 12:31:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FppJr-0000Jz-Uq for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 12:31:15 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpoUy-0005XV-US for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 11:38:41 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FpoK5-0001fj-2j for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 11:27:27 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6333F430133 for ; Mon, 12 Jun 2006 08:27:24 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7E5944300A2 for ; Mon, 12 Jun 2006 08:26:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 702241448003 for ; Mon, 12 Jun 2006 08:26:25 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.196]) by hermes.tigertech.net (Postfix) with ESMTP id 3606E1448005 for ; Mon, 12 Jun 2006 08:26:19 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id t13so871503wxc for ; Mon, 12 Jun 2006 08:26:18 -0700 (PDT) Received: by 10.70.100.17 with SMTP id x17mr6558837wxb; Mon, 12 Jun 2006 08:26:18 -0700 (PDT) Received: by 10.70.133.2 with HTTP; Mon, 12 Jun 2006 08:26:18 -0700 (PDT) Message-ID: <5bfe7a820606120826j2d650778k5d7c2f3044e34999@mail.gmail.com> Date: Mon, 12 Jun 2006 08:26:18 -0700 From: "Dorothy Stanley" To: "Saravanan Govindan" In-Reply-To: <5bfe7a820605241121g2efe49ffkb33a349365b7cdde@mail.gmail.com> MIME-Version: 1.0 References: <5bfe7a820605241121g2efe49ffkb33a349365b7cdde@mail.gmail.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.6 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_50_60, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Statistics for WTP Event Request - Issue 84 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1111498401==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -1.9 (-) X-Scan-Signature: 28c4c369715777944de1d586eee1c7cb --===============1111498401== Content-Type: multipart/alternative; boundary="----=_Part_70140_2399902.1150125978430" ------=_Part_70140_2399902.1150125978430 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, I'd like to make progress on issue 84 in the -02 draft, and had sent the proposal below a while ago. Comments please. Thanks, Dorothy On 5/24/06, Dorothy Stanley wrote: > > Saravanan, all, > > Agreed. > > This mail discusses the Issue 84 proposed statistics, and proposes > additional statistics. > > -------------------Issue 84---------------------------- > > introduce a "Statistics" message element with the > following fields. > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | WTP Load | WTP Transmit Queue | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Channel Interference | Congestion | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type: TBD > > WTP Load: A 16-bit value specifying the load (frames/sec) exchanged by the WTP. > > > WTP Transmit Queue: A 16-bit value specifying the prevailing queue level as a > portion of total queue size. > > Channel Interference: A 16-bit value specifying SINR (dB) monitored by the WTP. > > Congestion: A 16-bit value specifying the congestion experienced by the WTP. > > ----------------------------End of Issue 84------------------------------ > > WTP Load - load in frames per second exchanged by the WTP - Assuming that > the exchange is over the air; Add "Wireless Link Frames/Sec" statistics > field > in a new WTP Operational Statistics message element > > WTP Transmit Queue - as a percentage of queue size - Which Queue is this? > going to the AC or the STA? > If to the STA, then the statistic may vary with the L2 wireless type, e.g., > is it a > single queue for non-WMM traffic? multiple statistics for each of the WMM > queues, or an > aggregate of all wireless transmit queues? > > Channel Interference - SINR - this is radio dependent, include a noise > floor in the > proposed WTP Radio Statistics message element > > Congestion - Congestion experienced by the WTP - Need more info here, is > this congestion on the > WTP-AC link? How is it measured? > > Propose new WTP specific statistics: > > - Add more fields/detail to the WTP Reboot Statistics message element, > see 4.4.43 > - Add a new WTP Operational Statistics message element > - Add a new WTP Radio Statistics message element, as shown below > > > - Add the WTP Radio Statistics and WTP Reboot Statistics and WTP > Operational > Statistics message elements to the list of valid message elements in the > WTP Event Message description, section 9.5. > > > WTP Reboot Statistics > > The WTP Reboot Statistics message element is sent by the WTP to the > AC to communicate reasons why reboots have occurred. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > | Reboot Count | AC Initiated Count > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > | Link Failure Count | SW Failure Count > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++ > | HW Failure Count | Other Failure Count > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++ > | Unknown Failure Count | Last Fail Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Type: 43 for WTP Reboot Statistics > > Length: 15 > > Reboot Count: The number of reboots that have occurred due to a WTP > crash. A value of 65535 implies that this information is not > available on the WTP. > > AC Initiated Count: The number of reboots that have occurred at > the request of a CAPWAP protocol message, such as a change in > configuration that required a reboot or an explicit CAPWAP reset > request. A value of 65535 implies that this information is not > available on the WTP. > > Link Failure Count: The number of times that a CAPWAP protocol > connection with an AC has failed due to link failure. > > SW Failure Count: The number of times that a CAPWAP protocol < ==New > connection with an AC has failed due to software related reasons. > > HW Failure Count: The number of times that a CAPWAP protocol <==New > connection with an AC has failed due to hardware related reasons. > > Other Failure Count: The number of times that a CAPWAP protocol <==New > connection with an AC has failed due to known reasons, other than AC > initiated, > link, SW or HW failure. > > Unknown Failure Count: The number of times that a CAPWAP protocol > <==New > connection with an AC has failed for unknown reasons. > > Last Failure Type: The failure type of the most recent WTP failure. > The following values are <== expanded > supported: > > 0 - Not supported > > 1 - AC Initiated (see Section 9.3) > > 2 - Link Failure > > 3 - Software failure > > 4 - Hardware Failure > > 5 - Other Failure > > 255 - Unknown > > > ------------------------------------------------------------------------------------------------------ > WTP Operational Statistics <==New > > The WTP Operational Statistics message element is sent by the WTP to > the > AC to provide statistics realted to the operation of the WTP. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > | Wireless Link Frames/Sec | (Expect more fields to be > added... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++++++ > > Type: TBD for WTP Operational Statistics > > Length: xx > > Wireless Link Frames/Sec: The number of frames transmitted or received > per > second by the WTP over the sir interface. > > > -------------------------------------------------------------------------------------------------------------------- > > Proposed New message element: <==New > > WTP Radio Statistics > > The WTP Radio Statistics message element is sent by the WTP to the > AC to communicate statistics on radio behavior and reasons why the WTP > radio has been reset. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > | Radio ID |Last Fail Type | Reset Count > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > | SW Failure Count | HW Failure Count > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++ > | Other Failure Count | Unknown Failure Count | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++ > | Config Update Count | Channel Change Count | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Band Change Count | Current Noise Floor > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Type: TBD for WTP Radio Statistics > > Length: 20 > > Radio ID: The radio ID of the radio to which the statistics apply. > > Last Failure Type: The failure type of the most recent radio failure. > The following values are > supported: > > 0 - Not supported > > 1 - Software failure > > 2 - Hardware Failure > > 3 - Other Failure > > 255 - Unknown > > Reset Count: The number of times that the radio > has been reset. > > SW Failure Count: The number of times that the radio > has failed due to software related reasons. > > HW Failure Count: The number of times that the radio > has failed due to hardware related reasons. > > Other Failure Count: The number of times that the radio > has failed due to known reasons, other than SW or HW failure. > > Unknown Failure Count: The number of times that the radio > has failed for unknown reasons. > > Config Update Count: The number of times that the radio > configuration has been updated. > > Channel Change Count: The number of times that the radio > channel has been changed. > > Band Change Count: The number of times that the radio > has changes frequency bands. > > Current Noise Floor: A signed integer which indicates the noise floor > of the radio receiver in units of dBm. > ------------------------------------------------------------ > > On 5/23/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com> > wrote: > > > > The statistics mentioned in Issue 84 is a starting point for > > discussion on general statistics information to be exchanged between a WTP > > and AC. I suggest using WTP Event Request as the exchange mechanism, in > > which case, new message elements can be defined for the chosen stats. > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > ------------------------------ > > > > *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] > > *Sent:* Wednesday, May 24, 2006 2:02 AM > > *To:* Pat Calhoun (pacalhou) > > *Cc:* Saravanan Govindan; capwap > > *Subject:* Re: [Capwap] Statistics for WTP Event Request > > > > > > > > Issue 84, "Piggybacking statistical information in Echo Request/response > > is related to this request, listing > > WTP Load, WTP Transmit Queue, Channel Interference and Congestion as > > possible statistics. Issue 84 is half resolved - we decided not to use > > the > > Echo message as transport for statistics, but the question of additional > > useful > > WTP statistics is still open. So, we can use existing issue 84, or close > > 84 and > > open a new issue. > > > > Dorothy > > > > On 5/23/06, *Pat Calhoun (pacalhou)* wrote: > > > > Once you provide more details, I will create an issue to track this > > request. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Saravanan Govindan [mailto: Saravanan.Govindan@sg.panasonic.com] > > > Sent: Tuesday, May 23, 2006 1:52 AM > > > To: capwap > > > Subject: [Capwap] Statistics for WTP Event Request > > > > > > All, > > > > > > The WTP Event Request (Section 9.5) currently includes > > > message elements that cover > > > > > > - Errors for decryption / addressing > > > - Technology specific > > > > > > I propose including a generic Statistics message element to > > > be used with WTP Event Request. I am looking for an earlier > > > note that listed possible metrics to consider. I'll refresh > > > this post when I find it. > > > > > > Saravanan > > > > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > ------=_Part_70140_2399902.1150125978430 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline All,

I'd like to make progress on issue 84 in the -02 draft, and had sent
the proposal below a while ago. Comments please.

Thanks,

Dorothy


On 5/24/06, Dorothy Stanley <dstanley1389@gmail.com> wrote:
Saravanan, all,

Agreed.

This mail discusses the Issue 84 proposed statistics, and proposes additional statistics.

-------------------Issue 84---------------------------- 
<snip> introduce a "Statistics" message element with the 
following fields.
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          WTP Load             |     WTP Transmit Queue        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     |    Channel Interference       |          Congestion           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Type: TBD

WTP Load: A 16-bit value specifying the load (frames/sec) exchanged by the WTP.



WTP Transmit Queue: A 16-bit value specifying the prevailing queue level as a 
     portion of total queue size.

Channel Interference: A 16-bit value specifying SINR (dB) monitored by the WTP.


Congestion: A 16-bit value specifying the congestion experienced by the WTP.

----------------------------End of Issue 84------------------------------

WTP Load - load in frames per second exchanged by the WTP -  Assuming that
the exchange is over the air; Add  "Wireless Link Frames/Sec" statistics field
in a new WTP Operational Statistics message element

WTP Transmit Queue - as a percentage of queue size - Which Queue is this? going to the AC or the STA?
If to the STA, then the statistic may vary with the L2 wireless type, e.g., is it a
single queue for non-WMM traffic? multiple statistics for each of the WMM queues, or an
aggregate of all wireless transmit queues?

Channel Interference - SINR - this is radio dependent, include a noise floor in the
proposed WTP Radio Statistics message element

Congestion - Congestion experienced by the WTP - Need more info here, is this congestion on the
WTP-AC link? How is it measured?

Propose new WTP specific statistics:

- Add more fields/detail to the  WTP Reboot Statistics message element, see 4.4.43
- Add a new WTP Operational Statistics message element
- Add a new WTP Radio Statistics message element, as shown below


- Add the WTP Radio Statistics  and WTP Reboot Statistics and WTP Operational
Statistics message elements to the list of valid message elements in the
WTP Event Message description, section 9.5.


WTP Reboot Statistics

   The WTP  Reboot Statistics message element is sent by the WTP to the
   AC to communicate  reasons why reboots have occurred.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
     |          Reboot Count           |    AC Initiated Count                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
     |      Link Failure Count        |    SW Failure Count                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++
     |      HW Failure Count         |    Other Failure Count                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++
     |   Unknown Failure Count    |   Last Fail Type | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type:  43 for WTP  Reboot Statistics

   Length:  15

   Reboot Count:  The number of reboots that have occurred due to a WTP
      crash.  A value of 65535 implies that this information is not
      available on the WTP.

   AC Initiated Count:  The number of reboots that have occurred at
      the request of a CAPWAP protocol message, such as a change in
      configuration that required a reboot or an explicit CAPWAP reset
      request.  A value of 65535 implies that this information is not
      available on the WTP.

   Link Failure Count:  The number of times that a CAPWAP protocol
      connection with an AC has failed due to link failure.

   SW Failure Count:  The number of times that a CAPWAP protocol < ==New
      connection with an AC has failed due to software related reasons.

   HW Failure Count:  The number of times that a CAPWAP protocol <==New
      connection with an AC has failed due to hardware related reasons.

   Other Failure Count:  The number of times that a CAPWAP protocol <==New
      connection with an AC has failed due to known reasons, other than AC initiated,
     link, SW or HW failure.

   Unknown Failure Count:  The number of times that a CAPWAP protocol <==New
      connection with an AC has failed for unknown reasons.

   Last Failure Type:  The failure type of the most recent WTP failure.  The following values are <== expanded
      supported:

      0 - Not supported

      1 - AC Initiated (see Section 9.3)

      2 - Link Failure

      3 - Software failure

      4 - Hardware Failure
 
      5 - Other Failure

      255 - Unknown

------------------------------------------------------------------------------------------------------
WTP Operational Statistics                          <==New

   The WTP  Operational Statistics message element is sent by the WTP to the
   AC to provide statistics realted to the operation of the WTP.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
     | Wireless Link Frames/Sec |          (Expect more fields to be added...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++++++

   Type:  TBD for WTP  Operational  Statistics

   Length:  xx

   Wireless Link Frames/Sec:  The number of frames transmitted or received per
      second by the WTP over the sir interface.

--------------------------------------------------------------------------------------------------------------------

Proposed New message element:                                       <==New

WTP Radio Statistics

   The WTP  Radio Statistics message element is sent by the WTP to the
   AC to communicate statistics on radio behavior and reasons why the WTP radio has been reset.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
     |   Radio ID      |Last Fail Type  |       Reset Count                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
     |     SW Failure Count             |        HW Failure Count          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++
     |      Other  Failure Count         |   Unknown Failure Count       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++
     |   Config Update Count            |    Channel Change Count      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Band Change Count            |    Current Noise Floor            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type:  TBD for WTP  Radio Statistics

   Length:  20

   Radio ID:  The radio ID of the radio to which the statistics apply.

   Last Failure Type:  The failure type of the most recent radio failure.  The following values are
      supported:

      0 - Not supported

      1 - Software failure

      2 - Hardware Failure
 
      3 - Other Failure

      255 - Unknown

   Reset Count:  The number of times that the radio
      has been reset.

   SW Failure Count:  The number of times that the radio
      has failed due to software related reasons.

   HW Failure Count:  The number of times that the radio
       has failed due to hardware related reasons.

   Other Failure Count:  The number of times that the radio
       has failed due to known reasons, other than SW or HW failure.

   Unknown Failure Count:  The number of times that the radio
       has failed for unknown reasons.

   Config Update Count:  The number of times that the radio
       configuration has been updated.

   Channel Change Count:  The number of times that the radio
       channel has been changed.

   Band Change Count:  The number of times that the radio
       has changes frequency bands.

   Current Noise Floor: A signed integer which indicates the noise floor
       of the radio receiver in units of dBm.
------------------------------------------------------------

On 5/23/06, Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com> wrote:

The statistics mentioned in Issue 84 is a starting point for discussion on general statistics information to be exchanged between a WTP and AC. I suggest using WTP Event Request as the exchange mechanism, in which case, new message elements can be defined for the chosen stats.

 

Saravanan

 

 

 

 

From: Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Wednesday, May 24, 2006 2:02 AM
To: Pat Calhoun (pacalhou)
Cc: Saravanan Govindan; capwap
Subject: Re: [Capwap] Statistics for WTP Event Request

 

Issue 84, "Piggybacking statistical information in Echo Request/response is related to this request, listing
WTP Load, WTP Transmit Queue, Channel Interference and Congestion as
possible statistics. Issue 84 is half resolved - we decided not to use the
Echo message as transport for statistics, but the question of additional useful
WTP statistics is still open. So, we can use existing issue 84, or close 84 and
open a new issue.

Dorothy

On 5/23/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:

Once you provide more details, I will create an issue to track this
request.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems



> -----Original Message-----
> From: Saravanan Govindan [mailto: Saravanan.Govindan@sg.panasonic.com]
> Sent: Tuesday, May 23, 2006 1:52 AM
> To: capwap
> Subject: [Capwap] Statistics for WTP Event Request
>
> All,
>
> The WTP Event Request (Section 9.5) currently includes
> message elements that cover
>
> - Errors for decryption / addressing
> - Technology specific
>
> I propose including a generic Statistics message element to
> be used with WTP Event Request. I am looking for an earlier
> note that listed possible metrics to consider. I'll refresh
> this post when I find it.
>
> Saravanan
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

 



------=_Part_70140_2399902.1150125978430-- --===============1111498401== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1111498401==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 12 12:51:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fppdb-0003Sm-GG for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 12:51:39 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FppdZ-0003RD-MO for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 12:51:39 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 85145430137 for ; Mon, 12 Jun 2006 09:51:36 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 26237430058 for ; Mon, 12 Jun 2006 09:50:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E0C9C1448021 for ; Mon, 12 Jun 2006 09:50:54 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by hermes.tigertech.net (Postfix) with ESMTP id A2CC11448003 for ; Mon, 12 Jun 2006 09:50:50 -0700 (PDT) Received: from [209.86.224.37] (helo=elwamui-karabash.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Fppcn-0004W5-Q0; Mon, 12 Jun 2006 12:50:49 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Mon, 12 Jun 2006 12:50:49 -0400 Message-ID: <25505253.1150131049754.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> Date: Mon, 12 Jun 2006 09:50:49 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "Bob O'Hara (boohara)" , capwap Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710fd5f344f6ed279eabddf43dc4e072ef8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.37 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: Re: [Capwap] capwap transport analysis: QoS vs multiport X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Hi Bob, boohara wrote: >Scott, > >Of course you can't respond to my specific arguments, because they show >your line of reasoning to be without any merit. Let's just leave it at >that. > > -Bob My original post was quite long and detailed, and I thought it might be a bit tedious to subject everyone to a blow by blow response immediately after posting that. This is a complex discussion, and it's important to keep people engaged throughout the reasoning process. We've had the weekend to think this over, and hopefully other folks have had a chance to review both the post and your response and form opinions of their own by now. So, let's resume the discussion. I think the most effective way to deal with this is systematically. The starting premises are the foundation of what follows, so it they are incorrect, the issue must be re-analyzed in light of this. If we can approach this in a disciplined manner, we should be able to get through this quickly. Let's start with the premises and the comment immediately following them: > (1) intermediate network elements between the WTP and AC must > be able to re-mark packets > > (2) in particular, they need to ensure that control traffic > is treated at a higher priority than data traffic > > (3) some customers will want to send control down a different > path than data to achieve this (or some other) objective > > (4) many of these elements can only classify traffic based on > 5-tuples; they apparently cannot use VLAN tags or 1:1 > mappings of DSCP/802.1q/802.1d mappings > > Bob>> The statement has been made by several posters not that > the equipment cannot do this, but that it will not do it, > because the source of any QoS marking at the WTP may not be > trusted. The reason for this is that the source of this QoS > marking is the client, not the WTP and the client is not > trusted to mark QoS properly. Therefore any mapping of that > QoS by the WTP cannot be trusted, either. More on this, below. I assume this is meant to refute premise (4), based on the supposition that the only way to mark traffic is by copying WMM/.11e markings. This is not the case, as we know that WTPs and ACs can be programmed to classify traffic and mark it accordingly. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 12 13:45:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpqTr-00038c-Hr for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 13:45:39 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpqTo-0000o3-0c for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 13:45:39 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E5211430117 for ; Mon, 12 Jun 2006 10:45:34 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 90EA94300A2 for ; Mon, 12 Jun 2006 10:44:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5EA9C398014 for ; Mon, 12 Jun 2006 10:44:47 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id 539B7398039 for ; Mon, 12 Jun 2006 10:44:43 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 12 Jun 2006 10:44:42 -0700 X-IronPort-AV: i="4.05,229,1146466800"; d="scan'208"; a="1824109208:sNHT292915998" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5CHigbp014552; Mon, 12 Jun 2006 10:44:42 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5CHig9s006001; Mon, 12 Jun 2006 10:44:42 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 10:44:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 Jun 2006 10:44:41 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC01A25080@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Process in CAPWAP Thread-Index: AcaMIv6al2wcs/e8TvuwY5RhhPusZABLgvjQAD2d9ZA= From: "Bob O'Hara (boohara)" To: "Romascanu, Dan (Dan)" X-OriginalArrivalTime: 12 Jun 2006 17:44:41.0956 (UTC) FILETIME=[E271AA40:01C68E47] Authentication-Results: sj-dkim-2.cisco.com; header.From=boohara@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Process in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Dan, Thank you for your email. I look forward to your response. As you have pr= obably seen from the reflector traffic, CAPWAP is a lively group. = -Bob = -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] = Sent: Sunday, June 11, 2006 5:46 AM To: Bob O'Hara (boohara) Cc: capwap; david.kessens@nokia.com Subject: RE: Process in CAPWAP Bob, Thank you for the mail. = You probably refer to the mail from Dorothy Gellert sent to the list on Tue= sday 6/6 (US time): 'The CAPWAP editors have asked the Chairs to resolve the Mux vs Multiport i= ssue # 115, in order to progress the specification. Based on the discussio= n that has taken place the chairs are in agreement the simplest, cleanest s= olution for this is to add a Mux header. Barring any unforseen events, we = will instruct the editors resolve in favor of a new Mux header. We intend to close this issue by the end of the week, Friday, 6/9. Please = review the issue and send any constructive comments to the list by Friday.' I am looking together with my co-Area Director, David Kessens into the issu= es that you are raising and we shall respond in a matter of days. In the meantime I would encourage the working group, the editors and the ch= airs to continue to work and seek consensus, in the best possible cooperati= on spirit. According to the traffic on the list during the last few days I = agree that there still seem to be open issues and it does not seem to be co= nsensus in the Working Group. Dan = = > -----Original Message----- > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] = > Sent: Saturday, June 10, 2006 3:16 AM > To: Romascanu, Dan (Dan) > Cc: capwap > Subject: Process in CAPWAP > = > Dan, > = > A few days ago Dorothy Gellert sent an email to the working = > group on behalf of the chairs, announcing a decision on a = > technical issue in the working group. Specifically, she = > declared that the chairs decided the discussion of the use of = > a mux header vs. the use of separate ports for the = > differentiation of control and data traffic in the protocol = > to be over. She also indicated that the chairs had chosen = > the mux header as the method to be used in the protocol and = > set a deadline of today for closing the issue. > = > As soon as I read her email, I replied and asked that she = > document the process that the chairs used to arrive at their = > decision. My background is in the IEEE, where the process is = > clear, transparent, and open to all participants. CAPWAP is = > my first IETF working group. My understanding of = > decision-making in IETF is that it is based on rough = > consensus and that the chairs have responsibility to = > determine that consensus. With that understanding, I asked = > Dorothy to document what the chairs used as evidence of rough = > consensus on that issue, since I see evidence in the postings = > to the list that there is more support for separate ports = > than there is for the mux header. At a minimum, there is no = > consensus on this issue. > = > Since sending that email two days ago, neither chair has = > responded. I find that quite disturbing for several reasons. = > = > First, this is an issue that has been debated extensively = > (and still is being debated, regardless of the pronouncement = > from the chairs). The working group deserves to know how = > this technical issue was resolved. = > = > Second, standardization by fiat of the chair does not seem to = > be in keeping with the open process requirements of the IETF. = > Perhaps I am being na=EFve, but I don't believe there is a = > feted inner core (FIC) that is actually developing all the = > IETF standards. = > = > Third, the time allowed for any response to the email was = > only three days. This is an absurdly short time, given that = > it is the start of the summer vacation period in the northern = > hemisphere. It is quite possible that many participants will = > not even see her email until after the deadline expires. = > = > Finally, if there is no consensus on the issue, the chairs = > are expressing an engineering opinion and should be required = > to justify that opinion just as any other member of the = > working group. I don't believe that the IETF anoints the = > chairs of any working group as expert and able to make = > technical decisions for the working group. > = > I would appreciate your thoughts, as the AD, and response on = > these items. > = > Best regards, > -Bob > = > Bob O'Hara > = _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 12 15:05:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FprjB-0007Ig-Fc for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 15:05:33 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fprj9-00007E-Uj for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 15:05:33 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 483FF4300E4 for ; Mon, 12 Jun 2006 12:05:31 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 0EFA24300A2 for ; Mon, 12 Jun 2006 12:05:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id EF2B739807C for ; Mon, 12 Jun 2006 12:05:01 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9F596398056 for ; Mon, 12 Jun 2006 12:04:57 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so1901527pyu for ; Mon, 12 Jun 2006 12:04:56 -0700 (PDT) Received: by 10.35.98.6 with SMTP id a6mr1240076pym; Mon, 12 Jun 2006 11:57:52 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Mon, 12 Jun 2006 11:57:51 -0700 (PDT) Message-ID: <26140d940606121157i3af02977rc06d2ff950eb33cd@mail.gmail.com> Date: Mon, 12 Jun 2006 14:57:51 -0400 From: "Michael Montemurro" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20203802C@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A20203802C@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.109 tagged_above=-999 required=7 tests=HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0115684800==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 --===============0115684800== Content-Type: multipart/alternative; boundary="----=_Part_5906_11148829.1150138671912" ------=_Part_5906_11148829.1150138671912 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline So, again I propose the following changes for draft 2.0: Would it be sufficient to move Encryption Capabilities from the WTP Descriptor (Section 4.4.34) to the WTP Radio Information message element (Section 4.4.39). This addresses the comment on the WTP Descriptor and that change can be made for draft 2.0. Now it seems there is another broader issue on the support for different modes of wireless link layer encryption in the CAPWAP architecture. I've created issue 138 to address this issue. Cheers, Mike On 6/12/06, Pat Calhoun (pacalhou) wrote: > > However, the MUX issue has raised another interesting problem, which > > was raised by Scott, which is that in order for the WTP to perform > > packet classification, and tagging, it needs to have access to the > > data frames in the clear, which is not possible with this feature. > > > The WTP can perform marking by > mapping the WMM or 802.11e header info into DSCP/.1q/.1d markings > Access to data frames in the clear is not needed. > As raised a few times, one cannot trust a client's marking. Centralized > 802.11i encryption does not allow the WTP to inspect packets for TSPEC > conformance. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_5906_11148829.1150138671912 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
So, again I propose the following changes for draft 2.0:
 
Would it be sufficient to move Encryption Capabilities from the WTP Descriptor (Section 4.4.34) to the WTP Radio Information message element (Section 4.4.39).
 
This addresses the comment on the WTP Descriptor and that change can be made for draft 2.0.
 
Now it seems there is another broader issue on the support for different modes of wireless link layer encryption in the CAPWAP architecture. I've created issue 138 to address this issue.
 
Cheers,
 
     Mike


 
On 6/12/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
However, the MUX issue has raised another interesting problem, which
was raised by Scott, which is that in order for the WTP to perform
packet classification, and tagging, it needs to have access to the
data frames in the clear, which is not possible with this feature.

The WTP can perform marking by
mapping the WMM or 802.11e header info into DSCP/.1q/.1d markings
Access to data frames in the clear is not needed.
As raised a few times, one cannot trust a client's marking. Centralized
802.11i encryption does not allow the WTP to inspect packets for TSPEC
conformance.
 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


------=_Part_5906_11148829.1150138671912-- --===============0115684800== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0115684800==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 12 16:16:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpsmv-0006BP-Bv for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 16:13:29 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpsZM-0008NQ-79 for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 15:59:29 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 364234300F1 for ; Mon, 12 Jun 2006 12:59:27 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 50F2A4300A2 for ; Mon, 12 Jun 2006 12:58:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3905139804C for ; Mon, 12 Jun 2006 12:58:54 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 41315398039 for ; Mon, 12 Jun 2006 12:58:52 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 12 Jun 2006 12:58:51 -0700 X-IronPort-AV: i="4.05,229,1146466800"; d="scan'208,217"; a="293363218:sNHT70477470" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5CJwoPI004771; Mon, 12 Jun 2006 12:58:50 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5CJwNJW010907; Mon, 12 Jun 2006 12:58:50 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 12:58:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 Jun 2006 12:58:24 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2020381E0@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Encryption Capabilities Thread-Index: AcaOUicxWOZZQ/FKS6CHEo4oEEZApgACEtMw From: "Pat Calhoun (pacalhou)" To: "Michael Montemurro" X-OriginalArrivalTime: 12 Jun 2006 19:58:25.0816 (UTC) FILETIME=[91098980:01C68E5A] Authentication-Results: sj-dkim-5.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.468 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Encryption Capabilities X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0597118807==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af This is a multi-part message in MIME format. --===============0597118807== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68E5A.90CE4260" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68E5A.90CE4260 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At a minimum, the spec issues need to be addressed, so I'm ok with the change. However, I do want to open up the discussion of whether we need to keep this in the protocol to begin with, but as a separate topic. Thanks for creating the issue to track it. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Monday, June 12, 2006 11:58 AM To: Pat Calhoun (pacalhou) Cc: Dorothy Stanley; capwap Subject: Re: [Capwap] Encryption Capabilities =09 =09 So, again I propose the following changes for draft 2.0: =20 Would it be sufficient to move Encryption Capabilities from the WTP Descriptor (Section 4.4.34) to the WTP Radio Information message element (Section 4.4.39). =20 This addresses the comment on the WTP Descriptor and that change can be made for draft 2.0. =20 Now it seems there is another broader issue on the support for different modes of wireless link layer encryption in the CAPWAP architecture. I've created issue 138 to address this issue. =20 Cheers, =20 Mike =20 On 6/12/06, Pat Calhoun (pacalhou) wrote:=20 =09 However, the MUX issue has raised another interesting problem, which=20 was raised by Scott, which is that in order for the WTP to perform=20 packet classification, and tagging, it needs to have access to the data frames in the clear, which is not possible with this feature. The WTP can perform marking by mapping the WMM or 802.11e header info into DSCP/.1q/.1d markings=20 Access to data frames in the clear is not needed. =09 As raised a few times, one cannot trust a client's marking. Centralized 802.11i encryption does not allow the WTP to inspect packets for TSPEC conformance. =09 =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 ------_=_NextPart_001_01C68E5A.90CE4260 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
At a=20 minimum, the spec issues need to be addressed, so I'm ok with the = change.=20 However, I do want to open up the discussion of whether we need to keep = this in=20 the protocol to begin with, but as a separate topic. Thanks for creating = the=20 issue to track it.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Monday, June = 12, 2006=20 11:58 AM
To: Pat Calhoun (pacalhou)
Cc: Dorothy = Stanley;=20 capwap
Subject: Re: [Capwap] Encryption=20 Capabilities

So, again I propose the following changes for draft 2.0:
 
Would it be sufficient to move Encryption Capabilities from the = WTP=20 Descriptor (Section 4.4.34) to the WTP Radio Information message = element=20 (Section 4.4.39).
 
This addresses the comment on the WTP Descriptor and that change = can be=20 made for draft 2.0.
 
Now it seems there is another broader issue on the support for = different=20 modes of wireless link layer encryption in the CAPWAP architecture. = I've=20 created issue 138 to address this issue.
 
Cheers,
 
     Mike


 
On 6/12/06, Pat Calhoun=20 (pacalhou) <pcalhoun@cisco.com> = wrote:=20
However, the MUX issue has = raised another=20 interesting problem, which
was raised by Scott, which is that = in order=20 for the WTP to perform
packet classification, and tagging, it = needs to=20 have access to the
data frames in the clear, which is not = possible with=20 this feature.

The WTP can = perform marking=20 by
mapping the WMM or 802.11e header info into DSCP/.1q/.1d = markings=20
Access to data frames in the clear is not=20 needed.
As raised a = few times, one=20 cannot trust a client's marking. Centralized
802.11i = encryption does not=20 allow the WTP to inspect packets for TSPEC
conformance.
 

Pat Calhoun
CTO, Wireless = Networking Business=20 Unit
Cisco Systems

 
=

____________________________________________________= _____________
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20


------_=_NextPart_001_01C68E5A.90CE4260-- --===============0597118807== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0597118807==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 12 17:27:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FptwZ-0007xt-59 for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 17:27:31 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FptwX-0000bh-Bd for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 17:27:31 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 645864300FA for ; Mon, 12 Jun 2006 14:27:28 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 568C94300A2 for ; Mon, 12 Jun 2006 14:26:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3A47A144801F for ; Mon, 12 Jun 2006 14:26:39 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.207]) by hermes.tigertech.net (Postfix) with ESMTP id 8DE2C1448035 for ; Mon, 12 Jun 2006 14:26:35 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id s13so987761wxc for ; Mon, 12 Jun 2006 14:26:34 -0700 (PDT) Received: by 10.70.14.5 with SMTP id 5mr4014202wxn; Mon, 12 Jun 2006 14:26:34 -0700 (PDT) Received: by 10.70.133.2 with HTTP; Mon, 12 Jun 2006 14:26:33 -0700 (PDT) Message-ID: <5bfe7a820606121426v6b60b0e3rac747104424e9383@mail.gmail.com> Date: Mon, 12 Jun 2006 14:26:33 -0700 From: "Dorothy Stanley" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201FC06DC@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A201FC06DC@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.6 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_50_60, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Proposed Resolution to Issue 97: Discovery Type DefinitionInconsistencies X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1407259767==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa --===============1407259767== Content-Type: multipart/alternative; boundary="----=_Part_75583_30523676.1150147593963" ------=_Part_75583_30523676.1150147593963 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I am fine with the proposed change. Dorothy On 6/5/06, Pat Calhoun (pacalhou) wrote: > > I would like to propose something different. How about: > > > The Discovery Type message element is used by the WTP to indicate how > it has come to know about the existence of the AC, to which it has sent > the Discovery Request. > > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > | Discovery Type| > +-+-+-+-+-+-+-+-+ > > Type: 19 for Discovery Type > > Length: 1 > > Discovery Type: An 8-bit value indicating WTP knowledge of the AC > The following values are supported: > 0 - Unknown > 1 - Statically Configured > 2 - DHCP > 3 - DNS > > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > ________________________________ > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > Sent: Wednesday, May 24, 2006 12:10 PM > To: capwap > Subject: [Capwap] Proposed Resolution to Issue 97: Discovery > Type DefinitionInconsistencies > > > All, > > Issue 97 is listed below, together with a proposed resolution. > > Comments please. > > Thanks, > > Dorothy > ------------- > > Proposed Resolution: Accept, see 4.4.19, > > Change from: > > > The Discovery message element is used to configure a WTP to > operate in a > specific mode. > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > | Discovery Type| > +-+-+-+-+-+-+-+-+ > > Type: 19 for Discovery Type > > > Length: 1 > Discovery Type: An 8-bit value indicating how the AC was > discovered. > The following values are supported: > 0 - Broadcast > 1 - Configured > > to > > The Discovery Type message element is used to indicate that the > WTP has been > > configured with the AC address > to which the corresponding Discovery Request message is sent. > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > | Discovery Type| > +-+-+-+-+-+-+-+-+ > > Type: 19 for Discovery Type > > > Length: 1 > Discovery Type: An 8-bit value indicating WTP knowledge of the > AC > The following values are supported: > 0 - Unknown > 1 - Configured > > > > > > > > > > > > > Issue 97: > > Section 5.1.1 Defines the Discovery Type message element. This > message element > is included in the > Discovery Request message, sent by WTPs to discover potential > ACs. > > The current definition is below: > > > The Discovery message element is used to configure a WTP to > operate in a > specific mode. > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > | Discovery Type| > +-+-+-+-+-+-+-+-+ > > Type: 58 for Discovery Type > > > Length: 1 > Discovery Type: An 8-bit value indicating how the AC was > discovered. > The following values are supported: > 0 - Broadcast > 1 - Configured > > Comments: > 1. The statement that " The Discovery message element is used to > configure a WTP > > to operate in a specific mode." seems inconsistent > with its inclusion in the Discovery Request message. > 2. Discovery Type: An 8-bit value indicating how the AC was > discovered. - The AC > hasn't been discovered yet. Does this mean the mode - unicast, > broadcast/multi-cast > > in which the discovery request message was sent? Must the WTP be > either > configured with the AC address, or find the address on its own? > Seems like this > would be part of WTP configuration, rather than being included > in the discovery > > request message. > 3. What is the purpose/value of including "Discovery Type"? > Either define > consistently, or delete it > > Do we mean the following? > > > The Discovery Type message element is used to indicate that the > WTP has been > > configured with the AC address > to which the corresponding Discovery Request message is sent. > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > | Discovery Type| > +-+-+-+-+-+-+-+-+ > > Type: 58 for Discovery Type > > > Length: 1 > Discovery Type: An 8-bit value indicating WTP knowledge of the > AC > The following values are supported: > 0 - Unknown > 1 - Configured > > ------=_Part_75583_30523676.1150147593963 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I am fine with the proposed change.

Dorothy

On 6/5/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
I would like to propose something different. How about:


The Discovery Type message element is used by the WTP to indicate how
it has come to know about the existence of the AC, to which it has sent
the Discovery Request.

0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Discovery Type|
+-+-+-+-+-+-+-+-+

Type: 19 for Discovery Type

Length: 1

Discovery Type: An 8-bit value indicating WTP knowledge of the AC
The following values are supported:
   0 - Unknown
   1 - Statically Configured
   2 - DHCP
   3 - DNS



Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems




________________________________

        From: Dorothy Stanley [mailto:dstanley1389@gmail.com]
        Sent: Wednesday, May 24, 2006 12:10 PM
        To: capwap
        Subject: [Capwap] Proposed Resolution to Issue 97: Discovery
Type DefinitionInconsistencies


        All,

        Issue 97 is listed below, together with a proposed resolution.

        Comments please.

        Thanks,

        Dorothy
        -------------

        Proposed Resolution: Accept, see 4.4.19,

        Change from:


        The Discovery message element is used to configure a WTP to
operate in a
        specific mode.
         0
         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
         | Discovery Type|
         +-+-+-+-+-+-+-+-+

        Type: 19 for Discovery Type


         Length: 1
        Discovery Type: An 8-bit value indicating how the AC was
discovered.
        The following values are supported:
         0 - Broadcast
        1 - Configured

        to

        The Discovery Type message element is used to indicate that the
WTP has been

        configured with the AC address
        to which the corresponding Discovery Request message is sent.
         0
         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
         | Discovery Type|
         +-+-+-+-+-+-+-+-+

        Type: 19 for Discovery Type


         Length: 1
        Discovery Type: An 8-bit value indicating WTP knowledge of the
AC
        The following values are supported:
         0 - Unknown
        1 -  Configured












        Issue 97:

        Section 5.1.1 Defines the Discovery Type message element. This
message element
        is included in the
        Discovery Request message, sent by WTPs to discover potential
ACs.

        The current definition is below:


        The Discovery message element is used to configure a WTP to
operate in a
        specific mode.
         0
         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
         | Discovery Type|
         +-+-+-+-+-+-+-+-+

        Type: 58 for Discovery Type


         Length: 1
        Discovery Type: An 8-bit value indicating how the AC was
discovered.
        The following values are supported:
         0 - Broadcast
        1 - Configured

        Comments:
        1. The statement that " The Discovery message element is used to
configure a WTP

        to operate in a specific mode." seems inconsistent
        with its inclusion in the Discovery Request message.
        2. Discovery Type: An 8-bit value indicating how the AC was
discovered. - The AC
        hasn't been discovered yet. Does this mean the mode - unicast,
broadcast/multi-cast

        in which the discovery request message was sent? Must the WTP be
either
        configured with the AC address, or find the address on its own?
Seems like this
        would be part of WTP configuration, rather than being included
in the discovery

        request message.
        3. What is the purpose/value of including "Discovery Type"?
Either define
        consistently, or delete it

        Do we mean the following?


        The Discovery Type message element is used to indicate that the
WTP has been

        configured with the AC address
        to which the corresponding Discovery Request message is sent.
         0
         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
         | Discovery Type|
         +-+-+-+-+-+-+-+-+

        Type: 58 for Discovery Type


         Length: 1
        Discovery Type: An 8-bit value indicating WTP knowledge of the
AC
        The following values are supported:
         0 - Unknown
        1 -  Configured


------=_Part_75583_30523676.1150147593963-- --===============1407259767== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1407259767==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 12 19:40:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpw1d-0006qL-Gx for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 19:40:53 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpw1c-0007B0-2D for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 19:40:53 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 23329430104 for ; Mon, 12 Jun 2006 16:40:51 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E68D54300A2 for ; Mon, 12 Jun 2006 16:40:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C45E7398014 for ; Mon, 12 Jun 2006 16:40:27 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id DB989398044 for ; Mon, 12 Jun 2006 16:40:24 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 12 Jun 2006 16:40:24 -0700 X-IronPort-AV: i="4.06,124,1149490800"; d="scan'208"; a="1824359294:sNHT31271800" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k5CNeOQO025570 for ; Mon, 12 Jun 2006 16:40:24 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5CNeNcL024901 for ; Mon, 12 Jun 2006 16:40:24 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 16:40:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 Jun 2006 16:40:23 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC01A2529F@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] capwap transport analysis: QoS vs multiport Thread-Index: AcaOQF8X6kq4hQTrSBWh7Jg8xDCsAAAOCqtA From: "Bob O'Hara (boohara)" To: "capwap" X-OriginalArrivalTime: 12 Jun 2006 23:40:23.0871 (UTC) FILETIME=[933774F0:01C68E79] Authentication-Results: sj-dkim-7.cisco.com; header.From=boohara@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] capwap transport analysis: QoS vs multiport X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Scott, [snip] Let's start with the premises and the comment immediately following them: > (1) intermediate network elements between the WTP and AC must > be able to re-mark packets > > (2) in particular, they need to ensure that control traffic > is treated at a higher priority than data traffic > > (3) some customers will want to send control down a different > path than data to achieve this (or some other) objective > > (4) many of these elements can only classify traffic based on > 5-tuples; they apparently cannot use VLAN tags or 1:1 > mappings of DSCP/802.1q/802.1d mappings > > Bob>> The statement has been made by several posters not that > the equipment cannot do this, but that it will not do it, > because the source of any QoS marking at the WTP may not be > trusted. The reason for this is that the source of this QoS > marking is the client, not the WTP and the client is not > trusted to mark QoS properly. Therefore any mapping of that > QoS by the WTP cannot be trusted, either. More on this, below. I assume this is meant to refute premise (4), based on the supposition that the only way to mark traffic is by copying WMM/.11e markings. This is not the case, as we know that WTPs and ACs can be programmed to classify traffic and mark it accordingly. Bob>> This statement is to refute the claim made in premise (4) that the equipment cannot use VLAN tags or mappings of the DSCP/802.1Q/802.1D information in the frame/packet received from the 802.11 client device. The equipment could use it, if the information were trusted. The information is not trusted. Therefore, the information cannot be used. -Bob _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 12 20:12:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpwWA-0005Uu-1P for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 20:12:26 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpwPf-0001Yg-69 for capwap-archive@lists.ietf.org; Mon, 12 Jun 2006 20:05:45 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CD414430104 for ; Mon, 12 Jun 2006 17:05:42 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 13EC54300A2 for ; Mon, 12 Jun 2006 17:05:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E889E1448021 for ; Mon, 12 Jun 2006 17:05:18 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by hermes.tigertech.net (Postfix) with ESMTP id 1BD2F144801F for ; Mon, 12 Jun 2006 17:05:16 -0700 (PDT) Received: from [209.86.224.37] (helo=elwamui-karabash.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FpwPD-00050M-Gm; Mon, 12 Jun 2006 20:05:15 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Mon, 12 Jun 2006 20:05:15 -0400 Message-ID: <30870319.1150157115529.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> Date: Mon, 12 Jun 2006 17:05:15 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "Bob O'Hara (boohara)" , capwap Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff71009f0aa288c4412f39c7a0a9f0122bcc9350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.37 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: Re: [Capwap] capwap transport analysis: QoS vs multiport X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Hi Bob, >> (4) many of these elements can only classify traffic based on >> 5-tuples; they apparently cannot use VLAN tags or 1:1 >> mappings of DSCP/802.1q/802.1d mappings >> >> Bob>> The statement has been made by several posters not that >> the equipment cannot do this, but that it will not do it, >> because the source of any QoS marking at the WTP may not be >> trusted. The reason for this is that the source of this QoS >> marking is the client, not the WTP and the client is not >> trusted to mark QoS properly. Therefore any mapping of that >> QoS by the WTP cannot be trusted, either. More on this, below. > >I assume this is meant to refute premise (4), based on the supposition >that the only way to mark traffic is by copying WMM/.11e markings. This >is not the case, as we know that WTPs and ACs can be programmed to >classify traffic and mark it accordingly. > >Bob>> This statement is to refute the claim made in premise (4) that the >equipment cannot use VLAN tags or mappings of the DSCP/802.1Q/802.1D >information in the frame/packet received from the 802.11 client device. >The equipment could use it, if the information were trusted. The >information is not trusted. Therefore, the information cannot be used. [I don't agree that we should universally mistrust client marking, but that is a different (and independent) discussion, so we can take that up later.] So if the AC and WTP were to mark control packets so as to make them distinguishable from data packets (using one of the marking methods suggested above, and without relying on client truthfulness), what problems remain? Scott (4) _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 13 00:50:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq0r5-0004ox-Lt for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 00:50:19 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq0r3-0003ON-Md for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 00:50:19 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4C7694300F1 for ; Mon, 12 Jun 2006 21:50:17 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3B19C4300A2 for ; Mon, 12 Jun 2006 21:49:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2A36E398032 for ; Mon, 12 Jun 2006 21:49:32 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [12.129.211.51]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9126C39801C for ; Mon, 12 Jun 2006 21:49:25 -0700 (PDT) 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 <0J0S006N27WUHO@usaga01-in.huawei.com> for capwap@frascone.com; Mon, 12 Jun 2006 21:46:06 -0700 (PDT) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0S00M8I7WRVP@usaga01-in.huawei.com> for capwap@frascone.com; Mon, 12 Jun 2006 21:46:06 -0700 (PDT) Received: from [172.24.1.24] (Forwarded-For: [10.18.7.115]) by szxmc01-in.huawei.com (mshttpd); Tue, 13 Jun 2006 09:49:14 +0500 Date: Tue, 13 Jun 2006 09:49:14 +0500 From: zhaoyujin 31390 To: "Pat Calhoun (pacalhou)" Message-id: <38482c3851f6.3851f638482c@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: multipart/mixed; boundary="Boundary_(ID_2FRKNlbCguLpNYqQZWA30A)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.381 tagged_above=-999 required=7 tests=HTML_50_60, HTML_MESSAGE, MIME_HTML_MOSTLY X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Proposed Resolution to Issue 134/wasRe: New Issue - LocalMAC MUST vs MAY forward associationrequest messages X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.4 (/) X-Scan-Signature: 2e8a07f64def4bd8598257bc442beb9d This is a multi-part message in MIME format. --Boundary_(ID_2FRKNlbCguLpNYqQZWA30A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Why don't define a notification event from AP to AC to resolve the issue 134. Maybe AP can directly use "Add mobile" to notify AC this event. For local MAC, AP forward association request message to AC that maybe resolve issue 134, but the logic of this method is not better and not easy to be accepted. Best regards Michael yup- that works for me. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems -------------------------------------------------------------------------------- From: Dorothy Stanley [mailto:dstanley1389@gmail.com] Sent: Monday, June 12, 2006 7:09 AM To: Michael Montemurro Cc: capwap Subject: [Capwap] Proposed Resolution to Issue 134/wasRe: New Issue - LocalMAC MUST vs MAY forward associationrequest messages Pat, David, Agree that the AC must be notified. However the text also states that " the AC MAY reply with a failed Association Response if it deems it necessary. " introducing a race condition, when the WTP may have already responded to the Association Request with an Association Response (success), before it receives the "failed Association Response" from the AC. Proposed resolution of Issue 134: Change from: While the MAC is terminated on the WTP, it is necessary for the AC to be aware of mobility events within the WTPs. As a consequence, the WTP MUST forward the IEEE 802.11 Association Requests to the AC, and the AC MAY reply with a failed Association Response if it deems it necessary. to While the MAC is terminated on the WTP, it is necessary for the AC to be aware of mobility events within the WTPs. As a consequence, the WTP MUST forward the IEEE 802.11 Association Requests to the AC. The AC MAY reply with a failed Association Response if it deems it necessary, and upon receipt of a failed Association Response from the AC, the WTP must send a Disassociation frame to the mobile station. Thanks, Dorothy On 6/8/06, Michael Montemurro wrote: I've captured this as issue 134. Cheers, Mike On 6/6/06, Dorothy Stanley < dstanley1389@gmail.com> wrote: Pat, David, Your comments are consistent with those received back in April, when this mail was sent out - thus I did not make, and had not planned to make the proposed change. Thanks, Dorothy On 6/6/06, David T. Perkins wrote: HI, ABSOLUTELY agree with Pat. That is the AC MUST know what STAs are be serviced by the WTPs, and MUST decide which STAs are allowed to associate and send traffic. This is the fundamental difference between a CAPWAP network and a collection of APs. Regards, /david t. perkins On Tue, 6 Jun 2006, Pat Calhoun (pacalhou) wrote: > I disagree with this change request. The AC MUST know what STAs are > being serviced by WTPs. The term MUST cannot be changed to MAY. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > ________________________________ > > From: Dorothy Stanley [mailto: dstanley1389@gmail.com] > Sent: Tuesday, April 11, 2006 11:41 AM > To: capwap > Subject: [Capwap] New Issue - Local MAC MUST vs MAY forward > associationrequest messages > > > All, > > Section 11.1.2 Local MAC describes the Local MAC operation. It > currently states > (second paragraph below Figure 6): > > While the MAC is terminated on the WTP, it is necessary for the > AC to be aware of mobility events within the WTPs. > As a consequence, the WTP MUST forward the IEEE 802.11 > Association Requests to the AC, and the AC MAY reply > with a failed Association Response if it deems it necessary. > > > Since this is the Local MAC case, it seems that a MAY should be > sufficient. > > Recommended change: > > The MAC is terminated on the WTP, but the AC may need to be > aware of mobility events within the WTPs. > As a consequence, the WTP MAY forward the IEEE 802.11 > Association Requests to the AC, and the AC MAY reply > with a failed Association Response. > > Comments? > > Thanks, > > Dorothy > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap -------------------------------------------------------------------------------- _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --Boundary_(ID_2FRKNlbCguLpNYqQZWA30A) Content-type: multipart/alternative; boundary="Boundary_(ID_hY5pMJa5xzgJ4uEX8WqVSA)" Content-class: urn:content-classes:message --Boundary_(ID_hY5pMJa5xzgJ4uEX8WqVSA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT yup - that works for me. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com] Sent: Monday, June 12, 2006 7:09 AM To: Michael Montemurro Cc: capwap Subject: [Capwap] Proposed Resolution to Issue 134/wasRe: New Issue - LocalMAC MUST vs MAY forward associationrequest messages Pat, David, Agree that the AC must be notified. However the text also states that " the AC MAY reply with a failed Association Response if it deems it necessary. " introducing a race condition, when the WTP may have already responded to the Association Request with an Association Response (success), before it receives the "failed Association Response" from the AC. Proposed resolution of Issue 134: Change from: While the MAC is terminated on the WTP, it is necessary for the AC to be aware of mobility events within the WTPs. As a consequence, the WTP MUST forward the IEEE 802.11 Association Requests to the AC, and the AC MAY reply with a failed Association Response if it deems it necessary. to While the MAC is terminated on the WTP, it is necessary for the AC to be aware of mobility events within the WTPs. As a consequence, the WTP MUST forward the IEEE 802.11 Association Requests to the AC. The AC MAY reply with a failed Association Response if it deems it necessary, and upon receipt of a failed Association Response from the AC, the WTP must send a Disassociation frame to the mobile station. Thanks, Dorothy On 6/8/06, Michael Montemurro wrote: I've captured this as issue 134. Cheers, Mike On 6/6/06, Dorothy Stanley < dstanley1389@gmail.com > wrote: Pat, David, Your comments are consistent with those received back in April, when this mail was sent out - thus I did not make, and had not planned to make the proposed change. Thanks, Dorothy On 6/6/06, David T. Perkins wrote: HI, ABSOLUTELY agree with Pat. That is the AC MUST know what STAs are be serviced by the WTPs, and MUST decide which STAs are allowed to associate and send traffic. This is the fundamental difference between a CAPWAP network and a collection of APs. Regards, /david t. perkins On Tue, 6 Jun 2006, Pat Calhoun (pacalhou) wrote: > I disagree with this change request. The AC MUST know what STAs are > being serviced by WTPs. The term MUST cannot be changed to MAY. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > ________________________________ > > From: Dorothy Stanley [mailto: dstanley1389@gmail.com ] > Sent: Tuesday, April 11, 2006 11:41 AM > To: capwap > Subject: [Capwap] New Issue - Local MAC MUST vs MAY forward > associationrequest messages > > > All, > > Section 11.1.2 Local MAC describes the Local MAC operation. It > currently states > (second paragraph below Figure 6): > > While the MAC is terminated on the WTP, it is necessary for the > AC to be aware of mobility events within the WTPs. > As a consequence, the WTP MUST forward the IEEE 802.11 > Association Requests to the AC, and the AC MAY reply > with a failed Association Response if it deems it necessary. > > > Since this is the Local MAC case, it seems that a MAY should be > sufficient. > > Recommended change: > > The MAC is terminated on the WTP, but the AC may need to be > aware of mobility events within the WTPs. > As a consequence, the WTP MAY forward the IEEE 802.11 > Association Requests to the AC, and the AC MAY reply > with a failed Association Response. > > Comments? > > Thanks, > > Dorothy > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --Boundary_(ID_hY5pMJa5xzgJ4uEX8WqVSA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
yup - that works for me.
 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

From: Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Monday, June 12, 2006 7:09 AM
To: Michael Montemurro
Cc: capwap
Subject: [Capwap] Proposed Resolution to Issue 134/wasRe: New Issue - LocalMAC MUST vs MAY forward associationrequest messages

Pat, David,

Agree that the AC must be notified. However the text also states that
" the AC MAY reply
 with a failed Association Response if it deems it necessary. "

introducing a race condition, when the WTP may have already responded to the
Association Request with an Association Response (success), before it
receives the "failed Association Response" from the AC.

Proposed resolution of Issue 134:

Change from:

While the MAC is terminated on the WTP, it is necessary for the
AC to be aware of mobility events within the WTPs.
As a consequence, the WTP MUST forward the IEEE 802.11
Association Requests to the AC, and the AC MAY reply
 with a failed Association Response if it deems it necessary.

to

While the MAC is terminated on the WTP, it is necessary for the
AC to be aware of mobility events within the WTPs.
As a consequence, the WTP MUST forward the IEEE 802.11
Association Requests to the AC. The AC MAY reply
with a failed Association Response if it deems it necessary, and upon
receipt of a failed Association Response from the AC,  the
WTP must send a Disassociation frame to the mobile station.

Thanks,

Dorothy

On 6/8/06, Michael Montemurro <montemurro.michael@gmail.com> wrote:
I've captured this as issue 134.
 
Cheers,
 
Mike


 
On 6/6/06, Dorothy Stanley < dstanley1389@gmail.com> wrote:
Pat, David,
 
Your comments are consistent with those received back in April, when
this mail was sent out - thus
I did not make, and had not planned to make the proposed change.
 
Thanks,
 
Dorothy

 
On 6/6/06, David T. Perkins <dperkins@dsperkins.com > wrote:
HI,

ABSOLUTELY agree with Pat. That is the AC MUST know what STAs
are be serviced by the WTPs, and MUST decide which STAs are
allowed to associate and send traffic.
This is the fundamental difference between a CAPWAP network
and a collection of APs.

Regards,
/david t. perkins

On Tue, 6 Jun 2006, Pat Calhoun (pacalhou) wrote:

> I disagree with this change request. The AC MUST know what STAs are
> being serviced by WTPs. The term MUST cannot be changed to MAY.
>
>
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
>
>
>
>
> ________________________________
>
>       From: Dorothy Stanley [mailto: dstanley1389@gmail.com]
>       Sent: Tuesday, April 11, 2006 11:41 AM
>       To: capwap
>       Subject: [Capwap] New Issue - Local MAC MUST vs MAY forward
> associationrequest messages
>
>
>       All,
>
>       Section 11.1.2 Local MAC describes the Local MAC operation. It
> currently states
>       (second paragraph below Figure 6):
>
>       While the MAC is terminated on the WTP, it is necessary for the
> AC to be aware of mobility events within the WTPs.
>       As a consequence, the WTP MUST forward the IEEE 802.11
> Association Requests to the AC, and the AC MAY reply
>       with a failed Association Response if it deems it necessary.
>
>
>       Since this is the Local MAC case, it seems that a MAY should be
>       sufficient.
>
>       Recommended change:
>
>       The MAC is terminated on the WTP, but the AC may need to be
> aware of mobility events within the WTPs.
>       As a consequence, the WTP MAY forward the IEEE 802.11
> Association Requests to the AC, and the AC MAY reply
>       with a failed Association Response.
>
>       Comments?
>
>       Thanks,
>
>       Dorothy
>
>
>



_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap



--Boundary_(ID_hY5pMJa5xzgJ4uEX8WqVSA)-- --Boundary_(ID_2FRKNlbCguLpNYqQZWA30A) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --Boundary_(ID_2FRKNlbCguLpNYqQZWA30A) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --Boundary_(ID_2FRKNlbCguLpNYqQZWA30A)-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 13 02:12:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq28N-0006pi-SE for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 02:12:15 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq28M-0001BT-6C for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 02:12:15 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 53B034300EF for ; Mon, 12 Jun 2006 23:12:13 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 243C14300A2 for ; Mon, 12 Jun 2006 23:11:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0DF1F144800D for ; Mon, 12 Jun 2006 23:11:38 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 177B71448021 for ; Mon, 12 Jun 2006 23:11:32 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060308/3.7W/jazz) with ESMTP id k5D6BTWZ019091; Tue, 13 Jun 2006 15:11:29 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k5D6BTw15396; Tue, 13 Jun 2006 15:11:29 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with SMTP id k5D6BU316880; Tue, 13 Jun 2006 15:11:30 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 13 Jun 2006 14:12:04 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDEEF53D@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Statistics for WTP Event Request - Issue 84 Thread-Index: AcaONEGoScm3CRRLR0yMFFAnjs73DgAY+t7A From: "Saravanan Govindan" To: "Dorothy Stanley" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_60_70, HTML_MESSAGE X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Statistics for WTP Event Request - Issue 84 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0223188960==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 This is a multi-part message in MIME format. --===============0223188960== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68EAF.E4B8A78D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68EAF.E4B8A78D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dorothy, =20 In general, I think the new message elements you propose address this issue well. I have included specific notes below.=20 =20 Cheers, Saravanan=20 =20 =20 > WTP Load - load in frames per second exchanged by the WTP - Assuming that > the exchange is over the air; Add "Wireless Link Frames/Sec" statistics field > in a new WTP Operational Statistics message element [SG] I am ok with this.=20 =20 > WTP Transmit Queue - as a percentage of queue size - Which Queue is this? going to the AC or the STA? > If to the STA, then the statistic may vary with the L2 wireless type, e.g., is it a=20 > single queue for non-WMM traffic? multiple statistics for each of the WMM queues, or an > aggregate of all wireless transmit queues? [SG] Reviewing this stat, I think this relates to "Congestion" below. =20 =20 > Channel Interference - SINR - this is radio dependent, include a noise floor in the=20 > proposed WTP Radio Statistics message element >=20 > Congestion - Congestion experienced by the WTP - Need more info here, is this congestion on the > WTP-AC link? How is it measured? [SG] This refers to congestion over the air interface (WTP-STA). Congestion over the air interface is a function of channel conditions and the transmit queue to STA(s). In dense deployments with many WTPs and STAs, transmit queues build up with channel interference. A first step to addressing this is to let the AC know of the condition.=20 =20 I think this Congestion should represent the total value of all transmit queues at the WTP. At the same time, the AC needs to know the total queue size available - so as to calculate relative level of congestion.=20 =20 > Propose new WTP specific statistics: >=20 > - Add more fields/detail to the WTP Reboot Statistics message element, see 4.4.43 > - Add a new WTP Operational Statistics message element > - Add a new WTP Radio Statistics message element, as shown below [SG] I am ok with the proposed message elements and fields. In addition, I think WTP Operational Statistics message element should have the following fields; =20 - WTP Load in the form of Wireless Link Frames/Sec - Congestion in the form of total wireless transmit queue=20 ------_=_NextPart_001_01C68EAF.E4B8A78D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dorothy,

 

In general, I think the new message elements you propose address = this issue well. I have included specific notes below. =

 

Cheers,


Saravanan

 

 

> WTP Load - load in frames per second exchanged by the WTP = -  Assuming that
> the exchange is over the air; Add  "Wireless Link Frames/Sec" statistics field
> in a new WTP Operational Statistics message element

[SG] I am ok with this.

 


> WTP Transmit Queue - as a percentage of queue size - Which Queue is = this? going to the AC or the STA?
> If to the STA, then the statistic may vary with the L2 wireless = type, e.g., is it a
> single queue for non-WMM traffic? multiple statistics for each of = the WMM queues, or an
> aggregate of all wireless transmit queues?

[SG] Reviewing this stat, I think this relates to “Congestion” below.

 

 

> Channel Interference - SINR - this is radio dependent, = include a noise floor in the
> proposed WTP Radio Statistics message element
>

> Congestion - Congestion experienced by the WTP - Need more = info here, is this congestion on the
> WTP-AC link? How is it measured?

[SG] This refers to congestion over the air interface (WTP-STA). Congestion over the air interface is a function of channel conditions = and the transmit queue to STA(s). In dense deployments with many WTPs and STAs, transmit queues build up with channel interference. A first step to = addressing this is to let the AC know of the condition. =

 

I think this Congestion should represent the total value of all transmit queues at the WTP. At the same time, the AC needs to know the = total queue size available – so as to calculate relative level of = congestion.

 


> Propose new WTP specific statistics:
>
> - Add more fields/detail to the  WTP Reboot Statistics message element, see 4.4.43
> - Add a new WTP Operational Statistics message element
> - Add a new WTP Radio Statistics message element, as shown = below

[SG] I am ok with the proposed message elements and fields. In addition, I think WTP Operational Statistics message element should have = the following fields;

 

- WTP Load in the form of Wireless Link = Frames/Sec

- Congestion in the form of total wireless transmit queue =




------_=_NextPart_001_01C68EAF.E4B8A78D-- --===============0223188960== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0223188960==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 13 09:49:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq9H4-000503-US for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 09:49:42 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq9H3-0005YH-43 for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 09:49:42 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BF492430137 for ; Tue, 13 Jun 2006 06:49:40 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 5B4414300E4 for ; Tue, 13 Jun 2006 06:49:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 475D9431089 for ; Tue, 13 Jun 2006 06:49:02 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by hermes.tigertech.net (Postfix) with ESMTP id BB060431088 for ; Tue, 13 Jun 2006 06:48:56 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so2165359pyu for ; Tue, 13 Jun 2006 06:48:56 -0700 (PDT) Received: by 10.35.41.14 with SMTP id t14mr3522529pyj; Tue, 13 Jun 2006 06:48:55 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Tue, 13 Jun 2006 06:48:55 -0700 (PDT) Message-ID: <26140d940606130648l39d22ba4m93ac3499b035d681@mail.gmail.com> Date: Tue, 13 Jun 2006 09:48:55 -0400 From: "Michael Montemurro" To: "Dorothy Stanley" In-Reply-To: <5bfe7a820606120709q7fd414ehc7348750c21e27bd@mail.gmail.com> MIME-Version: 1.0 References: <5bfe7a820606120709q7fd414ehc7348750c21e27bd@mail.gmail.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Proposed Resolution to Issue 134/wasRe: New Issue - Local MAC MUST vs MAY forward associationrequest messages X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1373042085==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 --===============1373042085== Content-Type: multipart/alternative; boundary="----=_Part_477_22778959.1150206535303" ------=_Part_477_22778959.1150206535303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline This works for me. Mike On 6/12/06, Dorothy Stanley wrote: > > Pat, David, > > Agree that the AC must be notified. However the text also states that > " the AC MAY reply > with a failed Association Response if it deems it necessary. " > > introducing a race condition, when the WTP may have already responded to > the > Association Request with an Association Response (success), before it > receives the "failed Association Response" from the AC. > > Proposed resolution of Issue 134: > > Change from: > > While the MAC is terminated on the WTP, it is necessary for the > AC to be aware of mobility events within the WTPs. > As a consequence, the WTP MUST forward the IEEE 802.11 > Association Requests to the AC, and the AC MAY reply > with a failed Association Response if it deems it necessary. > > to > > While the MAC is terminated on the WTP, it is necessary for the > AC to be aware of mobility events within the WTPs. > As a consequence, the WTP MUST forward the IEEE 802.11 > Association Requests to the AC. The AC MAY reply > with a failed Association Response if it deems it necessary, and upon > receipt of a failed Association Response from the AC, the > WTP must send a Disassociation frame to the mobile station. > > Thanks, > > Dorothy > > On 6/8/06, Michael Montemurro wrote: > > > > I've captured this as issue 134. > > > > Cheers, > > > > Mike > > > > > > > > On 6/6/06, Dorothy Stanley < dstanley1389@gmail.com> wrote: > > > > > Pat, David, > > > > Your comments are consistent with those received back in April, when > > this mail was sent out - thus > > I did not make, and had not planned to make the proposed change. > > > > Thanks, > > > > Dorothy > > > > > > On 6/6/06, David T. Perkins wrote: > > > > > > HI, > > > > > > ABSOLUTELY agree with Pat. That is the AC MUST know what STAs > > > are be serviced by the WTPs, and MUST decide which STAs are > > > allowed to associate and send traffic. > > > This is the fundamental difference between a CAPWAP network > > > and a collection of APs. > > > > > > Regards, > > > /david t. perkins > > > > > > On Tue, 6 Jun 2006, Pat Calhoun (pacalhou) wrote: > > > > > > > I disagree with this change request. The AC MUST know what STAs are > > > > being serviced by WTPs. The term MUST cannot be changed to MAY. > > > > > > > > > > > > Pat Calhoun > > > > CTO, Wireless Networking Business Unit > > > > Cisco Systems > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: Dorothy Stanley [mailto: dstanley1389@gmail.com] > > > > Sent: Tuesday, April 11, 2006 11:41 AM > > > > To: capwap > > > > Subject: [Capwap] New Issue - Local MAC MUST vs MAY forward > > > > associationrequest messages > > > > > > > > > > > > All, > > > > > > > > Section 11.1.2 Local MAC describes the Local MAC operation. It > > > > > > > currently states > > > > (second paragraph below Figure 6): > > > > > > > > While the MAC is terminated on the WTP, it is necessary for > > > the > > > > AC to be aware of mobility events within the WTPs. > > > > As a consequence, the WTP MUST forward the IEEE 802.11 > > > > Association Requests to the AC, and the AC MAY reply > > > > with a failed Association Response if it deems it necessary. > > > > > > > > > > > > Since this is the Local MAC case, it seems that a MAY should > > > be > > > > sufficient. > > > > > > > > Recommended change: > > > > > > > > The MAC is terminated on the WTP, but the AC may need to be > > > > aware of mobility events within the WTPs. > > > > As a consequence, the WTP MAY forward the IEEE 802.11 > > > > Association Requests to the AC, and the AC MAY reply > > > > with a failed Association Response. > > > > > > > > Comments? > > > > > > > > Thanks, > > > > > > > > Dorothy > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > > > > > > ------=_Part_477_22778959.1150206535303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
This works for me.
 
Mike

 
On 6/12/06, Dorothy Stanley <dstanley1389@gmail.com> wrote:
Pat, David,

Agree that the AC must be notified. However the text also states that
" the AC MAY reply
 with a failed Association Response if it deems it necessary. "

introducing a race condition, when the WTP may have already responded to the
Association Request with an Association Response (success), before it
receives the "failed Association Response" from the AC.

Proposed resolution of Issue 134:

Change from:

While the MAC is terminated on the WTP, it is necessary for the
AC to be aware of mobility events within the WTPs.
As a consequence, the WTP MUST forward the IEEE 802.11
Association Requests to the AC, and the AC MAY reply
 with a failed Association Response if it deems it necessary.

to

While the MAC is terminated on the WTP, it is necessary for the
AC to be aware of mobility events within the WTPs.
As a consequence, the WTP MUST forward the IEEE 802.11
Association Requests to the AC. The AC MAY reply
with a failed Association Response if it deems it necessary, and upon
receipt of a failed Association Response from the AC,  the
WTP must send a Disassociation frame to the mobile station.

Thanks,

Dorothy

On 6/8/06, Michael Montemurro <montemurro.michael@gmail.com > wrote:
I've captured this as issue 134.
 
Cheers,
 
Mike


 
On 6/6/06, Dorothy Stanley < dstanley1389@gmail.com > wrote:
Pat, David,
 
Your comments are consistent with those received back in April, when
this mail was sent out - thus
I did not make, and had not planned to make the proposed change.
 
Thanks,
 
Dorothy

 
On 6/6/06, David T. Perkins <dperkins@dsperkins.com > wrote:
HI,

ABSOLUTELY agree with Pat. That is the AC MUST know what STAs
are be serviced by the WTPs, and MUST decide which STAs are
allowed to associate and send traffic.
This is the fundamental difference between a CAPWAP network
and a collection of APs.

Regards,
/david t. perkins

On Tue, 6 Jun 2006, Pat Calhoun (pacalhou) wrote:

> I disagree with this change request. The AC MUST know what STAs are
> being serviced by WTPs. The term MUST cannot be changed to MAY.
>
>
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
>
>
>
>
> ________________________________
>
>       From: Dorothy Stanley [mailto: dstanley1389@gmail.com]
>       Sent: Tuesday, April 11, 2006 11:41 AM
>       To: capwap
>       Subject: [Capwap] New Issue - Local MAC MUST vs MAY forward
> associationrequest messages
>
>
>       All,
>
>       Section 11.1.2 Local MAC describes the Local MAC operation. It
> currently states
>       (second paragraph below Figure 6):
>
>       While the MAC is terminated on the WTP, it is necessary for the
> AC to be aware of mobility events within the WTPs.
>       As a consequence, the WTP MUST forward the IEEE 802.11
> Association Requests to the AC, and the AC MAY reply
>       with a failed Association Response if it deems it necessary.
>
>
>       Since this is the Local MAC case, it seems that a MAY should be
>       sufficient.
>
>       Recommended change:
>
>       The MAC is terminated on the WTP, but the AC may need to be
> aware of mobility events within the WTPs.
>       As a consequence, the WTP MAY forward the IEEE 802.11
> Association Requests to the AC, and the AC MAY reply
>       with a failed Association Response.
>
>       Comments?
>
>       Thanks,
>
>       Dorothy
>
>
>



_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

 

 

 

------=_Part_477_22778959.1150206535303-- --===============1373042085== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1373042085==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 13 09:53:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq9Ky-0006XH-L8 for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 09:53:44 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq9Kx-0006d3-06 for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 09:53:44 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 90521430136 for ; Tue, 13 Jun 2006 06:53:42 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id ED7D54300E4 for ; Tue, 13 Jun 2006 06:53:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BA1894310A5 for ; Tue, 13 Jun 2006 06:53:12 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id 230184310A7 for ; Tue, 13 Jun 2006 06:53:07 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 13 Jun 2006 06:52:51 -0700 X-IronPort-AV: i="4.06,127,1149490800"; d="scan'208"; a="1824695714:sNHT2979016148" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5DDqpQm002073; Tue, 13 Jun 2006 06:52:51 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5DDqpIs022913; Tue, 13 Jun 2006 06:52:51 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Jun 2006 06:52:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 Jun 2006 06:52:50 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2020A6CC3@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Capwap] Proposed Resolution to Issue 134/wasRe: New Issue - LocalMAC MUST vs MAY forward associationrequest messages Thread-Index: AcaOpL0SYGG9S0jjSECRD1MjoaSoRwAS9YZQ From: "Pat Calhoun (pacalhou)" To: "zhaoyujin 31390" X-OriginalArrivalTime: 13 Jun 2006 13:52:51.0391 (UTC) FILETIME=[A983A4F0:01C68EF0] Authentication-Results: sj-dkim-5.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Proposed Resolution to Issue 134/wasRe: New Issue - LocalMAC MUST vs MAY forward associationrequest messages X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Because the Association Request provides you with all of the information that you need anyways. Otherwise, you'd end up breaking up the request and creating another CAPWAP control message that we would have to define in the protocol. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: zhaoyujin 31390 [mailto:zhaoyujin@huawei.com] > Sent: Monday, June 12, 2006 9:49 PM > To: Pat Calhoun (pacalhou) > Cc: Dorothy Stanley; Michael Montemurro; capwap > Subject: Re:Re: [Capwap] Proposed Resolution to Issue > 134/wasRe: New Issue - LocalMAC MUST vs MAY forward > associationrequest messages > > Why don't define a notification event from AP to AC to > resolve the issue 134. Maybe AP can directly use "Add > mobile" to notify AC this event. > > For local MAC, AP forward association request message to AC > that maybe resolve issue 134, but the logic of this method is > not better and not easy to be accepted. > > Best regards > Michael > > > > yup- that works for me. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > > -------------------------------------------------------------- > ------------------ > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > Sent: Monday, June 12, 2006 7:09 AM > To: Michael Montemurro > Cc: capwap > Subject: [Capwap] Proposed Resolution to Issue 134/wasRe: New > Issue - LocalMAC MUST vs MAY forward associationrequest messages > > > Pat, David, > > Agree that the AC must be notified. However the text also states that > " the AC MAY reply > with a failed Association Response if it deems it necessary. " > > introducing a race condition, when the WTP may have already > responded to the > Association Request with an Association Response (success), before it > receives the "failed Association Response" from the AC. > > Proposed resolution of Issue 134: > > Change from: > > While the MAC is terminated on the WTP, it is necessary for the > AC to be aware of mobility events within the WTPs. > As a consequence, the WTP MUST forward the IEEE 802.11 > Association Requests to the AC, and the AC MAY reply > with a failed Association Response if it deems it necessary. > > to > > While the MAC is terminated on the WTP, it is necessary for the > AC to be aware of mobility events within the WTPs. > As a consequence, the WTP MUST forward the IEEE 802.11 > Association Requests to the AC. The AC MAY reply > with a failed Association Response if it deems it necessary, and upon > receipt of a failed Association Response from the AC, the > WTP must send a Disassociation frame to the mobile station. > > Thanks, > > Dorothy > > > On 6/8/06, Michael Montemurro wrote: > I've captured this as issue 134. > > Cheers, > > Mike > > > > On 6/6/06, Dorothy Stanley < dstanley1389@gmail.com> wrote: > Pat, David, > > Your comments are consistent with those received back in April, when > this mail was sent out - thus > I did not make, and had not planned to make the proposed change. > > Thanks, > > Dorothy > > > On 6/6/06, David T. Perkins wrote: > HI, > > ABSOLUTELY agree with Pat. That is the AC MUST know what STAs > are be serviced by the WTPs, and MUST decide which STAs are > allowed to associate and send traffic. > This is the fundamental difference between a CAPWAP network > and a collection of APs. > > Regards, > /david t. perkins > > On Tue, 6 Jun 2006, Pat Calhoun (pacalhou) wrote: > > > I disagree with this change request. The AC MUST know what STAs are > > being serviced by WTPs. The term MUST cannot be changed to MAY. > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > > ________________________________ > > > > From: Dorothy Stanley [mailto: dstanley1389@gmail.com] > > Sent: Tuesday, April 11, 2006 11:41 AM > > To: capwap > > Subject: [Capwap] New Issue - Local MAC MUST vs MAY forward > > associationrequest messages > > > > > > All, > > > > Section 11.1.2 Local MAC describes the Local MAC > operation. It > > currently states > > (second paragraph below Figure 6): > > > > While the MAC is terminated on the WTP, it is > necessary for the > > AC to be aware of mobility events within the WTPs. > > As a consequence, the WTP MUST forward the IEEE 802.11 > > Association Requests to the AC, and the AC MAY reply > > with a failed Association Response if it deems it necessary. > > > > > > Since this is the Local MAC case, it seems that a MAY > should be > > sufficient. > > > > Recommended change: > > > > The MAC is terminated on the WTP, but the AC may need to be > > aware of mobility events within the WTPs. > > As a consequence, the WTP MAY forward the IEEE 802.11 > > Association Requests to the AC, and the AC MAY reply > > with a failed Association Response. > > > > Comments? > > > > Thanks, > > > > Dorothy > > > > > > > > > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > > -------------------------------------------------------------- > ------------------ > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 13 09:59:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq9Q7-00027m-ID for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 09:59:03 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq9Q6-00070j-3U for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 09:59:03 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BD24D43016C for ; Tue, 13 Jun 2006 06:59:01 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 9D7A6430149 for ; Tue, 13 Jun 2006 06:58:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9106339802E for ; Tue, 13 Jun 2006 06:58:35 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id DEDCC39801D for ; Tue, 13 Jun 2006 06:58:32 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 13 Jun 2006 06:58:32 -0700 X-IronPort-AV: i="4.06,127,1149490800"; d="scan'208"; a="293800816:sNHT30889128" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5DDwWUj016654; Tue, 13 Jun 2006 06:58:32 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5DDwWCU006846; Tue, 13 Jun 2006 06:58:32 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Jun 2006 06:58:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 Jun 2006 06:58:31 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2020A6CC6@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] capwap transport analysis: QoS vs multiport Thread-Index: AcaOfR9mghxFsecPRmS8X1/2hdbMRAAc4u7w From: "Pat Calhoun (pacalhou)" To: "Scott G. Kelly" , "Bob O'Hara (boohara)" , "capwap" X-OriginalArrivalTime: 13 Jun 2006 13:58:31.0941 (UTC) FILETIME=[747F7350:01C68EF1] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] capwap transport analysis: QoS vs multiport X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 > [I don't agree that we should universally mistrust client > marking, but that is a different (and independent) > discussion, so we can take that up later.] I have rarely ever had a discussion with a vendor, or customer, where they trust the end device to mark its own packets appropriately. First, they don't trust the device, and second, the burden of pushing classification policies to all of their end user devices is too onerous. > So if the AC and WTP were to mark control packets so as to > make them distinguishable from data packets (using one of the > marking methods suggested above, and without relying on > client truthfulness), what problems remain? Well, I believe there are two issues are exist: 1. The protocol currently has no method of pushing down classification rules, in the form of TSPECs. So the WTP doesn't actually know what rules to enforce. 2. When centralized 802.11i is in force, the WTP cannot actually perform classification because all packets are encrypted, which forces the WTP to trust the STA's marking. I believe that both issues need to be addressed in order to allow the WTP to perform this task, otherwise we venture into yet another area where some functionality of the protocol is not permitted when an optional feature is enabled. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 13 10:09:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq9Zu-0004vS-RO for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 10:09:10 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq9Zt-0007HE-Du for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 10:09:10 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CED2443015E for ; Tue, 13 Jun 2006 07:09:08 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 247144300E4 for ; Tue, 13 Jun 2006 07:08:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0356A4310E4 for ; Tue, 13 Jun 2006 07:08:46 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.192.83]) by hermes.tigertech.net (Postfix) with ESMTP id 6A1004310E2 for ; Tue, 13 Jun 2006 07:08:43 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (rwcrmhc13) with ESMTP id <20060613140842m13001uq9se>; Tue, 13 Jun 2006 14:08:42 +0000 Message-ID: <448EC6EA.7070606@hyperthought.com> Date: Tue, 13 Jun 2006 07:08:42 -0700 From: Scott G Kelly User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <4FF84B0BC277FF45AA27FE969DD956A2020A6CC6@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2020A6CC6@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap Subject: Re: [Capwap] capwap transport analysis: QoS vs multiport X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Hi Pat, Pat Calhoun (pacalhou) wrote: >> [I don't agree that we should universally mistrust client >> marking, but that is a different (and independent) >> discussion, so we can take that up later.] > > I have rarely ever had a discussion with a vendor, or customer, where > they trust the end device to mark its own packets appropriately. First, > they don't trust the device, and second, the burden of pushing > classification > policies to all of their end user devices is too onerous. > >> So if the AC and WTP were to mark control packets so as to >> make them distinguishable from data packets (using one of the >> marking methods suggested above, and without relying on >> client truthfulness), what problems remain? > > Well, I believe there are two issues are exist: > 1. The protocol currently has no method of pushing down classification > rules, in the form of TSPECs. So the WTP doesn't actually know what > rules to enforce. > 2. When centralized 802.11i is in force, the WTP cannot actually > perform classification because all packets are encrypted, which forces > the WTP to trust the STA's marking. > > I believe that both issues need to be addressed in order to allow the > WTP to perform this task, otherwise we venture into yet another area > where some functionality of the protocol is not permitted when an > optional feature is enabled. > I don't think you answered the question I asked, so maybe I didn't formulate it correctly. Let's defer the question of end-user devices marking their own traffic for now, as that is a different issue. Instead, let's try to answer to this: if the AC/WTP (which are infrastructure network gear installed by the network administrator) mark control traffic so that it can be distinguished from data traffic, what problems remain with respect to control traffic QoS? Thanks, Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 13 11:12:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqAYl-0000fU-U7 for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 11:12:03 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqAYk-0003l2-F7 for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 11:12:03 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 89645430149 for ; Tue, 13 Jun 2006 08:12:01 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9CAA74300D8 for ; Tue, 13 Jun 2006 08:11:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 699464311B6 for ; Tue, 13 Jun 2006 08:11:37 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id 9B79C4311B4 for ; Tue, 13 Jun 2006 08:11:33 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 13 Jun 2006 08:11:33 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5DFBWaB025711 for ; Tue, 13 Jun 2006 08:11:32 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5DFBW9s018798 for ; Tue, 13 Jun 2006 08:11:32 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Jun 2006 08:11:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 Jun 2006 08:11:31 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC01A25420@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] capwap transport analysis: QoS vs multiport Thread-Index: AcaOfQ2NxzrIWW//Qt2AigDywFoDqgAfN3Tg From: "Bob O'Hara (boohara)" To: "capwap" X-OriginalArrivalTime: 13 Jun 2006 15:11:32.0625 (UTC) FILETIME=[A796C810:01C68EFB] Authentication-Results: sj-dkim-3.cisco.com; header.From=boohara@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=3.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, RCVD_IN_BL_SPAMCOP_NET, SPF_HELO_PASS, SPF_PASS X-Spam-Level: *** Subject: Re: [Capwap] capwap transport analysis: QoS vs multiport X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.8 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Scott wrote: >So if the AC and WTP were to mark control packets >so as to make them distinguishable from data packets >(using one of the marking methods suggested above, >and without relying on client truthfulness), what >problems remain? As Pat points out in a separate email, the problem of controlling how the WTP marks those packets remains to be solved. But, that discussion can continue in Pat's thread. Another problem is that the WTP, itself, is not trusted by the network to which it is attached. A widespread example is a network of WLAN hotspots. The WTPs at the hotspot are connected to the AC over a third party's network. In some of those hotspots, the WTP will be local-MAC. A hotspot user's packets from a local-MAC WTP will be able to be inspected at ingress to the third party's network, since the 5-tuple is clearly available in those packets. QoS can be applied to those user data packets, without requiring any changes to the third party's network equipment. However, if those same packets are sent to the AC by a split-MAC WTP, the third party network will not be able to distinguish control packets from data packets, unless they are sent on separate ports. In the CAPWAP packet, the 5-tuple is the same for both control and data. -Bob _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 13 11:16:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqAdT-00025t-8J for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 11:16:55 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqAdS-0004Uc-Ej for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 11:16:55 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 15A8B430126 for ; Tue, 13 Jun 2006 08:16:54 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B38864300D8 for ; Tue, 13 Jun 2006 08:16:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 97ABF43119F for ; Tue, 13 Jun 2006 08:16:20 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.206]) by hermes.tigertech.net (Postfix) with ESMTP id 6740C4311C9 for ; Tue, 13 Jun 2006 08:16:12 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id t13so94760wxc for ; Tue, 13 Jun 2006 08:15:59 -0700 (PDT) Received: by 10.70.67.5 with SMTP id p5mr7703336wxa; Tue, 13 Jun 2006 08:15:59 -0700 (PDT) Received: by 10.70.133.2 with HTTP; Tue, 13 Jun 2006 08:15:58 -0700 (PDT) Message-ID: <5bfe7a820606130815x63b98de4y2e45dcc2dfe891c5@mail.gmail.com> Date: Tue, 13 Jun 2006 08:15:58 -0700 From: "Dorothy Stanley" To: "Saravanan Govindan" In-Reply-To: <5F09D220B62F79418461A978CA0921BDEEF53D@pslexc01.psl.local> MIME-Version: 1.0 References: <5F09D220B62F79418461A978CA0921BDEEF53D@pslexc01.psl.local> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.6 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_50_60, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Statistics for WTP Event Request - Issue 84 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0552126182==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 17cf8eab1d6bbd2874a56f9e3554d91d --===============0552126182== Content-Type: multipart/alternative; boundary="----=_Part_84508_24487562.1150211758776" ------=_Part_84508_24487562.1150211758776 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Saravanan, Thanks for your comments. I have more questions on the proposed congestion/wireless transmit queue statistic: >I think this Congestion should represent the total value of all transmit queues at the WTP. At the same time, the AC needs to know >the total queue size available =96 so as to calculate relative level of congestion. >Congestion in the form of total wireless transmit queue Discussion: a) Proposed name of Statistic: Wireless Transmit Queue Level b) If the WTP calculates the percentage of total , then the total queue size available need not be transported c) Suggest the follwoing definition: Wireless Transmit Queue Level - The percentage of Wireless Transmit queue utilization, calaculated as the sum of utilized transmit queue lengths divided by the sum of maximum transmit queue lengths, multiplied by 100. d) Include in WTP Operational Statistics Message Element e) This statistic is per-radio. Comments? Thanks, Dorothy On 6/12/06, Saravanan Govindan wrote: > > Dorothy, > > > > In general, I think the new message elements you propose address this > issue well. I have included specific notes below. > > > > Cheers, > > > Saravanan > > > > > > > WTP Load - load in frames per second exchanged by the WTP - Assuming > that > > the exchange is over the air; Add "Wireless Link Frames/Sec" statistic= s > field > > in a new WTP Operational Statistics message element > > [SG] I am ok with this. > > > > > > WTP Transmit Queue - as a percentage of queue size - Which Queue is > this? going to the AC or the STA? > > If to the STA, then the statistic may vary with the L2 wireless type, > e.g., is it a > > single queue for non-WMM traffic? multiple statistics for each of the > WMM queues, or an > > aggregate of all wireless transmit queues? > > [SG] Reviewing this stat, I think this relates to "Congestion" below. > > > > > > > Channel Interference - SINR - this is radio dependent, include a noise > floor in the > > proposed WTP Radio Statistics message element > > > > > Congestion - Congestion experienced by the WTP - Need more info here, i= s > this congestion on the > > WTP-AC link? How is it measured? > > [SG] This refers to congestion over the air interface (WTP-STA). > Congestion over the air interface is a function of channel conditions and > the transmit queue to STA(s). In dense deployments with many WTPs and STA= s, > transmit queues build up with channel interference. A first step to > addressing this is to let the AC know of the condition. > > > > I think this Congestion should represent the total value of all transmit > queues at the WTP. At the same time, the AC needs to know the total queue > size available =96 so as to calculate relative level of congestion. > > > > > > Propose new WTP specific statistics: > > > > - Add more fields/detail to the WTP Reboot Statistics message element, > see 4.4.43 > > - Add a new WTP Operational Statistics message element > > - Add a new WTP Radio Statistics message element, as shown below > > [SG] I am ok with the proposed message elements and fields. In addition, > I think WTP Operational Statistics message element should have the follow= ing > fields; > > > > - WTP Load in the form of Wireless Link Frames/Sec > > - Congestion in the form of total wireless transmit queue > > > > > ------=_Part_84508_24487562.1150211758776 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Saravanan,

Thanks for your comments. I have more questions on the proposed congestion/= wireless
transmit queue statistic:

= >I think this Congestion should represent the total value of all transmit queues at the WTP. At the same time, the AC needs to know >the = total queue size available =96 so as to calculate relative level of congestion. >Congestion in the form of total wireless transmit queue
Discussion:

a) Proposed name of Statistic: Wireless Transmit Queue Level
b) If the WTP calculates the percentage of total , then the total queue
size available need not be transported
c) Suggest the follwoing definition:

Wireless Transmit Queue Level - The percentage of Wireless Transmit queue utilization, calaculated as the sum of utilized transmit queue lengths divi= ded by the
sum of maximum transmit queue lengths,  multiplied by 100.

d) Include in WTP Operational Statistics Message Element
e) This statistic is per-radio.

Comments?

Thanks,

Dorothy

On 6/12/06, Saravanan Govindan <Saravanan.Govindan@sg.panasonic.com> wrote:=

Dorothy,

 

In general, I think the new message elements you propose address this issue well. I have included specific notes below.

 

Cheers,


Saravanan

 

 

> WTP Load - load in frames per second exchanged by the WTP -  Assuming that
> the exchange is over the air; Add  "Wireless Link Frames/Sec" statistics field
> in a new WTP Operational Statistics message element

[SG] I am ok with this.

 


> WTP Transmit Queue - as a percentage of queue size - Which Queue is th= is? going to the AC or the STA?
> If to the STA, then the statistic may vary with the L2 wireless type, e.g., is it a
> single queue for non-WMM traffic? multiple statistics for each of the = WMM queues, or an
> aggregate of all wireless transmit queues?

[SG] Reviewing this stat, I think this relates to "Congestion" below.

 

 

> Channel Interference - SINR - this is radio dependent, include a noise floor in the
> proposed WTP Radio Statistics message element
>

> Congestion - Congestion experienced by the WTP - Need more info here, is this congestion on the
> WTP-AC link? How is it measured?

[SG] This refers to congestion over the air interface (WTP-STA). Congestion over the air interface is a function of channel conditions and t= he transmit queue to STA(s). In dense deployments with many WTPs and STAs, transmit queues build up with channel interference. A first step to address= ing this is to let the AC know of the condition.

 

I think this Congestion should represent the total value of all transmit queues at the WTP. At the same time, the AC needs to know the tota= l queue size available =96 so as to calculate relative level of congestion. <= /span>

 


> Propose new WTP specific statistics:
>
> - Add more fields/detail to the  WTP Reboot Statistics message element, see 4.4.43
> - Add a new WTP Operational Statistics message element
> - Add a new WTP Radio Statistics message element, as shown below

[SG] I am ok with the proposed message elements and fields. In addition, I think WTP Operational Statistics message element should have th= e following fields;

 

- WTP Load in the form of Wireless Link Frames/Sec

- Congestion in the form of total wireless transmit queue =





------=_Part_84508_24487562.1150211758776-- --===============0552126182== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0552126182==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 13 13:49:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqD1P-0002mM-8r for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 13:49:47 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqCuD-000394-He for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 13:42:23 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 72424430100 for ; Tue, 13 Jun 2006 10:42:19 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B850E4300E7 for ; Tue, 13 Jun 2006 10:41:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id AC47F39804F for ; Tue, 13 Jun 2006 10:41:49 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by zoidberg.tigertech.net (Postfix) with ESMTP id C19E8398033 for ; Tue, 13 Jun 2006 10:41:46 -0700 (PDT) Received: from [209.86.224.48] (helo=elwamui-rustique.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FqCte-0006Xz-1o; Tue, 13 Jun 2006 13:41:46 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Tue, 13 Jun 2006 13:41:46 -0400 Message-ID: <22295955.1150220506047.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> Date: Tue, 13 Jun 2006 10:41:46 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "Bob O'Hara (boohara)" , capwap Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710598cf6501be71b8bb7f96b5f1db2264a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.48 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: Re: [Capwap] capwap transport analysis: QoS vs multiport X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Hi Bob, boohara wrote: > >Scott wrote: > >>So if the AC and WTP were to mark control packets >>so as to make them distinguishable from data packets >>(using one of the marking methods suggested above, >>and without relying on client truthfulness), what >>problems remain? > >As Pat points out in a separate email, the problem of controlling how >the WTP marks those packets remains to be solved. But, that discussion >can continue in Pat's thread. > >Another problem is that the WTP, itself, is not trusted by the network >to which it is attached. A widespread example is a network of WLAN >hotspots. The WTPs at the hotspot are connected to the AC over a third >party's network. > >In some of those hotspots, the WTP will be local-MAC. A hotspot user's >packets from a local-MAC WTP will be able to be inspected at ingress to >the third party's network, since the 5-tuple is clearly available in >those packets. QoS can be applied to those user data packets, without >requiring any changes to the third party's network equipment. > >However, if those same packets are sent to the AC by a split-MAC WTP, >the third party network will not be able to distinguish control packets >from data packets, unless they are sent on separate ports. In the >CAPWAP packet, the 5-tuple is the same for both control and data. Keeping in mind that what we are trying to do is ascertain whether premise (4) was correctly formulated, let me re-state that in its original form: (4) many of these elements can only classify traffic based on 5-tuples; they apparently cannot use VLAN tags or 1:1 mappings of DSCP/802.1q/802.1d mappings Apparently, what is at issue is the phrase "1:1 mappings of" - if I apply what you've said above to this premise, it seems that this would be an acceptable re-formulation: (4) many of these elements can only classify traffic based on 5-tuples; they apparently cannot use AC/WTP-provided VLAN tags or DSCP/802.1q/802.1d markings for QoS purposes Does this reflect your intent? Thanks, Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 13 14:12:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqDNE-0002wQ-Gs for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 14:12:20 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqDNB-0006Wr-Nn for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 14:12:20 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 580FF43010A for ; Tue, 13 Jun 2006 11:12:17 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7245C4300E8 for ; Tue, 13 Jun 2006 11:11:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5CBD01448017 for ; Tue, 13 Jun 2006 11:11:47 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.204]) by hermes.tigertech.net (Postfix) with ESMTP id 274E6144800F for ; Tue, 13 Jun 2006 11:11:44 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id t13so123802wxc for ; Tue, 13 Jun 2006 11:11:40 -0700 (PDT) Received: by 10.70.103.15 with SMTP id a15mr7881833wxc; Tue, 13 Jun 2006 11:11:40 -0700 (PDT) Received: by 10.70.133.2 with HTTP; Tue, 13 Jun 2006 11:11:39 -0700 (PDT) Message-ID: <5bfe7a820606131111s162410e6m9c126202fccf4254@mail.gmail.com> Date: Tue, 13 Jun 2006 11:11:40 -0700 From: "Dorothy Stanley" To: young MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.6 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_50_60, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: [Capwap] Proposed Resolution To Issue 106 Pre-amble Length Configuration/ wasRe: some suggestion for 802.11 binding TLV (Dorothy Stanley) X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1555604011==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 --===============1555604011== Content-Type: multipart/alternative; boundary="----=_Part_87189_28055163.1150222300009" ------=_Part_87189_28055163.1150222300009 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, Issue 106 is provided below, and the discussion to date is in the attached mail. Issue 106: Because CAPWAP provide the definition of 802.11 binding, the common configuration for AP came from different vendors should defined by draft. I= felt something like "Preamble-length" configuration need to be added into draft. Proposed Resolution: Provide an option to turn short preamble on/off. Background: The short preamble is optional, and is typically allowed to be turned off. Long preamble is mandatory, and is used to send 1Mbps frames. In the IEEE 802.11 WTP Radio Configuration Message Element, use the 8-bit reserved field to turn use of the short pre-amble on or off: Change from: 11.10.24 IEEE 802.11 WTP Radio Configuration The WTP WLAN radio configuration is used by the AC to configure a Radio on the WTP, and by the WTP to deliver its radio configuration to the AC. The message element value contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Reserved | Num of BSSIDs | DTIM Period | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSSID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSSID | Beacon Period | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Country Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1047 for IEEE 802.11 WTP WLAN Radio Configuration Length: 16 Radio ID: An 8-bit value representing the radio to configure. Reserved: MUST be set to zero to 11.10.24 IEEE 802.11 WTP Radio Configuration The WTP WLAN radio configuration is used by the AC to configure a Radio on the WTP, and by the WTP to deliver its radio configuration to the AC. The message element value contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID |Short Preamble | Num of BSSIDs | DTIM Period | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSSID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSSID | Beacon Period | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Country Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1047 for IEEE 802.11 WTP WLAN Radio Configuration Length: 16 Radio ID: An 8-bit value representing the radio to configure. Short Preamble: A bit field indicating that the short preamble is not supported (0) or supported (1). On 4/27/06, young wrote: > > Dear All: > > > > I give more detailed suggestion about the following requirement: > > > 2) New TLV "Preamble-length" > > a) Why we need it? > > "Preamble-length" is basic configuration for most vendor's AP product. As > CAPWAP will provide 802.11 binding element, it should support the common > 802.11 configuration that most vendor support. > > b) The TLV could be carried in the "Configure Update request, configure > request, configure response" > > c) The TLV format > > The CAPWAP already has TLV IEEE 802.11 MAC operation, and we could add on= e > more element named "Preamble-length". The value for it could be: > > 1 =96 short (default) > > 2 - long > ------=_Part_87189_28055163.1150222300009 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline QWxsLDxicj4KPGJyPgpJc3N1ZSAxMDYgaXMgcHJvdmlkZWQgYmVsb3csIGFuZCB0aGUgZGlzY3Vz c2lvbiB0byBkYXRlIGlzIGluIHRoZSBhdHRhY2hlZCBtYWlsLjxicj4KPGJyPgpJc3N1ZSAxMDY6 PGJyPgo8cHJlPkJlY2F1c2UgQ0FQV0FQIHByb3ZpZGUgdGhlIGRlZmluaXRpb24gb2YgODAyLjEx IGJpbmRpbmcsIHRoZSBjb21tb248YnI+Y29uZmlndXJhdGlvbiBmb3IgQVAgY2FtZSBmcm9tIGRp ZmZlcmVudCB2ZW5kb3JzIHNob3VsZCBkZWZpbmVkIGJ5IGRyYWZ0LiBJIGZlbHQ8YnI+c29tZXRo aW5nIGxpa2UgIlByZWFtYmxlLWxlbmd0aCIgY29uZmlndXJhdGlvbiBuZWVkIHRvIGJlIGFkZGVk IGludG8gZHJhZnQuCjwvcHJlPgo8YnI+ClByb3Bvc2VkIFJlc29sdXRpb246IFByb3ZpZGUgYW4g b3B0aW9uIHRvIHR1cm4gc2hvcnQgcHJlYW1ibGUgb24vb2ZmLjxicj4KPGJyPgpCYWNrZ3JvdW5k OiBUaGUgc2hvcnQgcHJlYW1ibGUgaXMgb3B0aW9uYWwsIGFuZCBpcyB0eXBpY2FsbHkgYWxsb3dl ZCB0byBiZSB0dXJuZWQgb2ZmLiBMb25nPGJyPgpwcmVhbWJsZSBpcyBtYW5kYXRvcnksIGFuZCBp cyB1c2VkIHRvIHNlbmQgMU1icHMgZnJhbWVzLiA8YnI+Cjxmb250IGNvbG9yPSJuYXZ5IiBmYWNl PSJBcmlhbCIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgY29sb3I6IG5h dnk7IGZvbnQtZmFtaWx5OiBBcmlhbDsiPjxicj4KSW4gdGhlIElFRUUgODAyLjExIFdUUCBSYWRp byBDb25maWd1cmF0aW9uIE1lc3NhZ2UgRWxlbWVudCwgdXNlIHRoZTxicj4KOC1iaXQgcmVzZXJ2 ZWQgZmllbGQgdG8gdHVybiB1c2Ugb2YgdGhlIHNob3J0IHByZS1hbWJsZSBvbiBvciBvZmY6PGJy Pgo8YnI+CkNoYW5nZSBmcm9tOjxicj4KPGJyPgo8L3NwYW4+PC9mb250Pgo8cHJlPjExLjEwLjI0 ICBJRUVFIDgwMi4xMSBXVFAgUmFkaW8gQ29uZmlndXJhdGlvbjxicj48YnI+ICAgVGhlIFdUUCBX TEFOIHJhZGlvIGNvbmZpZ3VyYXRpb24gaXMgdXNlZCBieSB0aGUgQUMgdG8gY29uZmlndXJlIGE8 YnI+ICAgUmFkaW8gb24gdGhlIFdUUCwgYW5kIGJ5IHRoZSBXVFAgdG8gZGVsaXZlciBpdHMgcmFk aW8gY29uZmlndXJhdGlvbjxicj4gICB0byB0aGUgQUMuICBUaGUgbWVzc2FnZSBlbGVtZW50IHZh bHVlIGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgZmllbGRzOgo8YnI+PGJyPiAgICAgICAgIDAgICAg ICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDM8 YnI+ICAgICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxPGJyPiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwo8YnI+ICAgICAgIHwgICAgUmFk aW8gSUQgICB8ICAgIFJlc2VydmVkICAgfCBOdW0gb2YgQlNTSURzIHwgIERUSU0gUGVyaW9kICB8 PGJyPiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKzxicj4gICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICBCU1NJRCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKPGJyPiAgICAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kzxicj4gICAgICAgfCAgICAgICAgICBCU1NJRCAgICAgICAgICAgICAgICB8ICAgICAgQmVhY29u IFBlcmlvZCAgICAgICAgICAgIHw8YnI+ICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCjxicj4gICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICBDb3VudHJ5IENvZGUgICAgICAgICAgICAgICAgICAgICAgICAg IHw8YnI+ICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rPGJyPjxicj48YnI+PGJyPiAgIFR5cGU6ICAxMDQ3IGZvciBJ RUVFIDgwMi4xMSBXVFAgV0xBTiBSYWRpbyBDb25maWd1cmF0aW9uCjxicj48YnI+ICAgTGVuZ3Ro OiAgMTY8YnI+PGJyPiAgIFJhZGlvIElEOiAgQW4gOC1iaXQgdmFsdWUgcmVwcmVzZW50aW5nIHRo ZSByYWRpbyB0byBjb25maWd1cmUuPGJyPjxicj4gICBSZXNlcnZlZDogIE1VU1QgYmUgc2V0IHRv IHplcm88YnI+PGJyPnRvPGJyPjxicj4xMS4xMC4yNCBJRUVFIDgwMi4xMSBXVFAgUmFkaW8gQ29u ZmlndXJhdGlvbjxicj48YnI+ICAgVGhlIFdUUCBXTEFOIHJhZGlvIGNvbmZpZ3VyYXRpb24gaXMg dXNlZCBieSB0aGUgQUMgdG8gY29uZmlndXJlIGEKPGJyPiAgIFJhZGlvIG9uIHRoZSBXVFAsIGFu ZCBieSB0aGUgV1RQIHRvIGRlbGl2ZXIgaXRzIHJhZGlvIGNvbmZpZ3VyYXRpb248YnI+ICAgdG8g dGhlIEFDLiAgVGhlIG1lc3NhZ2UgZWxlbWVudCB2YWx1ZSBjb250YWlucyB0aGUgZm9sbG93aW5n IGZpZWxkczo8YnI+PGJyPiAgICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAg ICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKPGJyPiAgICAgICAgIDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMTxicj4gICAg ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSs8YnI+ICAgICAgIHwgICAgUmFkaW8gSUQgICB8U2hvcnQgUHJlYW1ibGUgfCBO dW0gb2YgQlNTSURzIHwgIERUSU0gUGVyaW9kICB8Cjxicj4gICAgICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8YnI+ICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgQlNTSUQgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8PGJyPiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwo8YnI+ICAgICAgIHwgICAgICAgICAgQlNT SUQgICAgICAgICAgICAgICAgfCAgICAgIEJlYWNvbiBQZXJpb2QgICAgICAgICAgICB8PGJyPiAg ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKzxicj4gICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICBDb3VudHJ5 IENvZGUgICAgICAgICAgICAgICAgICAgICAgICAgIHwKPGJyPiAgICAgICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzxicj48 YnI+PGJyPjxicj4gICBUeXBlOiAgMTA0NyBmb3IgSUVFRSA4MDIuMTEgV1RQIFdMQU4gUmFkaW8g Q29uZmlndXJhdGlvbjxicj48YnI+ICAgTGVuZ3RoOiAgMTY8YnI+PGJyPiAgIFJhZGlvIElEOiAg QW4gOC1iaXQgdmFsdWUgcmVwcmVzZW50aW5nIHRoZSByYWRpbyB0byBjb25maWd1cmUuCjxicj48 YnI+ICAgU2hvcnQgUHJlYW1ibGU6ICBBIGJpdCBmaWVsZCBpbmRpY2F0aW5nIHRoYXQgdGhlIHNo b3J0IHByZWFtYmxlPGJyPiAgICAgICAgICAgIGlzIG5vdCBzdXBwb3J0ZWQgKDApIG9yIHN1cHBv cnRlZCAoMSkuPGJyPjxicj48YnI+PC9wcmU+Cjxicj4KPGJyPjxicj48ZGl2PjxzcGFuIGNsYXNz PSJnbWFpbF9xdW90ZSI+T24gNC8yNy8wNiwgPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPnlv dW5nPC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlvdW5nQGh1YXdlaS0zY29tLmNvbSI+eW91bmdA aHVhd2VpLTNjb20uY29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAy MDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgo8ZGl2 PgoKCgoKCgoKCgoKCjxkaXYgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgbGFuZz0iWkgtQ04i PgoKPGRpdiBzdHlsZT0iIj4KCjxwPjxmb250IGZhY2U9IsvOzOUiIHNpemU9IjIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwLjVwdDsiIGxhbmc9IkVOLVVTIj5EZWFyIEFsbDo8L3NwYW4+PC9m b250PjwvcD4KCjxwPjxmb250IGZhY2U9IsvOzOUiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDEwLjVwdDsiIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4KCjxw Pjxmb250IGZhY2U9IsvOzOUiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVw dDsiIGxhbmc9IkVOLVVTIj5JIGdpdmUgbW9yZSBkZXRhaWxlZCBzdWdnZXN0aW9uIGFib3V0IHRo ZSBmb2xsb3dpbmcgcmVxdWlyZW1lbnQ6PC9zcGFuPjwvZm9udD48L3A+PC9kaXY+PC9kaXY+PC9k aXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPgombHQ7c25pcCZndDsgPGJyPgo8L2Rpdj48YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJn YigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0 OiAxZXg7Ij48ZGl2PjxkaXYgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgbGFuZz0iWkgtQ04i PjxkaXYgc3R5bGU9IiI+PGJyPgo8cD48Zm9udCBmYWNlPSLLzszlIiBzaXplPSIyIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IiBsYW5nPSJFTi1VUyI+MikgTmV3IFRMViAmcXVvdDtQ cmVhbWJsZS1sZW5ndGgmcXVvdDs8L3NwYW4+PC9mb250PjwvcD4KCjxwPjxmb250IGZhY2U9IsvO zOUiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsiIGxhbmc9IkVOLVVT Ij5hKSBXaHkgd2UgbmVlZCBpdD88L3NwYW4+PC9mb250PjwvcD4KCjxwPjxmb250IGZhY2U9IsvO zOUiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsiIGxhbmc9IkVOLVVT Ij4mcXVvdDtQcmVhbWJsZS1sZW5ndGgmcXVvdDsgaXMgYmFzaWMgY29uZmlndXJhdGlvbiBmb3IK bW9zdCB2ZW5kb3I8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPSIy Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IiBsYW5nPSJFTi1VUyI+Jzwvc3Bhbj48 L2ZvbnQ+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyIgbGFu Zz0iRU4tVVMiPnMgQVAgcHJvZHVjdC4gQXMgQ0FQV0FQIHdpbGwKcHJvdmlkZSA4MDIuMTEgYmlu ZGluZyBlbGVtZW50LCBpdCBzaG91bGQgc3VwcG9ydCB0aGUgY29tbW9uIDgwMi4xMQpjb25maWd1 cmF0aW9uIHRoYXQgbW9zdCB2ZW5kb3Igc3VwcG9ydC48L3NwYW4+PC9mb250PjwvcD4KCjxwPjxm b250IGZhY2U9IsvOzOUiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsi IGxhbmc9IkVOLVVTIj5iKSBUaGUgVExWIGNvdWxkIGJlIGNhcnJpZWQgaW4gdGhlIDwvc3Bhbj48 L2ZvbnQ+PGZvbnQgZmFjZT0iQ291cmllciBOZXciIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDEwLjVwdDsiIGxhbmc9IkVOLVVTIj4iPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIy Ij4KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyIgbGFuZz0iRU4tVVMiPkNvbmZpZ3Vy ZSBVcGRhdGUgcmVxdWVzdCwgY29uZmlndXJlIHJlcXVlc3QsIGNvbmZpZ3VyZQpyZXNwb25zZTwv c3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iQ291cmllciBOZXciIHNpemU9IjIiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDEwLjVwdDsiIGxhbmc9IkVOLVVTIj4iPC9zcGFuPjwvZm9udD48L3A+Cgo8 cD48Zm9udCBmYWNlPSLLzszlIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41 cHQ7IiBsYW5nPSJFTi1VUyI+YykgVGhlIFRMViBmb3JtYXQgPC9zcGFuPjwvZm9udD48L3A+Cgo8 cD48Zm9udCBmYWNlPSLLzszlIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41 cHQ7IiBsYW5nPSJFTi1VUyI+VGhlIENBUFdBUCBhbHJlYWR5IGhhcyBUTFYgSUVFRSA4MDIuMTEg TUFDIG9wZXJhdGlvbiwgYW5kCndlIGNvdWxkIGFkZCBvbmUgbW9yZSBlbGVtZW50IG5hbWVkICZx dW90O1ByZWFtYmxlLWxlbmd0aCZxdW90Oy4gVGhlIHZhbHVlIGZvcgppdCBjb3VsZCBiZTo8L3Nw YW4+PC9mb250PjwvcD4KCjxwIHN0eWxlPSJ0ZXh0LWFsaWduOiBsZWZ0OyIgYWxpZ249ImxlZnQi Pjxmb250IGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciIHNpemU9IjIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwcHQ7IGNvbG9yOiBibGFjazsiIGxhbmc9IkVOLVVTIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMSCoQwpzaG9ydCAoZGVmYXVsdCk8L3NwYW4+PC9mb250 PjwvcD4KCjxwPjxmb250IGNvbG9yPSJibGFjayIgZmFjZT0iQ291cmllciBOZXciIHNpemU9IjIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGNvbG9yOiBibGFjazsiIGxhbmc9IkVOLVVT Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKMiAtIGxvbmc8L3NwYW4+PC9mb250Pjwv cD48Zm9udCBmYWNlPSLLzszlIiBzaXplPSIxIj48c3BhbiBsYW5nPSJFTi1VUyI+PC9zcGFuPjwv Zm9udD48Zm9udCBmYWNlPSLLzszlIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MC41cHQ7IiBsYW5nPSJFTi1VUyI+PC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSLLzszlIiBzaXpl PSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IiBsYW5nPSJFTi1VUyI+Cjwvc3Bh bj48L2ZvbnQ+PGZvbnQgZmFjZT0iy87M5SIgc2l6ZT0iMSI+PHNwYW4gbGFuZz0iRU4tVVMiPjwv c3Bhbj48L2ZvbnQ+PC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj4K ------=_Part_87189_28055163.1150222300009-- --===============1555604011== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1555604011==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 13 16:40:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqFgo-0002o4-Jd for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 16:40:42 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqFgn-0004In-Q7 for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 16:40:42 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6E6C343013D for ; Tue, 13 Jun 2006 13:40:41 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id AA0034300E8 for ; Tue, 13 Jun 2006 13:40:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 941171448044 for ; Tue, 13 Jun 2006 13:40:11 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.199]) by hermes.tigertech.net (Postfix) with ESMTP id 8B6081448049 for ; Tue, 13 Jun 2006 13:40:08 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id t13so144060wxc for ; Tue, 13 Jun 2006 13:40:07 -0700 (PDT) Received: by 10.70.128.9 with SMTP id a9mr8053529wxd; Tue, 13 Jun 2006 13:40:07 -0700 (PDT) Received: by 10.70.133.2 with HTTP; Tue, 13 Jun 2006 13:40:07 -0700 (PDT) Message-ID: <5bfe7a820606131340v5df56eado8edeef81a2053346@mail.gmail.com> Date: Tue, 13 Jun 2006 13:40:07 -0700 From: "Dorothy Stanley" To: capwap MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.1 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_10_20, HTML_FONT_BIG, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: [Capwap] Proposed Resolution for Issue 74: "About IEEE 802.11 Binding" X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1414398203==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.1 (+) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 --===============1414398203== Content-Type: multipart/alternative; boundary="----=_Part_89131_6981483.1150231207588" ------=_Part_89131_6981483.1150231207588 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, Issue 74 is listed below, and proposes text changes to 2 sections, the IEEE 802.11 WLAN Config Response message (now 11.7.2) and the Mobile Configuration Response Message (now 10.2). Proposed Resolutions are included below. Comments welcome. Thanks, Dorothy Issue 74 Part 1: Because different product has different process mechanism, LWAPP need give clear description about process. And if "IEEE 802.11 WLAN Configuration Response" also has a Result Code message element as "Mobile Config Response", 802.11 protocol may be better to control WLAN configuration. I suggest: >11.8.2 IEEE 802.11 WLAN Config Response > > The IEEE 802.11 WLAN Configuration Response is sent by the WTP to the > AC as an acknowledgement of the receipt of an IEEE 802.11 WLAN > Configuration Request. > This LWAPP control message does not include any message elements. change to: 11.8.2 IEEE 802.11 WLAN Config Response The IEEE 802.11 WLAN Configuration Response is sent by the WTP to the AC as an acknowledgement of the receipt of an IEEE 802.11 WLAN Configuration Request. Before this LWAPP control message is sent, the IEEE 802.11 WLAN Cofiguration should be successfully implemented. This LWAPP control message does not include any message elements. Proposed Resolution: Change the current -01 text from: 11.7.2. IEEE 802.11 WLAN Config Response The IEEE 802.11 WLAN Configuration Response is sent by the AC to the WTP as an acknowledgement of the receipt of an IEEE 802.11 WLAN Configuration Request. The following message elements may be included in the IEEE 802.11 WLAN Config Request message. Only one message element MUST be present. o IEEE 802.11 Assigned WTP BSSID, see Section 11.10.3 to 11.7.2. IEEE 802.11 WLAN Configuration Response The IEEE 802.11 WLAN Configuration Response message is sent by the WTP to the AC. It is used to acknowledge receipt of an IEEE 802.11 WLAN Configuration Request message, and to indicate if the requested configuration was successfully applied, or if an error related to the processing of the IEEE 802.11 WLAN Configuration Request message occurred on the WTP. The following message element MAY be included in the IEEE 802.11 WLAN Config Response message. o IEEE 802.11 Assigned WTP BSSID, see Section 11.10.3 The following message element MUST be included in the IEEE 802.11 WLAN Config Request message. Only one message element MUST be present. o Result Code, see Section 4.4.29 Issue 74 Part 2: >9.2 Mobile Config Response > > The Mobile Configuration Response is used to acknowledge a previously > received Mobile Configuration Request, and includes a Result Code > message element which indicates whether an error occured on the WTP. > > This message requires no special processing, and is only used to > acknowledge the Mobile Configuration Request. > change to: 9.2 Mobile Config Response The Mobile Configuration Response is used to acknowledge a previously received Mobile Configuration Request, and includes a Result Code message element, see Section 4.4.29 which indicates whether an error occured on the WTP. Before this message is sent, the Mobile Cofiguration should be implemented. The Result Code indicate if Mobile Cofiguration is successfully on WTP. This message requires no special processing, and is only used to acknowledge the Mobile Configuration Request. Proposed Resolution: Change the Current -01 text from: 10.2. Mobile Config Response The Mobile Configuration Response message is used to acknowledge a previously received Mobile Configuration Request message, and MUST include a Result Code message element, see Section 4.4.29 which indicates whether an error occurred on the WTP. This message requires no special processing, and is only used to acknowledge receipt of the Mobile Configuration Request message. to 10.2. Mobile Configuration Response The Mobile Configuration Response message is used to acknowledge a previously received Mobile Configuration Request message. The following message element MUST be present in the Mobile Configuration Response message. o Result Code, see Section 4.4.29 The Result Code message element indicates that the requested configuration was successfully applied, or that an error related to processing of the Mobile Configuration Request message occurred on the WTP. ------=_Part_89131_6981483.1150231207588 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline All,

Issue 74 is listed below, and proposes text changes to 2 sections, the
IEEE 802.11 WLAN Config Response message (now 11.7.2) and the Mobile Configuration
Response Message (now 10.2).
Proposed Resolutions are included below.

Comments welcome.

Thanks,

Dorothy

Issue 74 Part 1: Because different product has different process mechanism, LWAPP need give 
clear description about process. 
And if "IEEE 802.11 WLAN Configuration Response" also has a Result Code 

message element as "Mobile Config Response", 802.11 protocol may be better to 
control WLAN configuration.
I suggest:

>11.8.2  IEEE 802.11 WLAN Config Response
>
>   The IEEE 802.11
 WLAN Configuration Response is sent by the WTP to the
>   AC as an acknowledgement of the receipt of an IEEE 802.11 WLAN
>   Configuration Request.
>   This LWAPP control message does not include any message elements.


change to:
11.8.2  IEEE 802.11 WLAN Config Response
    The IEEE 802.11 WLAN Configuration Response is sent by the WTP to the
    AC as an acknowledgement of the receipt of an IEEE 802.11 WLAN
    Configuration Request.


    Before this LWAPP control message is sent, the IEEE 802.11 WLAN 
    Cofiguration should be successfully implemented.

    This LWAPP control message does not include any message elements.


Proposed Resolution:

Change the current -01 text  from:
11.7.2.  IEEE 802.11 WLAN Config Response

   The IEEE 802.11 WLAN Configuration Response is sent by the AC to the
   WTP as an acknowledgement of the receipt of an IEEE 
802.11 WLAN
   Configuration Request.

   The following message elements may be included in the IEEE 802.11
   WLAN Config Request message.  Only one message element MUST be
   present.

   o  IEEE 802.11
 Assigned WTP BSSID, see Section 11.10.3

to

11.7.2.  IEEE 802.11 WLAN Configuration Response

   The IEEE 802.11 WLAN Configuration Response message is sent by the WTP to the

   AC. It is used to acknowledge receipt of an IEEE 802.11 WLAN
   Configuration Request message, and to indicate if the requested
   configuration was successfully applied, or if an error related to the processing

   of the IEEE 802.11 WLAN Configuration Request message occurred on the
   WTP.

   The following message element MAY be included in the IEEE 802.11
   WLAN Config Response message.  

   o  IEEE 802.11
 Assigned WTP BSSID, see Section 11.10.3

   The following message element MUST be included in the IEEE 802.11
   WLAN Config Request message.  Only one message element MUST be
   present.

   o  Result Code, see Section 
4.4.29


Issue 74 Part 2:
>9.2  Mobile Config Response
>
>   The Mobile Configuration Response is used to acknowledge a previously
>   received Mobile Configuration Request, and includes a Result Code

>   message element which indicates whether an error occured on the WTP.
>
>   This message requires no special processing, and is only used to
>   acknowledge the Mobile Configuration Request.

>

change to:
9.2  Mobile Config Response

   The Mobile Configuration Response is used to acknowledge a previously
   received Mobile Configuration Request, and includes a Result Code
   message element, see Section 
4.4.29 which indicates whether an error occured on the WTP.

   Before this message is sent, the Mobile Cofiguration should be implemented.
   The Result Code indicate if Mobile Cofiguration is successfully on WTP.


   This message requires no special processing, and is only used to
   acknowledge the Mobile Configuration Request.


Proposed Resolution:
Change the Current -01 text from:

10.2.  Mobile Config Response

   The Mobile Configuration Response message is used to acknowledge a
   previously received Mobile Configuration Request message, and MUST
   include a Result Code message element, see Section 
4.4.29 which
   indicates whether an error occurred on the WTP.

   This message requires no special processing, and is only used to
   acknowledge receipt of the Mobile Configuration Request message.

to


10.2.  Mobile Configuration Response

   The Mobile Configuration Response message is used to acknowledge a
   previously received Mobile Configuration Request message. The following
   message element MUST be present in the Mobile Configuration Response message.


   o  Result Code, see Section 4.4.29
   
   The Result Code message element indicates that the requested configuration
   was successfully applied, or that an error related to processing of the 
   Mobile Configuration Request message occurred on the WTP.


------=_Part_89131_6981483.1150231207588-- --===============1414398203== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1414398203==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 13 17:25:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqGOC-0002d4-Su for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 17:25:32 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqGOA-0000zg-AY for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 17:25:32 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C2A4F43012C for ; Tue, 13 Jun 2006 14:25:29 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 491F44300E8 for ; Tue, 13 Jun 2006 14:25:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 39674398033 for ; Tue, 13 Jun 2006 14:25:07 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 88AA039800C for ; Tue, 13 Jun 2006 14:25:05 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5DLP5lJ011496; Tue, 13 Jun 2006 14:25:05 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5DLP4S7011488; Tue, 13 Jun 2006 14:25:04 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 13 Jun 2006 14:25:04 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Dorothy Stanley In-Reply-To: <5bfe7a820606131340v5df56eado8edeef81a2053346@mail.gmail.com> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Proposed Resolution for Issue 74: "About IEEE 802.11 Binding" X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 HI, There is a fundamental flaw with the config request/response messages in CAPWAP-01, and that is config changes can fail. When they do, the CAPWAP-01 does not say what is the result and how the error(s) are returned. The config changes can be "all or nothing". Or they could be one of the many partial applications. Also, in a failure, are the values assumed to be checked (and applied) strictly sequentially as found in the request, or can the values be checked (and applied) in an implementation defined order. What if there are more than one failure. What if the values when applied individually will work, but not together? I believe that the config operations need much more work. Also, when this is rewritten, I don't believe that using the term "LWAPP" is appropriate! Regards, /david t. perkins On Tue, 13 Jun 2006, Dorothy Stanley wrote: > All, > > Issue 74 is listed below, and proposes text changes to 2 sections, the > IEEE 802.11 WLAN Config Response message (now 11.7.2) and the Mobile > Configuration > Response Message (now 10.2). > Proposed Resolutions are included below. > > Comments welcome. > > Thanks, > > Dorothy > > Issue 74 Part 1: Because different product has different process > mechanism, LWAPP need give > clear description about process. > And if "IEEE 802.11 WLAN Configuration Response" also has a Result Code > message element as "Mobile Config Response", 802.11 protocol may be better to > control WLAN configuration. > I suggest: > > >11.8.2 IEEE 802.11 WLAN Config Response > > > > The IEEE 802.11 WLAN Configuration Response is sent by the WTP to the > > AC as an acknowledgement of the receipt of an IEEE 802.11 WLAN > > Configuration Request. > > This LWAPP control message does not include any message elements. > > change to: > 11.8.2 IEEE 802.11 WLAN Config Response > The IEEE 802.11 WLAN Configuration Response is sent by the WTP to the > AC as an acknowledgement of the receipt of an IEEE 802.11 WLAN > Configuration Request. > > Before this LWAPP control message is sent, the IEEE 802.11 WLAN > Cofiguration should be successfully implemented. > > This LWAPP control message does not include any message elements. > > Proposed Resolution: > > Change the current -01 text from: > 11.7.2. IEEE 802.11 WLAN Config Response > > The IEEE 802.11 WLAN Configuration Response is sent by the AC to the > WTP as an acknowledgement of the receipt of an IEEE 802.11 WLAN > Configuration Request. > > The following message elements may be included in the IEEE 802.11 > WLAN Config Request message. Only one message element MUST be > present. > > o IEEE 802.11 Assigned WTP BSSID, see Section 11.10.3 > > to > > 11.7.2. IEEE 802.11 WLAN Configuration Response > > The IEEE 802.11 WLAN Configuration Response message is sent by the WTP to the > AC. It is used to acknowledge receipt of an IEEE 802.11 WLAN > Configuration Request message, and to indicate if the requested > configuration was successfully applied, or if an error related to > the processing > of the IEEE 802.11 WLAN Configuration Request message occurred on the > WTP. > > The following message element MAY be included in the IEEE 802.11 > WLAN Config Response message. > > o IEEE 802.11 Assigned WTP BSSID, see Section 11.10.3 > > The following message element MUST be included in the IEEE 802.11 > WLAN Config Request message. Only one message element MUST be > present. > > o Result Code, see Section 4.4.29 > > > Issue 74 Part 2: > >9.2 Mobile Config Response > > > > The Mobile Configuration Response is used to acknowledge a previously > > received Mobile Configuration Request, and includes a Result Code > > message element which indicates whether an error occured on the WTP. > > > > This message requires no special processing, and is only used to > > acknowledge the Mobile Configuration Request. > > > > change to: > 9.2 Mobile Config Response > > The Mobile Configuration Response is used to acknowledge a previously > received Mobile Configuration Request, and includes a Result Code > message element, see Section 4.4.29 which indicates whether an > error occured on the WTP. > > Before this message is sent, the Mobile Cofiguration should be implemented. > The Result Code indicate if Mobile Cofiguration is successfully on WTP. > > This message requires no special processing, and is only used to > acknowledge the Mobile Configuration Request. > > > Proposed Resolution: > Change the Current -01 text from: > > 10.2. Mobile Config Response > > The Mobile Configuration Response message is used to acknowledge a > previously received Mobile Configuration Request message, and MUST > include a Result Code message element, see Section 4.4.29 which > indicates whether an error occurred on the WTP. > > This message requires no special processing, and is only used to > acknowledge receipt of the Mobile Configuration Request message. > > to > > 10.2. Mobile Configuration Response > > The Mobile Configuration Response message is used to acknowledge a > previously received Mobile Configuration Request message. The following > message element MUST be present in the Mobile Configuration Response message. > > o Result Code, see Section 4.4.29 > > The Result Code message element indicates that the requested configuration > was successfully applied, or that an error related to processing of the > Mobile Configuration Request message occurred on the WTP. > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 13 17:59:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqGul-0006rC-Fe for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 17:59:11 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqGHZ-0000lt-5o for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 17:18:41 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqG5h-0004MH-Qr for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 17:06:27 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 24D1D43010E for ; Tue, 13 Jun 2006 14:06:23 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 50B1E4300E8 for ; Tue, 13 Jun 2006 14:05:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 44718398033 for ; Tue, 13 Jun 2006 14:05:57 -0700 (PDT) Received: from mgw-ext13.nokia.com (mgw-ext13.nokia.com [131.228.20.172]) by zoidberg.tigertech.net (Postfix) with ESMTP id F320239800C for ; Tue, 13 Jun 2006 14:05:53 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5DL5oi2026839 for ; Wed, 14 Jun 2006 00:05:52 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 00:04:58 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jun 2006 16:04:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 Jun 2006 14:04:55 -0700 Message-ID: <8A76136424391244A5CF01653370853701B32751@mvebe101.NOE.Nokia.com> In-Reply-To: <22295955.1150220506047.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] capwap transport analysis: QoS vs multiport Thread-Index: AcaPEMwEfJ+xZKqoTH26xAYNM1/GyAAGcAjw From: To: X-OriginalArrivalTime: 13 Jun 2006 21:04:56.0958 (UTC) FILETIME=[065B39E0:01C68F2D] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.178 tagged_above=-999 required=7 tests=NO_REAL_NAME X-Spam-Level: Subject: Re: [Capwap] capwap transport analysis: QoS vs multiport X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Colleagues, It's obvious but we should state that our discussion is strictly limited to 802.3 VLAN capable AC<->WTP connection with .3 frame size between the AC and WTP being less or equal to the WTP-STA frame size. Anything such as wireless would widen the scope beyond what we are talking about here. Best Regards, Michael -----Original Message----- From: ext Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: Tuesday, June 13, 2006 10:42 AM To: Bob O'Hara (boohara); capwap Subject: Re: [Capwap] capwap transport analysis: QoS vs multiport Hi Bob, boohara wrote: > >Scott wrote: > >>So if the AC and WTP were to mark control packets so as to make them >>distinguishable from data packets (using one of the marking methods >>suggested above, and without relying on client truthfulness), what >>problems remain? > >As Pat points out in a separate email, the problem of controlling how >the WTP marks those packets remains to be solved. But, that discussion >can continue in Pat's thread. > >Another problem is that the WTP, itself, is not trusted by the network >to which it is attached. A widespread example is a network of WLAN >hotspots. The WTPs at the hotspot are connected to the AC over a third >party's network. > >In some of those hotspots, the WTP will be local-MAC. A hotspot user's >packets from a local-MAC WTP will be able to be inspected at ingress to >the third party's network, since the 5-tuple is clearly available in >those packets. QoS can be applied to those user data packets, without >requiring any changes to the third party's network equipment. > >However, if those same packets are sent to the AC by a split-MAC WTP, >the third party network will not be able to distinguish control packets >from data packets, unless they are sent on separate ports. In the >CAPWAP packet, the 5-tuple is the same for both control and data. Keeping in mind that what we are trying to do is ascertain whether premise (4) was correctly formulated, let me re-state that in its original form: (4) many of these elements can only classify traffic based on 5-tuples; they apparently cannot use VLAN tags or 1:1 mappings of DSCP/802.1q/802.1d mappings Apparently, what is at issue is the phrase "1:1 mappings of" - if I apply what you've said above to this premise, it seems that this would be an acceptable re-formulation: (4) many of these elements can only classify traffic based on 5-tuples; they apparently cannot use AC/WTP-provided VLAN tags or DSCP/802.1q/802.1d markings for QoS purposes Does this reflect your intent? Thanks, Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 13 19:30:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqIKz-00073N-22 for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 19:30:21 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqIKw-0006cj-TS for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 19:30:21 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 309124300FA for ; Tue, 13 Jun 2006 16:30:18 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D23F84300A9 for ; Tue, 13 Jun 2006 16:29:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B5A7A144800E for ; Tue, 13 Jun 2006 16:29:34 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.194]) by hermes.tigertech.net (Postfix) with ESMTP id D895F1448003 for ; Tue, 13 Jun 2006 16:29:31 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id i26so1364762wxd for ; Tue, 13 Jun 2006 16:29:31 -0700 (PDT) Received: by 10.70.130.3 with SMTP id c3mr39890wxd; Tue, 13 Jun 2006 16:29:30 -0700 (PDT) Received: by 10.70.133.2 with HTTP; Tue, 13 Jun 2006 16:29:30 -0700 (PDT) Message-ID: <5bfe7a820606131629la4275e4r184d0f50e29dd5bd@mail.gmail.com> Date: Tue, 13 Jun 2006 16:29:30 -0700 From: "Dorothy Stanley" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201FC06E4@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A201FC06E4@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.6 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Proposed Rsolution Issue 81: Minor edits and questionsCAPWAP Protocol specification X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0255770297==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: c021adebe99b05433d94f84a85f41df2 --===============0255770297== Content-Type: multipart/alternative; boundary="----=_Part_90699_3241102.1150241370942" ------=_Part_90699_3241102.1150241370942 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Pat, Ok, I suggest that we re-name the information element then, to "Tunnel Mode", which seems to more accurately describe all modes in the field, rather than Frame Type (-00) and (Encapsulation Type) (-01), and which matches the language used in the IEEE 802.11 Add WLAN message element The proposed text is below. One question though. When local MAC/Local bridging is selected, what encapsulation is used for transport of the 802.11 Association and Action Frames from the WTP to/from the AC. It looks like that encapsulation is not yet specified. Are 2 modes indicated - local bridging and 802.3 or local bridging and native wireless, with the assumption that when local bridging is present, user data (vs 802.11control) only is locally bridged? Dorothy So the suggested resolution for part 2 of issue 81 is: Change from: 4.4.36. WTP Frame Encapsulation Type The WTP Frame EncapsultationType message element allows the WTP to communicate the encapsulation type, or tunneling modes of operation which it supports to the AC. A WTP that advertises support for all types allows the AC to select which type will be used, based on its local policy. 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Frame Enc Type | +-+-+-+-+-+-+-+-+ Type: 36 for WTP Frame Encapsulation Type Length: 1 Frame Encapsulation Type: The Frame type specifies the encapsulation modes supported by the WTP. The following values are supported: 1 - Local Bridging: Local Bridging allows the WTP to perform the bridging function. This value MUST NOT be used when the WTP MAC Type is set to Split-MAC. 2 - 802.3 Bridging: 802.3 Bridging requires the WTP and AC to encapsulate all user payload as native IEEE 802.3 frames (see Section 4.2). This value MUST NOT be used when the WTP MAC Type is set to Split-MAC. 4 - Native Bridging: Native Bridging requires the WTP and AC to encapsulate all user payloads as native wireless frames, as defined by the wireless binding (see Section 4.2). 7 - All: The WTP is capable of supporting all frame encapsulation types. To: 4.4.36. WTP Tunnel Mode The WTP Tunnel Mode message element allows the WTP to communicate the tunneling modes of operation which it supports to the AC. A WTP that advertises support for all types allows the AC to select which type will be used, based on its local policy. 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Frame Enc Type | +-+-+-+-+-+-+-+-+ Type: 36 for WTP Tunnel Mode Length: 1 Tunnel Mode: The Tunnel Mode specifies the tunneling modes supported by the WTP. The following values are supported: 1 - Local Bridging: When Local Bridging is used, the WTP does not tunnel user traffic to the AC; all user traffic is locally bridged. This value MUST NOT be used when the WTP MAC Type is set to Split-MAC 2 - 802.3 Tunnel: 802.3 Tunnel mode requires the WTP and AC to encapsulate all user payload as native IEEE 802.3 frames (see Section 4.2). All user teaffic is tunneled to the AC. This value MUST NOT be used when the WTP MAC Type is set to Split-MAC. 4 - Native Tunnel: Native Tunnel requires the WTP and AC to encapsulate all user payloads as native wireless frames, as defined by the wireless binding (see Section 4.2). All user traffic is tunneled to the AC. 7 - All: The WTP is capable of supporting all tunnel types. On 6/5/06, Pat Calhoun (pacalhou) wrote: > > Dorothy, > > My comments (using your numbering below). > 1. ok with change > 2. How would a WTP communicate that it is capable of providing local > bridging services to the AC? > 3. ok with change > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > ------------------------------ > *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] > *Sent:* Thursday, May 25, 2006 12:28 PM > *To:* capwap > *Subject:* [Capwap] Proposed Rsolution Issue 81: Minor edits and > questionsCAPWAP Protocol specification > > All, > > The proposed resolution to Issue 81 is listed below. > > Comments welcome. > > Thanks, > > Dorothy > > ---------------------------------------------------------------------------------- > > Issue 81: > > Very Readable -- some minor comments > > Page 33 -- Section 5.1 -- 5th paragraph > > If a Discovery Response .... equal to SilentInterval before sending further > Discovery Request messages. > > change to > > > If a Discovery Response .... equal to SilentInterval before returning to the > ide stand and sending further Discovery Request messages. > > > Section 5.1.5 WTP Frame Type -- Page 37 - Local Bridging > > > What do the frames look like -- do not understand what is sent or received. > > > Page 51 -- Top of Page -- Secton 7.3.2 > > cause repeated twice -- delete 1st reference > > > 1. Page 33, Section 5.1 is the Discovery Request Message definition > > The proposed change is to the following text: > > If a Discovery Response message is not received after sending the > maximum number of Discovery Request messages, the WTP enters the > Sulking state and MUST wait for an interval equal to SilentInterval > before sending further Discovery Request messages. > > Proposed resolution: In the -01 state machine, the WTP remains > in the Discover state whle determining which AC to send the Join Request > message to, see the description of state (b), Discovery to Discovery. > Reject the proposed change. > > 2. Section 5.1.4, WTP Frame Type is now section 4.4.36, > WTP Frame Encapsulation Type, copied below. It is unclear > why local bridging is listed as a frame type/eccapsulation type. > > Recommended change: > > Change from: > > 4.4.36. WTP Frame Encapsulation Type > > The WTP Frame EncapsultationType message element allows the WTP to > communicate the encapsulation type, or tunneling modes of operation > which it supports to the AC. A WTP that advertises support for all > types allows the AC to select which type will be used, based on its > local policy. > > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |Frame Enc Type | > +-+-+-+-+-+-+-+-+ > > Type: 36 for WTP Frame Encapsulation Type > > Length: 1 > > Frame Encapsulation Type: The Frame type specifies the encapsulation > modes supported by the WTP. The following values are supported: > > 1 - Local Bridging: Local Bridging allows the WTP to perform the > bridging function. This value MUST NOT be used when the WTP > MAC Type is set to Split-MAC. > > 2 - 802.3 Bridging: 802.3 Bridging requires the WTP and AC to > encapsulate all user payload as native IEEE 802.3 frames (see > Section 4.2). This value MUST NOT be used when the WTP MAC > Type is set to Split-MAC. > > 4 - Native Bridging: Native Bridging requires the WTP and AC to > encapsulate all user payloads as native wireless frames, as > defined by the wireless binding (see Section 4.2). > > 7 - All: The WTP is capable of supporting all frame encapsulation > types. > > To: > > 4.4.36. WTP Frame Encapsulation Type > > The WTP Frame EncapsultationType message element allows the WTP to > communicate the encapsulation type, or tunneling modes of operation > which it supports to the AC. A WTP that advertises support for all > types allows the AC to select which type will be used, based on its > local policy. > > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |Frame Enc Type | > +-+-+-+-+-+-+-+-+ > > Type: 36 for WTP Frame Encapsulation Type > > Length: 1 > > Frame Encapsulation Type: The Frame type specifies the encapsulation > modes supported by the WTP. The following values are supported: > > 1 - 802.3 Encapsulation: 802.3 Bridging requires the WTP and AC to > encapsulate all user payload as native IEEE 802.3 frames (see > Section 4.2). This value MUST NOT be used when the WTP MAC > Type is set to Split-MAC. > > 2 - Native Encapsulation: Native Bridging requires the WTP and AC > to > encapsulate all user payloads as native wireless frames, as > defined by the wireless binding (see Section 4.2). > > 3 - All: The WTP is capable of supporting both frame encapsulation > types. > > > 3. Change State Event, now 4.4.11 - the first "case" reference, (duplicate > text) has been deleted in draft -01. > > > ------=_Part_90699_3241102.1150241370942 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Pat,

Ok, I suggest that we re-name the information element then, to
"Tunnel Mode", which seems to more accurately describe all modes in the
field, rather than Frame Type (-00) and (Encapsulation Type) (-01), and
which matches the language used in the IEEE 802.11 Add WLAN message element
The proposed text is below.

One question though. When local MAC/Local bridging is selected, what encapsulation
is used for transport of the 802.11 Association and Action Frames from the WTP to/from
the AC. It looks like that encapsulation is not yet specified. Are 2 modes
indicated  - local bridging and 802.3 or local bridging and native wireless, with
the assumption that when local bridging is present, user data (vs 802.11 control)
only is locally bridged?

Dorothy

So the suggested resolution for part 2 of issue 81 is:

Change from:

4.4.36.  WTP Frame Encapsulation Type

   The WTP Frame EncapsultationType message element allows the WTP to
   communicate the encapsulation type, or tunneling modes of operation
   which it supports to the AC.  A WTP that advertises support for all
   types allows the AC to select which type will be used, based on its
   local policy.

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |Frame Enc Type  |
     +-+-+-+-+-+-+-+-+

   Type:  36 for WTP Frame Encapsulation Type

   Length:  1

   Frame Encapsulation Type:  The Frame type specifies the encapsulation
      modes supported by the WTP.  The following values are supported:

      1 - Local Bridging:  Local Bridging allows the WTP to perform the
         bridging function.  This value MUST NOT be used when the WTP
         MAC Type is set to Split-MAC.

      2 - 802.3 Bridging:  802.3 Bridging requires the WTP and AC to
         encapsulate all user payload as native IEEE 802.3 frames (see
         Section 4.2).  This value MUST NOT be used when the WTP MAC
         Type is set to Split-MAC.

      4 - Native Bridging:  Native Bridging requires the WTP and AC to
         encapsulate all user payloads as native wireless frames, as
         defined by the wireless binding (see Section 4.2).

      7 - All:  The WTP is capable of supporting all frame encapsulation
         types.

To:

4.4.36.  WTP Tunnel Mode

   The WTP Tunnel Mode message element allows the WTP to
   communicate the tunneling modes of operation
   which it supports to the AC.  A WTP that advertises support for all
   types allows the AC to select which type will be used, based on its
   local policy.

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |Frame Enc Type  |
     +-+-+-+-+-+-+-+-+

   Type:  36 for WTP Tunnel Mode

   Length:  1

   Tunnel Mode:  The Tunnel Mode specifies the tunneling
      modes supported by the WTP.  The following values are supported:

      1 - Local Bridging:  When Local Bridging is used, the WTP does not
          tunnel user traffic to the AC; all user traffic is locally bridged.
         This value MUST NOT be used when the WTP
         MAC Type is set to Split-MAC

      2 - 802.3 Tunnel:  802.3 Tunnel mode requires the WTP and AC to
         encapsulate all user payload as native IEEE 802.3 frames (see
         Section 4.2).  All user teaffic is tunneled to the AC. This value MUST
         NOT be used when the WTP MAC Type is set to Split-MAC.

      4 - Native Tunnel:  Native Tunnel requires the WTP and AC to
         encapsulate all user payloads as native wireless frames, as
         defined by the wireless binding (see Section 4.2). All user traffic
         is tunneled to the AC.

      7 - All:  The WTP is capable of supporting all tunnel types.


On 6/5/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
Dorothy,
 
My comments (using your numbering below).
1. ok with change
2. How would a WTP communicate that it is capable of providing local bridging services to the AC?
3. ok with change
 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

From: Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Thursday, May 25, 2006 12:28 PM
To: capwap
Subject: [Capwap] Proposed Rsolution Issue 81: Minor edits and questionsCAPWAP Protocol specification

All,

The proposed resolution to Issue 81 is listed below.

Comments welcome.

Thanks,

Dorothy
----------------------------------------------------------------------------------

Issue 81:
Very Readable -- some minor comments

Page 33 -- Section 5.1 -- 5th paragraph

If a Discovery Response .... equal to SilentInterval before sending further 

Discovery Request messages.

change to


If a Discovery Response .... equal to SilentInterval before returning to the 
ide stand and sending further Discovery Request messages.


Section 5.1.5
 WTP Frame Type -- Page 37 - Local Bridging


What do the frames look like -- do not understand what is sent or received.


Page 51 -- Top of Page -- Secton 7.3.2

cause repeated twice -- delete 1st reference

1. Page 33, Section 5.1 is the Discovery Request Message definition

The proposed change is to the following text:

   If a Discovery Response message is not received after sending the
   maximum number of Discovery Request messages, the WTP enters the
   Sulking state and MUST wait for an interval equal to SilentInterval
   before sending further Discovery Request messages.

Proposed resolution: In the -01 state machine, the WTP remains
in the Discover state whle determining which AC to send the Join Request
message to, see the description of state (b), Discovery to Discovery.
Reject the proposed change.

2. Section 5.1.4, WTP Frame Type is now section 4.4.36,
WTP Frame Encapsulation Type, copied below. It is unclear
why local bridging is listed as a frame type/eccapsulation type.

Recommended change:

Change from:

4.4.36.  WTP Frame Encapsulation Type

   The WTP Frame EncapsultationType message element allows the WTP to
   communicate the encapsulation type, or tunneling modes of operation
   which it supports to the AC.  A WTP that advertises support for all
   types allows the AC to select which type will be used, based on its
   local policy.

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |Frame Enc Type  |
     +-+-+-+-+-+-+-+-+

   Type:  36 for WTP Frame Encapsulation Type

   Length:  1

   Frame Encapsulation Type:  The Frame type specifies the encapsulation
      modes supported by the WTP.  The following values are supported:

      1 - Local Bridging:  Local Bridging allows the WTP to perform the
         bridging function.  This value MUST NOT be used when the WTP
         MAC Type is set to Split-MAC.

      2 - 802.3 Bridging:  802.3 Bridging requires the WTP and AC to
         encapsulate all user payload as native IEEE 802.3 frames (see
         Section 4.2).  This value MUST NOT be used when the WTP MAC
         Type is set to Split-MAC.

      4 - Native Bridging:  Native Bridging requires the WTP and AC to
         encapsulate all user payloads as native wireless frames, as
         defined by the wireless binding (see Section 4.2).

      7 - All:  The WTP is capable of supporting all frame encapsulation
         types.

To:

4.4.36.  WTP Frame Encapsulation Type

   The WTP Frame EncapsultationType message element allows the WTP to
   communicate the encapsulation type, or tunneling modes of operation
   which it supports to the AC.  A WTP that advertises support for all
   types allows the AC to select which type will be used, based on its
   local policy.

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |Frame Enc Type  |
     +-+-+-+-+-+-+-+-+

   Type:  36 for WTP Frame Encapsulation Type

   Length:  1

   Frame Encapsulation Type:  The Frame type specifies the encapsulation
      modes supported by the WTP.  The following values are supported:

      1 - 802.3 Encapsulation:  802.3 Bridging requires the WTP and AC to
         encapsulate all user payload as native IEEE 802.3 frames (see
         Section 4.2).  This value MUST NOT be used when the WTP MAC
         Type is set to Split-MAC.

      2 - Native Encapsulation:  Native Bridging requires the WTP and AC to
         encapsulate all user payloads as native wireless frames, as
         defined by the wireless binding (see Section 4.2).

      3 - All:  The WTP is capable of supporting both frame encapsulation
         types.


3. Change State Event, now 4.4.11 - the first "case" reference, (duplicate
text) has been deleted in draft -01.



------=_Part_90699_3241102.1150241370942-- --===============0255770297== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0255770297==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 13 20:27:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqJEe-0007fO-Ae for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 20:27:52 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqJEc-0005ZJ-MT for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 20:27:52 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B21D143013D for ; Tue, 13 Jun 2006 17:27:49 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1E2154300E8 for ; Tue, 13 Jun 2006 17:27:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0A1EB39804C for ; Tue, 13 Jun 2006 17:27:28 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0AF0639801A for ; Tue, 13 Jun 2006 17:27:24 -0700 (PDT) Received: from [209.86.224.48] (helo=elwamui-rustique.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FqJEC-0002R3-Cn; Tue, 13 Jun 2006 20:27:24 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Tue, 13 Jun 2006 20:27:24 -0400 Message-ID: <23351529.1150244844309.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> Date: Tue, 13 Jun 2006 20:27:24 -0400 (EDT) From: "Scott G. Kelly" To: "Bob O'Hara (boohara)" , capwap Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff71056687cc8e4f872af9e2de7df33c8270a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.48 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [Capwap] reasonably bounding our QoS ambitions for the base protocol X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 I wanted to limit my earlier reply to the question the thread originally was addressing (getting the premises straight), but I also think the response below needs more attention. I've changed the subject line to keep the two threads distinct. Comments inline... -----Original Message----- >From: "Bob O'Hara (boohara)" >Sent: Jun 13, 2006 11:11 AM >To: capwap >Subject: Re: [Capwap] capwap transport analysis: QoS vs multiport > > > >Scott wrote: > >>So if the AC and WTP were to mark control packets >>so as to make them distinguishable from data packets >>(using one of the marking methods suggested above, >>and without relying on client truthfulness), what >>problems remain? > >As Pat points out in a separate email, the problem of controlling how >the WTP marks those packets remains to be solved. But, that discussion >can continue in Pat's thread. > >Another problem is that the WTP, itself, is not trusted by the network >to which it is attached. A widespread example is a network of WLAN >hotspots. The WTPs at the hotspot are connected to the AC over a third >party's network. > >In some of those hotspots, the WTP will be local-MAC. A hotspot user's >packets from a local-MAC WTP will be able to be inspected at ingress to >the third party's network, since the 5-tuple is clearly available in >those packets. QoS can be applied to those user data packets, without >requiring any changes to the third party's network equipment. Currently, the vast majority (if not all) of the deployed hotspots are local MAC, and users of those hotspots have no expectation of QoS. If the access point requires QoS for control traffic, then it also needs it for the 802.11 mgmt traffic that it's forwarding to the AC, and the hotspot provider would negotiate an appropriate agreement with the ISP - but in this case, *both* the capwap control and data channels would require QoS. However, there is a much simpler solution (assuming this ever becomes a real problem). If user data *were* choking the Internet link and hence causing control traffic starvation, the WTP is in a unique position to detect this and defend itself by throttling down user traffic while it attempts to re-establish its control linkage. Also, there is no requirement that a local-MAC WTP reset just because the control channel is temporarily lost - indeed, isn't it common (in fact, demanded by customers) today for local MAC WTP's to switch into a restricted mode upon loss of the control channel connection, and to maintain existing user sessions while rejecting new ones? That is, this particular problem is already being effectively addressed in other ways. >However, if those same packets are sent to the AC by a split-MAC WTP, >the third party network will not be able to distinguish control packets >from data packets, unless they are sent on separate ports. In the >CAPWAP packet, the 5-tuple is the same for both control and data. I'm having a really hard time with this one - forwarding user data back to the AC in a hotspot scenario, and doing it over an untrusting (and untrusted) 3rd party network, and expecting to provide QoS to boot? It's hard to imagine this happening in practice, but the fact is that the same argument applies with respect to control channel traffic, i.e. if a flooded data channel is causing control channel starvation, the WTP or AC *knows* this - it's immediately evident - and the WTP or AC can throttle back the data channel flow in favor of the control channel. And this requires no 3rd party intervention. I'm sure that if we put our minds to it, we can dream up corner cases which might not be addressed by a single port protocol, but there are other ways to solve the problems above that don't entail the complexity and costs of the multiport approach. And as an aside, this would appear to be one of the cases where NAT is most likely to occur, further complicating things. ---- I think it's important to acknowledge that none of the proposed solutions is perfect, or will service all possible scenarios that we might dream up. I think it's also important to realize that there are many problems to be solved in wlan deployments, and we are not, indeed cannot be chartered to solve each and every one of them here. We need to solve a reasonable subset of them, and address other problems in later efforts. The vast majority of real-world deployments where reliable provision of QoS might be reasonably expected are within a single domain of control, and those that are not present very challenging problems - problems which should not within the charter of this working group at this time, if we are to accomplish anything useful within a meaningful time frame. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 13 20:48:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqJYs-0002Ku-Ki for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 20:48:46 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqJYr-0000MQ-5c for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 20:48:46 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D26A1430123 for ; Tue, 13 Jun 2006 17:48:44 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 5A8074300E8 for ; Tue, 13 Jun 2006 17:48:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id ECCDC1448012 for ; Tue, 13 Jun 2006 17:48:22 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id 532991448003 for ; Tue, 13 Jun 2006 17:48:20 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 13 Jun 2006 17:48:20 -0700 X-IronPort-AV: i="4.06,128,1149490800"; d="scan'208"; a="294246338:sNHT31740144" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k5E0mJHn013174; Tue, 13 Jun 2006 17:48:19 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5E0mJCU020394; Tue, 13 Jun 2006 17:48:19 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Jun 2006 17:48:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 Jun 2006 17:48:18 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2020A7027@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] reasonably bounding our QoS ambitions for the base protocol Thread-Index: AcaPSWE4RCyOI4dyR2eO2ZahW3ObrQAAbqzg From: "Pat Calhoun (pacalhou)" To: "Scott G. Kelly" , "Bob O'Hara (boohara)" , "capwap" X-OriginalArrivalTime: 14 Jun 2006 00:48:19.0436 (UTC) FILETIME=[3ADB12C0:01C68F4C] Authentication-Results: sj-dkim-1.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] reasonably bounding our QoS ambitions for the base protocol X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 > The vast majority of real-world deployments where reliable > provision of QoS might be reasonably expected are within a > single domain of control, and those that are not present very > challenging problems - problems which should not within the > charter of this working group at this time, if we are to > accomplish anything useful within a meaningful time frame. Scott, Either way you slice this issue, there is work on the table. If we opt for the MUX, then we need to add packet classification extensions to the protocol. If we opt for multi-port, then we add a keepalive to the data channel and text to ensure the state machine is fine. Personally, I think multi-ports opens up significant scenarios that are not otherwise available in the MUX case. Given we have work either way, I don't see why the MUX proposal is more attractive. All it does Is add restrictions, which will cause the WG to solve this problem in a subsequent revision of the RFCed protocol (-bis, or ver 2), in a manner that will certainly create header imcompatibilities. Why walk into this today, when we know pain will come from it? Nothing is free. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 13 21:11:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqJuU-0005rS-0r for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 21:11:06 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqJuP-0003OO-H2 for capwap-archive@lists.ietf.org; Tue, 13 Jun 2006 21:11:06 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E2F3943013C for ; Tue, 13 Jun 2006 18:11:00 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 04BCC4300E8 for ; Tue, 13 Jun 2006 18:10:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id DF05E398050 for ; Tue, 13 Jun 2006 18:10:40 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by zoidberg.tigertech.net (Postfix) with ESMTP id DD7C839801A for ; Tue, 13 Jun 2006 18:10:37 -0700 (PDT) Received: from [209.86.224.48] (helo=elwamui-rustique.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FqJu1-0002JF-6g; Tue, 13 Jun 2006 21:10:37 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Tue, 13 Jun 2006 21:10:37 -0400 Message-ID: <22485696.1150247437156.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> Date: Tue, 13 Jun 2006 21:10:37 -0400 (EDT) From: "Scott G. Kelly" To: "Pat Calhoun (pacalhou)" , "Bob O'Hara (boohara)" , capwap Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710a45ab8f8bc372de0085cc1090d3738d6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.48 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: Re: [Capwap] reasonably bounding our QoS ambitions for the base protocol X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hi Pat, >Scott, > >Either way you slice this issue, there is work on the table. If we >opt for the MUX, then we need to add packet classification extensions >to the protocol. If we opt for multi-port, then we add a keepalive to >the data channel and text to ensure the state machine is fine. I think this misses the mark by quite a bit. No matter what we do, we have QoS-related packet classification issues. That should be crystal clear by now. QoS is not just a question of distinguishing capwap control from data; we need granular QoS for encapsulated data channel elements, and perhaps even more so. Neither solution provides this, and that is the *real* QoS work that needs doing. The multiport proposal does nothing to address these issues, but will cost us a lot for an arguably non-existent benefit. Honestly, after looking closely at this, I find it hard to believe that QoS is the real motivator here. >Personally, I think multi-ports opens up significant scenarios that >are not otherwise available in the MUX case. Given we have work either >way, I don't see why the MUX proposal is more attractive. All it does >Is add restrictions, which will cause the WG to solve this problem in >a subsequent revision of the RFCed protocol (-bis, or ver 2), in a >manner that will certainly create header imcompatibilities. It is clear from analysis that has been posted here that the multiport approach entails far more pain than the single port approach, and solves far fewer problems in the process. Neither approach is perfect, but the multiport approach will clearly have numerous and significant operational issues that the single port approach will not. These issues have been documented and remain unrefuted. Ignoring facts does not make them go away. >Why walk into this today, when we know pain will come from it? > >Nothing is free. Clearly, and we should choose the approach that maximizes the return on our investment. Splitting capwap into two sub-protocols to partially (and poorly) solve problems that have already have lower cost solutions seems like a bad bet. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 14 03:05:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqPRP-0004z1-OR for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 03:05:27 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqPRN-0004ls-Rp for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 03:05:27 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0417A4300F1 for ; Wed, 14 Jun 2006 00:05:24 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9151743006C for ; Wed, 14 Jun 2006 00:04:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DCAC6430386 for ; Wed, 14 Jun 2006 00:04:42 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 7CFC0430199 for ; Wed, 14 Jun 2006 00:04:37 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060308/3.7W/kings) with ESMTP id k5E74YqK019797; Wed, 14 Jun 2006 16:04:34 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k5E74Yq22736; Wed, 14 Jun 2006 16:04:34 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/phillies) with SMTP id k5E74ak21108; Wed, 14 Jun 2006 16:04:36 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 14 Jun 2006 15:05:03 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDEEF6D5@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Statistics for WTP Event Request - Issue 84 Thread-Index: AcaO+/nTfjo9WjR9QWCD554hhG3fNAAfY96Q From: "Saravanan Govindan" To: "Dorothy Stanley" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_60_70, HTML_MESSAGE X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Statistics for WTP Event Request - Issue 84 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0071562820==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8897a8f96c648179e32cc9ffbb0aaffd This is a multi-part message in MIME format. --===============0071562820== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68F80.76137230" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68F80.76137230 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dorothy, =20 I agree with your definition and text for the new statistic. Regarding the statistic's relation to WTP radios, I think the statistic would be different for each radio provided that the radios are each served by separate transmit queues.=20 =20 I am ok with the semantics of the new name. I think for the benefit of first-time readers, a short description can be added to the definition. Please consider something along the lines of; =20 "The Wireless Transmit Queue Level is representative of congestion conditions over wireless interfaces between the WTP and wireless terminals." =20 Cheers, Saravanan=20 =20 =20 =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Tuesday, June 13, 2006 11:16 PM To: Saravanan Govindan Cc: Pat Calhoun (pacalhou); capwap Subject: Re: [Capwap] Statistics for WTP Event Request - Issue 84 =20 Saravanan, Thanks for your comments. I have more questions on the proposed congestion/wireless transmit queue statistic: >I think this Congestion should represent the total value of all transmit queues at the WTP. At the same time, the AC needs to know >the total queue size available - so as to calculate relative level of congestion. >Congestion in the form of total wireless transmit queue Discussion: a) Proposed name of Statistic: Wireless Transmit Queue Level b) If the WTP calculates the percentage of total , then the total queue size available need not be transported c) Suggest the follwoing definition: Wireless Transmit Queue Level - The percentage of Wireless Transmit queue utilization, calaculated as the sum of utilized transmit queue lengths divided by the sum of maximum transmit queue lengths, multiplied by 100. d) Include in WTP Operational Statistics Message Element e) This statistic is per-radio. Comments? Thanks, Dorothy On 6/12/06, Saravanan Govindan wrote:=20 Dorothy, =20 In general, I think the new message elements you propose address this issue well. I have included specific notes below.=20 =20 Cheers, Saravanan=20 =20 =20 > WTP Load - load in frames per second exchanged by the WTP - Assuming that > the exchange is over the air; Add "Wireless Link Frames/Sec" statistics field > in a new WTP Operational Statistics message element [SG] I am ok with this.=20 =20 > WTP Transmit Queue - as a percentage of queue size - Which Queue is this? going to the AC or the STA? > If to the STA, then the statistic may vary with the L2 wireless type, e.g., is it a=20 > single queue for non-WMM traffic? multiple statistics for each of the WMM queues, or an > aggregate of all wireless transmit queues? [SG] Reviewing this stat, I think this relates to "Congestion" below. =20 =20 > Channel Interference - SINR - this is radio dependent, include a noise floor in the=20 > proposed WTP Radio Statistics message element >=20 > Congestion - Congestion experienced by the WTP - Need more info here, is this congestion on the > WTP-AC link? How is it measured? [SG] This refers to congestion over the air interface (WTP-STA). Congestion over the air interface is a function of channel conditions and the transmit queue to STA(s). In dense deployments with many WTPs and STAs, transmit queues build up with channel interference. A first step to addressing this is to let the AC know of the condition.=20 =20 I think this Congestion should represent the total value of all transmit queues at the WTP. At the same time, the AC needs to know the total queue size available - so as to calculate relative level of congestion.=20 =20 > Propose new WTP specific statistics: >=20 > - Add more fields/detail to the WTP Reboot Statistics message element, see 4.4.43 > - Add a new WTP Operational Statistics message element > - Add a new WTP Radio Statistics message element, as shown below [SG] I am ok with the proposed message elements and fields. In addition, I think WTP Operational Statistics message element should have the following fields; =20 - WTP Load in the form of Wireless Link Frames/Sec - Congestion in the form of total wireless transmit queue=20 =20 ------_=_NextPart_001_01C68F80.76137230 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dorothy,

 

I agree with your definition and text for the new = statistic. Regarding the statistic’s relation to WTP radios, I think the = statistic would be different for each radio provided that the radios are each = served by separate transmit queues.

 

I am ok with the semantics of the new name. I think = for the benefit of first-time readers, a short description can be added to the definition. Please consider something along the lines = of;

 

“The Wireless Transmit Queue Level is = representative of congestion conditions over wireless interfaces between the WTP and = wireless terminals.”

 

Cheers,


Saravanan

 

 

 

From: = Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Tuesday, June 13, = 2006 11:16 PM
To: Saravanan Govindan
Cc: Pat Calhoun = (pacalhou); capwap
Subject: Re: [Capwap] = Statistics for WTP Event Request - Issue 84

 

Saravanan,

Thanks for your comments. I have more questions on the proposed congestion/wireless
transmit queue statistic:

>I think this Congestion should represent the total value of all = transmit queues at the WTP. At the same time, the AC needs to know >the total = queue size available – so as to calculate relative level of = congestion.
>Congestion in the form of total wireless transmit queue

Discussion:

a) Proposed name of Statistic: Wireless Transmit Queue Level
b) If the WTP calculates the percentage of total , then the total = queue
size available need not be transported
c) Suggest the follwoing definition:

Wireless Transmit Queue Level - The percentage of Wireless Transmit = queue
utilization, calaculated as the sum of utilized transmit queue lengths = divided by the
sum of maximum transmit queue lengths,  multiplied by 100.

d) Include in WTP Operational Statistics Message Element
e) This statistic is per-radio.

Comments?

Thanks,

Dorothy

On 6/12/06, Saravanan = Govindan <Saravanan.Govindan@sg= .panasonic.com> wrote:

Dorothy,

 

In general, I think the new message elements you propose address this issue = well. I have included specific notes below.

 

Cheers,


Saravanan

 

 

> WTP Load - load in frames per second = exchanged by the WTP -  Assuming that
> the exchange is over the air; Add  "Wireless Link Frames/Sec" statistics field
> in a new WTP Operational Statistics message = element

[SG] I am ok with this.

 


> WTP Transmit Queue - as a percentage of queue size - Which Queue is = this? going to the AC or the STA?
> If to the STA, then the statistic may vary with the L2 wireless = type, e.g., is it a
> single queue for non-WMM traffic? multiple statistics for each of = the WMM queues, or an
> aggregate of all wireless transmit = queues?

[SG] Reviewing this stat, I think this relates to "Congestion" = below.

 

 

> Channel Interference - SINR - this is radio dependent, include a noise = floor in the
> proposed WTP Radio Statistics message element
>

> Congestion - Congestion experienced by = the WTP - Need more info here, is this congestion on the
> WTP-AC link? How is it measured?

[SG] This refers to congestion over the air interface (WTP-STA). Congestion over = the air interface is a function of channel conditions and the transmit queue to = STA(s). In dense deployments with many WTPs and STAs, transmit queues build up = with channel interference. A first step to addressing this is to let the AC = know of the condition.

 

I think this Congestion should represent the total value of all transmit queues at = the WTP. At the same time, the AC needs to know the total queue size available = – so as to calculate relative level of congestion. =

 


> Propose new WTP specific statistics:
>
> - Add more fields/detail to the  WTP Reboot Statistics message element, see 4.4.43
> - Add a new WTP Operational Statistics message element
> - Add a new WTP Radio Statistics message element, as shown = below

[SG] I am ok with the proposed message elements and fields. In addition, I think = WTP Operational Statistics message element should have the following = fields;

 

- WTP Load in the form of Wireless Link = Frames/Sec

- Congestion in the form of total wireless transmit queue =



 

------_=_NextPart_001_01C68F80.76137230-- --===============0071562820== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0071562820==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 14 09:19:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqVHj-0003gS-76 for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 09:19:51 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqVHh-00023U-BB for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 09:19:51 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 97BA143013C for ; Wed, 14 Jun 2006 06:19:48 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8AFDB43006D for ; Wed, 14 Jun 2006 06:19:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 61AB0430AE7 for ; Wed, 14 Jun 2006 06:19:12 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.199]) by hermes.tigertech.net (Postfix) with ESMTP id 36505430AD0 for ; Wed, 14 Jun 2006 06:19:09 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id t13so90334wxc for ; Wed, 14 Jun 2006 06:19:08 -0700 (PDT) Received: by 10.70.14.5 with SMTP id 5mr738887wxn; Wed, 14 Jun 2006 06:19:08 -0700 (PDT) Received: by 10.70.133.2 with HTTP; Wed, 14 Jun 2006 06:19:08 -0700 (PDT) Message-ID: <5bfe7a820606140619w68ed214bn8e1aca2a7193fc21@mail.gmail.com> Date: Wed, 14 Jun 2006 06:19:08 -0700 From: "Dorothy Stanley" To: "Saravanan Govindan" In-Reply-To: <5F09D220B62F79418461A978CA0921BDEEF6D5@pslexc01.psl.local> MIME-Version: 1.0 References: <5F09D220B62F79418461A978CA0921BDEEF6D5@pslexc01.psl.local> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.6 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_60_70, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Statistics for WTP Event Request - Issue 84 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0462539506==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 08868c2bcdb53bddcb7cc7e7cf96b038 --===============0462539506== Content-Type: multipart/alternative; boundary="----=_Part_96221_9968827.1150291148210" ------=_Part_96221_9968827.1150291148210 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Saravanan, Thank you. I will incorporate the proposed text, and believe that this should close Issue 84 in -02. Dorothy On 6/14/06, Saravanan Govindan wrote: > > Dorothy, > > > > I agree with your definition and text for the new statistic. Regarding th= e > statistic's relation to WTP radios, I think the statistic would be differ= ent > for each radio provided that the radios are each served by separate trans= mit > queues. > > > > I am ok with the semantics of the new name. I think for the benefit of > first-time readers, a short description can be added to the definition. > Please consider something along the lines of; > > > > "The Wireless Transmit Queue Level is representative of congestion > conditions over wireless interfaces between the WTP and wireless terminal= s." > > > > Cheers, > > > Saravanan > > > > > > > ------------------------------ > > *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] > *Sent:* Tuesday, June 13, 2006 11:16 PM > *To:* Saravanan Govindan > *Cc:* Pat Calhoun (pacalhou); capwap > > *Subject:* Re: [Capwap] Statistics for WTP Event Request - Issue 84 > > > > Saravanan, > > Thanks for your comments. I have more questions on the proposed > congestion/wireless > transmit queue statistic: > > >I think this Congestion should represent the total value of all transmit > queues at the WTP. At the same time, the AC needs to know >the total queu= e > size available =96 so as to calculate relative level of congestion. > >Congestion in the form of total wireless transmit queue > > Discussion: > > a) Proposed name of Statistic: Wireless Transmit Queue Level > b) If the WTP calculates the percentage of total , then the total queue > size available need not be transported > c) Suggest the follwoing definition: > > Wireless Transmit Queue Level - The percentage of Wireless Transmit queue > utilization, calaculated as the sum of utilized transmit queue lengths > divided by the > sum of maximum transmit queue lengths, multiplied by 100. > > d) Include in WTP Operational Statistics Message Element > e) This statistic is per-radio. > > Comments? > > Thanks, > > Dorothy > > On 6/12/06, *Saravanan Govindan* > wrote: > > Dorothy, > > > > In general, I think the new message elements you propose address this > issue well. I have included specific notes below. > > > > Cheers, > > > Saravanan > > > > > > > WTP Load - load in frames per second exchanged by the WTP - Assuming > that > > the exchange is over the air; Add "Wireless Link Frames/Sec" statistic= s > field > > in a new WTP Operational Statistics message element > > [SG] I am ok with this. > > > > > > WTP Transmit Queue - as a percentage of queue size - Which Queue is > this? going to the AC or the STA? > > If to the STA, then the statistic may vary with the L2 wireless type, > e.g., is it a > > single queue for non-WMM traffic? multiple statistics for each of the > WMM queues, or an > > aggregate of all wireless transmit queues? > > [SG] Reviewing this stat, I think this relates to "Congestion" below. > > > > > > > Channel Interference - SINR - this is radio dependent, include a noise > floor in the > > proposed WTP Radio Statistics message element > > > > > Congestion - Congestion experienced by the WTP - Need more info here, i= s > this congestion on the > > WTP-AC link? How is it measured? > > [SG] This refers to congestion over the air interface (WTP-STA). > Congestion over the air interface is a function of channel conditions and > the transmit queue to STA(s). In dense deployments with many WTPs and STA= s, > transmit queues build up with channel interference. A first step to > addressing this is to let the AC know of the condition. > > > > I think this Congestion should represent the total value of all transmit > queues at the WTP. At the same time, the AC needs to know the total queue > size available =96 so as to calculate relative level of congestion. > > > > > > Propose new WTP specific statistics: > > > > - Add more fields/detail to the WTP Reboot Statistics message element, > see 4.4.43 > > - Add a new WTP Operational Statistics message element > > - Add a new WTP Radio Statistics message element, as shown below > > [SG] I am ok with the proposed message elements and fields. In addition, = I > think WTP Operational Statistics message element should have the followin= g > fields; > > > > - WTP Load in the form of Wireless Link Frames/Sec > > - Congestion in the form of total wireless transmit queue > > > > > ------=_Part_96221_9968827.1150291148210 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Saravanan,

Thank you. I will incorporate the proposed text, and believe that
this should close Issue 84 in -02.

Dorothy

On 6/14/06, Saravanan Govindan <Saravanan.Govindan@sg.panasonic.com> wrote:

Dorothy,

 

I agree with your definition and text for the new statistic. Regarding the statistic's relation to WTP radios, I think the statistic would be different for each radio provided that the radios are each served = by separate transmit queues.

 

I am ok with the semantics of the new name. I think for the benefit of first-time readers, a short description can be added to the definition. Please consider something along the lines of;

 

"The Wireless Transmit Queue Level is representative of congestion conditions over wireless interfaces between the WTP and wireless terminals."

 

Cheers,


Saravanan

 

 

 

 

Saravanan,

Thanks for your comments. I have more questions on the proposed congestion/wireless
transmit queue statistic:

>I think this Congestion should represent the total value of all transmi= t queues at the WTP. At the same time, the AC needs to know >the total que= ue size available =96 so as to calculate relative level of congestion.
>Congestion in the form of total wireless transmit queue

Discussion:

a) Proposed name of Statistic: Wireless Transmit Queue Level
b) If the WTP calculates the percentage of total , then the total queue
size available need not be transported
c) Suggest the follwoing definition:

Wireless Transmit Queue Level - The percentage of Wireless Transmit queue utilization, calaculated as the sum of utilized transmit queue lengths divi= ded by the
sum of maximum transmit queue lengths,  multiplied by 100.

d) Include in WTP Operational Statistics Message Element
e) This statistic is per-radio.

Comments?

Thanks,

Dorothy

On 6/12/06, Saravanan Govind= an < Saravanan.Govindan@sg.panasonic.com> wrote:

Dorothy,

 

In general, I think the new message elements you propose address this issue we= ll. I have included specific notes below.

 

Cheers,


Saravanan

 

 

> WTP Load - load in frames per second= exchanged by the WTP -  Assuming that
> the exchange is over the air; Add  "Wireless Link Frames/Sec" statistics field
> in a new WTP Operational Statistics message element

[SG] I am ok with this.

 


> WTP Transmit Queue - as a percentage of queue size - Which Queue is th= is? going to the AC or the STA?
> If to the STA, then the statistic may vary with the L2 wireless type, e.g., is it a
> single queue for non-WMM traffic? multiple statistics for each of the = WMM queues, or an
> aggregate of all wireless transmit queues?

[SG] Reviewing this stat, I think this relates to "Congestion" below.<= /span>

 

 

> Channel Interference - SINR - this is radio dependent, include a noise floo= r in the
> proposed WTP Radio Statistics message element
>

> Congestion - Congestion experienced = by the WTP - Need more info here, is this congestion on the
> WTP-AC link? How is it measured?

[SG] This refers to congestion over the air interface (WTP-STA). Congestion over the = air interface is a function of channel conditions and the transmit queue to STA= (s). In dense deployments with many WTPs and STAs, transmit queues build up with channel interference. A first step to addressing this is to let the AC know= of the condition.

 

I think this Congestion should represent the total value of all transmit queues at the W= TP. At the same time, the AC needs to know the total queue size available =96 so as to calculate relative level of congestion.

 


> Propose new WTP specific statistics:
>
> - Add more fields/detail to the  WTP Reboot Statistics message element, see 4.4.43
> - Add a new WTP Operational Statistics message element
> - Add a new WTP Radio Statistics message element, as shown below

[SG] I am ok with the proposed message elements and fields. In addition, I think WTP Operational Statistics message element should have the following fields;

 

- WTP Load in the form of Wireless Link Frames/Sec

- Congestion in the form of total wireless transmit queue



 


------=_Part_96221_9968827.1150291148210-- --===============0462539506== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0462539506==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 14 09:46:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqVhU-0007lX-6u for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 09:46:28 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqVhS-0004yL-8j for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 09:46:28 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DD865430092 for ; Wed, 14 Jun 2006 06:46:25 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 751F643006D for ; Wed, 14 Jun 2006 06:45:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 535A8430B51 for ; Wed, 14 Jun 2006 06:45:49 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.201]) by hermes.tigertech.net (Postfix) with ESMTP id 0F1CC430B44 for ; Wed, 14 Jun 2006 06:45:46 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id i30so95737wxd for ; Wed, 14 Jun 2006 06:45:46 -0700 (PDT) Received: by 10.70.109.5 with SMTP id h5mr780629wxc; Wed, 14 Jun 2006 06:45:46 -0700 (PDT) Received: by 10.70.133.2 with HTTP; Wed, 14 Jun 2006 06:45:46 -0700 (PDT) Message-ID: <5bfe7a820606140645p704e9f41t65956f3e034cd140@mail.gmail.com> Date: Wed, 14 Jun 2006 06:45:46 -0700 From: "Dorothy Stanley" To: "David T. Perkins" In-Reply-To: MIME-Version: 1.0 References: <5bfe7a820606131340v5df56eado8edeef81a2053346@mail.gmail.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.6 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Proposed Resolution for Issue 74: "About IEEE 802.11 Binding" X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1165632761==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 --===============1165632761== Content-Type: multipart/alternative; boundary="----=_Part_96495_4502671.1150292746137" ------=_Part_96495_4502671.1150292746137 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline David, Comments inline. Thanks, Dorothy On 6/13/06, David T. Perkins wrote: > > HI, > > There is a fundamental flaw with the config request/response > messages in CAPWAP-01, and that is config changes can fail. Agree that application of the configuration request messages can fail. When they do, the CAPWAP-01 does not say what is the result > and how the error(s) are returned. In -01, the Mobile Config Request returns an error result, while the IEEE 802.11 WLAN Configuration Response does not. My interpretation of Comment 74 is that the commenter is asking to make these 2 consistent, and have both return a result code. I believe that this is a resonable request. There may still be additional work needed beyond the scope of this issue. The config changes can be "all or nothing". Or they could > be one of the many partial applications. Also, in a failure, > are the values assumed to be checked (and applied) strictly > sequentially as found in the request, or can the values > be checked (and applied) in an implementation defined > order. What if there are more than one failure. What > if the values when applied individually will work, but > not together? The proposed change here is to simply indicate that a failure occurred. I believe that the config operations need much more work. Don't disagree, there are already other issues open for this. Also, when this is rewritten, I don't believe that using > the term "LWAPP" is appropriate! Certainly agree. The legacy terminology is part of the original comment, which was opened back in February. Regards, > /david t. perkins > > On Tue, 13 Jun 2006, Dorothy Stanley wrote: > > All, > > > > Issue 74 is listed below, and proposes text changes to 2 sections, the > > IEEE 802.11 WLAN Config Response message (now 11.7.2) and the Mobile > > Configuration > > Response Message (now 10.2). > > Proposed Resolutions are included below. > > > > Comments welcome. > > > > Thanks, > > > > Dorothy > > > > Issue 74 Part 1: Because different product has different process > > mechanism, LWAPP need give > > clear description about process. > > And if "IEEE 802.11 WLAN Configuration Response" also has a Result Code > > message element as "Mobile Config Response", 802.11 protocol may be > better to > > control WLAN configuration. > > I suggest: > > > > >11.8.2 IEEE 802.11 WLAN Config Response > > > > > > The IEEE 802.11 WLAN Configuration Response is sent by the WTP to > the > > > AC as an acknowledgement of the receipt of an IEEE 802.11 WLAN > > > Configuration Request. > > > This LWAPP control message does not include any message elements. > > > > change to: > > 11.8.2 IEEE 802.11 WLAN Config Response > > The IEEE 802.11 WLAN Configuration Response is sent by the WTP to > the > > AC as an acknowledgement of the receipt of an IEEE 802.11 WLAN > > Configuration Request. > > > > Before this LWAPP control message is sent, the IEEE 802.11 WLAN > > Cofiguration should be successfully implemented. > > > > This LWAPP control message does not include any message elements. > > > > Proposed Resolution: > > > > Change the current -01 text from: > > 11.7.2. IEEE 802.11 WLAN Config Response > > > > The IEEE 802.11 WLAN Configuration Response is sent by the AC to the > > WTP as an acknowledgement of the receipt of an IEEE 802.11 WLAN > > Configuration Request. > > > > The following message elements may be included in the IEEE 802.11 > > WLAN Config Request message. Only one message element MUST be > > present. > > > > o IEEE 802.11 Assigned WTP BSSID, see Section 11.10.3 > > > > to > > > > 11.7.2. IEEE 802.11 WLAN Configuration Response > > > > The IEEE 802.11 WLAN Configuration Response message is sent by the > WTP to the > > AC. It is used to acknowledge receipt of an IEEE 802.11 WLAN > > Configuration Request message, and to indicate if the requested > > configuration was successfully applied, or if an error related to > > the processing > > of the IEEE 802.11 WLAN Configuration Request message occurred on the > > WTP. > > > > The following message element MAY be included in the IEEE 802.11 > > WLAN Config Response message. > > > > o IEEE 802.11 Assigned WTP BSSID, see Section 11.10.3 > > > > The following message element MUST be included in the IEEE 802.11 > > WLAN Config Request message. Only one message element MUST be > > present. > > > > o Result Code, see Section 4.4.29 > > > > > > Issue 74 Part 2: > > >9.2 Mobile Config Response > > > > > > The Mobile Configuration Response is used to acknowledge a > previously > > > received Mobile Configuration Request, and includes a Result Code > > > message element which indicates whether an error occured on the WTP. > > > > > > This message requires no special processing, and is only used to > > > acknowledge the Mobile Configuration Request. > > > > > > > change to: > > 9.2 Mobile Config Response > > > > The Mobile Configuration Response is used to acknowledge a previously > > received Mobile Configuration Request, and includes a Result Code > > message element, see Section 4.4.29 which indicates whether an > > error occured on the WTP. > > > > Before this message is sent, the Mobile Cofiguration should be > implemented. > > The Result Code indicate if Mobile Cofiguration is successfully on > WTP. > > > > This message requires no special processing, and is only used to > > acknowledge the Mobile Configuration Request. > > > > > > Proposed Resolution: > > Change the Current -01 text from: > > > > 10.2. Mobile Config Response > > > > The Mobile Configuration Response message is used to acknowledge a > > previously received Mobile Configuration Request message, and MUST > > include a Result Code message element, see Section 4.4.29 which > > indicates whether an error occurred on the WTP. > > > > This message requires no special processing, and is only used to > > acknowledge receipt of the Mobile Configuration Request message. > > > > to > > > > 10.2. Mobile Configuration Response > > > > The Mobile Configuration Response message is used to acknowledge a > > previously received Mobile Configuration Request message. The > following > > message element MUST be present in the Mobile Configuration Response > message. > > > > o Result Code, see Section 4.4.29 > > > > The Result Code message element indicates that the requested > configuration > > was successfully applied, or that an error related to processing of > the > > Mobile Configuration Request message occurred on the WTP. > > > > ------=_Part_96495_4502671.1150292746137 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline David,

Comments inline.

Thanks,

Dorothy

On 6/13/06, David T. Perkins <dperkins@dsperkins.com> wrote:
HI,

There is a fundamental flaw with the config request/response
messages in CAPWAP-01, and that is config changes can fail.

Agree that application of the configuration request messages can fail.

When they do, the CAPWAP-01 does not say what is the result
and how the error(s) are returned.

In -01, the Mobile Config Request returns an error result, while the
IEEE 802.11 WLAN Configuration Response does not.
My interpretation of Comment 74 is that the commenter is asking to
make these 2 consistent, and have both return a result code.
I believe that this is a resonable request. There may still be
additional work needed beyond the scope of this issue.

The config changes can be "all or nothing". Or they could
be one of the many partial applications. Also, in a failure,
are the values assumed to be checked (and applied) strictly
sequentially as found in the request, or can the values
be checked (and applied) in an implementation defined
order. What if there are more than one failure. What
if the values when applied individually will work, but
not together?

The proposed change here is to simply indicate that a failure
occurred.

I believe that the config operations need much more work.

Don't disagree, there are already other issues open for this.

Also, when this is rewritten, I don't believe that using
the term "LWAPP" is appropriate!

Certainly agree. The legacy terminology is
part of the original comment, which was opened back in February.

Regards,
/david t. perkins

On Tue, 13 Jun 2006, Dorothy Stanley wrote:
> All,
>
> Issue 74 is listed below, and proposes text changes to 2 sections, the
> IEEE 802.11 WLAN Config Response message (now 11.7.2) and the Mobile
> Configuration
> Response Message (now 10.2).
> Proposed Resolutions are included below.
>
> Comments welcome.
>
> Thanks,
>
> Dorothy
>
> Issue 74 Part 1: Because different product has different process
> mechanism, LWAPP need give
> clear description about process.
> And if "IEEE 802.11 WLAN Configuration Response" also has a Result Code
> message element as "Mobile Config Response", 802.11 protocol may be better to
> control WLAN configuration.
> I suggest:
>
> >11.8.2  IEEE 802.11 WLAN Config Response
> >
> >   The IEEE 802.11 WLAN Configuration Response is sent by the WTP to the
> >   AC as an acknowledgement of the receipt of an IEEE 802.11 WLAN
> >   Configuration Request.
> >   This LWAPP control message does not include any message elements.
>
> change to:
> 11.8.2  IEEE 802.11 WLAN Config Response
>     The IEEE 802.11 WLAN Configuration Response is sent by the WTP to the
>     AC as an acknowledgement of the receipt of an IEEE 802.11 WLAN
>     Configuration Request.
>
>     Before this LWAPP control message is sent, the IEEE 802.11 WLAN
>     Cofiguration should be successfully implemented.
>
>     This LWAPP control message does not include any message elements.
>
> Proposed Resolution:
>
> Change the current -01 text  from:
> 11.7.2.  IEEE 802.11 WLAN Config Response
>
>    The IEEE 802.11 WLAN Configuration Response is sent by the AC to the
>    WTP as an acknowledgement of the receipt of an IEEE 802.11 WLAN
>    Configuration Request.
>
>    The following message elements may be included in the IEEE 802.11
>    WLAN Config Request message.  Only one message element MUST be
>    present.
>
>    o  IEEE 802.11 Assigned WTP BSSID, see Section 11.10.3
>
> to
>
> 11.7.2.  IEEE 802.11 WLAN Configuration Response
>
>    The IEEE 802.11 WLAN Configuration Response message is sent by the WTP to the
>    AC. It is used to acknowledge receipt of an IEEE 802.11 WLAN
>    Configuration Request message, and to indicate if the requested
>    configuration was successfully applied, or if an error related to
> the processing
>    of the IEEE 802.11 WLAN Configuration Request message occurred on the
>    WTP.
>
>    The following message element MAY be included in the IEEE 802.11
>    WLAN Config Response message.
>
>    o  IEEE 802.11 Assigned WTP BSSID, see Section 11.10.3
>
>    The following message element MUST be included in the IEEE 802.11
>    WLAN Config Request message.  Only one message element MUST be
>    present.
>
>    o  Result Code, see Section 4.4.29
>
>
> Issue 74 Part 2:
> >9.2  Mobile Config Response
> >
> >   The Mobile Configuration Response is used to acknowledge a previously
> >   received Mobile Configuration Request, and includes a Result Code
> >   message element which indicates whether an error occured on the WTP.
> >
> >   This message requires no special processing, and is only used to
> >   acknowledge the Mobile Configuration Request.
> >
>
> change to:
> 9.2  Mobile Config Response
>
>    The Mobile Configuration Response is used to acknowledge a previously
>    received Mobile Configuration Request, and includes a Result Code
>    message element, see Section 4.4.29 which indicates whether an
> error occured on the WTP.
>
>    Before this message is sent, the Mobile Cofiguration should be implemented.
>    The Result Code indicate if Mobile Cofiguration is successfully on WTP.
>
>    This message requires no special processing, and is only used to
>    acknowledge the Mobile Configuration Request.
>
>
> Proposed Resolution:
> Change the Current -01 text from:
>
> 10.2.  Mobile Config Response
>
>    The Mobile Configuration Response message is used to acknowledge a
>    previously received Mobile Configuration Request message, and MUST
>    include a Result Code message element, see Section 4.4.29 which
>    indicates whether an error occurred on the WTP.
>
>    This message requires no special processing, and is only used to
>    acknowledge receipt of the Mobile Configuration Request message.
>
> to
>
> 10.2.  Mobile Configuration Response
>
>    The Mobile Configuration Response message is used to acknowledge a
>    previously received Mobile Configuration Request message. The following
>    message element MUST be present in the Mobile Configuration Response message.
>
>    o  Result Code, see Section 4.4.29
>
>    The Result Code message element indicates that the requested configuration
>    was successfully applied, or that an error related to processing of the
>    Mobile Configuration Request message occurred on the WTP.
>


------=_Part_96495_4502671.1150292746137-- --===============1165632761== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1165632761==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 14 12:00:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXn6-0000dW-PF for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 12:00:24 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXlb-0007pj-VG for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 11:58:52 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8BAF9430133 for ; Wed, 14 Jun 2006 08:58:51 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2612443006C for ; Wed, 14 Jun 2006 08:58:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0F177431516 for ; Wed, 14 Jun 2006 08:58:10 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id D2AAA431504 for ; Wed, 14 Jun 2006 08:58:07 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 14 Jun 2006 08:58:07 -0700 X-IronPort-AV: i="4.06,132,1149490800"; d="scan'208,217"; a="1825567381:sNHT116365060" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5EFw7Qs019908; Wed, 14 Jun 2006 08:58:07 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5EFw6Iw017060; Wed, 14 Jun 2006 08:58:07 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 08:58:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Jun 2006 08:58:05 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2020A7110@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution for Issue 74: "About IEEE 802.11Binding" Thread-Index: AcaPKaiYFk/XVpyXS7+j3v5UbtkJ2gAoafOA From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "capwap" X-OriginalArrivalTime: 14 Jun 2006 15:58:06.0700 (UTC) FILETIME=[53668AC0:01C68FCB] Authentication-Results: sj-dkim-8.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.1 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_20_30, HTML_FONT_BIG, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: Re: [Capwap] Proposed Resolution for Issue 74: "About IEEE 802.11Binding" X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0468176783==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.7 (/) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 This is a multi-part message in MIME format. --===============0468176783== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68FCB.53381D33" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68FCB.53381D33 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Works for me. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Tuesday, June 13, 2006 1:40 PM To: capwap Subject: [Capwap] Proposed Resolution for Issue 74: "About IEEE 802.11Binding" =09 =09 All, =09 Issue 74 is listed below, and proposes text changes to 2 sections, the IEEE 802.11 WLAN Config Response message (now 11.7.2) and the Mobile Configuration Response Message (now 10.2). Proposed Resolutions are included below. =09 Comments welcome. =09 Thanks, =09 Dorothy =09 =09 Issue 74 Part 1: Because different product has different process mechanism, LWAPP need give=20 clear description about process.=20 And if "IEEE 802.11 WLAN Configuration Response" also has a Result Code=20 =09 message element as "Mobile Config Response", 802.11 protocol may be better to=20 control WLAN configuration. I suggest: =09 >11.8.2 IEEE 802.11 WLAN Config Response > > The IEEE 802.11 WLAN Configuration Response is sent by the WTP to the > AC as an acknowledgement of the receipt of an IEEE 802.11 WLAN > Configuration Request. > This LWAPP control message does not include any message elements. =09 =09 change to: 11.8.2 IEEE 802.11 WLAN Config Response The IEEE 802.11 WLAN Configuration Response is sent by the WTP to the AC as an acknowledgement of the receipt of an IEEE 802.11 WLAN Configuration Request. =09 =09 Before this LWAPP control message is sent, the IEEE 802.11 WLAN=20 Cofiguration should be successfully implemented. =09 This LWAPP control message does not include any message elements. =09 =09 Proposed Resolution: =09 Change the current -01 text from: 11.7.2. IEEE 802.11 WLAN Config Response =09 The IEEE 802.11 WLAN Configuration Response is sent by the AC to the WTP as an acknowledgement of the receipt of an IEEE=20 802.11 WLAN Configuration Request. =09 The following message elements may be included in the IEEE 802.11 WLAN Config Request message. Only one message element MUST be present. =09 o IEEE 802.11 Assigned WTP BSSID, see Section 11.10.3 =09 to =09 11.7.2. IEEE 802.11 WLAN Configuration Response =09 The IEEE 802.11 WLAN Configuration Response message is sent by the WTP to the =09 AC. It is used to acknowledge receipt of an IEEE 802.11 WLAN Configuration Request message, and to indicate if the requested configuration was successfully applied, or if an error related to the processing =09 of the IEEE 802.11 WLAN Configuration Request message occurred on the WTP. =09 The following message element MAY be included in the IEEE 802.11 WLAN Config Response message. =20 =09 o IEEE 802.11 Assigned WTP BSSID, see Section 11.10.3 =09 The following message element MUST be included in the IEEE 802.11 WLAN Config Request message. Only one message element MUST be present. =09 o Result Code, see Section=20 4.4.29 =09 =09 Issue 74 Part 2: >9.2 Mobile Config Response > > The Mobile Configuration Response is used to acknowledge a previously > received Mobile Configuration Request, and includes a Result Code =09 > message element which indicates whether an error occured on the WTP. > > This message requires no special processing, and is only used to > acknowledge the Mobile Configuration Request. =09 > =09 change to: 9.2 Mobile Config Response =09 The Mobile Configuration Response is used to acknowledge a previously received Mobile Configuration Request, and includes a Result Code message element, see Section=20 4.4.29 which indicates whether an error occured on the WTP. =09 Before this message is sent, the Mobile Cofiguration should be implemented. The Result Code indicate if Mobile Cofiguration is successfully on WTP. =09 =09 This message requires no special processing, and is only used to acknowledge the Mobile Configuration Request. =09 =09 Proposed Resolution: Change the Current -01 text from: =09 =09 10.2. Mobile Config Response =09 The Mobile Configuration Response message is used to acknowledge a previously received Mobile Configuration Request message, and MUST include a Result Code message element, see Section=20 4.4.29 which indicates whether an error occurred on the WTP. =09 This message requires no special processing, and is only used to acknowledge receipt of the Mobile Configuration Request message. =09 to =09 =09 10.2. Mobile Configuration Response =09 The Mobile Configuration Response message is used to acknowledge a previously received Mobile Configuration Request message. The following message element MUST be present in the Mobile Configuration Response message. =09 =09 o Result Code, see Section 4.4.29 =20 The Result Code message element indicates that the requested configuration was successfully applied, or that an error related to processing of the=20 Mobile Configuration Request message occurred on the WTP. =09 =09 ------_=_NextPart_001_01C68FCB.53381D33 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Works=20 for me.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Tuesday, June 13, = 2006 1:40=20 PM
To: capwap
Subject: [Capwap] Proposed = Resolution for=20 Issue 74: "About IEEE 802.11Binding"

All,

Issue 74 is listed below, and proposes text = changes to=20 2 sections, the
IEEE 802.11 WLAN Config Response message (now = 11.7.2) and=20 the Mobile Configuration
Response Message (now 10.2).
Proposed=20 Resolutions are included below.

Comments=20 welcome.

Thanks,

Dorothy

Issue 74 Part 1: =
Because different product has different process mechanism, LWAPP need =
give 
clear description about process. 
And if "IEEE 802.11 WLAN =
Configuration Response" also has a Result Code=20

message element as "Mobile Config Response", 802.11 protocol may be =
better to 
control WLAN configuration.
I =
suggest:

>11.8.2  IEEE 802.11 WLAN Config =
Response
>
>   The IEEE 802.11
 WLAN Configuration Response is sent by the WTP to the
>   AC as =
an acknowledgement of the receipt of an IEEE 802.11 WLAN
>   =
Configuration Request.
>   This LWAPP control message does not =
include any message elements.


change to:
11.8.2  IEEE 802.11 WLAN Config Response
    =
The IEEE 802.11 WLAN Configuration Response is sent by the WTP to =
the
    AC as an acknowledgement of the receipt of an IEEE 802.11 =
WLAN
    Configuration Request.


    Before this LWAPP control message is sent, the IEEE 802.11 =
WLAN 
    Cofiguration should be successfully implemented.

    =
This LWAPP control message does not include any message =
elements.


Proposed Resolution:

Change the current -01 =
text  from:
11.7.2.  IEEE 802.11 WLAN Config Response

  =
 The IEEE 802.11 WLAN Configuration Response is sent by the AC to =
the
   WTP as an acknowledgement of the receipt of an IEEE=20
802.11 WLAN
   Configuration Request.

   The following message =
elements may be included in the IEEE 802.11
   WLAN Config Request =
message.  Only one message element MUST be
   present.

   o  =
IEEE 802.11
 Assigned WTP BSSID, see Section 11.10.3

to

11.7.2.  IEEE 802.11 WLAN =
Configuration Response

   The IEEE 802.11 WLAN Configuration =
Response message is sent by the WTP to the

   AC. It is used to acknowledge receipt of an IEEE 802.11 WLAN
  =
 Configuration Request message, and to indicate if the requested
   =
configuration was successfully applied, or if an error related to the =
processing

   of the IEEE 802.11 WLAN Configuration Request message occurred on =
the
   WTP.

   The following message element MAY be included =
in the IEEE 802.11
   WLAN Config Response message.  

   o  =
IEEE 802.11
 Assigned WTP BSSID, see Section 11.10.3

   The following message =
element MUST be included in the IEEE 802.11
   WLAN Config Request =
message.  Only one message element MUST be
   present.

   o  =
Result Code, see Section=20
4.4.29


Issue 74 Part 2:
>9.2  Mobile Config =
Response
>
>   The Mobile Configuration Response is used to =
acknowledge a previously
>   received Mobile Configuration =
Request, and includes a Result Code

>   message element which indicates whether an error occured on =
the WTP.
>
>   This message requires no special processing, =
and is only used to
>   acknowledge the Mobile Configuration =
Request.

>

change to:
9.2  Mobile Config Response

   The =
Mobile Configuration Response is used to acknowledge a previously
   =
received Mobile Configuration Request, and includes a Result Code
   =
message element, see Section=20
4.4.29 which indicates whether an error occured on the WTP.

   =
Before this message is sent, the Mobile Cofiguration should be =
implemented.
   The Result Code indicate if Mobile Cofiguration is =
successfully on WTP.


   This message requires no special processing, and is only used =
to
   acknowledge the Mobile Configuration =
Request.


Proposed Resolution:
Change the Current -01 text=20 from:

10.2.  Mobile Config Response

   The Mobile =
Configuration Response message is used to acknowledge a
   previously =
received Mobile Configuration Request message, and MUST
   include a =
Result Code message element, see Section=20
4.4.29 which
   indicates whether an error occurred on the =
WTP.

   This message requires no special processing, and is only =
used to
   acknowledge receipt of the Mobile Configuration Request =
message.

to


10.2.  Mobile Configuration Response

   The Mobile =
Configuration Response message is used to acknowledge a
   previously =
received Mobile Configuration Request message. The following
   =
message element MUST be present in the Mobile Configuration Response =
message.


   o  Result Code, see Section 4.4.29
   
   The Result =
Code message element indicates that the requested configuration
   =
was successfully applied, or that an error related to processing of the =

   Mobile Configuration Request message occurred on the WTP.


------_=_NextPart_001_01C68FCB.53381D33-- --===============0468176783== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0468176783==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 14 12:00:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXnG-0000ug-E1 for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 12:00:34 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXjH-0006rf-Qx for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 11:56:29 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 17EE8430112 for ; Wed, 14 Jun 2006 08:56:27 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1D75643006C for ; Wed, 14 Jun 2006 08:56:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0CC8C398009 for ; Wed, 14 Jun 2006 08:56:02 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8F81D398013 for ; Wed, 14 Jun 2006 08:55:58 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 14 Jun 2006 08:55:57 -0700 X-IronPort-AV: i="4.06,132,1149490800"; d="scan'208"; a="1825565857:sNHT32859856" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5EFtv0Y018484; Wed, 14 Jun 2006 08:55:57 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5EFtucN016396; Wed, 14 Jun 2006 08:55:57 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 08:55:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Jun 2006 08:55:55 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2020A710D@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] reasonably bounding our QoS ambitions for the base protocol Thread-Index: AcaPT1nXvhKriBGfQKO8n5A2x8ahIwAd/YNA From: "Pat Calhoun (pacalhou)" To: "Scott G. Kelly" , "Bob O'Hara (boohara)" , "capwap" X-OriginalArrivalTime: 14 Jun 2006 15:55:56.0545 (UTC) FILETIME=[05D27710:01C68FCB] Authentication-Results: sj-dkim-8.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] reasonably bounding our QoS ambitions for the base protocol X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Scott, we've entered a circular logic world. I've addressed each one of your points in various e-mails, not ignored them and hope they go away, as you state. I, and others, have raised QoS *and* scalability issues with the proposal, and the points raised on scaling haven't been refuted - or even answered. I've stated that this proposal will require us to go down the multi port option in the future anyhow, and all we are doing is avoiding up front pain for long term interoperability issues. Maybe it's just me, but it appears you are simply not willing to listen to arguments against your MUX proposal. I don't think there's much that can be said at this point, other than to agree that we disagree. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > Sent: Tuesday, June 13, 2006 6:11 PM > To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); capwap > Subject: RE: [Capwap] reasonably bounding our QoS ambitions > for the base protocol > > Hi Pat, > > >Scott, > > > >Either way you slice this issue, there is work on the table. > If we opt > >for the MUX, then we need to add packet classification extensions to > >the protocol. If we opt for multi-port, then we add a > keepalive to the > >data channel and text to ensure the state machine is fine. > > I think this misses the mark by quite a bit. No matter what > we do, we have QoS-related packet classification issues. That > should be crystal clear by now. QoS is not just a question > of distinguishing capwap control from data; we need granular > QoS for encapsulated data channel elements, and perhaps even > more so. Neither solution provides this, and that is the > *real* QoS work that needs doing. The multiport proposal does > nothing to address these issues, but will cost us a lot for > an arguably non-existent benefit. Honestly, after looking > closely at this, I find it hard to believe that QoS is the > real motivator here. > > >Personally, I think multi-ports opens up significant > scenarios that are > >not otherwise available in the MUX case. Given we have work either > >way, I don't see why the MUX proposal is more attractive. > All it does > >Is add restrictions, which will cause the WG to solve this > problem in a > >subsequent revision of the RFCed protocol (-bis, or ver 2), > in a manner > >that will certainly create header imcompatibilities. > > It is clear from analysis that has been posted here that the > multiport approach entails far more pain than the single port > approach, and solves far fewer problems in the process. > Neither approach is perfect, but the multiport approach will > clearly have numerous and significant operational issues that > the single port approach will not. These issues have been > documented and remain unrefuted. Ignoring facts does not make > them go away. > > >Why walk into this today, when we know pain will come from it? > > > >Nothing is free. > > Clearly, and we should choose the approach that maximizes the > return on our investment. Splitting capwap into two > sub-protocols to partially (and poorly) solve problems that > have already have lower cost solutions seems like a bad bet. > > Scott > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 14 13:24:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqZ6c-0006NZ-7t for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 13:24:38 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqZ6a-00070S-MU for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 13:24:38 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B17074300EA for ; Wed, 14 Jun 2006 10:24:35 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 47CD5430064 for ; Wed, 14 Jun 2006 10:24:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2D7EB4315F7 for ; Wed, 14 Jun 2006 10:24:14 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by hermes.tigertech.net (Postfix) with ESMTP id 15237144800C for ; Wed, 14 Jun 2006 10:24:11 -0700 (PDT) Received: from [209.86.224.42] (helo=elwamui-muscovy.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FqZ6B-00065d-92; Wed, 14 Jun 2006 13:24:11 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Wed, 14 Jun 2006 13:24:10 -0400 Message-ID: <27638199.1150305851197.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Date: Wed, 14 Jun 2006 13:24:10 -0400 (EDT) From: "Scott G. Kelly" To: "Pat Calhoun (pacalhou)" , capwap Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710fe49ef0f6aaec3cd87d6d2615f04fe81350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.42 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: Re: [Capwap] reasonably bounding our QoS ambitions for the base protocol X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Hi Pat, pacalhou wrote: >Scott, we've entered a circular logic world. I've addressed each one of >your points in various e-mails, not ignored them and hope they go away, >as you state. I agree that we're going in circles, but I dont agree that you've addressed each of my points. I posted a detailed cost/benefit analysis of two ports vs one port which clearly establishes the technical costs and deficiencies of the two port approach, but you never acknowledged, refuted, or commented on this. >I, and others, have raised QoS *and* scalability issues with the >proposal, >and the points raised on scaling haven't been refuted - or even >answered. Am I missing something? The only scalability issues I've seen were in Rohit's post, and I thought it was quite clear that his concerns were based on the mistaken assumption that capwap data and control channels would share a dtls tunnel. This won't work, and has never been suggested (at least, not by me), so this should lay his concerns to rest. Are there any other scalability concerns to be addressed? >I've stated that this proposal will require us to go down the multi port >option in the future anyhow, and all we are doing is avoiding up front >pain for long term interoperability issues. I know you stated this yesterday, but (unless I've missed something) you have yet to substantiate this assertion. What would compel us to go down this path later? >Maybe it's just me, but it appears you are simply not willing to listen >to arguments against your MUX proposal. I don't think there's much that >can be said at this point, other than to agree that we disagree. Let's not personalize this by making the single-port proposal "mine" and the multi-port proposal "yours". The are options that are on the table, and should be objectively analyzed as such. In that spirit, I remain willing to objectively review both options. However, the QoS arguments presented on behalf of the multi-port approach simply do not stand up to scrutiny, and the minimal benefits the multiport approach may provide in this regard are easily derived from other less costly approaches. This cannot be the only motivation for taking on so much implementation and operational pain - it defies reason. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 14 13:42:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqZOL-0007Nj-TV for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 13:42:57 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqZOK-0001iv-Ab for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 13:42:57 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id F0072430130 for ; Wed, 14 Jun 2006 10:42:55 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 136A4430064 for ; Wed, 14 Jun 2006 10:42:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 040F0398008 for ; Wed, 14 Jun 2006 10:42:32 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id B2178398060 for ; Wed, 14 Jun 2006 10:42:28 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 14 Jun 2006 10:42:28 -0700 X-IronPort-AV: i="4.06,132,1149490800"; d="scan'208"; a="1825621505:sNHT40340864" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5EHgSHI010272 for ; Wed, 14 Jun 2006 10:42:28 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5EHgSIs029882 for ; Wed, 14 Jun 2006 10:42:28 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 10:42:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Jun 2006 10:42:27 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC01A7ADE0@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] capwap transport analysis: QoS vs multiport Thread-Index: AcaPEKnL/kizWPdxRcioRqg9ItcswgAyPSLg From: "Bob O'Hara (boohara)" To: "capwap" X-OriginalArrivalTime: 14 Jun 2006 17:42:27.0945 (UTC) FILETIME=[E764B590:01C68FD9] Authentication-Results: sj-dkim-8.cisco.com; header.From=boohara@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] capwap transport analysis: QoS vs multiport X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Scott, Your reformulation of premise (4) is closer to my intent, but still off the mark. This is what I would prefer to see from premise (4): (4) many of these elements only classify traffic based on 5-tuples, due to administrative or policy constraints; they will not use AC/WTP-provided VLAN tags or DSCP/802.1q/802.1d markings for QoS purposes -Bob -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: Tuesday, June 13, 2006 10:42 AM To: Bob O'Hara (boohara); capwap Subject: Re: [Capwap] capwap transport analysis: QoS vs multiport Hi Bob, boohara wrote: > >Scott wrote: > >>So if the AC and WTP were to mark control packets >>so as to make them distinguishable from data packets >>(using one of the marking methods suggested above, >>and without relying on client truthfulness), what >>problems remain? > >As Pat points out in a separate email, the problem of controlling how >the WTP marks those packets remains to be solved. But, that discussion >can continue in Pat's thread. > >Another problem is that the WTP, itself, is not trusted by the network >to which it is attached. A widespread example is a network of WLAN >hotspots. The WTPs at the hotspot are connected to the AC over a third >party's network. > >In some of those hotspots, the WTP will be local-MAC. A hotspot user's >packets from a local-MAC WTP will be able to be inspected at ingress to >the third party's network, since the 5-tuple is clearly available in >those packets. QoS can be applied to those user data packets, without >requiring any changes to the third party's network equipment. > >However, if those same packets are sent to the AC by a split-MAC WTP, >the third party network will not be able to distinguish control packets >from data packets, unless they are sent on separate ports. In the >CAPWAP packet, the 5-tuple is the same for both control and data. Keeping in mind that what we are trying to do is ascertain whether premise (4) was correctly formulated, let me re-state that in its original form: (4) many of these elements can only classify traffic based on 5-tuples; they apparently cannot use VLAN tags or 1:1 mappings of DSCP/802.1q/802.1d mappings Apparently, what is at issue is the phrase "1:1 mappings of" - if I apply what you've said above to this premise, it seems that this would be an acceptable re-formulation: (4) many of these elements can only classify traffic based on 5-tuples; they apparently cannot use AC/WTP-provided VLAN tags or DSCP/802.1q/802.1d markings for QoS purposes Does this reflect your intent? Thanks, Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 14 14:26:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqa4R-00048j-Rf for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 14:26:27 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqa4Q-00082P-5R for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 14:26:27 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3B28F43008C for ; Wed, 14 Jun 2006 11:26:25 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2B1D043006C for ; Wed, 14 Jun 2006 11:25:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1591F1448007 for ; Wed, 14 Jun 2006 11:25:58 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id F00621448013 for ; Wed, 14 Jun 2006 11:25:55 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 14 Jun 2006 11:25:55 -0700 X-IronPort-AV: i="4.06,133,1149490800"; d="scan'208"; a="294712785:sNHT46480836" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5EIPsvE015732 for ; Wed, 14 Jun 2006 11:25:54 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5EIPpA2014780 for ; Wed, 14 Jun 2006 11:25:54 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 11:25:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Jun 2006 11:25:51 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC01A7AE21@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CAPWAP] reasonably bounding our QoS ambitions for the base protocol Thread-Index: AcaPSVAWl7BU49mBQZiZ9n2YKGrQRwAkLDVw From: "Bob O'Hara (boohara)" To: "capwap" X-OriginalArrivalTime: 14 Jun 2006 18:25:52.0084 (UTC) FILETIME=[F794C940:01C68FDF] Authentication-Results: sj-dkim-4.cisco.com; header.From=boohara@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] [CAPWAP] reasonably bounding our QoS ambitions for the base protocol X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Scott, Perhaps separating the topics is a reasonable thing to do. Addressing your points below... 1. Characterizing the "vast majority" of hotspot deployments as local MAC is incorrect. The vast majority of hotspots fall outside the architectures encompassed by CAPWAP. They are classical, stand-alone APs without any AC, at all. Of those hotspot deployments that are not stand-alone APs, there is a good mix of both local-MAC and split-MAC hotspot deployments. 2. The fact that users of today's hotspots have no expectation of QoS is irrelevant to the discussion 3. The problem is real, regardless of whether you believe it to be, or not. An actual service provider has posted several more than once on this list, saying exactly that. Simply claiming that their problem is irrelevant does not make it so. 4. The WTP is only in a unique position to take the actions you cite (throttling down user traffic) only if the problem can be detected by the WTP. If the traffic is dropped beyond the link outbound from the WTP, how does it learn what packets were dropped and where? There is no mechanism to provide this feedback to the WTP. 5. There are many implementation-specific features, such as those you attribute to a potential local-MAC implementation, that are possible. But, this strands the split-Mac architecture. 6. Being unable to imagine the problem does not invalidate it. Again, a service provider has validated exactly this problem and provided specific support and examples for it. The claim is that the WTP and AC "*know*" that data flooding is causing loss of control channel packets. The claim that this is so, is not proof of it. Neither the AC nor the WTP can know why any particular packet is dropped, or even if it was dropped. There is no feedback mechanism in CAPWAP providing such feedback. All that the WTP or AC know is that an expected packet did not arrive, causing the state machine to change states. There is no ability to determine why that packet did not arrive. 7. A recurring point in this discussion, not only this email, is the increased costs and complexity of the two port approach. This is incorrect. There is no additional cost or complexity to this approach in the AC or WTP implementation, even for NAT traversal. NAT traversal is required for even a single port. If it can be accomplished for a single port, it is no more difficult or costly to do it for one or more additional ports. The actual cost is in requiring change/replacement/upgrading of intermediate networking equipment to adapt to a new protocol, while providing the same services as are provided to other protocols. 8. You state that the "vast majority" of deployments that might expect reliable QoS are within a single domain of control. Would you please state the references of this data? Many of the arguments presented below seem to be leading to a reduction of the market to which the full capabilities of CAPWAP would apply. I believe that this is not appropriate. In particular, the hotspot will soon have expectations of QoS that are similar to those of an enterprise. The growth of VOIP on WLAN will drive the QoS requirement. Designing a protocol, now, that does not encompass this requirement is very short sighted. -Bob -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: Tuesday, June 13, 2006 5:27 PM To: Bob O'Hara (boohara); capwap Subject: reasonably bounding our QoS ambitions for the base protocol I wanted to limit my earlier reply to the question the thread originally was addressing (getting the premises straight), but I also think the response below needs more attention. I've changed the subject line to keep the two threads distinct. Comments inline... -----Original Message----- >From: "Bob O'Hara (boohara)" >Sent: Jun 13, 2006 11:11 AM >To: capwap >Subject: Re: [Capwap] capwap transport analysis: QoS vs multiport > > > >Scott wrote: > >>So if the AC and WTP were to mark control packets >>so as to make them distinguishable from data packets >>(using one of the marking methods suggested above, >>and without relying on client truthfulness), what >>problems remain? > >As Pat points out in a separate email, the problem of controlling how >the WTP marks those packets remains to be solved. But, that discussion >can continue in Pat's thread. > >Another problem is that the WTP, itself, is not trusted by the network >to which it is attached. A widespread example is a network of WLAN >hotspots. The WTPs at the hotspot are connected to the AC over a third >party's network. > >In some of those hotspots, the WTP will be local-MAC. A hotspot user's >packets from a local-MAC WTP will be able to be inspected at ingress to >the third party's network, since the 5-tuple is clearly available in >those packets. QoS can be applied to those user data packets, without >requiring any changes to the third party's network equipment. Currently, the vast majority (if not all) of the deployed hotspots are local MAC, and users of those hotspots have no expectation of QoS. If the access point requires QoS for control traffic, then it also needs it for the 802.11 mgmt traffic that it's forwarding to the AC, and the hotspot provider would negotiate an appropriate agreement with the ISP - but in this case, *both* the capwap control and data channels would require QoS. However, there is a much simpler solution (assuming this ever becomes a real problem). If user data *were* choking the Internet link and hence causing control traffic starvation, the WTP is in a unique position to detect this and defend itself by throttling down user traffic while it attempts to re-establish its control linkage. Also, there is no requirement that a local-MAC WTP reset just because the control channel is temporarily lost - indeed, isn't it common (in fact, demanded by customers) today for local MAC WTP's to switch into a restricted mode upon loss of the control channel connection, and to maintain existing user sessions while rejecting new ones? That is, this particular problem is already being effectively addressed in other ways. >However, if those same packets are sent to the AC by a split-MAC WTP, >the third party network will not be able to distinguish control packets >from data packets, unless they are sent on separate ports. In the >CAPWAP packet, the 5-tuple is the same for both control and data. I'm having a really hard time with this one - forwarding user data back to the AC in a hotspot scenario, and doing it over an untrusting (and untrusted) 3rd party network, and expecting to provide QoS to boot? It's hard to imagine this happening in practice, but the fact is that the same argument applies with respect to control channel traffic, i.e. if a flooded data channel is causing control channel starvation, the WTP or AC *knows* this - it's immediately evident - and the WTP or AC can throttle back the data channel flow in favor of the control channel. And this requires no 3rd party intervention. I'm sure that if we put our minds to it, we can dream up corner cases which might not be addressed by a single port protocol, but there are other ways to solve the problems above that don't entail the complexity and costs of the multiport approach. And as an aside, this would appear to be one of the cases where NAT is most likely to occur, further complicating things. ---- I think it's important to acknowledge that none of the proposed solutions is perfect, or will service all possible scenarios that we might dream up. I think it's also important to realize that there are many problems to be solved in wlan deployments, and we are not, indeed cannot be chartered to solve each and every one of them here. We need to solve a reasonable subset of them, and address other problems in later efforts. The vast majority of real-world deployments where reliable provision of QoS might be reasonably expected are within a single domain of control, and those that are not present very challenging problems - problems which should not within the charter of this working group at this time, if we are to accomplish anything useful within a meaningful time frame. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From anasso@devereux.org Wed Jun 14 15:21:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqavq-0006J8-AQ for capwap-archive@ietf.org; Wed, 14 Jun 2006 15:21:38 -0400 Received: from 200.139.118.158.adsl.gvt.net.br ([200.139.118.158] helo=devereux.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fqavo-0005P4-5h for capwap-archive@ietf.org; Wed, 14 Jun 2006 15:21:38 -0400 Message-ID: <000001c68fe7$c7cc4c30$dc65a8c0@rcw71> Reply-To: "Anass Sulzer" From: "Anass Sulzer" To: capwap-archive@ietf.org Subject: Re: geqek 631 Date: Wed, 14 Jun 2006 12:21:47 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68FAD.1B6D7430" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68FAD.1B6D7430 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lev gf=20 itra Pr vd=20 ozac So pj=20 ma Meridi zc=20 a Ambi fs=20 en VALlU yl=20 M f fb=20 rom o ch=20 nly $ gi=20 1,2 bh=20 1 VlAGR fi=20 A fro vi=20 m o va=20 nly $=20 vy=20 3,3 ge=20 3 Xan yu=20 ax C ot=20 lALlS f yv=20 rom onl ex=20 y $=20 bm=20 3,7 tp=20 5 Sav np=20 e ove fq=20 r 50 ll=20 % wi ki=20 th u oy=20 s http://www.qualintens.com =20 _____ =20 and untouched. I have enough to last me my time, said Bilbo, when they=20 had dug it up. You had better take this, Gandalf. I daresay you can=20 find a use for it.=20 Indeed I can! said the wizard. But share and share alike! You may=20 find you have more needs than you expect.=20 So they put the gold in bags and slung them on the ponies, who were=20 ------=_NextPart_000_0001_01C68FAD.1B6D7430 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi

Lev
gf
itra
Pr
vd
ozac
So
pj
ma
Meridi
zc
a
Ambi
fs
en
VALlU
yl
M f
fb
rom o
ch
nly $
gi
1,2
bh
1
VlAGR
fi
A fro
vi
m o
va
nly $
vy
3,3
ge
3
Xan
yu
ax
C
ot
lALlS f
yv
rom onl
ex
y $
bm
3,7
tp
5

Sav
np
e ove
fq
r 50
ll
% wi
ki
th u
oy
s http://www.qualintens.com
 
and untouched. I = have enough to last me my time, said Bilbo, when they
had dug it up. = You had better take this, Gandalf. I daresay you can
find a use for = it.
Indeed I can! said the wizard. But share and share alike! You = may
find you have more needs than you expect.
So they put the = gold in bags and slung them on the ponies, who were =
------=_NextPart_000_0001_01C68FAD.1B6D7430-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 14 17:10:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqcdd-0000Rt-FM for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 17:10:57 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqcda-0000tR-NL for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 17:10:57 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DBD1B430123 for ; Wed, 14 Jun 2006 14:10:53 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 02D9A430064 for ; Wed, 14 Jun 2006 14:10:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E6358398053 for ; Wed, 14 Jun 2006 14:10:30 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by zoidberg.tigertech.net (Postfix) with ESMTP id AF50E39810B for ; Wed, 14 Jun 2006 14:10:26 -0700 (PDT) Received: from [209.86.224.43] (helo=elwamui-norfolk.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Fqcd8-0008Gh-5S; Wed, 14 Jun 2006 17:10:26 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Wed, 14 Jun 2006 17:10:25 -0400 Message-ID: <18243054.1150319425801.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Date: Wed, 14 Jun 2006 14:10:25 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "Bob O'Hara (boohara)" , capwap Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710df75dfd7a7cafeacb610ed5516142b78350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.43 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: Re: [Capwap] [CAPWAP] reasonably bounding our QoS ambitions for the base protocol X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Hi Bob, >1. Characterizing the "vast majority" of hotspot deployments as local >MAC is incorrect. The vast majority of hotspots fall outside the >architectures encompassed by CAPWAP. They are classical, stand-alone >APs without any AC, at all. Of those hotspot deployments that are not >stand-alone APs, there is a good mix of both local-MAC and split-MAC >hotspot deployments. Of course, you are correct about the APs not being capwap wtp's. However, their current deployment model most closely reflects the intent of capwap's local mac model. Sorry for any confusion, and while strictly speaking you are correct, I don't think this invalidates any of the points that followed. >2. The fact that users of today's hotspots have no expectation of QoS is >irrelevant to the discussion Actually, I think it *is* relevant, because it means that local (self-defense) throttling is a more reasonable solution to the problem, were it ever to occur (since there is no explicit user-data SLA to be concerned with). However, let's not get bogged down in this, because as you suggest, it's not central to the discussion >3. The problem is real, regardless of whether you believe it to be, or >not. An actual service provider has posted several more than once on >this list, saying exactly that. Simply claiming that their problem is >irrelevant does not make it so. I interpret his private communication to you and me as throwing this assertion into question, but it's up to him to post a public clarification if he cares to. That's all I can reasonably say on this point. >4. The WTP is only in a unique position to take the actions you cite >(throttling down user traffic) only if the problem can be detected by >the WTP. If the traffic is dropped beyond the link outbound from the >WTP, how does it learn what packets were dropped and where? There is no >mechanism to provide this feedback to the WTP. If the WTP is not getting responses to control traffic, but it is seeing inbound data traffic, then it is immediately evident that the internet connection is up. If the link is saturated, throttling it down and trying again with control traffic is a viable (and advisable) adaptation. Of course, many things could go wrong with WTP-AC link further up the line, but the argument this started with is that we need differential QoS between control and data to prevent data flooding from causing control traffic starvation. The WTP is clearly in a position to detect and mitigate this. >5. There are many implementation-specific features, such as those you >attribute to a potential local-MAC implementation, that are possible. >But, this strands the split-Mac architecture. Again, we must keep in mind the problem we are purporting to solve with two ports: differential control vs data channel QoS. Because the WTP can detect and throttle the flooding data flow, I don't see how split-mac architectures are stranded. >6. Being unable to imagine the problem does not invalidate it. Again, a >service provider has validated exactly this problem and provided >specific support and examples for it. See response to 3, above. >The claim is that the WTP and AC >"*know*" that data flooding is causing loss of control channel packets. No, the claim is that they know when the two are occurring together, and they can then attempt to prove the two are correlated quite simply. Is it absolute? No. Is the two-port approach absolute? No. >The claim that this is so, is not proof of it. Neither the AC nor the >WTP can know why any particular packet is dropped, or even if it was >dropped. There is no feedback mechanism in CAPWAP providing such >feedback. All that the WTP or AC know is that an expected packet did >not arrive, causing the state machine to change states. There is no >ability to determine why that packet did not arrive. See above. >7. A recurring point in this discussion, not only this email, is the >increased costs and complexity of the two port approach. This is >incorrect. There is no additional cost or complexity to this approach >in the AC or WTP implementation, even for NAT traversal. NAT traversal >is required for even a single port. If it can be accomplished for a >single port, it is no more difficult or costly to do it for one or more >additional ports. The actual cost is in requiring >change/replacement/upgrading of intermediate networking equipment to >adapt to a new protocol, while providing the same services as are >provided to other protocols. See http://lists.frascone.com/pipermail/capwap/msg02798.html Here's the reader's digest version: we get nat-t for free with the single port approach, due to the built-in heartbeat. It's clearly much more expensive with the multi-port approach. >8. You state that the "vast majority" of deployments that might expect >reliable QoS are within a single domain of control. Would you please >state the references of this data? I don't have time to research and prove this, and I concede that I am speaking from experience. >Many of the arguments presented below seem to be leading to a reduction >of the market to which the full capabilities of CAPWAP would apply. I >believe that this is not appropriate. In particular, the hotspot will >soon have expectations of QoS that are similar to those of an >enterprise. The growth of VOIP on WLAN will drive the QoS requirement. >Designing a protocol, now, that does not encompass this requirement is >very short sighted. I agree that some of the arguments do lead us to a reduction of the functionality we are trying to provide in rev 1 of a base protocol, but I don't think this is bad. I think we must limit our ambitions for the first rev if we are to get something out there soon. The IETF has seen a number of attempts at swiss-army-knife-style specification, and they tend to fail miserably. So, it seems prudent to set our sights a little lower at first, being careful not to slam doors shut, but at the same time not trying to solve everything conceivable in the first pass. That's one of the reasons we have version numbers in these protocols. It is reasonable to try to anticipate likely developments and try to anticipate them in the protocol design, and VoIP (and QoS in general) is clearly very important. But VoIP, video, and other QoS drivers are not being addressed by either of these proposals. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 14 17:44:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqdAR-0002L5-G7 for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 17:44:51 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqd3L-00053C-N8 for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 17:37:33 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5575B43006C for ; Wed, 14 Jun 2006 14:37:31 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 0B683430064 for ; Wed, 14 Jun 2006 14:36:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E95C9144801A for ; Wed, 14 Jun 2006 14:36:56 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.205]) by hermes.tigertech.net (Postfix) with ESMTP id 7C5EE144800A for ; Wed, 14 Jun 2006 14:36:53 -0700 (PDT) Received: by nz-out-0102.google.com with SMTP id z31so240849nzd for ; Wed, 14 Jun 2006 14:36:52 -0700 (PDT) Received: by 10.65.232.11 with SMTP id j11mr1039209qbr; Wed, 14 Jun 2006 14:36:52 -0700 (PDT) Received: by 10.65.206.17 with HTTP; Wed, 14 Jun 2006 14:36:52 -0700 (PDT) Message-ID: <5bfe7a820606141436t6c371ab7ke77908bad0c6e23f@mail.gmail.com> Date: Wed, 14 Jun 2006 14:36:52 -0700 From: "Dorothy Stanley" To: "Michael Montemurro" MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.6 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com, Margaret Wasserman Subject: [Capwap] Proposed Resolution to Issue 135: have a possible application for CAPWAP that involves running the WTP/wasRe: RC4 Encryption? X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0673134079==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f --===============0673134079== Content-Type: multipart/alternative; boundary="----=_Part_66149_28364091.1150321012399" ------=_Part_66149_28364091.1150321012399 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, Proposed resolution to Issue 135: Close, no change to the draft, include Charles' and Eric's comments as the reasons for not supporting the RC4 cipher. Comments?. Thanks, Dorothy On 6/8/06, Michael Montemurro wrote: > > I've capture this as issue 135 > > > On 6/6/06, Charles Clancy wrote: > > > > Are you suggesting adding DTLS ciphersuites such as > > TLS_RSA_WITH_RC4_128_SHA and TLS_PSK_WITH_RC4_128_SHA? > > > > There's a fundamental problem when using RC4 with DTLS (that > > incidentally does not appear to be addressed in RFC 4279). In > > particular, we seed the KDF and use its never-ending output to encrypt > > data by XORing it with the plaintext packets. However in DTLS, we can > > lose packets. This means gaps in the keystream, and the key states > > become out of sync. The only way to fix this is to do what WEP did, > > with per-packet IVs, and then you get all the same problems found in > > WEP. > > > > So, as-is, RC4 ciphersuites don't work well with DTLS, and if we fix > > them, we introduce security problems. > > > > -- > > t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy > > > > Margaret Wasserman wrote: > > > Hi All, > > > > > > I tried to send a message to the list on this topic a while back, but > > I > > > don't think it ever went out... Sorry if this is a duplicate. > > > > > > I have a possible application for CAPWAP that involves running the WTP > > > portion on a DSP-only device. In that situation, it will be very > > difficult > > > to support AES encryption, due to the processing overhead. > > > > > > Would the WG consider supporting a lighter weight algorithm for > > encryption, > > > such as RC4? We could state that AES is preferred when possible, but > > make > > > RC4 an accepted option in cases where the hardware would not support > > the > > > processing overhead of AES encryption. > > > > > > Thoughts? > > > > > > Margaret > > > > > > > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_66149_28364091.1150321012399 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline All,

Proposed resolution to Issue 135:

Close, no change to the draft, include Charles' and Eric's comments
as the reasons for not supporting the RC4 cipher.

Comments?.

Thanks,

Dorothy

On 6/8/06, Michael Montemurro <montemurro.michael@gmail.com> wrote:
I've capture this as issue 135


On 6/6/06, Charles Clancy <clancy@cs.umd.edu > wrote:
Are you suggesting adding DTLS ciphersuites such as
TLS_RSA_WITH_RC4_128_SHA and TLS_PSK_WITH_RC4_128_SHA?

There's a fundamental problem when using RC4 with DTLS (that
incidentally does not appear to be addressed in RFC 4279).  In
particular, we seed the KDF and use its never-ending output to encrypt
data by XORing it with the plaintext packets.  However in DTLS, we can
lose packets.  This means gaps in the keystream, and the key states
become out of sync.  The only way to fix this is to do what WEP did,
with per-packet IVs, and then you get all the same problems found in WEP.

So, as-is, RC4 ciphersuites don't work well with DTLS, and if we fix
them, we introduce security problems.

--
t. charles clancy, ph.d.  <>   tcc@umd.edu  <>   www.cs.umd.edu/~clancy

Margaret Wasserman wrote:
> Hi All,
>
> I tried to send a message to the list on this topic a while back, but I
> don't think it ever went out...  Sorry if this is a duplicate.
>
> I have a possible application for CAPWAP that involves running the WTP
> portion on a DSP-only device.  In that situation, it will be very difficult
> to support AES encryption, due to the processing overhead.
>
> Would the WG consider supporting a lighter weight algorithm for encryption,
> such as RC4?  We could state that AES is preferred when possible, but make
> RC4 an accepted option in cases where the hardware would not support the
> processing overhead of AES encryption.
>
> Thoughts?
>
> Margaret
>
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


------=_Part_66149_28364091.1150321012399-- --===============0673134079== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0673134079==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 14 17:45:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqdAp-0002eC-VP for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 17:45:15 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqcw7-0002s0-AD for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 17:30:04 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id EF45E43010D for ; Wed, 14 Jun 2006 14:30:02 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 8AC9E430064 for ; Wed, 14 Jun 2006 14:29:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 73E42398053 for ; Wed, 14 Jun 2006 14:29:41 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id CAB4E3980FA for ; Wed, 14 Jun 2006 14:29:37 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5ELTaH3026378 for ; Wed, 14 Jun 2006 14:29:36 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5ELTZaV026370 for ; Wed, 14 Jun 2006 14:29:36 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 14 Jun 2006 14:29:35 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [Capwap] CAPWAP packet formats X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 HI, I sent in a proposal for an update of the CAPWAP packet formats, and haven't heard back much. I plan to send an update later today or tomorrow. The planned updates include: 1) a few typo fixes, and terminology updates 2) details about encapsulation of data packets 3) some more info about how the msg seq num, msg ID, and "F" fields from the control header are used in retries 4) the high level reasons behind the proposal Are there any other items to include? Editors - what are your plans for CAPWAP-02? Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 14 17:51:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqdAO-0002Hk-Au for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 17:44:48 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqd6I-00068I-RG for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 17:40:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 71842430117 for ; Wed, 14 Jun 2006 14:40:34 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 11DF5430064 for ; Wed, 14 Jun 2006 14:40:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 074F0398124 for ; Wed, 14 Jun 2006 14:40:11 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by zoidberg.tigertech.net (Postfix) with ESMTP id 94FBA39811D for ; Wed, 14 Jun 2006 14:40:06 -0700 (PDT) Received: from [209.86.224.43] (helo=elwamui-norfolk.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Fqd5q-000894-0T; Wed, 14 Jun 2006 17:40:06 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Wed, 14 Jun 2006 17:40:05 -0400 Message-ID: <30265062.1150321205857.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Date: Wed, 14 Jun 2006 14:40:05 -0700 (GMT-07:00) From: "Scott G. Kelly" To: Dorothy Stanley , Michael Montemurro Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff7104d1fdd9a1078ccdda7165dd8e2218384350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.43 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com, Margaret Wasserman Subject: Re: [Capwap] Proposed Resolution to Issue 135: have a possible application for CAPWAP that involves running the WTP/wasRe: RC4 Encryption? X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Agree. -----Original Message----- >From: Dorothy Stanley >Sent: Jun 14, 2006 2:36 PM >To: Michael Montemurro >Cc: capwap@frascone.com, Margaret Wasserman >Subject: [Capwap] Proposed Resolution to Issue 135: have a possible application for CAPWAP that involves running the WTP/wasRe: RC4 Encryption? > >All, > >Proposed resolution to Issue 135: > >Close, no change to the draft, include Charles' and Eric's comments >as the reasons for not supporting the RC4 cipher. > >Comments?. > >Thanks, > >Dorothy > >On 6/8/06, Michael Montemurro wrote: >> >> I've capture this as issue 135 >> >> >> On 6/6/06, Charles Clancy wrote: >> > >> > Are you suggesting adding DTLS ciphersuites such as >> > TLS_RSA_WITH_RC4_128_SHA and TLS_PSK_WITH_RC4_128_SHA? >> > >> > There's a fundamental problem when using RC4 with DTLS (that >> > incidentally does not appear to be addressed in RFC 4279). In >> > particular, we seed the KDF and use its never-ending output to encrypt >> > data by XORing it with the plaintext packets. However in DTLS, we can >> > lose packets. This means gaps in the keystream, and the key states >> > become out of sync. The only way to fix this is to do what WEP did, >> > with per-packet IVs, and then you get all the same problems found in >> > WEP. >> > >> > So, as-is, RC4 ciphersuites don't work well with DTLS, and if we fix >> > them, we introduce security problems. >> > >> > -- >> > t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy >> > >> > Margaret Wasserman wrote: >> > > Hi All, >> > > >> > > I tried to send a message to the list on this topic a while back, but >> > I >> > > don't think it ever went out... Sorry if this is a duplicate. >> > > >> > > I have a possible application for CAPWAP that involves running the WTP >> > > portion on a DSP-only device. In that situation, it will be very >> > difficult >> > > to support AES encryption, due to the processing overhead. >> > > >> > > Would the WG consider supporting a lighter weight algorithm for >> > encryption, >> > > such as RC4? We could state that AES is preferred when possible, but >> > make >> > > RC4 an accepted option in cases where the hardware would not support >> > the >> > > processing overhead of AES encryption. >> > > >> > > Thoughts? >> > > >> > > Margaret >> > > >> > > >> > > _________________________________________________________________ >> > > To unsubscribe or modify your subscription options, please visit: >> > > http://lists.frascone.com/mailman/listinfo/capwap >> > > >> > > Archives: http://lists.frascone.com/pipermail/capwap >> > >> > _________________________________________________________________ >> > To unsubscribe or modify your subscription options, please visit: >> > http://lists.frascone.com/mailman/listinfo/capwap >> > >> > Archives: http://lists.frascone.com/pipermail/capwap >> > >> >> >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap >> >> _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 14 17:58:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqdNS-0005sG-EV for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 17:58:18 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqdNQ-0003K4-UY for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 17:58:18 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 383D7430127 for ; Wed, 14 Jun 2006 14:58:16 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C3661430064 for ; Wed, 14 Jun 2006 14:57:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A41FA144801A for ; Wed, 14 Jun 2006 14:57:47 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.198]) by hermes.tigertech.net (Postfix) with ESMTP id ABC03144800C for ; Wed, 14 Jun 2006 14:57:44 -0700 (PDT) Received: by nz-out-0102.google.com with SMTP id z31so244315nzd for ; Wed, 14 Jun 2006 14:57:44 -0700 (PDT) Received: by 10.65.61.4 with SMTP id o4mr1043926qbk; Wed, 14 Jun 2006 14:57:44 -0700 (PDT) Received: by 10.65.206.17 with HTTP; Wed, 14 Jun 2006 14:57:43 -0700 (PDT) Message-ID: <5bfe7a820606141457p2e8ac440qe3979a9ecb89a15@mail.gmail.com> Date: Wed, 14 Jun 2006 14:57:43 -0700 From: "Dorothy Stanley" To: "David T. Perkins" In-Reply-To: MIME-Version: 1.0 References: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.0 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Cc: capwap@frascone.com Subject: Re: [Capwap] CAPWAP packet formats X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1644518696==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.0 (+) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --===============1644518696== Content-Type: multipart/alternative; boundary="----=_Part_66213_16626830.1150322263980" ------=_Part_66213_16626830.1150322263980 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline David, My understanding of the editors' schedule for CAPWAP-02 is as follows. Now though June 21st (Wednesday) resolve issues on the list and incorporate the corresponding text changes. June 22-23 - Editors final review of draft for inadvertent typos, mis-applied changes, etc June 23 (latest) - Submit -02 for publication. The hard stop submission deadline is Monday June 26 9am Eastern. The update proposal which you reference is captured as issue 137. Thanks, Dorothy On 6/14/06, David T. Perkins wrote: > > HI, > > I sent in a proposal for an update of the CAPWAP packet > formats, and haven't heard back much. I plan to send an > update later today or tomorrow. > > The planned updates include: > 1) a few typo fixes, and terminology updates > 2) details about encapsulation of data packets > 3) some more info about how the msg seq num, msg ID, and "F" > fields from the control header are used in retries > 4) the high level reasons behind the proposal > > Are there any other items to include? > > Editors - what are your plans for CAPWAP-02? > > Regards, > /david t. perkins > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_66213_16626830.1150322263980 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline David,

My understanding of the editors' schedule for CAPWAP-02 is as follows.

Now though June 21st (Wednesday) resolve issues on the list and incorporate
the corresponding text changes.

June 22-23 - Editors final review of draft for inadvertent typos, mis-applied changes, etc

June 23 (latest) - Submit -02 for publication. The hard stop submission deadline is Monday June 26 9am Eastern.

The update proposal which you reference is captured as issue 137.

Thanks,

Dorothy


On 6/14/06, David T. Perkins <dperkins@dsperkins.com> wrote:
HI,

I sent in a proposal for an update of the CAPWAP packet
formats, and haven't heard back much. I plan to send an
update later today or tomorrow.

The planned updates include:
1) a few typo fixes, and terminology updates
2) details about encapsulation of data packets
3) some more info about how the msg seq num, msg ID, and "F"
   fields from the control header are used in retries
4) the high level reasons behind the proposal

Are there any other items to include?

Editors - what are your plans for CAPWAP-02?

Regards,
/david t. perkins

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_66213_16626830.1150322263980-- --===============1644518696== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1644518696==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 14 18:32:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqduQ-0008Cb-Fh for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 18:32:22 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqduN-0004Fs-Ql for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 18:32:22 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BFFD64300FE for ; Wed, 14 Jun 2006 15:32:18 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 095E5430064 for ; Wed, 14 Jun 2006 15:31:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id EC4CE39810B for ; Wed, 14 Jun 2006 15:31:43 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id 16F313980E0 for ; Wed, 14 Jun 2006 15:31:39 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 14 Jun 2006 15:31:39 -0700 X-IronPort-AV: i="4.06,133,1149490800"; d="scan'208,217"; a="1825816761:sNHT60976970" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k5EMVdqS013465; Wed, 14 Jun 2006 15:31:39 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5EMVd9s014551; Wed, 14 Jun 2006 15:31:39 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 15:31:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Jun 2006 15:31:38 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2020A734D@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] CAPWAP packet formats Thread-Index: AcaP/ao6W8gK7pmXSvue+hnHSPNHjwABHLVg From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "David T. Perkins" X-OriginalArrivalTime: 14 Jun 2006 22:31:39.0157 (UTC) FILETIME=[4D858C50:01C69002] Authentication-Results: sj-dkim-1.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.459 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_40_50, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] CAPWAP packet formats X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0265895689==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 This is a multi-part message in MIME format. --===============0265895689== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69002.4D6C0C83" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69002.4D6C0C83 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The issue that was created is really overloaded. While there is a header format change proposal, it also includes a counter to the MUX. I can take a look at the former, but I think it is too early to jump on the latter. I think this issue should be split up into two; header format change request and Alternative DTLS usage model. =20 Does that make sense? =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Wednesday, June 14, 2006 2:58 PM To: David T. Perkins Cc: capwap@frascone.com Subject: Re: [Capwap] CAPWAP packet formats =09 =09 David, =09 My understanding of the editors' schedule for CAPWAP-02 is as follows.=20 =09 Now though June 21st (Wednesday) resolve issues on the list and incorporate the corresponding text changes. =09 June 22-23 - Editors final review of draft for inadvertent typos, mis-applied changes, etc =09 June 23 (latest) - Submit -02 for publication. The hard stop submission deadline is Monday June 26 9am Eastern. =09 The update proposal which you reference is captured as issue 137. =09 Thanks, =09 Dorothy =09 =09 =09 On 6/14/06, David T. Perkins wrote:=20 HI, =09 I sent in a proposal for an update of the CAPWAP packet formats, and haven't heard back much. I plan to send an update later today or tomorrow. =09 The planned updates include: 1) a few typo fixes, and terminology updates=20 2) details about encapsulation of data packets 3) some more info about how the msg seq num, msg ID, and "F" fields from the control header are used in retries 4) the high level reasons behind the proposal=20 =09 Are there any other items to include? =09 Editors - what are your plans for CAPWAP-02? =09 Regards, /david t. perkins =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit:=20 http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 ------_=_NextPart_001_01C69002.4D6C0C83 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The=20 issue that was created is really overloaded. While there is a header = format=20 change proposal, it also includes a counter to the MUX. I can take a = look at the=20 former, but I think it is too early to jump on the latter. I think this = issue=20 should be split up into two; header format change request and = Alternative DTLS=20 usage model.
 
Does=20 that make sense?
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Wednesday, June 14, = 2006 2:58=20 PM
To: David T. Perkins
Cc:=20 capwap@frascone.com
Subject: Re: [Capwap] CAPWAP packet=20 formats

David,

My understanding of the editors' schedule for = CAPWAP-02 is as follows.

Now though June 21st (Wednesday) = resolve=20 issues on the list and incorporate
the corresponding text=20 changes.

June 22-23 - Editors final review of draft for = inadvertent=20 typos, mis-applied changes, etc

June 23 (latest) - Submit -02 = for=20 publication. The hard stop submission deadline is Monday June 26 9am=20 Eastern.

The update proposal which you reference is captured as = issue=20 137.

Thanks,

Dorothy


On 6/14/06, David T.=20 Perkins <dperkins@dsperkins.com>=20 wrote:
HI,

I=20 sent in a proposal for an update of the CAPWAP packet
formats, = and=20 haven't heard back much. I plan to send an
update later today or=20 tomorrow.

The planned updates include:
1) a few typo = fixes, and=20 terminology updates
2) details about encapsulation of data = packets
3)=20 some more info about how the msg seq num, msg ID, and = "F"
  =20 fields from the control header are used in retries
4) the high = level=20 reasons behind the proposal

Are there any other items to=20 include?

Editors - what are your plans for=20 CAPWAP-02?

Regards,
/david t.=20 = perkins

__________________________________________________________= _______
To=20 unsubscribe or modify your subscription options, please visit: =
http://lists.f= rascone.com/mailman/listinfo/capwap

Archives:=20 http://lists.frascone= .com/pipermail/capwap=20

------_=_NextPart_001_01C69002.4D6C0C83-- --===============0265895689== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0265895689==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 14 18:40:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqe1y-0004ig-Rv for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 18:40:10 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqe1y-0004rz-1C for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 18:40:10 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A0AEF4300EA for ; Wed, 14 Jun 2006 15:40:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8089C430064 for ; Wed, 14 Jun 2006 15:39:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 63630144801A for ; Wed, 14 Jun 2006 15:39:14 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.194]) by hermes.tigertech.net (Postfix) with ESMTP id A03881448029 for ; Wed, 14 Jun 2006 15:39:11 -0700 (PDT) Received: by nz-out-0102.google.com with SMTP id z31so250823nzd for ; Wed, 14 Jun 2006 15:39:10 -0700 (PDT) Received: by 10.64.3.9 with SMTP id 9mr1141661qbc; Wed, 14 Jun 2006 15:39:10 -0700 (PDT) Received: by 10.65.206.17 with HTTP; Wed, 14 Jun 2006 15:39:10 -0700 (PDT) Message-ID: <5bfe7a820606141539n22827885md3df8b55cf477cbb@mail.gmail.com> Date: Wed, 14 Jun 2006 15:39:10 -0700 From: "Dorothy Stanley" To: "Michael Montemurro" MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.0 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Cc: sujatha.varadarajan@flextronicssoftware.com, capwap@frascone.com Subject: [Capwap] Proposed Resolution for Issue 78:- no result code for WLAN config command X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0653721306==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.0 (+) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 --===============0653721306== Content-Type: multipart/alternative; boundary="----=_Part_66429_30346616.1150324750545" ------=_Part_66429_30346616.1150324750545 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, Issue 78, copied in the e-mail below raises 2 questions. Proposed resolutions to both questions are provided below. Comments please. Thanks, Dorothy --------------------------------------------------------------------------------------------------------------- Issue 78, Part 1: 1. I found that in the CAPWAP specification, the WLAN > configuration > request sent from the AC to the WTP is acked by the WLAN Configuration > Response. This Message does not have any message elements. > And I presume > it is sent irrespective of success / failure of configuration. > > Can we have the Radio Id , WLAN ID and Success Code Message Elements > (tlvs) to be sent as part of WLAN Configure Response ? ?If > not, is there > any other means of finding out if my WLAN Configuration (Add > / Update / > Delete ) succeeded or not? Proposed Resolution to Issue 78 Part 1: Same as (part of) Issue 74, include the Result Code message element as a mandatory message element in the IEEE 802.11 WLAN Configuration Response message. Issue 78 Part 2: > 2. The WTP Radio Information that lists the Radio type and Id is part > of the Discovery Request. It is not sent as part of any Message after > that. But since the AC does not keep any state for a > Discovery Request, > the AC does not remember it. I assume that without knowing the Radio > type, the AC would not be able to configure the WTP. I suggest we add > Radio Type TLV to the Configure Request, to avoid this. Proposed Resolution for Issue 78 Part 2: Add "WTP Radio Information" to the list of message elements that MUST be included in the Configuration Status Message (WTP->AC) On 3/16/06, Michael Montemurro wrote: > > I've recorded this issue as a bug. The issue number is 78. > > Cheers, > > Mike > > > -----Original Message----- > > From: sujay [mailto:sujayg@huawei.com] > > Sent: March 8, 2006 2:11 AM > > To: sujatha.varadarajan@flextronicssoftware.com; capwap@frascone.com > > Subject: RE: [Capwap] FW: 802.11 Specific - no result code > > for WLAN config command > > > > Sujatha, > > The first point you have mentioned could be addressed thus; > > > > Send WLAN Configuration reponse only when the operation is > > successful.Using the sequence number in the request packet > > you should be able identify which WLAN configuration request > > has failed and thus the Radio ID. WLAN Id etc. > > > > > > Second point; > > > > (In the expired lwapp-03.txt this message was being sent in the Join > > Request Message, > > not so in the current.) > > > > It could be handled in two ways; > > 1. the AC should not send the Discovery Response if it is unable to > > configure the WTP > > With its given WTP radio information, that automatically means the > > ClientHello SHOULD > > not be expected from the that non-supported WTP. > > > > 2. It could be added as a part of the 802.11 binding message, IEEE > > 802.11 WTP WLAN Radio Configuration, > > message another "Radio Type". > > > > > > Any comments? > > > > Regards, > > Sujay > > > > My Location; > > http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.72485 > 2,7.525085 > > &t=h&hl=en > > > > > > > > > > Hi, > > > > 1. I found that in the CAPWAP specification, the WLAN > > configuration > > request sent from the AC to the WTP is acked by the WLAN Configuration > > Response. This Message does not have any message elements. > > And I presume > > it is sent irrespective of success / failure of configuration. > > > > Can we have the Radio Id , WLAN ID and Success Code Message Elements > > (tlvs) to be sent as part of WLAN Configure Response ? ?If > > not, is there > > any other means of finding out if my WLAN Configuration (Add > > / Update / > > Delete ) succeeded or not? > > > > 2. The WTP Radio Information that lists the Radio type and Id is part > > of the Discovery Request. It is not sent as part of any Message after > > that. But since the AC does not keep any state for a > > Discovery Request, > > the AC does not remember it. I assume that without knowing the Radio > > type, the AC would not be able to configure the WTP. I suggest we add > > Radio Type TLV to the Configure Request, to avoid this. > > > > > > > > Thanks > > > > Sujatha V > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_66429_30346616.1150324750545 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline All,

Issue 78, copied in the e-mail below raises 2 questions.
Proposed resolutions to both questions are provided below.
Comments please.

Thanks,

Dorothy
---------------------------------------------------------------------------------------------------------------
Issue 78, Part 1:

 1.  I found that in the CAPWAP specification, the WLAN
> configuration
> request sent from the AC to the WTP is acked by the WLAN Configuration
> Response. This Message does not have any message elements.
> And I presume
> it is sent irrespective of success / failure of configuration.
>
>  Can we have the Radio Id , WLAN ID and Success Code Message Elements
> (tlvs) to be sent as part of WLAN Configure Response ? ?If
> not, is there
> any other means of finding out if my WLAN Configuration (Add
> / Update /
> Delete ) succeeded or not?

Proposed Resolution to Issue 78 Part 1:
Same as (part of)  Issue 74, include the Result Code message element
as a mandatory message element in the IEEE 802.11 WLAN
Configuration Response message.

Issue 78 Part 2:

>  2. The WTP Radio Information that lists the Radio type and Id is part
> of the Discovery Request. It is not sent as part of any Message after
> that.  But since the AC does not keep any state for a
> Discovery Request,
> the AC does not remember it. I assume that without knowing the Radio
> type, the AC would not be able to configure the WTP. I suggest we add
> Radio Type TLV to the Configure Request, to avoid this.

Proposed Resolution for Issue 78 Part 2:

Add "WTP Radio Information" to the list of message elements that
MUST be included in the Configuration Status Message (WTP->AC)

On 3/16/06, Michael Montemurro <michael.montemurro@siemens.com > wrote:
I've recorded this issue as a bug. The issue number is 78.

Cheers,

        Mike

> -----Original Message-----
> From: sujay [mailto:sujayg@huawei.com]
> Sent: March 8, 2006 2:11 AM
> To: sujatha.varadarajan@flextronicssoftware.com; capwap@frascone.com
> Subject: RE: [Capwap] FW: 802.11 Specific - no result code
> for WLAN config command
>
> Sujatha,
> The first point you have mentioned could  be addressed thus;
>
> Send WLAN Configuration reponse only when the operation is
> successful.Using the sequence number in the request packet
> you should be able identify which WLAN configuration request
> has failed and thus the Radio ID. WLAN Id etc.
>
>
> Second point;
>
> (In the expired lwapp-03.txt this message was being sent in the Join
> Request Message,
> not so in the current.)
>
> It could be handled in two ways;
> 1. the AC should not send the Discovery Response if it is unable to
> configure the WTP
> With its given WTP radio information, that automatically means the
> ClientHello SHOULD
> not be expected from the that non-supported WTP.
>
> 2. It could be added as a part of the 802.11 binding message, IEEE
> 802.11 WTP WLAN Radio Configuration,
> message another "Radio Type".
>
>
> Any comments?
>
> Regards,
> Sujay
>
> My Location;
> http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.72485
2,7.525085
> &t=h&hl=en
>
>
>
>
>  Hi,
>
>    1.  I found that in the CAPWAP specification, the WLAN
> configuration
> request sent from the AC to the WTP is acked by the WLAN Configuration
> Response. This Message does not have any message elements.
> And I presume
> it is sent irrespective of success / failure of configuration.
>
>  Can we have the Radio Id , WLAN ID and Success Code Message Elements
> (tlvs) to be sent as part of WLAN Configure Response ? ?If
> not, is there
> any other means of finding out if my WLAN Configuration (Add
> / Update /
> Delete ) succeeded or not?
>
>  2. The WTP Radio Information that lists the Radio type and Id is part
> of the Discovery Request. It is not sent as part of any Message after
> that.  But since the AC does not keep any state for a
> Discovery Request,
> the AC does not remember it. I assume that without knowing the Radio
> type, the AC would not be able to configure the WTP. I suggest we add
> Radio Type TLV to the Configure Request, to avoid this.
>
>
>
> Thanks
>
> Sujatha V
>
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_66429_30346616.1150324750545-- --===============0653721306== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0653721306==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 14 18:47:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqe93-0006KY-WC for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 18:47:30 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqe92-00066x-IG for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 18:47:29 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 365A0430100 for ; Wed, 14 Jun 2006 15:47:28 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 9F8F1430064 for ; Wed, 14 Jun 2006 15:47:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8F3F23980FA for ; Wed, 14 Jun 2006 15:47:08 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E7AE139802A for ; Wed, 14 Jun 2006 15:47:05 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5EMl5od013378 for ; Wed, 14 Jun 2006 15:47:05 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5EMl5Jn013375 for ; Wed, 14 Jun 2006 15:47:05 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 14 Jun 2006 15:47:04 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [Capwap] CERT issues in CAPWAP-01 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c HI, I didn't see the following in the issue tracker. I reported them to Scott and Charles back around May 8. 1) Cipher Suites for CERTS CAPWAP-01 has the following cipher suites specified: TLS_DH_RSA_WITH_AES_128_CBC_SHA, TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA, and TLS_DH_RSA_WITH_AES_256_CBC_SHA The above is a mistake, and the following should be used: TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA, and TLS_DHE_RSA_WITH_AES_256_CBC_SHA 2) CERT usage type: CAPWAP-01 has the folllwing about CERTS: 2.4.4.3. Certificate Usage Validation of the certificates by the AC and WTP is required so that only an AC may perform the functions of an AC and that only a WTP may perform the functions of a WTP. This restriction of functions to the AC or WTP requires that the certificates used by the AC MUST be distinguishable from the certificate used by the WTP. To accomplish this differentiation, the x.509v3 certificates MUST include the Extensions field [11] and MUST include the NetscapeComment [15] extension. For an AC, the value of the NetscapeComment extension MUST be the string "CAPWAP AC Device Certificate". For a WTP, the value of the NetscapeComment extension MUST be the string "CAPWAP WTP Device Certificate". Part of the CAPWAP certificate validation process includes ensuring that the proper string is included in the NetscapeComment extension, and only allowing the CAPWAP session to be established if the extension does not represent the same role as the device validating the certificate. For instance, a WTP MUST NOT accept a certificate whose NetscapeComment field is set to "CAPWAP WTP Device Certificate". Using the "NetscapeComment extension" is not appropriate. 3) Selfsigned CERTs, CA CERTs, and validity checking I didn't see anything about whether or not the CERTs were selfsigned. And if not selfsigned, who would sign them. Also, how would a limited resource WTP verify an AC's cert? What if the WTP had no realtime clock (or a realtime clock with an unknown certainty)? 4) Common Name in a WTP's CERT I believe that the common name on the WTP's CERT must be the WTP's ID (which would be either the serial number or "base MAC address"), and should be provided as a parameter on the join. Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 14 19:05:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqeQG-0001mu-SX for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 19:05:16 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqeQE-0007hq-L9 for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 19:05:16 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CA8A6430092 for ; Wed, 14 Jun 2006 16:05:13 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id BFDA0430064 for ; Wed, 14 Jun 2006 16:04:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AF075144800C for ; Wed, 14 Jun 2006 16:04:24 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.207]) by hermes.tigertech.net (Postfix) with ESMTP id 8AABC1448027 for ; Wed, 14 Jun 2006 16:04:20 -0700 (PDT) Received: by nz-out-0102.google.com with SMTP id n29so278687nzf for ; Wed, 14 Jun 2006 16:04:19 -0700 (PDT) Received: by 10.65.72.15 with SMTP id z15mr38548qbk; Wed, 14 Jun 2006 16:04:19 -0700 (PDT) Received: by 10.65.206.17 with HTTP; Wed, 14 Jun 2006 16:04:19 -0700 (PDT) Message-ID: <5bfe7a820606141604h6c56ea2cxabe49f4b9ff19ab4@mail.gmail.com> Date: Wed, 14 Jun 2006 16:04:19 -0700 From: "Dorothy Stanley" To: "David T. Perkins" In-Reply-To: MIME-Version: 1.0 References: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.7 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_30_40, HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] CERT issues in CAPWAP-01 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0042366385==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.7 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad --===============0042366385== Content-Type: multipart/alternative; boundary="----=_Part_66553_2552537.1150326259675" ------=_Part_66553_2552537.1150326259675 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline David, Charles had forwarded the text below. Does this text address your concerns? This is included as part of Issue 2. I thought I sent it to the list, but evidently not. Dorothy 2.4.4.1. Authenticating with Certificates Note that only block ciphers are currently recommended for use with DTLS. To understand the reasoning behind this, see [26]. However,support for AES counter mode encryption is currently progressing in the TLS working group, and once protocol identifiers are available, they will be added below. At present, the following algorithms MUST be supported when using certificates for CAPWAP authentication: o TLS_RSA_WITH_AES_128_CBC_SHA o TLS_RSA_WITH_3DES_EDE_CBC _SHA The following algorithms SHOULD be supported when using certificates: o TLS_DHE_RSA_WITH_AES_128_CBC_SHA o TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA The following algorithms MAY be supported when using certificates: o TLS_RSA_WITH_AES_256_CBC_SHA o TLS_DHE_RSA_WITH_AES_256_CBC_SHA 2.4.4.2. Authenticating with Preshared Keys Pre-shared keys present significant challenges from a security perspective, and for that reason, their use is strongly discouraged. However, [13] defines several different methods for authenticating with preshared keys, and we focus on the following two: o PSK key exchange algorithm - simplest method, ciphersuites use only symmetric key algorithms o DHE_PSK key exchange algorithm - use a PSK to authenticate a Diffie-Hellman exchange. These ciphersuites give some additional protection against dictionary attacks and also provide Perfect Forward Secrecy (PFS). The first approach (plain PSK) is susceptible to passive dictionary attacks; hence, while this alorithm MUST be supported, special care should be taken when choosing that method. In particular, user- readable passphrases SHOULD NOT be used, and use of short PSKs SHOULD be strongly discouraged. The following cryptographic algorithms MUST be supported when using preshared keys: o TLS_PSK_WITH_AES_128_CBC_SHA o TLS_PSK_WITH_3DES_EDE_CBC_SHA o TLS_DHE_PSK_WITH_AES_128_CBC_SHA o TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA The following algorithms MAY be supported when using preshared keys: o TLS_PSK_WITH_AES_256_CBC_SHA o TLS_DHE_PSK_WITH_AES_256_CBC_SHA 2.4.4.3. Certificate Usage When using certificates, both authentication and authorization must be considered. Section 13.3 provides recommendations on how to authenticate a certificate and bind that to a CAPWAP entity. This section deals with certificate authorization. Certificate authorization by the AC and WTP is required so that only an AC may perform the functions of an AC and that only a WTP may perform the functions of a WTP. This restriction of functions to the AC or WTP requires that the certificates used by the AC MUST be distinguishable from the certificate used by the WTP. To accomplish this differentiation, the X.509 certificates MUST include the extended key usage (EKU) certificate extension [11]. The EKU field indicates one or more purposes for which a certificate may be used. It is an essential part in authorization. Its syntax is as follows: ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId KeyPurposeId ::= OBJECT IDENTIFIER Here we define two KeyPurposeId values, one for the WTP and one for the AC. Inclusion of one of those two values indicates a certificate is authorized for use by a WTP or AC, respectively. These values are formatted as id-kp fields. id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp XX } id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp YY } The integer values XX and YY are yet to be allocated by IANA. For an AC, the id-kp-capwapAC EKU MUST be present in the certificate. For a WTP, the id-kp-capwapWTP EKU MUST be present in the certificate. Part of the CAPWAP certificate validation process includes ensuring that the proper EKU is included and only allowing the CAPWAP session to be established if the extension properly represents the device. 13.3. Use of Certificates in CAPWAP For public-key-based DTLS deployments, each device SHOULD have unique credentials, with an extended key usage authorizing them to act as either a WTP or AC. If devices do not have unique credentials, it is possible that by compromising one, any other one using the same credential may also be considered to be compromised. Certificate validation involves checking a large variety of things. Since the necessary things to validate are often environment-specific, many are beyond the scope of this document. In this section, we provide some basic guidance on certificate validation. Each device is responsible for authenticating and authorizing devices with which they communicate. Authentication entails validation of the chain of trust leading to the peer certificate, followed by the the peer certificate itself. At a minimum, devices SHOULD use SSH-style certificate caching to guarantee consistency. If devices have access to a certificate authority, they SHOULD properly validate the trust chain. Implementations SHOULD also provide a secure method for verifying that the credential in question has not been revoked. Note that if the WTP relies on the AC for network connectivity (e.g. the AC is a layer 2 switch to which the WTP is directly connected), there is a chicken and egg problem, in that the WTP may not be able to contact an OCSP server or otherwise obtain an up to date CRL if a compromised AC doesn't explicitly permit this. This cannot be avoided, except through effective physical security and monitoring measures at the AC. Proper validation of certificates typically requires checking to ensure the certificate has not yet expired. If devices have a real-time clock, they SHOULD verify the certificate validity dates. If no real-time clock is available, the device SHOULD attempt to determine the current time using NTP prior to certificate validation. If neither is available, devices SHOULD verify that the start validity date of its peer's certificate is less than its own certificate's expiration date, and its peer's expiration date is greater than its own start date. Note that failure to check a certificate's temporal validity can make a device vulnerable to man-in-the-middle attacks launched using compromised, expired certificates, and therefore devices should make every effort to perform this validation. Another important part of certificate authentication is binding a certificate to a particular device. There are many ways to accomplish this. CAPWAP RECOMMENDS specifying the certificate common name (CN) as the WTP or AC MAC address formatted as ASCII HEX, followed by an @ symbol, and then an administrative domain. For example, 01:23:45:67:89:ab@DOMAIN.NET. During authentication, devices SHOULD ensure that the MAC matches the MAC specified in the CAPWAP header, and that the domain in both the AC and WTP certificates match. On 6/14/06, David T. Perkins wrote: > > HI, > > I didn't see the following in the issue tracker. I reported > them to Scott and Charles back around May 8. > > 1) Cipher Suites for CERTS > CAPWAP-01 has the following cipher suites specified: > TLS_DH_RSA_WITH_AES_128_CBC_SHA, > TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA, and > TLS_DH_RSA_WITH_AES_256_CBC_SHA > > The above is a mistake, and the following should be used: > TLS_DHE_RSA_WITH_AES_128_CBC_SHA, > TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA, and > TLS_DHE_RSA_WITH_AES_256_CBC_SHA > > 2) CERT usage type: > CAPWAP-01 has the folllwing about CERTS: > 2.4.4.3. Certificate Usage > > Validation of the certificates by the AC and WTP is required so that > only an AC may perform the functions of an AC and that only a WTP may > perform the functions of a WTP. This restriction of functions to the > AC or WTP requires that the certificates used by the AC MUST be > distinguishable from the certificate used by the WTP. To accomplish > this differentiation, the x.509v3 certificates MUST include the > Extensions field [11] and MUST include the NetscapeComment [15] > extension. > > For an AC, the value of the NetscapeComment extension MUST be the > string "CAPWAP AC Device Certificate". For a WTP, the value of the > NetscapeComment extension MUST be the string "CAPWAP WTP Device > Certificate". > > Part of the CAPWAP certificate validation process includes ensuring > that the proper string is included in the NetscapeComment extension, > and only allowing the CAPWAP session to be established if the > extension does not represent the same role as the device validating > the certificate. For instance, a WTP MUST NOT accept a certificate > whose NetscapeComment field is set to "CAPWAP WTP Device > Certificate". > > Using the "NetscapeComment extension" is not appropriate. > > 3) Selfsigned CERTs, CA CERTs, and validity checking > I didn't see anything about whether or not the CERTs > were selfsigned. And if not selfsigned, who would sign them. > Also, how would a limited resource WTP verify an AC's cert? > What if the WTP had no realtime clock (or a realtime clock > with an unknown certainty)? > > 4) Common Name in a WTP's CERT > I believe that the common name on the WTP's CERT > must be the WTP's ID (which would be either the serial > number or "base MAC address"), and should be provided > as a parameter on the join. > > > Regards, > /david t. perkins > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_66553_2552537.1150326259675 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline David,

Charles had forwarded the text below. Does this text address your concerns?
This is included as part of Issue 2. I thought I sent it to the
list, but evidently not.

Dorothy

2.4.4.1.  Authenticating with Certificates

   Note that only block ciphers are currently recommended for use with
   DTLS.  To understand the reasoning behind this, see [26].
   However,support for AES counter mode encryption is currently
   progressing in the TLS working group, and once protocol identifiers
   are available, they will be added below.  At present, the following
   algorithms MUST be supported when using certificates for CAPWAP
   authentication:

   o  TLS_RSA_WITH_AES_128_CBC_SHA
   o  TLS_RSA_WITH_3DES_EDE_CBC
_SHA

   The following algorithms SHOULD be supported when using certificates:

   o  TLS_DHE_RSA_WITH_AES_128_CBC_SHA
   o  TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA

   The following algorithms MAY be supported when using certificates:

   o  TLS_RSA_WITH_AES_256_CBC_SHA
   o  TLS_DHE_RSA_WITH_AES_256_CBC_SHA

2.4.4.2.  Authenticating with Preshared Keys

   Pre-shared keys present significant challenges from a security
   perspective, and for that reason, their use is strongly
   discouraged.  However, [13] defines several different methods for
   authenticating with preshared keys, and we focus on the following
   two:

   o  PSK key exchange algorithm - simplest method, ciphersuites use
      only symmetric key algorithms

   o  DHE_PSK key exchange algorithm - use a PSK to authenticate a
      Diffie-Hellman exchange.  These ciphersuites give some additional
      protection against dictionary attacks and also provide Perfect
      Forward Secrecy (PFS).

   The first approach (plain PSK) is susceptible to passive dictionary
   attacks; hence, while this alorithm MUST be supported, special care
   should be taken when choosing that method.  In particular, user-
   readable passphrases SHOULD NOT be used, and use of short PSKs
   SHOULD be strongly discouraged.

   The following cryptographic algorithms MUST be supported when using
   preshared keys:

   o  TLS_PSK_WITH_AES_128_CBC_SHA
   o  TLS_PSK_WITH_3DES_EDE_CBC_SHA
   o  TLS_DHE_PSK_WITH_AES_128_CBC_SHA
   o  TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA

   The following algorithms MAY be supported when using preshared
   keys:

   o  TLS_PSK_WITH_AES_256_CBC_SHA
   o  TLS_DHE_PSK_WITH_AES_256_CBC_SHA

2.4.4.3.  Certificate Usage

   When using certificates, both authentication and authorization must
   be considered.  Section 13.3 provides recommendations on how to
   authenticate a certificate and bind that to a CAPWAP entity.  This
   section deals with certificate authorization.

   Certificate authorization by the AC and WTP is required so that
   only an AC may perform the functions of an AC and that only a WTP may
   perform the functions of a WTP.  This restriction of functions to the
   AC or WTP requires that the certificates used by the AC MUST be
   distinguishable from the certificate used by the WTP.  To accomplish
   this differentiation, the X.509 certificates MUST include the
   extended key usage (EKU) certificate extension [11].

   The EKU field indicates one or more purposes for which a certificate
   may be used.  It is an essential part in authorization.  Its syntax
   is as follows:

      ExtKeyUsageSyntax  ::=  SEQUENCE SIZE (1..MAX) OF KeyPurposeId

      KeyPurposeId  ::=  OBJECT IDENTIFIER

   Here we define two KeyPurposeId values, one for the WTP and one for
   the AC.  Inclusion of one of those two values indicates a
   certificate is authorized for use by a WTP or AC, respectively.
   These values are formatted as id-kp fields.

      id-kp  OBJECT IDENTIFIER  ::=
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) 3 }

      id-kp-capwapWTP  OBJECT IDENTIFIER  ::=  { id-kp XX }

      id-kp-capwapAC   OBJECT IDENTIFIER  ::=  { id-kp YY }

   The integer values XX and YY are yet to be allocated by IANA.

   For an AC, the id-kp-capwapAC EKU MUST be present in the
   certificate.  For a WTP, the id-kp-capwapWTP EKU MUST be present in
   the certificate.

   Part of the CAPWAP certificate validation process includes ensuring
   that the proper EKU is included and only allowing the CAPWAP
   session to be established if the extension properly represents the
   device.


13.3.  Use of Certificates in CAPWAP

   For public-key-based DTLS deployments, each device SHOULD have
   unique credentials, with an extended key usage authorizing them to
   act as either a WTP or AC.  If devices do not have unique
   credentials, it is possible that by compromising one, any other one
   using the same credential may also be considered to be compromised.

   Certificate validation involves checking a large variety of things.
   Since the necessary things to validate are often
   environment-specific, many are beyond the scope of this document.
   In this section, we provide some basic guidance on certificate
   validation.

   Each device is responsible for authenticating and authorizing
   devices with which they communicate.  Authentication entails
   validation of the chain of trust leading to the peer certificate,
   followed by the the peer certificate itself.  At a minimum, devices
   SHOULD use SSH-style certificate caching to guarantee consistency.
   If devices have access to a certificate authority, they SHOULD
   properly validate the trust chain.  Implementations SHOULD also
   provide a secure method for verifying that the credential in
   question has not been revoked.

   Note that if the WTP relies on the AC for network connectivity
   (e.g.  the AC is a layer 2 switch to which the WTP is directly
   connected), there is a chicken and egg problem, in that the WTP may
   not be able to contact an OCSP server or otherwise obtain an up to
   date CRL if a compromised AC doesn't explicitly permit this.  This
   cannot be avoided, except through effective physical security and
   monitoring measures at the AC.

   Proper validation of certificates typically requires checking to
   ensure the certificate has not yet expired.  If devices have a
   real-time clock, they SHOULD verify the certificate validity dates.
   If no real-time clock is available, the device SHOULD attempt to
   determine the current time using NTP prior to certificate
   validation.  If neither is available, devices SHOULD verify that
   the start validity date of its peer's certificate is less than its
   own certificate's expiration date, and its peer's expiration date
   is greater than its own start date.  Note that failure to check a
   certificate's temporal validity can make a device vulnerable to
   man-in-the-middle attacks launched using compromised, expired
   certificates, and therefore devices should make every effort to
   perform this validation.

   Another important part of certificate authentication is binding a
   certificate to a particular device.  There are many ways to
   accomplish this.  CAPWAP RECOMMENDS specifying the certificate
   common name (CN) as the WTP or AC MAC address formatted as ASCII
   HEX, followed by an @ symbol, and then an administrative domain.
   For example, 01:23:45:67:89:ab@DOMAIN.NET.  During authentication,
   devices SHOULD ensure that the MAC matches the MAC specified in the
   CAPWAP header, and that the domain in both the AC and WTP
   certificates match.


On 6/14/06, David T. Perkins <dperkins@dsperkins.com> wrote:
HI,

I didn't see the following in the issue tracker. I reported
them to Scott and Charles back around May 8.

1) Cipher Suites for CERTS
CAPWAP-01 has the following cipher suites specified:
TLS_DH_RSA_WITH_AES_128_CBC_SHA,
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA, and
TLS_DH_RSA_WITH_AES_256_CBC_SHA

The above is a mistake, and the following should be used:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA, and
TLS_DHE_RSA_WITH_AES_256_CBC_SHA

2) CERT usage type:
CAPWAP-01 has the folllwing about CERTS:
   2.4.4.3.  Certificate Usage

   Validation of the certificates by the AC and WTP is required so that
   only an AC may perform the functions of an AC and that only a WTP may
   perform the functions of a WTP.  This restriction of functions to the
   AC or WTP requires that the certificates used by the AC MUST be
   distinguishable from the certificate used by the WTP.  To accomplish
   this differentiation, the x.509v3 certificates MUST include the
   Extensions field [11] and MUST include the NetscapeComment [15]
   extension.

   For an AC, the value of the NetscapeComment extension MUST be the
   string "CAPWAP AC Device Certificate".  For a WTP, the value of the
   NetscapeComment extension MUST be the string "CAPWAP WTP Device
   Certificate".

   Part of the CAPWAP certificate validation process includes ensuring
   that the proper string is included in the NetscapeComment extension,
   and only allowing the CAPWAP session to be established if the
   extension does not represent the same role as the device validating
   the certificate.  For instance, a WTP MUST NOT accept a certificate
   whose NetscapeComment field is set to "CAPWAP WTP Device
   Certificate".

Using the "NetscapeComment extension" is not appropriate.

3) Selfsigned CERTs, CA CERTs, and validity checking
I didn't see anything about whether or not the CERTs
were selfsigned. And if not selfsigned, who would sign them.
Also, how would a limited resource WTP verify an AC's cert?
What if the WTP had no realtime clock (or a realtime clock
with an unknown certainty)?

4) Common Name in a WTP's CERT
I believe that the common name on the WTP's CERT
must be the WTP's ID (which would be either the serial
number or "base MAC address"), and should be provided
as a parameter on the join.


Regards,
/david t. perkins

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_66553_2552537.1150326259675-- --===============0042366385== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0042366385==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 14 19:23:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqeiF-0001aw-Of for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 19:23:51 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqeiE-0001If-5R for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 19:23:51 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C328443011F for ; Wed, 14 Jun 2006 16:23:49 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id DB88843006D for ; Wed, 14 Jun 2006 16:23:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CB2F71448029 for ; Wed, 14 Jun 2006 16:23:15 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by hermes.tigertech.net (Postfix) with ESMTP id 126CA1448027 for ; Wed, 14 Jun 2006 16:23:12 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so71436pyu for ; Wed, 14 Jun 2006 16:23:12 -0700 (PDT) Received: by 10.35.99.5 with SMTP id b5mr1879305pym; Wed, 14 Jun 2006 16:23:11 -0700 (PDT) Received: by 10.65.206.17 with HTTP; Wed, 14 Jun 2006 16:23:11 -0700 (PDT) Message-ID: <5bfe7a820606141623n672ce620uf4771efc68d83eef@mail.gmail.com> Date: Wed, 14 Jun 2006 16:23:11 -0700 From: "Dorothy Stanley" To: "Pat Calhoun (pacalhou)" , "Saravanan Govindan" , capwap MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.0 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: [Capwap] Proposed Resolution of Issue 132/Re: Clarification of protocol goals X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0834459300==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.0 (+) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb --===============0834459300== Content-Type: multipart/alternative; boundary="----=_Part_66601_31222376.1150327391758" ------=_Part_66601_31222376.1150327391758 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, Issue 132 is included in the email below. Proposed Resolution: Change goal #1 in section 1.1 from To centralize the bridging, forwarding, authentication and policy enforcement functions for a wireless network. Optionally, the AC may also provide centralized encryption of user traffic. Centralization of these functions will enable reduced cost and higher efficiency by applying the capabilities of network processing silicon to the wireless network, as in wired LANs. to To centralize the authentication and policy enforcement functions for a wireless network. The AC may also provide centralized bridging, forwarding, and encryption of user traffic. Centralization of these functions will enable reduced cost and higher efficiency by applying the capabilities of network processing silicon to the wireless network, as in wired LANs. Comments? Thanks, Dorothy On 6/3/06, Pat Calhoun (pacalhou) wrote: > > I created issue 132 to track this change request. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > > Sent: Wednesday, May 24, 2006 6:01 PM > > To: capwap > > Subject: [Capwap] Clarification of protocol goals > > > > All, > > > > One of the goals stated in Section 1.1 "Goals" is; > > > > "1. To centralize the bridging, forwarding, authentication > > and policy ...." > > > > Centralized bridging seems to be applicable to Split MAC > > alone. In the case of CAPWAP being used to manage Local MAC > > WTPs, bridging is not centralized. > > > > I suggest an update to this goal; > > > > "1. To centralize major functions of a wireless network, such > > as configuration, authentication, policy enforcement and in > > some cases, bridging and forwarding. " > > > > Comments? > > > > Saravanan > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_66601_31222376.1150327391758 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline All,

Issue 132 is included in the email below.

Proposed Resolution:

Change goal #1 in section 1.1 from

To centralize the bridging, forwarding, authentication and policy enforcement functions for a
wireless network. Optionally, the AC may also provide centralized encryption of user traffic.
Centralization of these functions will enable reduced cost and higher efficiency by applying
the capabilities of network processing silicon to the wireless network, as in wired LANs.

to

To centralize the authentication and policy enforcement functions for a
wireless network. The AC may also provide centralized bridging, forwarding, and encryption of user traffic.
Centralization of these functions will enable reduced cost and higher efficiency by applying
the capabilities of network processing silicon to the wireless network, as in wired LANs.

Comments?

Thanks,

Dorothy

On 6/3/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
I created issue 132 to track this change request.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems



> -----Original Message-----
> From: Saravanan Govindan [mailto: Saravanan.Govindan@sg.panasonic.com]
> Sent: Wednesday, May 24, 2006 6:01 PM
> To: capwap
> Subject: [Capwap] Clarification of protocol goals
>
> All,
>
> One of the goals stated in Section 1.1 "Goals" is;
>
> "1. To centralize the bridging, forwarding, authentication
> and policy ...."
>
> Centralized bridging seems to be applicable to Split MAC
> alone. In the case of CAPWAP being used to manage Local MAC
> WTPs, bridging is not centralized.
>
> I suggest an update to this goal;
>
> "1. To centralize major functions of a wireless network, such
> as configuration, authentication, policy enforcement and in
> some cases, bridging and forwarding. "
>
> Comments?
>
> Saravanan
>
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_66601_31222376.1150327391758-- --===============0834459300== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0834459300==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 14 19:36:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqeux-0003Rs-3j for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 19:36:59 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqeuv-0003Vf-MC for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 19:36:59 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8DDFF430125 for ; Wed, 14 Jun 2006 16:36:56 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E918D43006C for ; Wed, 14 Jun 2006 16:36:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D2F5A144800A for ; Wed, 14 Jun 2006 16:36:36 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 34644144800C for ; Wed, 14 Jun 2006 16:36:34 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5ENaXpB025861; Wed, 14 Jun 2006 16:36:33 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5ENaXd1025855; Wed, 14 Jun 2006 16:36:33 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 14 Jun 2006 16:36:33 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Dorothy Stanley In-Reply-To: <5bfe7a820606141604h6c56ea2cxabe49f4b9ff19ab4@mail.gmail.com> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] CERT issues in CAPWAP-01 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 HI, Looks like Charles has been lots of good work. Thanks Charles! Two small, but important issues are: 1) It should be OK for the clock on a WTP to be "wacky", due to having no battery backed up clock, the battery going bad, the clock never set properly. On the other hand, an AC's clock should be set pretty accurately. I't not sure that the recommendations support this scenario. In general, want to support: 0) WTPs with no management interface (other than CAPWAP) 1) first time use of WTP after being manufactured 2) continued use of WTP after long time operation 3) continued use in short term deployments (such as WiFi network used by a Circus that moves from town to town (setting up and tearing down for for each move), or for the WiFi network used at conferences (such as the IETF). 2) The new text suggests the common name in the format "01:23:45:67:89:ab@DOMAIN.NET" for WTPs. And implies that "DOMAIN.NET" is the "administrative domain". To me, "administrative domain" implies the user of the WTP. But, I believe that the WTP manufacturer must be required to generate a CERT (and the WTP should come "preloaded" with the CERT), and the user of the WTP should not have to create the WTP CERT. (By the way, not sure how long the CERT should be valid.) Thus, I see no need or desire for "@DOMAIN.NET" added to the common name, and suggest that it be removed. (Also, I think that we have now a new requirement to be able via CAPWAP to replace the WTP's CERT with another, and may be to add CA CERTs for the AC's CERT chain. Also, what is the min depth that a WTP should support?) On Wed, 14 Jun 2006, Dorothy Stanley wrote: > David, > > Charles had forwarded the text below. Does this text address your concerns? > This is included as part of Issue 2. I thought I sent it to the > list, but evidently not. > > Dorothy > Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 14 20:04:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqfLH-0000Pm-O0 for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 20:04:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqfLG-0006wt-BO for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 20:04:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 065A443012C for ; Wed, 14 Jun 2006 17:04:10 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 28DD643006C for ; Wed, 14 Jun 2006 17:03:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 105C71448035 for ; Wed, 14 Jun 2006 17:03:49 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 842ED144802C for ; Wed, 14 Jun 2006 17:03:47 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5F03l59001916 for ; Wed, 14 Jun 2006 17:03:47 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5F03k1j001912 for ; Wed, 14 Jun 2006 17:03:47 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 14 Jun 2006 17:03:46 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [Capwap] VLAN name in (section 4.4.8)Add Mobile Station X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb HI, The message element (4.4.8)Add Modile Station has subfield "VLAN name". However, there are no CAPWAP messages or message elements for VLAN names on a WTP to be managed by the the AC. (A value for a VLAN Name is only approapriate for a localMAC WTP.) Managed means to find out the list of the VLAN names, create VLANs and apply attributes, modify VLAN attributes, and delete VLANs. The attributes include the VLAN name, and ports:tag pairs in the VLAN. (By the way, this is sort of an expansion of CAPWAP, but it is the price to pay to support localMAC.) For example, consider a localMAC WTP with 4 802.3 ports. It could have the following configuration: VLAN RED - members: port 1:untagged, port 2:tag 23, port 4:tag 56 VLAN GREEN - members: port 1:tag 96, port 2:tag 103 VLAN YELLOW - members: port 1:tag 200, port 4:untagged (Port 3 is not a member of any VLAN) This is not simple, esspecially since there may be restrictions, such as 1) all ports in a VLAN must use the same tag, or 2) a port can be either a TRUNK port or a feeder port and feeder ports are untagged, and the VLANs on the trunk port must be all tagged. (I've seen many different sets of limitations.) I'm not sure what to suggest, other than to drop support for localMAC WTPs (only joking). Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 14 20:18:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqfZ6-0000CT-VV for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 20:18:28 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqfZ5-00081U-EF for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 20:18:28 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9F8084300D9 for ; Wed, 14 Jun 2006 17:18:26 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 42D1843006D for ; Wed, 14 Jun 2006 17:17:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5209C39810B for ; Wed, 14 Jun 2006 17:17:54 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [216.148.227.153]) by zoidberg.tigertech.net (Postfix) with ESMTP id 64EB73980FE for ; Wed, 14 Jun 2006 17:17:52 -0700 (PDT) Received: from [192.168.0.3] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (rwcrmhc13) with ESMTP id <20060615001750m1300g1vrge>; Thu, 15 Jun 2006 00:17:51 +0000 Message-ID: <4490A6DE.60404@cs.umd.edu> Date: Wed, 14 Jun 2006 20:16:30 -0400 From: Charles Clancy User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David T. Perkins" References: In-Reply-To: X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] CERT issues in CAPWAP-01 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 David, If anything, I think our clock text is too specific. Enumerating all the possible ways a WTP clock could be updated is out of scope, since it does not affect the CAPWAP protocol directly, and can be implementation specific. Since it affects overall security, addressed it (but not trying to solve it) in the "security recommendations" section is appropriate. I propose replacing the clock paragraph with: Proper validation of certificates typically requires checking to ensure the certificate has not yet expired. If devices have a real-time clock, they SHOULD verify the certificate validity dates. If no real-time clock is available, the device SHOULD make a best-effort attempt to validate the certificate validity dates through other means. Failure to check a certificate's temporal validity can make a device vulnerable to man-in-the-middle attacks launched using compromised, expired certificates, and therefore devices should make every effort to perform this validation. With regard to your second point, there are several ways to do WTP and AC authorization. The EKU field authorizes a device to act as a WTP or an AC, but not in any particular administrative domain. Without including a domain, I could go out and buy any WTP from the same vendor and join it to an AC. To solve this, SSH-style key caching could be used on the WTP to save the AC credentials, and ACs would have to maintain an ACL with MACs of all authorized WTPs. If this is easier than provisioning properly signed certs, then I'd feel comfortable removing the @DOMAIN.NET. Remember, this section is just specifying security *recommendations*, not absolutes. Maybe we should address both approaches, specifying how to use them securely? -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy David T. Perkins wrote: > HI, > > Looks like Charles has been lots of good work. > Thanks Charles! > > Two small, but important issues are: > 1) It should be OK for the clock on a WTP to be "wacky", > due to having no battery backed up clock, the battery > going bad, the clock never set properly. On the other > hand, an AC's clock should be set pretty accurately. > I't not sure that the recommendations support this > scenario. In general, want to support: > 0) WTPs with no management interface (other than CAPWAP) > 1) first time use of WTP after being manufactured > 2) continued use of WTP after long time operation > 3) continued use in short term deployments (such > as WiFi network used by a Circus that moves from > town to town (setting up and tearing down for > for each move), or for the WiFi network used > at conferences (such as the IETF). > 2) The new text suggests the common name in the format > "01:23:45:67:89:ab@DOMAIN.NET" for WTPs. And implies > that "DOMAIN.NET" is the "administrative domain". > To me, "administrative domain" implies the user > of the WTP. But, I believe that the WTP manufacturer > must be required to generate a CERT (and the WTP > should come "preloaded" with the CERT), and the user > of the WTP should not have to create the WTP CERT. > (By the way, not sure how long the CERT should be > valid.) Thus, I see no need or desire for > "@DOMAIN.NET" added to the common name, and suggest > that it be removed. (Also, I think that we have > now a new requirement to be able via CAPWAP to > replace the WTP's CERT with another, and may be > to add CA CERTs for the AC's CERT chain. Also, > what is the min depth that a WTP should support?) > > On Wed, 14 Jun 2006, Dorothy Stanley wrote: > >>David, >> >>Charles had forwarded the text below. Does this text address your concerns? >>This is included as part of Issue 2. I thought I sent it to the >>list, but evidently not. >> >>Dorothy >> > > > > Regards, > /david t. perkins > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 14 20:23:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqfe3-0003yP-3f for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 20:23:35 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqfe1-0008AL-J0 for capwap-archive@lists.ietf.org; Wed, 14 Jun 2006 20:23:35 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3D6BD430127 for ; Wed, 14 Jun 2006 17:23:33 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 05A2C43006C for ; Wed, 14 Jun 2006 17:23:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E9AF6144801A for ; Wed, 14 Jun 2006 17:23:04 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by hermes.tigertech.net (Postfix) with ESMTP id E9BA8144800A for ; Wed, 14 Jun 2006 17:23:01 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x31so168627pye for ; Wed, 14 Jun 2006 17:23:01 -0700 (PDT) Received: by 10.35.89.10 with SMTP id r10mr1979324pyl; Wed, 14 Jun 2006 17:23:00 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Wed, 14 Jun 2006 17:23:00 -0700 (PDT) Message-ID: <26140d940606141723y2b76b65fs91a1f29a043f3f86@mail.gmail.com> Date: Wed, 14 Jun 2006 20:23:00 -0400 From: "Michael Montemurro" To: "David T. Perkins" In-Reply-To: MIME-Version: 1.0 References: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] VLAN name in (section 4.4.8)Add Mobile Station X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1730596946==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --===============1730596946== Content-Type: multipart/alternative; boundary="----=_Part_14802_13408765.1150330980918" ------=_Part_14802_13408765.1150330980918 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline David, I created issue 140 to track this. Cheers, Mike On 6/14/06, David T. Perkins wrote: > > HI, > > The message element (4.4.8)Add Modile Station has subfield > "VLAN name". However, there are no CAPWAP messages or > message elements for VLAN names on a WTP to be managed > by the the AC. (A value for a VLAN Name is only approapriate > for a localMAC WTP.) Managed means to find out the list > of the VLAN names, create VLANs and apply attributes, > modify VLAN attributes, and delete VLANs. The attributes > include the VLAN name, and ports:tag pairs > in the VLAN. (By the way, this is sort of an expansion > of CAPWAP, but it is the price to pay to support localMAC.) > > For example, consider a localMAC WTP with 4 802.3 ports. > It could have the following configuration: > > VLAN RED - members: port 1:untagged, port 2:tag 23, > port 4:tag 56 > VLAN GREEN - members: port 1:tag 96, port 2:tag 103 > VLAN YELLOW - members: port 1:tag 200, port 4:untagged > (Port 3 is not a member of any VLAN) > > This is not simple, esspecially since there may be restrictions, > such as 1) all ports in a VLAN must use the same tag, or > 2) a port can be either a TRUNK port or a feeder port and > feeder ports are untagged, and the VLANs on the trunk > port must be all tagged. (I've seen many different > sets of limitations.) > > I'm not sure what to suggest, other than to drop support > for localMAC WTPs (only joking). > > Regards, > /david t. perkins > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_14802_13408765.1150330980918 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
David,
 
I created issue 140 to track this.
 
Cheers,
 
Mike

 
On 6/14/06, David T. Perkins <dperkins@dsperkins.com> wrote:
HI,

The message element (4.4.8)Add Modile Station has subfield
"VLAN name". However, there are no CAPWAP messages or
message elements for VLAN names on a WTP to be managed
by the the AC. (A value for a VLAN Name is only approapriate
for a localMAC WTP.) Managed means to find out the list
of the VLAN names, create VLANs and apply attributes,
modify VLAN attributes, and delete VLANs. The attributes
include the VLAN name, and ports:tag pairs
in the VLAN. (By the way, this is sort of an expansion
of CAPWAP, but it is the price to pay to support localMAC.)

For example, consider a localMAC WTP with 4 802.3 ports.
It could have the following configuration:

VLAN RED - members: port 1:untagged, port 2:tag 23,
                   port 4:tag 56
VLAN GREEN - members: port 1:tag 96, port 2:tag 103
VLAN YELLOW - members: port 1:tag 200, port 4:untagged
(Port 3 is not a member of any VLAN)

This is not simple, esspecially since there may be restrictions,
such as 1) all ports in a VLAN must use the same tag, or
2) a port can be either a TRUNK port or a feeder port and
feeder ports are untagged, and the VLANs on the trunk
port must be all tagged. (I've seen many different
sets of limitations.)

I'm not sure what to suggest, other than to drop support
for localMAC WTPs (only joking).

Regards,
/david t. perkins


_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_14802_13408765.1150330980918-- --===============1730596946== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1730596946==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 15 01:25:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqkM8-0000Xv-Nk for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 01:25:24 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqkM4-00060U-PX for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 01:25:24 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id AD1C043010E for ; Wed, 14 Jun 2006 22:25:19 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id DCFA143006D for ; Wed, 14 Jun 2006 22:24:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id CFF1839801A for ; Wed, 14 Jun 2006 22:24:04 -0700 (PDT) Received: from huawei.com (szxga03-in.huawei.com [61.144.161.55]) by zoidberg.tigertech.net (Postfix) with ESMTP id 26B2A398017 for ; Wed, 14 Jun 2006 22:24:01 -0700 (PDT) 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 <0J0V00E8DYZ2T4@szxga03-in.huawei.com> for capwap@frascone.com; Thu, 15 Jun 2006 13:23:26 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0V00D1EYZ1BW@szxga03-in.huawei.com> for capwap@frascone.com; Thu, 15 Jun 2006 13:23:26 +0800 (CST) Received: from dell60 ([10.18.7.113]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0V00CQZZ1HI1@szxml04-in.huawei.com> for capwap@frascone.com; Thu, 15 Jun 2006 13:24:54 +0800 (CST) Date: Thu, 15 Jun 2006 10:44:17 +0530 From: sujay In-reply-to: <5bfe7a820606141539n22827885md3df8b55cf477cbb@mail.gmail.com> To: 'Dorothy Stanley' , 'Michael Montemurro' Message-id: <002f01c6903a$8d7c8a10$7107120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.057 tagged_above=-999 required=7 tests=HTML_30_40, HTML_MESSAGE X-Spam-Level: Cc: sujatha.varadarajan@flextronicssoftware.com, capwap@frascone.com Subject: Re: [Capwap] Proposed Resolution for Issue 78:- no result code for WLAN config command X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0500519832==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 2.6 (++) X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05 This is a multi-part message in MIME format. --===============0500519832== Content-type: multipart/alternative; boundary="Boundary_(ID_rt+Dg16ECqriCqfwM7tG9g)" This is a multi-part message in MIME format. --Boundary_(ID_rt+Dg16ECqriCqfwM7tG9g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thanks Dorothy, It looks fine by me. Regds, Sujay G My Location; http://maps.google.com/maps?ll=14.626109,76.959229 &spn=4.724852,7.525085&t=h&hl=en This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Dorothy Stanley [mailto:dstanley1389@gmail.com] Sent: Thursday, June 15, 2006 4:09 AM To: Michael Montemurro Cc: sujay; sujatha.varadarajan@flextronicssoftware.com; capwap@frascone.com Subject: Proposed Resolution for Issue 78:- no result code for WLAN config command All, Issue 78, copied in the e-mail below raises 2 questions. Proposed resolutions to both questions are provided below. Comments please. Thanks, Dorothy ------------------------------------------------------------------------ --------------------------------------- Issue 78, Part 1: 1. I found that in the CAPWAP specification, the WLAN > configuration > request sent from the AC to the WTP is acked by the WLAN Configuration > Response. This Message does not have any message elements. > And I presume > it is sent irrespective of success / failure of configuration. > > Can we have the Radio Id , WLAN ID and Success Code Message Elements > (tlvs) to be sent as part of WLAN Configure Response ? ?If > not, is there > any other means of finding out if my WLAN Configuration (Add > / Update / > Delete ) succeeded or not? Proposed Resolution to Issue 78 Part 1: Same as (part of) Issue 74, include the Result Code message element as a mandatory message element in the IEEE 802.11 WLAN Configuration Response message. Issue 78 Part 2: > 2. The WTP Radio Information that lists the Radio type and Id is part > of the Discovery Request. It is not sent as part of any Message after > that. But since the AC does not keep any state for a > Discovery Request, > the AC does not remember it. I assume that without knowing the Radio > type, the AC would not be able to configure the WTP. I suggest we add > Radio Type TLV to the Configure Request, to avoid this. Proposed Resolution for Issue 78 Part 2: Add "WTP Radio Information" to the list of message elements that MUST be included in the Configuration Status Message (WTP->AC) On 3/16/06, Michael Montemurro > wrote: I've recorded this issue as a bug. The issue number is 78. Cheers, Mike > -----Original Message----- > From: sujay [mailto:sujayg@huawei.com] > Sent: March 8, 2006 2:11 AM > To: sujatha.varadarajan@flextronicssoftware.com; capwap@frascone.com > Subject: RE: [Capwap] FW: 802.11 Specific - no result code > for WLAN config command > > Sujatha, > The first point you have mentioned could be addressed thus; > > Send WLAN Configuration reponse only when the operation is > successful.Using the sequence number in the request packet > you should be able identify which WLAN configuration request > has failed and thus the Radio ID. WLAN Id etc. > > > Second point; > > (In the expired lwapp-03.txt this message was being sent in the Join > Request Message, > not so in the current.) > > It could be handled in two ways; > 1. the AC should not send the Discovery Response if it is unable to > configure the WTP > With its given WTP radio information, that automatically means the > ClientHello SHOULD > not be expected from the that non-supported WTP. > > 2. It could be added as a part of the 802.11 binding message, IEEE > 802.11 WTP WLAN Radio Configuration, > message another "Radio Type". > > > Any comments? > > Regards, > Sujay > > My Location; > http://maps.google.com/maps?ll=14.626109,76.959229 &spn=4.72485 2,7.525085 > &t=h&hl=en > > > > > Hi, > > 1. I found that in the CAPWAP specification, the WLAN > configuration > request sent from the AC to the WTP is acked by the WLAN Configuration > Response. This Message does not have any message elements. > And I presume > it is sent irrespective of success / failure of configuration. > > Can we have the Radio Id , WLAN ID and Success Code Message Elements > (tlvs) to be sent as part of WLAN Configure Response ? ?If > not, is there > any other means of finding out if my WLAN Configuration (Add > / Update / > Delete ) succeeded or not? > > 2. The WTP Radio Information that lists the Radio type and Id is part > of the Discovery Request. It is not sent as part of any Message after > that. But since the AC does not keep any state for a > Discovery Request, > the AC does not remember it. I assume that without knowing the Radio > type, the AC would not be able to configure the WTP. I suggest we add > Radio Type TLV to the Configure Request, to avoid this. > > > > Thanks > > Sujatha V > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --Boundary_(ID_rt+Dg16ECqriCqfwM7tG9g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Message
Thanks Dorothy,
 
It looks fine by me.
 
Regds,
Sujay G
My Location;
http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085&t=h&hl=en


This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
-----Original Message-----
From: Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Thursday, June 15, 2006 4:09 AM
To: Michael Montemurro
Cc: sujay; sujatha.varadarajan@flextronicssoftware.com; capwap@frascone.com
Subject: Proposed Resolution for Issue 78:- no result code for WLAN config command

All,

Issue 78, copied in the e-mail below raises 2 questions.
Proposed resolutions to both questions are provided below.
Comments please.

Thanks,

Dorothy
---------------------------------------------------------------------------------------------------------------
Issue 78, Part 1:

 1.  I found that in the CAPWAP specification, the WLAN
> configuration
> request sent from the AC to the WTP is acked by the WLAN Configuration
> Response. This Message does not have any message elements.
> And I presume
> it is sent irrespective of success / failure of configuration.
>
>  Can we have the Radio Id , WLAN ID and Success Code Message Elements
> (tlvs) to be sent as part of WLAN Configure Response ? ?If
> not, is there
> any other means of finding out if my WLAN Configuration (Add
> / Update /
> Delete ) succeeded or not?

Proposed Resolution to Issue 78 Part 1:
Same as (part of)  Issue 74, include the Result Code message element
as a mandatory message element in the IEEE 802.11 WLAN
Configuration Response message.

Issue 78 Part 2:

>  2. The WTP Radio Information that lists the Radio type and Id is part
> of the Discovery Request. It is not sent as part of any Message after
> that.  But since the AC does not keep any state for a
> Discovery Request,
> the AC does not remember it. I assume that without knowing the Radio
> type, the AC would not be able to configure the WTP. I suggest we add
> Radio Type TLV to the Configure Request, to avoid this.

Proposed Resolution for Issue 78 Part 2:

Add "WTP Radio Information" to the list of message elements that
MUST be included in the Configuration Status Message (WTP->AC)

On 3/16/06, Michael Montemurro <michael.montemurro@siemens.com > wrote:
I've recorded this issue as a bug. The issue number is 78.

Cheers,

        Mike

> -----Original Message-----
> From: sujay [mailto:sujayg@huawei.com]
> Sent: March 8, 2006 2:11 AM
> To: sujatha.varadarajan@flextronicssoftware.com; capwap@frascone.com
> Subject: RE: [Capwap] FW: 802.11 Specific - no result code
> for WLAN config command
>
> Sujatha,
> The first point you have mentioned could  be addressed thus;
>
> Send WLAN Configuration reponse only when the operation is
> successful.Using the sequence number in the request packet
> you should be able identify which WLAN configuration request
> has failed and thus the Radio ID. WLAN Id etc.
>
>
> Second point;
>
> (In the expired lwapp-03.txt this message was being sent in the Join
> Request Message,
> not so in the current.)
>
> It could be handled in two ways;
> 1. the AC should not send the Discovery Response if it is unable to
> configure the WTP
> With its given WTP radio information, that automatically means the
> ClientHello SHOULD
> not be expected from the that non-supported WTP.
>
> 2. It could be added as a part of the 802.11 binding message, IEEE
> 802.11 WTP WLAN Radio Configuration,
> message another "Radio Type".
>
>
> Any comments?
>
> Regards,
> Sujay
>
> My Location;
> http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.72485
2,7.525085
> &t=h&hl=en
>
>
>
>
>  Hi,
>
>    1.  I found that in the CAPWAP specification, the WLAN
> configuration
> request sent from the AC to the WTP is acked by the WLAN Configuration
> Response. This Message does not have any message elements.
> And I presume
> it is sent irrespective of success / failure of configuration.
>
>  Can we have the Radio Id , WLAN ID and Success Code Message Elements
> (tlvs) to be sent as part of WLAN Configure Response ? ?If
> not, is there
> any other means of finding out if my WLAN Configuration (Add
> / Update /
> Delete ) succeeded or not?
>
>  2. The WTP Radio Information that lists the Radio type and Id is part
> of the Discovery Request. It is not sent as part of any Message after
> that.  But since the AC does not keep any state for a
> Discovery Request,
> the AC does not remember it. I assume that without knowing the Radio
> type, the AC would not be able to configure the WTP. I suggest we add
> Radio Type TLV to the Configure Request, to avoid this.
>
>
>
> Thanks
>
> Sujatha V
>
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

--Boundary_(ID_rt+Dg16ECqriCqfwM7tG9g)-- --===============0500519832== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0500519832==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 15 01:49:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqkiR-0002Vf-AX for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 01:48:27 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqkZC-0006VC-5Y for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 01:38:55 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C98B54301A5 for ; Wed, 14 Jun 2006 22:38:53 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E507F4300EA for ; Wed, 14 Jun 2006 22:38:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D039B39801A for ; Wed, 14 Jun 2006 22:38:22 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E4F2E398017 for ; Wed, 14 Jun 2006 22:38:18 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5F5cHnh000666; Wed, 14 Jun 2006 22:38:17 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5F5cGnK000662; Wed, 14 Jun 2006 22:38:17 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 14 Jun 2006 22:38:16 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Charles Clancy In-Reply-To: <4490A6DE.60404@cs.umd.edu> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] CERT issues in CAPWAP-01 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 2.5 (++) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e HI, Thank you for responding to my issues. It seems to me that we are not yet looking at the same problem. So let me try again. What I was trying to point out is that there are a few VERY common scenarios (use cases) where the clock on a WTP can be totally wrong. If a WTP is coded so that it will not continue and communicate with an AC when it thinks the AC's CERTs are outside the time window, (or it thinks that it's on CERTs are outside the time window) then you will have a useless device (a brick). In many (maybe most) deployments, it costs more to physically touch a WTP than the equipment cost of the WTP. At the Dallas IETF, there were APs that were "somewhere" in the ceiling not doing any useful work, but sending out beacons with their config'ed SSID because it was too expensive to find them, and take them down. It was more cost effective to just new new APs. For an AC, it's clock must be accurate, and it would be OK for it to not proceed if it believes its CERTs are outside their time window. But, the CAPWAP protocol should allow an AC to establish a session with a WTP that has a WACKY clock (and even a CERT that has expired). NOTE: the AC clock must be pretty accurate for management (such as logs) to be useful (or work). The CAPWAP protocol has support to set the WTP's clock. But it doesn't have support to update a CERT in a WTP. It seems like this is needed. Assume the clocks are OK, now lets talk about WTP CERT validation by the AC. This wasn't addressed, but I believe that WTP CERTs MUST be signed by the WTP manufacturer, or one of the WELL KNOWN certification authorities. Adding the CA CERTs in an AC is done through means outside of CAPWAP (such as via the CLI on the AC). Thus, WTP CERTs MUST NOT be selfsigned. And, I believe that the WTPs CERTs should have for the common name the ASCII of MAC address, or other unique ID of the WTP (and this must be provided in the Join Request message). I didn't understand in the previous text, nor in your message below why the common name would have a suffix of "@DOMAIN.NET". Now lets talk about AC CERT validation by the WTP. The CERT for the AC can be created by the AC manufacturer, the user, or 3rd party. It could be selfsigned, or have a chain from the manufacturer or a WELL KNOWN CA. Given this, it will be difficult for a WTP to verify a AC CERT, at least the first time. This is just a "leap of faith" if the CERT cannot be verified. After this first connection, the AC through the CAPWAP protocol could configure the WTP with the needed CA CERT(s). However, there may be some WTPs that have no additional persistent storage for these CERTs. So, it appears to me that the following changes are required to CAPWAP-01: 1) specify that WTP CERTs cannot be selfsigned, and MUST have a common name of the ASCII of the MAC address (or other unique ID, such as serial number) 2) The Join Request must be updated to include the common name as a message element 3) specify that WTPs must continue even when it believes its CERT or the AC's CERT is outside the time window 4) the CAPWAP protocol must have a new message to install an updated CERT for the WTP. 5) the CAPWAP protocol must have a new message to install a CA CERT. Hope this helps. And if I totally misunderstood you, then I apologize, and ask you to provide some examples. Regards, /david t. perkins On Wed, 14 Jun 2006, Charles Clancy wrote: > David, > > If anything, I think our clock text is too specific. Enumerating all > the possible ways a WTP clock could be updated is out of scope, since it > does not affect the CAPWAP protocol directly, and can be implementation > specific. Since it affects overall security, addressed it (but not > trying to solve it) in the "security recommendations" section is > appropriate. I propose replacing the clock paragraph with: > > Proper validation of certificates typically requires checking to > ensure the certificate has not yet expired. If devices have a > real-time clock, they SHOULD verify the certificate validity dates. > If no real-time clock is available, the device SHOULD make a > best-effort attempt to validate the certificate validity dates > through other means. Failure to check a certificate's temporal > validity can make a device vulnerable to man-in-the-middle attacks > launched using compromised, expired certificates, and therefore > devices should make every effort to perform this validation. > > With regard to your second point, there are several ways to do WTP and > AC authorization. The EKU field authorizes a device to act as a WTP or > an AC, but not in any particular administrative domain. Without > including a domain, I could go out and buy any WTP from the same vendor > and join it to an AC. To solve this, SSH-style key caching could be > used on the WTP to save the AC credentials, and ACs would have to > maintain an ACL with MACs of all authorized WTPs. If this is easier > than provisioning properly signed certs, then I'd feel comfortable > removing the @DOMAIN.NET. Remember, this section is just specifying > security *recommendations*, not absolutes. Maybe we should address both > approaches, specifying how to use them securely? > > -- > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > David T. Perkins wrote: > > HI, > > > > Looks like Charles has been lots of good work. > > Thanks Charles! > > > > Two small, but important issues are: > > 1) It should be OK for the clock on a WTP to be "wacky", > > due to having no battery backed up clock, the battery > > going bad, the clock never set properly. On the other > > hand, an AC's clock should be set pretty accurately. > > I't not sure that the recommendations support this > > scenario. In general, want to support: > > 0) WTPs with no management interface (other than CAPWAP) > > 1) first time use of WTP after being manufactured > > 2) continued use of WTP after long time operation > > 3) continued use in short term deployments (such > > as WiFi network used by a Circus that moves from > > town to town (setting up and tearing down for > > for each move), or for the WiFi network used > > at conferences (such as the IETF). > > 2) The new text suggests the common name in the format > > "01:23:45:67:89:ab@DOMAIN.NET" for WTPs. And implies > > that "DOMAIN.NET" is the "administrative domain". > > To me, "administrative domain" implies the user > > of the WTP. But, I believe that the WTP manufacturer > > must be required to generate a CERT (and the WTP > > should come "preloaded" with the CERT), and the user > > of the WTP should not have to create the WTP CERT. > > (By the way, not sure how long the CERT should be > > valid.) Thus, I see no need or desire for > > "@DOMAIN.NET" added to the common name, and suggest > > that it be removed. (Also, I think that we have > > now a new requirement to be able via CAPWAP to > > replace the WTP's CERT with another, and may be > > to add CA CERTs for the AC's CERT chain. Also, > > what is the min depth that a WTP should support?) > > > > On Wed, 14 Jun 2006, Dorothy Stanley wrote: > > > >>David, > >> > >>Charles had forwarded the text below. Does this text address your concerns? > >>This is included as part of Issue 2. I thought I sent it to the > >>list, but evidently not. > >> > >>Dorothy > >> > > > > > > > > Regards, > > /david t. perkins > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 15 02:12:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fql64-0006if-MU for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 02:12:52 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fql5I-00082r-RF for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 02:12:06 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 38BB04301B8 for ; Wed, 14 Jun 2006 23:12:04 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B2CF04300FE for ; Wed, 14 Jun 2006 23:11:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9DF05144801A for ; Wed, 14 Jun 2006 23:11:38 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2079B144800A for ; Wed, 14 Jun 2006 23:11:35 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5F6BZBa010089 for ; Wed, 14 Jun 2006 23:11:35 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5F6BZu3010085 for ; Wed, 14 Jun 2006 23:11:35 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 14 Jun 2006 23:11:35 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [Capwap] Consistent range for radio ID and WLAN ID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 2.5 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 HI, I've seen several places where the range of the Radio ID and WLAN ID is inconsistant. In section 4.1, in the transport header, the RID is 5 bits (a range of 0-31), but in section 4.4.34, the max radios and radios in use is a 8 bits (range of 0-255). Also, in sections 4.4.8, 4.4.11, 4.4.14, 4.4.15, 4.4.17, 4.4.28, 4.4.39, 11.10.1, 11.10.2, 11.10.5, 11.10.6, 11.10.8, 11.10.9, 11.10.10, 11.10.11, 11.10.13, 11.10.14, 11.10.15, 11.10.16, 11.10.17, 11.10.18, 11.10.19, 11.10.20, 11.10.21, 11.10.22, 11.10.23, and 11.10.24 the radio ID field is 8 bits. In section 11.4, WLAN is a bit map of length 16 (thus a range of 0-15). However, in the following sections, WLAN ID is 8 bits (a range of 0-255): 11.10.1, 11.10.9, 11.10.10, and 11.10.11. And in sections 11.10.5 and 11.10.21 the WLAN ID is 16 bits (0-65535) Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 15 02:14:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fql7D-0006zc-Jn for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 02:14:03 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fql7C-0008E4-9r for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 02:14:03 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id EEB7D4301F7 for ; Wed, 14 Jun 2006 23:14:01 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id CAB74430104 for ; Wed, 14 Jun 2006 23:13:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C01BF398022 for ; Wed, 14 Jun 2006 23:13:39 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2C65D398020 for ; Wed, 14 Jun 2006 23:13:36 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5F6DatL010573 for ; Wed, 14 Jun 2006 23:13:36 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5F6DaMR010570 for ; Wed, 14 Jun 2006 23:13:36 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 14 Jun 2006 23:13:36 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [Capwap] Missing Radio ID and WLAN ID subfields X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 2.5 (++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c HI, The information elements in section 11.10.3 and 11.10.7 MUST have the Radio ID and WLAN ID subfields added. Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 15 04:08:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqmtb-0006OQ-1l for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 04:08:07 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqmtZ-0005fC-Ht for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 04:08:07 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BE85C430140 for ; Thu, 15 Jun 2006 01:08:04 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id EF20F430064 for ; Thu, 15 Jun 2006 01:07:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D867139803A for ; Thu, 15 Jun 2006 01:07:20 -0700 (PDT) X-Greylist-Status: Sender first seen 3 days 19:20:57 ago Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by zoidberg.tigertech.net (Postfix) with ESMTP id A6B0E398031 for ; Thu, 15 Jun 2006 01:07:17 -0700 (PDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5F83mEm000787 for ; Thu, 15 Jun 2006 04:03:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Jun 2006 11:07:14 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Process in CAPWAP Thread-Index: AcaMIv6al2wcs/e8TvuwY5RhhPusZAELwwbQ From: "Romascanu, Dan (Dan)" To: "Bob O'Hara (boohara)" X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Process in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Hi Bob, The ADs looked in the issue that you raised related to the consensus on the= Mux vs Multiport issue # 115. We analyzed the traffic on the list and we a= lso discussed with the WG chairs. Our opinion is that although the chairs = suggested a solution for consensus the WG did not agree with it. Despite th= e chairs and WG efforts to reach a timely conclusion according to the curre= nt WG schedules, more work needs to be done to reach at minimum rough conse= nsus on this point. The chairs have the responsibility to drive the consensus process, and the = criteria for reaching the decisions should be clearly explained. = In order to overcome the dead-end we recommend to the WG to bring in the di= scussion opinions about the consensus criteria (QoS, scalability, compatibi= lity with routing and switching infrastructure), their priority and recomme= ndations from external experts that were less involved in the discussions u= ntil now, for example by consulting the Routing Area. We offer to approach= the Routing Area ADs to have an expert designated to this purpose. We recommend that the WG continues its work and capitalizes on the effort m= ade until now to close a large number of open issues in the next version of= the draft. This issue together with the other open issues should be brough= t for discussion on the list and in Montreal, and we hope that a conclusion= based on rough consensus can be reached soon after the Montreal meeting, s= o that the impact on the Working Group schedules be minimized. David and Dan = = > -----Original Message----- > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] = > Sent: Saturday, June 10, 2006 3:16 AM > To: Romascanu, Dan (Dan) > Cc: capwap > Subject: Process in CAPWAP > = > Dan, > = > A few days ago Dorothy Gellert sent an email to the working = > group on behalf of the chairs, announcing a decision on a = > technical issue in the working group. Specifically, she = > declared that the chairs decided the discussion of the use of = > a mux header vs. the use of separate ports for the = > differentiation of control and data traffic in the protocol = > to be over. She also indicated that the chairs had chosen = > the mux header as the method to be used in the protocol and = > set a deadline of today for closing the issue. > = > As soon as I read her email, I replied and asked that she = > document the process that the chairs used to arrive at their = > decision. My background is in the IEEE, where the process is = > clear, transparent, and open to all participants. CAPWAP is = > my first IETF working group. My understanding of = > decision-making in IETF is that it is based on rough = > consensus and that the chairs have responsibility to = > determine that consensus. With that understanding, I asked = > Dorothy to document what the chairs used as evidence of rough = > consensus on that issue, since I see evidence in the postings = > to the list that there is more support for separate ports = > than there is for the mux header. At a minimum, there is no = > consensus on this issue. > = > Since sending that email two days ago, neither chair has = > responded. I find that quite disturbing for several reasons. = > = > First, this is an issue that has been debated extensively = > (and still is being debated, regardless of the pronouncement = > from the chairs). The working group deserves to know how = > this technical issue was resolved. = > = > Second, standardization by fiat of the chair does not seem to = > be in keeping with the open process requirements of the IETF. = > Perhaps I am being na=EFve, but I don't believe there is a = > feted inner core (FIC) that is actually developing all the = > IETF standards. = > = > Third, the time allowed for any response to the email was = > only three days. This is an absurdly short time, given that = > it is the start of the summer vacation period in the northern = > hemisphere. It is quite possible that many participants will = > not even see her email until after the deadline expires. = > = > Finally, if there is no consensus on the issue, the chairs = > are expressing an engineering opinion and should be required = > to justify that opinion just as any other member of the = > working group. I don't believe that the IETF anoints the = > chairs of any working group as expert and able to make = > technical decisions for the working group. > = > I would appreciate your thoughts, as the AD, and response on = > these items. > = > Best regards, > -Bob > = > Bob O'Hara > = _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 15 07:54:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqqQr-0002lM-OZ for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 07:54:41 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqqQq-0002LH-4D for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 07:54:41 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4447E43013E for ; Thu, 15 Jun 2006 04:54:39 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 26A8F430059 for ; Thu, 15 Jun 2006 04:54:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0E44239801F for ; Thu, 15 Jun 2006 04:54:15 -0700 (PDT) Received: from rwcrmhc15.comcast.net (rwcrmhc15.comcast.net [204.127.192.85]) by zoidberg.tigertech.net (Postfix) with ESMTP id 40F55398031 for ; Thu, 15 Jun 2006 04:54:11 -0700 (PDT) Received: from [192.168.0.3] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (rwcrmhc15) with ESMTP id <20060615115410m15003f9kee>; Thu, 15 Jun 2006 11:54:11 +0000 Message-ID: <449149E8.5040109@cs.umd.edu> Date: Thu, 15 Jun 2006 07:52:08 -0400 From: Charles Clancy User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David T. Perkins" References: In-Reply-To: X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] CERT issues in CAPWAP-01 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d There are two distinct problems: authentication and authorization. Validating a cert through a CA and checking its timestamps all provide authentication, which proves the device really is the device it claims to be. The EKU and administrative domain provide authorization, which proves that the device can operate on a particular network. Note that authorization could also be accomplished with ACLs. > What I was trying to point out is that there are a few > VERY common scenarios (use cases) where the clock on > a WTP can be totally wrong. If a WTP is coded so that > it will not continue and communicate with an AC when > it thinks the AC's CERTs are outside the time window, > (or it thinks that it's on CERTs are outside the time > window) then you will have a useless device (a brick). I understand. My point is that figuring out how to deal with this should be left up to the implementor. In the security recommendations section, we can say "if you don't check the dates, you could be in trouble". The same goes for CRLs. There are plenty of ways a WTP can fix its clock. NTP, clock from the AC, whatever. None of them guarantee security, as they are all unauthenticated. How does a WTP know when to accept an expired AC cert, and when not to? To guarantee non-brick-age, it would need to always accept an expired cert, and then update its clock with the AC (who could be an attacker feeding it a date that matches its cert). Since there's no clear solution, my advice is to leave it as "implementor beware". > I believe that WTP CERTs MUST be signed by the > WTP manufacturer, or one of the WELL KNOWN certification > authorities. Adding the CA CERTs in an AC is done through > means outside of CAPWAP (such as via the CLI > on the AC). Thus, WTP CERTs MUST NOT be selfsigned. If the manufacturer is preloading certs on to these devices, why wouldn't it also be preloading its own CA root cert? Well known CAs are just that -- well known. Consequenty they should all be preloaded too. I don't see why any device would ever need new CA certs loaded onto it, unless the deployer was generating new certs for every device, using a local CA root. Root certs can expire, so being able to update them isn't necessarily a bad thing. > This wasn't addressed, but > And, I believe that the WTPs CERTs should have > for the common name the ASCII of MAC address, > or other unique ID of the WTP (and this must be provided > in the Join Request message). I didn't understand > in the previous text, nor in your message below > why the common name would have a suffix of > "@DOMAIN.NET". The domain in the CN is used for authorization. It prevents me from going to the store, buying a WTP with preloaded manufacturer cert, plugging it into your network, and having your AC accept my WTP. It also prevents me from going to the store, buying an AC, plugging it into your network, and then having all your WTPs "discover" it instead of your AC, and hijacking all your WTPs. Like I said, there are other ways to do authorization. One could use ACLs instead, where each AC and WTP is programmed with a list of other ACs and WTPs it's authorized to communicate with. This list could be built somewhat automatically if implementors had a provisioning mode where devices would assume every cert it sees is authorized, and could use them to build ACLs (similar to SSH-style key caching). I suspect different vendors will want to do it in different ways. > Now lets talk about AC CERT validation by the WTP. > The CERT for the AC can be created by the AC > manufacturer, the user, or 3rd party. It could > be selfsigned, or have a chain from the manufacturer > or a WELL KNOWN CA. Given this, it will be difficult > for a WTP to verify a AC CERT, at least the first > time. If the WTP is preloaded with all the appropriate well-known and manufacturer CA roots, then it should be possible to validate the cert. If not, you need a provisioing period, like the one I mentioned, where all certs are automatically accepted and cached. > After this first connection, > the AC through the CAPWAP protocol could configure > the WTP with the needed CA CERT(s). However, there > may be some WTPs that have no additional persistent > storage for these CERTs. I argue that there could be many "first" connections. What happens if you add or replace ACs in the network? You still want your WTPs to talk to these new ACs. But, you don't want your WTP to automatically accept any cert it hasn't seen before -- otherwise an attacker could come in and fire up their AC. > So, it appears to me that the following changes > are required to CAPWAP-01: > 1) specify that WTP CERTs cannot be selfsigned, > and MUST have a common name of the ASCII > of the MAC address (or other unique ID, > such as serial number) Seems reasonable. However, I still think adding an administrative domain to the CN should be an option for those that don't want to maintain ACLs. > 2) The Join Request must be updated to include > the common name as a message element Isn't the BSSID already there? Shouldn't that match the MAC? > 3) specify that WTPs must continue even when it > believes its CERT or the AC's CERT is outside > the time window That seems equivalent to mandating WTPs never validate timestamps on any AC certs. What if the WTP has a real-time clock and actually CAN distinguish between good and bad certs? > 4) the CAPWAP protocol must have a new message > to install an updated CERT for the WTP. Seems reasonable. > 5) the CAPWAP protocol must have a new message > to install a CA CERT. Seems reasonable. Overall, my opinion is that certificate validation is a challenging problem. It would probably take 40+ pages of text to address everything in detail, and that's not a quagmire I personally want to get into. As a result, my advice is to put some broad guidance in the security considerations section highlighting the major issues, and leave it up to the implementors. Other than the CN specification, it won't affect interoperability. Vendors should figure out something that works for them, in their customers' environments. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 15 09:17:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqrj6-0006aH-Rr for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 09:17:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqrj6-0003fP-Pa for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 09:17:36 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqrVC-0007HY-Ok for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 09:03:17 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 44E7A430108 for ; Thu, 15 Jun 2006 06:03:14 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id ED549430059 for ; Thu, 15 Jun 2006 06:02:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id DC69F398062 for ; Thu, 15 Jun 2006 06:02:53 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.151]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0FECB398010 for ; Thu, 15 Jun 2006 06:02:50 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (rwcrmhc11) with ESMTP id <20060615130250m1100b1ap8e>; Thu, 15 Jun 2006 13:02:50 +0000 Message-ID: <44915A7A.6010707@hyperthought.com> Date: Thu, 15 Jun 2006 06:02:50 -0700 From: Scott G Kelly User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "David T. Perkins" References: In-Reply-To: X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] CERT issues in CAPWAP-01 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Hi David, Like I said previously, I agree with pretty much everything Charles said, so I won't re-iterate his points, and will instead simply add a few comments below: David T. Perkins wrote: > HI, > > Thank you for responding to my issues. It seems to me that > we are not yet looking at the same problem. So let me try > again. > > What I was trying to point out is that there are a few > VERY common scenarios (use cases) where the clock on > a WTP can be totally wrong. If a WTP is coded so that > it will not continue and communicate with an AC when > it thinks the AC's CERTs are outside the time window, > (or it thinks that it's on CERTs are outside the time > window) then you will have a useless device (a brick). > In many (maybe most) deployments, it costs more to > physically touch a WTP than the equipment cost of the WTP. > At the Dallas IETF, there were APs that were "somewhere" > in the ceiling not doing any useful work, but sending > out beacons with their config'ed SSID because it was > too expensive to find them, and take them down. It > was more cost effective to just new new APs. > > For an AC, it's clock must be accurate, > and it would be OK for it to not proceed if it believes > its CERTs are outside their time window. But, the > CAPWAP protocol should allow an AC to establish > a session with a WTP that has a WACKY clock (and > even a CERT that has expired). NOTE: the AC clock > must be pretty accurate for management (such as > logs) to be useful (or work). The CAPWAP protocol has > support to set the WTP's clock. But it doesn't have support > to update a CERT in a WTP. It seems like this is > needed. > > Assume the clocks are OK, now lets talk about WTP > CERT validation by the AC. This wasn't addressed, but > I believe that WTP CERTs MUST be signed by the > WTP manufacturer, or one of the WELL KNOWN certification > authorities. Adding the CA CERTs in an AC is done through > means outside of CAPWAP (such as via the CLI > on the AC). Thus, WTP CERTs MUST NOT be selfsigned. > And, I believe that the WTPs CERTs should have > for the common name the ASCII of MAC address, > or other unique ID of the WTP (and this must be provided > in the Join Request message). I didn't understand > in the previous text, nor in your message below > why the common name would have a suffix of > "@DOMAIN.NET". > > Now lets talk about AC CERT validation by the WTP. > The CERT for the AC can be created by the AC > manufacturer, the user, or 3rd party. It could > be selfsigned, or have a chain from the manufacturer > or a WELL KNOWN CA. Given this, it will be difficult > for a WTP to verify a AC CERT, at least the first > time. This is just a "leap of faith" if the CERT > cannot be verified. After this first connection, > the AC through the CAPWAP protocol could configure > the WTP with the needed CA CERT(s). However, there > may be some WTPs that have no additional persistent > storage for these CERTs. > > So, it appears to me that the following changes > are required to CAPWAP-01: > 1) specify that WTP CERTs cannot be selfsigned, > and MUST have a common name of the ASCII > of the MAC address (or other unique ID, > such as serial number) While we may not think self-signing is a good idea for our typical deployment models, I'm not sure we have to say you MUST NOT do this, but I'll give this some more thought. > 2) The Join Request must be updated to include > the common name as a message element What is your objective with this requirement? > 3) specify that WTPs must continue even when it > believes its CERT or the AC's CERT is outside > the time window Charles addressed this. > 4) the CAPWAP protocol must have a new message > to install an updated CERT for the WTP. > 5) the CAPWAP protocol must have a new message > to install a CA CERT. I agree that we should discuss this, but I'm a little leary of taking on the task of fully specifying every nuance of cert use and mgmt. Remember, the ipsec group spun out a whole new wg to handle this particular problem. It's complicated. What we're trying to do in the base protocol is come up with minimal and sufficient guidelines to get people going. I think cert mgmt and usage could be revisited in detail later, perhaps under a new charter, but that we might want to consciously avoid getting too bogged down in this for rev 1. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 15 10:14:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqsc9-0001SS-Jo for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 10:14:29 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqrO3-0001bY-Kr for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 08:55:51 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqrG2-00073f-Jh for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 08:47:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CBE54430167 for ; Thu, 15 Jun 2006 05:47:32 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id BB586430059 for ; Thu, 15 Jun 2006 05:47:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A4ED7398073 for ; Thu, 15 Jun 2006 05:47:10 -0700 (PDT) X-Greylist-Status: Bypassed (other successful deliveries from server) Received: from rwcrmhc15.comcast.net (unknown [216.148.227.155]) by zoidberg.tigertech.net (Postfix) with ESMTP id EBD63398062 for ; Thu, 15 Jun 2006 05:47:07 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (rwcrmhc15) with ESMTP id <20060615124707m15003brp9e>; Thu, 15 Jun 2006 12:47:07 +0000 Message-ID: <449156CA.8090408@hyperthought.com> Date: Thu, 15 Jun 2006 05:47:06 -0700 From: Scott G Kelly User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "David T. Perkins" References: In-Reply-To: X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] CERT issues in CAPWAP-01 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Hi David, I think I agree with everything Charles said in reply to your concerns, and I won't repeat all of that, but I have a few other comments, one in this email and a few in one of your replies (which I'll handle there): David T. Perkins wrote: > HI, > > Looks like Charles has been lots of good work. > Thanks Charles! > > Two small, but important issues are: > 1) It should be OK for the clock on a WTP to be "wacky", > due to having no battery backed up clock, the battery > going bad, the clock never set properly. On the other > hand, an AC's clock should be set pretty accurately. > I't not sure that the recommendations support this > scenario. In general, want to support: > 0) WTPs with no management interface (other than CAPWAP) > 1) first time use of WTP after being manufactured > 2) continued use of WTP after long time operation > 3) continued use in short term deployments (such > as WiFi network used by a Circus that moves from > town to town (setting up and tearing down for > for each move), or for the WiFi network used > at conferences (such as the IETF). I agree with your concern from an operational perspective, and I think for this reason WTP manufacturers would be well advised to provide an alternative management interface. Many currently provide serial ports for this purpose, though as you suggest, this is sometimes (actually, often) impractical to access. For this reason, it is probably good to provide an ssh-style command line capability for just this purpose, along with associated auditing. We can recommend something in capwap (i.e. that it may not be prudent to rely on capwap as the sole mgmt interface to a WTP), but beyond than that, this begins to feel a bit out of scope. > 2) The new text suggests the common name in the format > "01:23:45:67:89:ab@DOMAIN.NET" for WTPs. And implies > that "DOMAIN.NET" is the "administrative domain". > To me, "administrative domain" implies the user > of the WTP. But, I believe that the WTP manufacturer > must be required to generate a CERT (and the WTP > should come "preloaded" with the CERT), and the user > of the WTP should not have to create the WTP CERT. > (By the way, not sure how long the CERT should be > valid.) Thus, I see no need or desire for > "@DOMAIN.NET" added to the common name, and suggest > that it be removed. (Also, I think that we have > now a new requirement to be able via CAPWAP to > replace the WTP's CERT with another, and may be > to add CA CERTs for the AC's CERT chain. Also, > what is the min depth that a WTP should support?) I agree that an Internet domain is not always a convenient or appropriate identifier, but I think you could replace "DOMAIN.NET" with "DavidTPerkins" if you wanted to. As for WTP manufacturer's pre-loading certs, we cannot realistically impose such requirements on them. Some already do so this, but without a PKI (which includes a trusted 3rd party), secure manufacturing processes, etc. the security of the associated credentials should not be over-estimated. Scott > > On Wed, 14 Jun 2006, Dorothy Stanley wrote: >> David, >> >> Charles had forwarded the text below. Does this text address your concerns? >> This is included as part of Issue 2. I thought I sent it to the >> list, but evidently not. >> >> Dorothy >> > > > Regards, > /david t. perkins > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 15 14:12:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqwKL-0008Ag-Sy for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 14:12:21 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqwKK-0002h8-68 for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 14:12:21 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CF684430103 for ; Thu, 15 Jun 2006 11:12:19 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 5505E430059 for ; Thu, 15 Jun 2006 11:11:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3E4E239801F for ; Thu, 15 Jun 2006 11:11:36 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id 45F12398019 for ; Thu, 15 Jun 2006 11:11:33 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 15 Jun 2006 11:11:33 -0700 X-IronPort-AV: i="4.06,137,1149490800"; d="scan'208"; a="1826382280:sNHT44604788" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k5FIBXf1007330; Thu, 15 Jun 2006 11:11:33 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5FIBXke010010; Thu, 15 Jun 2006 11:11:33 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Jun 2006 11:11:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Jun 2006 11:11:32 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC01A7B2EF@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Process in CAPWAP Thread-Index: AcaMIv6al2wcs/e8TvuwY5RhhPusZAELwwbQABULHhA= From: "Bob O'Hara (boohara)" To: "capwap" X-OriginalArrivalTime: 15 Jun 2006 18:11:33.0020 (UTC) FILETIME=[21F3C5C0:01C690A7] Authentication-Results: sj-dkim-1.cisco.com; header.From=boohara@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Process in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Dan, David, I certainly appreciate the difficulty that our chairs have to navigate the = path to consensus necessary for a successful standard. I do not envy them = their task, particularly in this area where we believe that the success of = the CAPWAP standard is critical to this market area and the customers in it. There are certainly enough open issues to resolve, that asking for expert a= dvice on this particular issue is not likely to adversely affect the time f= or completion of our work. I think that this will be very helpful to us. = Thank you. -Bob = -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] = Sent: Thursday, June 15, 2006 1:07 AM To: Bob O'Hara (boohara) Cc: capwap; david.kessens@nokia.com Subject: RE: Process in CAPWAP Hi Bob, The ADs looked in the issue that you raised related to the consensus on the= Mux vs Multiport issue # 115. We analyzed the traffic on the list and we a= lso discussed with the WG chairs. Our opinion is that although the chairs = suggested a solution for consensus the WG did not agree with it. Despite th= e chairs and WG efforts to reach a timely conclusion according to the curre= nt WG schedules, more work needs to be done to reach at minimum rough conse= nsus on this point. The chairs have the responsibility to drive the consensus process, and the = criteria for reaching the decisions should be clearly explained. = In order to overcome the dead-end we recommend to the WG to bring in the di= scussion opinions about the consensus criteria (QoS, scalability, compatibi= lity with routing and switching infrastructure), their priority and recomme= ndations from external experts that were less involved in the discussions u= ntil now, for example by consulting the Routing Area. We offer to approach= the Routing Area ADs to have an expert designated to this purpose. We recommend that the WG continues its work and capitalizes on the effort m= ade until now to close a large number of open issues in the next version of= the draft. This issue together with the other open issues should be brough= t for discussion on the list and in Montreal, and we hope that a conclusion= based on rough consensus can be reached soon after the Montreal meeting, s= o that the impact on the Working Group schedules be minimized. David and Dan = = > -----Original Message----- > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] = > Sent: Saturday, June 10, 2006 3:16 AM > To: Romascanu, Dan (Dan) > Cc: capwap > Subject: Process in CAPWAP > = > Dan, > = > A few days ago Dorothy Gellert sent an email to the working = > group on behalf of the chairs, announcing a decision on a = > technical issue in the working group. Specifically, she = > declared that the chairs decided the discussion of the use of = > a mux header vs. the use of separate ports for the = > differentiation of control and data traffic in the protocol = > to be over. She also indicated that the chairs had chosen = > the mux header as the method to be used in the protocol and = > set a deadline of today for closing the issue. > = > As soon as I read her email, I replied and asked that she = > document the process that the chairs used to arrive at their = > decision. My background is in the IEEE, where the process is = > clear, transparent, and open to all participants. CAPWAP is = > my first IETF working group. My understanding of = > decision-making in IETF is that it is based on rough = > consensus and that the chairs have responsibility to = > determine that consensus. With that understanding, I asked = > Dorothy to document what the chairs used as evidence of rough = > consensus on that issue, since I see evidence in the postings = > to the list that there is more support for separate ports = > than there is for the mux header. At a minimum, there is no = > consensus on this issue. > = > Since sending that email two days ago, neither chair has = > responded. I find that quite disturbing for several reasons. = > = > First, this is an issue that has been debated extensively = > (and still is being debated, regardless of the pronouncement = > from the chairs). The working group deserves to know how = > this technical issue was resolved. = > = > Second, standardization by fiat of the chair does not seem to = > be in keeping with the open process requirements of the IETF. = > Perhaps I am being na=EFve, but I don't believe there is a = > feted inner core (FIC) that is actually developing all the = > IETF standards. = > = > Third, the time allowed for any response to the email was = > only three days. This is an absurdly short time, given that = > it is the start of the summer vacation period in the northern = > hemisphere. It is quite possible that many participants will = > not even see her email until after the deadline expires. = > = > Finally, if there is no consensus on the issue, the chairs = > are expressing an engineering opinion and should be required = > to justify that opinion just as any other member of the = > working group. I don't believe that the IETF anoints the = > chairs of any working group as expert and able to make = > technical decisions for the working group. > = > I would appreciate your thoughts, as the AD, and response on = > these items. > = > Best regards, > -Bob > = > Bob O'Hara > = _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 15 21:41:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr3LB-0004Pa-4a for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 21:41:41 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr3L9-0001Ly-71 for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 21:41:40 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 57727430082 for ; Thu, 15 Jun 2006 18:41:38 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 03EF943005A for ; Thu, 15 Jun 2006 18:41:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E26AE1448001 for ; Thu, 15 Jun 2006 18:41:08 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by hermes.tigertech.net (Postfix) with ESMTP id C1C311448024 for ; Thu, 15 Jun 2006 18:41:05 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id d80so438426pyd for ; Thu, 15 Jun 2006 18:41:04 -0700 (PDT) Received: by 10.35.84.16 with SMTP id m16mr3938307pyl; Thu, 15 Jun 2006 18:41:04 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Thu, 15 Jun 2006 18:41:04 -0700 (PDT) Message-ID: <26140d940606151841o68c7bd40nf0b89a5a6c70554f@mail.gmail.com> Date: Thu, 15 Jun 2006 21:41:04 -0400 From: "Michael Montemurro" To: "David T. Perkins" In-Reply-To: MIME-Version: 1.0 References: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Consistent range for radio ID and WLAN ID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1414396686==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 --===============1414396686== Content-Type: multipart/alternative; boundary="----=_Part_11718_22595747.1150422064785" ------=_Part_11718_22595747.1150422064785 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline David, Thanks for pointing this out. I've recorded it as issue 141. Mike On 6/15/06, David T. Perkins wrote: > > HI, > > I've seen several places where the range of the > Radio ID and WLAN ID is inconsistant. > > In section 4.1, in the transport header, the RID is > 5 bits (a range of 0-31), but in section 4.4.34, > the max radios and radios in use is a 8 bits (range > of 0-255). Also, in sections 4.4.8, 4.4.11, 4.4.14, > 4.4.15, 4.4.17, 4.4.28, 4.4.39, 11.10.1, 11.10.2, > 11.10.5, 11.10.6, 11.10.8, 11.10.9, 11.10.10, > 11.10.11, 11.10.13, 11.10.14, 11.10.15, 11.10.16, > 11.10.17, 11.10.18, 11.10.19, 11.10.20, 11.10.21, > 11.10.22, 11.10.23, and 11.10.24 the radio ID > field is 8 bits. > > In section 11.4, WLAN is a bit map of length 16 > (thus a range of 0-15). However, in the following > sections, WLAN ID is 8 bits (a range of 0-255): > 11.10.1, 11.10.9, 11.10.10, and 11.10.11. > And in sections 11.10.5 and 11.10.21 the WLAN ID > is 16 bits (0-65535) > > Regards, > /david t. perkins > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_11718_22595747.1150422064785 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
David,
 
Thanks for pointing this out. I've recorded it as issue 141.
 
Mike

 
On 6/15/06, David T. Perkins <dperkins@dsperkins.com> wrote:
HI,

I've seen several places where the range of the
Radio ID and WLAN ID is inconsistant.

In section 4.1, in the transport header, the RID is
5 bits (a range of 0-31), but in section 4.4.34,
the max radios and radios in use is a 8 bits (range
of 0-255). Also, in sections 4.4.8, 4.4.11, 4.4.14,
4.4.15 , 4.4.17, 4.4.28, 4.4.39, 11.10.1, 11.10.2,
11.10.5, 11.10.6, 11.10.8, 11.10.9, 11.10.10,
11.10.11, 11.10.13, 11.10.14, 11.10.15, 11.10.16,
11.10.17, 11.10.18, 11.10.19, 11.10.20, 11.10.21,
11.10.22, 11.10.23, and 11.10.24 the radio ID
field is 8 bits.

In section 11.4, WLAN is a bit map of length 16
(thus a range of 0-15). However, in the following
sections, WLAN ID is 8 bits (a range of 0-255):
11.10.1, 11.10.9, 11.10.10, and 11.10.11.
And in sections 11.10.5 and 11.10.21 the WLAN ID
is 16 bits (0-65535)

Regards,
/david t. perkins


_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_11718_22595747.1150422064785-- --===============1414396686== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1414396686==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 15 21:43:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr3Mq-0004gq-2b for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 21:43:24 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr3Mn-00028I-KB for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 21:43:24 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0667C4300CE for ; Thu, 15 Jun 2006 18:43:21 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C3F7E43005A for ; Thu, 15 Jun 2006 18:42:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B61121448024 for ; Thu, 15 Jun 2006 18:42:44 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by hermes.tigertech.net (Postfix) with ESMTP id 974131448004 for ; Thu, 15 Jun 2006 18:42:42 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id b36so353634pyb for ; Thu, 15 Jun 2006 18:42:41 -0700 (PDT) Received: by 10.35.20.14 with SMTP id x14mr3886506pyi; Thu, 15 Jun 2006 18:42:41 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Thu, 15 Jun 2006 18:42:41 -0700 (PDT) Message-ID: <26140d940606151842w717b4b8bl6a495743f2854e1@mail.gmail.com> Date: Thu, 15 Jun 2006 21:42:41 -0400 From: "Michael Montemurro" To: "David T. Perkins" In-Reply-To: MIME-Version: 1.0 References: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Missing Radio ID and WLAN ID subfields X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0449250159==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 --===============0449250159== Content-Type: multipart/alternative; boundary="----=_Part_11751_28651816.1150422161492" ------=_Part_11751_28651816.1150422161492 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline David, I've created issue 142 to deal with this issue. Mike On 6/15/06, David T. Perkins wrote: > > HI, > > The information elements in section 11.10.3 and 11.10.7 > MUST have the Radio ID and WLAN ID subfields added. > > Regards, > /david t. perkins > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_11751_28651816.1150422161492 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
David,
 
I've created issue 142 to deal with this issue.
 
Mike

 
On 6/15/06, David T. Perkins <dperkins@dsperkins.com> wrote:
HI,

The information elements in section 11.10.3 and 11.10.7
MUST have the Radio ID and WLAN ID subfields added.

Regards,
/david t. perkins



_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_11751_28651816.1150422161492-- --===============0449250159== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0449250159==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 15 21:49:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr3SQ-0001Bq-AD for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 21:49:10 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr3SN-0002oS-EQ for capwap-archive@lists.ietf.org; Thu, 15 Jun 2006 21:49:10 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id ED4714300AA for ; Thu, 15 Jun 2006 18:49:06 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 6106743005A for ; Thu, 15 Jun 2006 18:48:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 469401448024 for ; Thu, 15 Jun 2006 18:48:30 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by hermes.tigertech.net (Postfix) with ESMTP id 9870B144800A for ; Thu, 15 Jun 2006 18:48:27 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id b36so354448pyb for ; Thu, 15 Jun 2006 18:48:26 -0700 (PDT) Received: by 10.35.20.14 with SMTP id x14mr3892480pyi; Thu, 15 Jun 2006 18:48:26 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Thu, 15 Jun 2006 18:48:26 -0700 (PDT) Message-ID: <26140d940606151848h64fb89f8v242d3079200c5429@mail.gmail.com> Date: Thu, 15 Jun 2006 21:48:26 -0400 From: "Michael Montemurro" To: "Scott G Kelly" In-Reply-To: <44915A7A.6010707@hyperthought.com> MIME-Version: 1.0 References: <44915A7A.6010707@hyperthought.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] CERT issues in CAPWAP-01 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0343645674==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f --===============0343645674== Content-Type: multipart/alternative; boundary="----=_Part_11823_15628050.1150422506210" ------=_Part_11823_15628050.1150422506210 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, I've created issue 143 to deal with this problemm. On 6/15/06, Scott G Kelly wrote: > > Hi David, > > Like I said previously, I agree with pretty much everything Charles > said, so I won't re-iterate his points, and will instead simply add a > few comments below: > > David T. Perkins wrote: > > HI, > > > > Thank you for responding to my issues. It seems to me that > > we are not yet looking at the same problem. So let me try > > again. > > > > What I was trying to point out is that there are a few > > VERY common scenarios (use cases) where the clock on > > a WTP can be totally wrong. If a WTP is coded so that > > it will not continue and communicate with an AC when > > it thinks the AC's CERTs are outside the time window, > > (or it thinks that it's on CERTs are outside the time > > window) then you will have a useless device (a brick). > > In many (maybe most) deployments, it costs more to > > physically touch a WTP than the equipment cost of the WTP. > > At the Dallas IETF, there were APs that were "somewhere" > > in the ceiling not doing any useful work, but sending > > out beacons with their config'ed SSID because it was > > too expensive to find them, and take them down. It > > was more cost effective to just new new APs. > > > > For an AC, it's clock must be accurate, > > and it would be OK for it to not proceed if it believes > > its CERTs are outside their time window. But, the > > CAPWAP protocol should allow an AC to establish > > a session with a WTP that has a WACKY clock (and > > even a CERT that has expired). NOTE: the AC clock > > must be pretty accurate for management (such as > > logs) to be useful (or work). The CAPWAP protocol has > > support to set the WTP's clock. But it doesn't have support > > to update a CERT in a WTP. It seems like this is > > needed. > > > > Assume the clocks are OK, now lets talk about WTP > > CERT validation by the AC. This wasn't addressed, but > > I believe that WTP CERTs MUST be signed by the > > WTP manufacturer, or one of the WELL KNOWN certification > > authorities. Adding the CA CERTs in an AC is done through > > means outside of CAPWAP (such as via the CLI > > on the AC). Thus, WTP CERTs MUST NOT be selfsigned. > > And, I believe that the WTPs CERTs should have > > for the common name the ASCII of MAC address, > > or other unique ID of the WTP (and this must be provided > > in the Join Request message). I didn't understand > > in the previous text, nor in your message below > > why the common name would have a suffix of > > "@DOMAIN.NET". > > > > Now lets talk about AC CERT validation by the WTP. > > The CERT for the AC can be created by the AC > > manufacturer, the user, or 3rd party. It could > > be selfsigned, or have a chain from the manufacturer > > or a WELL KNOWN CA. Given this, it will be difficult > > for a WTP to verify a AC CERT, at least the first > > time. This is just a "leap of faith" if the CERT > > cannot be verified. After this first connection, > > the AC through the CAPWAP protocol could configure > > the WTP with the needed CA CERT(s). However, there > > may be some WTPs that have no additional persistent > > storage for these CERTs. > > > > So, it appears to me that the following changes > > are required to CAPWAP-01: > > 1) specify that WTP CERTs cannot be selfsigned, > > and MUST have a common name of the ASCII > > of the MAC address (or other unique ID, > > such as serial number) > > While we may not think self-signing is a good idea for our typical > deployment models, I'm not sure we have to say you MUST NOT do this, but > I'll give this some more thought. > > > 2) The Join Request must be updated to include > > the common name as a message element > > What is your objective with this requirement? > > > 3) specify that WTPs must continue even when it > > believes its CERT or the AC's CERT is outside > > the time window > > Charles addressed this. > > > 4) the CAPWAP protocol must have a new message > > to install an updated CERT for the WTP. > > 5) the CAPWAP protocol must have a new message > > to install a CA CERT. > > I agree that we should discuss this, but I'm a little leary of taking on > the task of fully specifying every nuance of cert use and mgmt. > Remember, the ipsec group spun out a whole new wg to handle this > particular problem. It's complicated. > > What we're trying to do in the base protocol is come up with minimal and > sufficient guidelines to get people going. I think cert mgmt and usage > could be revisited in detail later, perhaps under a new charter, but > that we might want to consciously avoid getting too bogged down in this > for rev 1. > > Scott > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_11823_15628050.1150422506210 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
All,
 
I've created issue 143 to deal with this problemm.

 
On 6/15/06, Scott G Kelly <scott@hyperthought.com> wrote:
Hi David,

Like I said previously, I agree with pretty much everything Charles
said, so I won't re-iterate his points, and will instead simply add a
few comments below:

David T. Perkins wrote:
> HI,
>
> Thank you for responding to my issues. It seems to me that
> we are not yet looking at the same problem. So let me try
> again.
>
> What I was trying to point out is that there are a few
> VERY common scenarios (use cases) where the clock on
> a WTP can be totally wrong. If a WTP is coded so that
> it will not continue and communicate with an AC when
> it thinks the AC's CERTs are outside the time window,
> (or it thinks that it's on CERTs are outside the time
> window) then you will have a useless device (a brick).
> In many (maybe most) deployments, it costs more to
> physically touch a WTP than the equipment cost of the WTP.
> At the Dallas IETF, there were APs that were "somewhere"
> in the ceiling not doing any useful work, but sending
> out beacons with their config'ed SSID because it was
> too expensive to find them, and take them down. It
> was more cost effective to just new new APs.
>
> For an AC, it's clock must be accurate,
> and it would be OK for it to not proceed if it believes
> its CERTs are outside their time window. But, the
> CAPWAP protocol should allow an AC to establish
> a session with a WTP that has a WACKY clock (and
> even a CERT that has expired). NOTE: the AC clock
> must be pretty accurate for management (such as
> logs) to be useful (or work). The CAPWAP protocol has
> support to set the WTP's clock. But it doesn't have support
> to update a CERT in a WTP. It seems like this is
> needed.
>
> Assume the clocks are OK, now lets talk about WTP
> CERT validation by the AC. This wasn't addressed, but
> I believe that WTP CERTs MUST be signed by the
> WTP manufacturer, or one of the WELL KNOWN certification
> authorities. Adding the CA CERTs in an AC is done through
> means outside of CAPWAP (such as via the CLI
> on the AC). Thus, WTP CERTs MUST NOT be selfsigned.
> And, I believe that the WTPs CERTs should have
> for the common name the ASCII of MAC address,
> or other unique ID of the WTP (and this must be provided
> in the Join Request message). I didn't understand
> in the previous text, nor in your message below
> why the common name would have a suffix of
> "@DOMAIN.NET".
>
> Now lets talk about AC CERT validation by the WTP.
> The CERT for the AC can be created by the AC
> manufacturer, the user, or 3rd party. It could
> be selfsigned, or have a chain from the manufacturer
> or a WELL KNOWN CA. Given this, it will be difficult
> for a WTP to verify a AC CERT, at least the first
> time. This is just a "leap of faith" if the CERT
> cannot be verified. After this first connection,
> the AC through the CAPWAP protocol could configure
> the WTP with the needed CA CERT(s). However, there
> may be some WTPs that have no additional persistent
> storage for these CERTs.
>
> So, it appears to me that the following changes
> are required to CAPWAP-01:
>   1) specify that WTP CERTs cannot be selfsigned,
>      and MUST have a common name of the ASCII
>      of the MAC address (or other unique ID,
>      such as serial number)

While we may not think self-signing is a good idea for our typical
deployment models, I'm not sure we have to say you MUST NOT do this, but
I'll give this some more thought.

>   2) The Join Request must be updated to include
>      the common name as a message element

What is your objective with this requirement?

>   3) specify that WTPs must continue even when it
>      believes its CERT or the AC's CERT is outside
>      the time window

Charles addressed this.

>   4) the CAPWAP protocol must have a new message
>      to install an updated CERT for the WTP.
>   5) the CAPWAP protocol must have a new message
>      to install a CA CERT.

I agree that we should discuss this, but I'm a little leary of taking on
the task of fully specifying every nuance of cert use and mgmt.
Remember, the ipsec group spun out a whole new wg to handle this
particular problem. It's complicated.

What we're trying to do in the base protocol is come up with minimal and
sufficient guidelines to get people going. I think cert mgmt and usage
could be revisited in detail later, perhaps under a new charter, but
that we might want to consciously avoid getting too bogged down in this
for rev 1.

Scott

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_11823_15628050.1150422506210-- --===============0343645674== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0343645674==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 16 04:58:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrA9o-00017s-9a for capwap-archive@lists.ietf.org; Fri, 16 Jun 2006 04:58:24 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrA9m-0005Ry-Mw for capwap-archive@lists.ietf.org; Fri, 16 Jun 2006 04:58:24 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DCDB0430130 for ; Fri, 16 Jun 2006 01:58:21 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 374544300B0 for ; Fri, 16 Jun 2006 01:57:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 22B4F398031 for ; Fri, 16 Jun 2006 01:57:34 -0700 (PDT) X-Greylist-Status: Sender first seen 4 days 20:11:10 ago Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7FEC7398023 for ; Fri, 16 Jun 2006 01:57:29 -0700 (PDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5G8rue8012432 for ; Fri, 16 Jun 2006 04:53:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 Jun 2006 11:57:25 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Process in CAPWAP Thread-Index: AcaMIv6al2wcs/e8TvuwY5RhhPusZAELwwbQABULHhAAHxdIYA== From: "Romascanu, Dan (Dan)" To: "capwap" X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: Re: [Capwap] Process in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac I would suggest that the chairs draw a short list of clear questions and is= sues for clarification, including references that would help to focus the w= ork of the experts. Can we have this list prepared in the next few days? = Thanks and Regards, Dan = = > -----Original Message----- > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] = > Sent: Thursday, June 15, 2006 9:12 PM > To: capwap > Cc: david.kessens@nokia.com; Romascanu, Dan (Dan) > Subject: RE: Process in CAPWAP > = > Dan, David, > = > I certainly appreciate the difficulty that our chairs have to = > navigate the path to consensus necessary for a successful = > standard. I do not envy them their task, particularly in = > this area where we believe that the success of the CAPWAP = > standard is critical to this market area and the customers in it. > = > There are certainly enough open issues to resolve, that = > asking for expert advice on this particular issue is not = > likely to adversely affect the time for completion of our = > work. I think that this will be very helpful to us. = > = > Thank you. > = > -Bob > = > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Thursday, June 15, 2006 1:07 AM > To: Bob O'Hara (boohara) > Cc: capwap; david.kessens@nokia.com > Subject: RE: Process in CAPWAP > = > Hi Bob, > = > The ADs looked in the issue that you raised related to the = > consensus on the Mux vs Multiport issue # 115. We analyzed = > the traffic on the list and we also discussed with the WG = > chairs. Our opinion is that although the chairs suggested a = > solution for consensus the WG did not agree with it. Despite = > the chairs and WG efforts to reach a timely conclusion = > according to the current WG schedules, more work needs to be = > done to reach at minimum rough consensus on this point. > = > The chairs have the responsibility to drive the consensus = > process, and the criteria for reaching the decisions should = > be clearly explained. = > = > In order to overcome the dead-end we recommend to the WG to = > bring in the discussion opinions about the consensus criteria = > (QoS, scalability, compatibility with routing and switching = > infrastructure), their priority and recommendations from = > external experts that were less involved in the discussions = > until now, for example by consulting the Routing Area. We = > offer to approach the Routing Area ADs to have an expert = > designated to this purpose. > = > We recommend that the WG continues its work and capitalizes = > on the effort made until now to close a large number of open = > issues in the next version of the draft. This issue together = > with the other open issues should be brought for discussion = > on the list and in Montreal, and we hope that a conclusion = > based on rough consensus can be reached soon after the = > Montreal meeting, so that the impact on the Working Group = > schedules be minimized. > = > David and Dan > = > = > = > = > > -----Original Message----- > > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > > Sent: Saturday, June 10, 2006 3:16 AM > > To: Romascanu, Dan (Dan) > > Cc: capwap > > Subject: Process in CAPWAP > > = > > Dan, > > = > > A few days ago Dorothy Gellert sent an email to the working = > group on = > > behalf of the chairs, announcing a decision on a technical issue in = > > the working group. Specifically, she declared that the = > chairs decided = > > the discussion of the use of a mux header vs. the use of separate = > > ports for the differentiation of control and data traffic in the = > > protocol to be over. She also indicated that the chairs had chosen = > > the mux header as the method to be used in the protocol and set a = > > deadline of today for closing the issue. > > = > > As soon as I read her email, I replied and asked that she = > document the = > > process that the chairs used to arrive at their decision. My = > > background is in the IEEE, where the process is clear, transparent, = > > and open to all participants. CAPWAP is my first IETF = > working group. = > > My understanding of decision-making in IETF is that it is based on = > > rough consensus and that the chairs have responsibility to = > determine = > > that consensus. With that understanding, I asked Dorothy = > to document = > > what the chairs used as evidence of rough consensus on that issue, = > > since I see evidence in the postings to the list that there is more = > > support for separate ports than there is for the mux header. At a = > > minimum, there is no consensus on this issue. > > = > > Since sending that email two days ago, neither chair has = > responded. I = > > find that quite disturbing for several reasons. > > = > > First, this is an issue that has been debated extensively = > (and still = > > is being debated, regardless of the pronouncement from the = > chairs). = > > The working group deserves to know how this technical issue was = > > resolved. > > = > > Second, standardization by fiat of the chair does not seem to be in = > > keeping with the open process requirements of the IETF. > > Perhaps I am being na=EFve, but I don't believe there is a = > feted inner = > > core (FIC) that is actually developing all the IETF standards. > > = > > Third, the time allowed for any response to the email was = > only three = > > days. This is an absurdly short time, given that it is the = > start of = > > the summer vacation period in the northern hemisphere. It is quite = > > possible that many participants will not even see her email until = > > after the deadline expires. > > = > > Finally, if there is no consensus on the issue, the chairs are = > > expressing an engineering opinion and should be required to justify = > > that opinion just as any other member of the working group. = > I don't = > > believe that the IETF anoints the chairs of any working group as = > > expert and able to make technical decisions for the working group. > > = > > I would appreciate your thoughts, as the AD, and response on these = > > items. > > = > > Best regards, > > -Bob > > = > > Bob O'Hara > > = > = _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From busynicol@hoonah.net Fri Jun 16 12:50:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrHWL-0003wQ-6B for capwap-archive@ietf.org; Fri, 16 Jun 2006 12:50:09 -0400 Received: from 72.red-83-41-143.dynamicip.rima-tde.net ([83.41.143.72] helo=hoonah.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FrHWI-0001YR-E0 for capwap-archive@ietf.org; Fri, 16 Jun 2006 12:50:09 -0400 Message-ID: <000001c69164$edcdc340$be5fa8c0@dvm62> Reply-To: "Nicol Busby" From: "Nicol Busby" To: capwap-archive@ietf.org Subject: vatal test Date: Fri, 16 Jun 2006 09:50:09 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6912A.416EEB40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.0 (++++) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6912A.416EEB40 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0002_01C6912A.416EEB40" ------=_NextPart_001_0002_01C6912A.416EEB40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://soluomendesca.com _____ =20 empty stomach, as he wiped his sword on the grass and put it back into its sheath. I will give you a name, he said to it, and I shall call you Sting. After that he set out to explore. The forest was grim and silent, but obviously he had first of all to look for his friends, who were not likely to be very far off, unless they had been made prisoners ------=_NextPart_001_0002_01C6912A.416EEB40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

empty stomach, as he wiped his sword on the grass and put it = back into
its sheath.
I will give you a name, he said to it, and I shall call you
Sting. After that he set out to explore. The forest was grim and
silent, but obviously he had first of all to look for his friends, = who
were not likely to be very far off, unless they had been made = prisoners
------=_NextPart_001_0002_01C6912A.416EEB40-- ------=_NextPart_000_0001_01C6912A.416EEB40 Content-Type: image/gif; name="spot48.gif" Content-Transfer-Encoding: base64 Content-ID: <000101c69164$edcb7e32$be5fa8c0@dvm62> R0lGODdhugC1AMIAAAAAAC1IeP///wAA//8AANK3gAAAAAAAACwAAAAAugC1AAAD/ii6Wvwwykmr vThHJ7jGnlRwYbd9X7moaLtWKvu6jAymdA7rUDjywGAwxis5bMKkcjlB0mzOYpOpiVJxp6vLqu16 v+DwcEcWZ7g5D9TMbl+O07Hbi54/6vZ4fq/Fn2sWfjd6fEokQoKAiiaMPYWPd1V2iTMNkpBlIpib jlRGX5SFoX+BUpynqJpJo1mlqZeLg7KvYmq0hFmst7u8bLq9qm+bfr9AxUzHs52xnFzJlsurFMVR z4/WOtigmdGVphcBAV7h4dNC4sDQGAEl5RTsCvAdxeR9D+h37hPk+A36fP8EBITgbmAkFAZdtSLI r59Ah/fQ1Vvg7pCZEPoSMtAY/qRil3ISKU5k0a/gRDnB3uH7V4CfP4knH4p8CBNivIbiMsaUSc7B zpkQfeJz8o8jClYtKXpYafJmuKVMa96UYFKezKtOswokmZOqQxssbXZxklRjU5olmc6MJ+Ps1LVY dW7oGsGoyLR5VIB0iNOfU7w3OcitC3Mj4LhqK7lkuM4q1m5h9hpemxTt5LeIvT19XDRx5n07A3Jl 7ElhxMMPhf69/LmlWLecPQ+m+rj2CsE27RqCHLPz28WYZyeEXRQqXI45+YqFG5FT76q/F7MTp5ot 88sBicvOHa/2QNjNDzYi5S3D93rlXE91KVyt3sKnleO+LjR0Q+w4kwOXxq00/v8lGDWDxTctaCNe C8ulAwsz6ViR4Dzq/McgGAamNEwawphDBy6QeaUbEMtVWKAy14FX4U8DZhjfcvfd9WFkymE23oIV pJdNIH1N5VpQm00E3YFsyCWiVwthuF53SMpIEXasSfhBey6mxV5yUXo4pYuT+WgWXRCGp9J7Y5VH ZHAhBRadfitENeZzZEqFFUZc9mCXQfoM2VhsclIJVILDwSejW7M195pRP03HYYRXSHbcfWG9+RdL a/kW6XagbWlBndcRSIOi0e05WWWLrokaoIm1haJMSEDq2hpt2IcnqDyNOuifgEH5TmqEXZrbg264 6tuvsoraJKmZ3hNXk0tS/oYsSi7Yt6NW0HXm5gzgEaujbUhWd5Wk1r5oxnmr6URldujNatti2gZq WKGurrYur8hYyIq3RhqjoIZP3KrkLvDewQI1pjm5Ir6b9AvDM0QgsuG9JIZhoEUTBtzhEHZe8bA9 BDOc4oyN+EBasQofJSCAiTjomYoiM7sFgEDOUS6vZK3cMC3HUMIpWoXthzOZFxVJI8QWhnngSaC+ rJVAd61HncYUqpw0kbD2+Wh/VB/87xwQG2jflcxN19PRTIfcqqSxslanmmI6bCcaHtNYo57ALjXf fGBjHXbauqIJLH74GVr13YXIpaWeZ0JL+G6Af4QObjuOe9iV6trL8t8t/t/YcsV5IRVx4nz8kLLT DSIq9qFlsP35JAuDjnHHm8s8sRtAiz6zpq27nm+9nJ+u4SeVt4E5nPP6OeLsTctu+xIfploY5rsw n2sSRrVtfO3HI36J9EF/HF+oSjMalUdhO48DnfBUNcJgP3ZXn/i3S8y+lzPRvZdx2/JpcCTvMwzu pHhu+57O0+PYKYgxDojkpybcEt5naKe74sEIEFuKUf2G5Zho/IJVdnsdKfaXJwlWhmzYyp0rhkS+ jTztJb+B07Q2JkLqaSA/VTKhl1qEJXqRB28+a6EGb4G97AlQFDmc3A6rJ7RtqK53KFtZ/kjnMBwy cYiS0+ERGyhFIGZw/lPwasepqGgsJ7rtKM6jIaEOl7YtDk9f77JJ44CTI4mtzmwKZMyLbLRDP+Qo fSoBGQu1kB3z3G9fTwQHXaiDGg+ZAFJBTKIil7Wok5QPgbsqVweiAiea1C1LYOEVCG9hKaQZrmyA FBffDBfHI43ph88x43je18l8KC2EcKQgzwDJk/8J8iCqDByLvteUvYzkYyC01lYqZa48njKQX+gk +uBGw1h2zU/q0mIJy2MQunmxV7vs380sCczFXaU6ZxNJqrAFK+2Z84yWCAWYZHizXsapmifziDAJ tS1G0lKPAkPIMrmppUku0Jn8mySl6tKds5ArTQRBKCr+Z6OqMLN+/jGh37mIZiuGbG0onbKoDavo RiaEyHKfs8WEloi7RJrmjzeEIvF80YA6UAIPFWRawogYRSQO8Hgzxd8XFzlSH/q0iKmjxUYD+MOb pgFziHwbaKwnU5OaYn1P8ib8uKix3xGzDvQiaV6CaiVL+PKT9ZAoG/UjVZr6lHd7EEQlEeOmr2oT PiOJ3r0IuMfnVbSdatnMK/GJzm44w4g1bYk1oUQ2vPYvYx0lKgOnqJI7UqqwZOXaPTla1J8a00yE fRwZaeVCxF6jZ5xdoKK0VZZd2ROo+XTgadYlWjRpM0Cb3GktbNorMGVWZ+LSDlDRijpIVMOoQuTp grSa0q36kLiL/qVcAD1HW8p21rKeZalqz2hV5yr3CT2ELleliwfeFleEzdRucBV7ReeczLrXnV3N LpskYKzXrAR7qVK7uqcV7gwTyJVt73YCTrT1M0m5vKZxR9bYQBFLWxHJqXgQFjK6ju2DtRroo4KC XuFauFJvReEsYfnc0fEQeoc7i3oyOlmLIXMR3n2FfBLIvdiW9GLjBUN70jXQwV3YqSWlKk2xilu/ bTi3HO5wc6uYX5ZdjYFF7m2FcZzjJndYBklmsm/7OtvsebdC1YCDhwF7NwavNLjMJa9nrUFmlao4 vKU5cmqVPDb6KFK+ydUxgZ+HmZJFN153hq+Ab5ynLBFurDRs/dy7lizec+AlrJ1SIYABteBCS5mx RcUggg7tzU1KbaiE7hKIAxpaJT2lRxQGaaajOtZP1Rmy5Kzsd1ctZyo3y7TPjLWntDxEB9e1pg/U HotliWnYVfWc3oErudq6lFajtn1IhfWgJ4zANwFwyPpNrCLsbGIkxECto2ZGitvnXupRe5VcHrAI FUyKMDsZ2tk+d5mlvec4L/nbeE6FpNO9ZV+jWNz0Rve5v1xZcxsvyvVmd5GwXetHv666HAW4lq0N OHJz+92v+GvmzJFigOd5eADL98Ob2LnpalzVH9/uurkb7hjD+cTqiJmeWS3meF8c5Ty0uKgjvXHf SdcFCQAAOw== ------=_NextPart_000_0001_01C6912A.416EEB40-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 16 21:48:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrPv7-00089E-Kb for capwap-archive@lists.ietf.org; Fri, 16 Jun 2006 21:48:17 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrPv4-0006Va-H4 for capwap-archive@lists.ietf.org; Fri, 16 Jun 2006 21:48:17 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7FD2B4300CC for ; Fri, 16 Jun 2006 18:48:13 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 48F684300AA for ; Fri, 16 Jun 2006 18:47:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 300751448003 for ; Fri, 16 Jun 2006 18:47:26 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by hermes.tigertech.net (Postfix) with ESMTP id F225A1448005 for ; Fri, 16 Jun 2006 18:47:23 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so788145pyu for ; Fri, 16 Jun 2006 18:47:22 -0700 (PDT) Received: by 10.35.78.13 with SMTP id f13mr2615645pyl; Fri, 16 Jun 2006 18:47:22 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Fri, 16 Jun 2006 18:47:22 -0700 (PDT) Message-ID: <26140d940606161847m635c372bq10887ea55cf744ff@mail.gmail.com> Date: Fri, 16 Jun 2006 21:47:22 -0400 From: "Michael Montemurro" To: "Saravanan Govindan" In-Reply-To: <5F09D220B62F79418461A978CA0921BDEEEF07@pslexc01.psl.local> MIME-Version: 1.0 References: <5F09D220B62F79418461A978CA0921BDEEEF07@pslexc01.psl.local> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0407330406==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a78ee79e7121d5e3529be34866f161 --===============0407330406== Content-Type: multipart/alternative; boundary="----=_Part_11646_32624890.1150508842482" ------=_Part_11646_32624890.1150508842482 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Saravanan, I have looked through IEEE 802.11i as well as talked with others who had implemented IEEE 802.11i. The treatment of the KeyRSC setting is not explained as well as it could be in the IEEE 802.11i draft. In many implementations, the Authenticator sets the transmit sequence counter with the new GTK and passes them both down to the MAC. The Authenticator then transmits this information to the STA as part of the GTK1 EAPoL message. Both the STA and the WTP will then begin using the new TSC and the group ke= y to encrypt broadcast/multicast traffic. To address this in CAPWAP I have updated the AddWLAN message to include the transmit sequence counter for the GTK. That should address any issues with counters and key states. Cheers, Mike On 6/7/06, Saravanan Govindan wrote: > > Hi Mike, > > > > Following from my earlier note, this is the suggestion for handling KeyRS= C > maintained in a WTP. > > > > The suggestion is to include a new IEEE 802.11 specific CAPWAP control > messages called "IEEE 802.11 Key Configuration". > > > > Following from CAPWAP Specifications-01; > > > > CAPWAP Control Message Message Type > > Value > > > > IEEE 802.11 Key Configuration 3398914 > > IEEE 802.11 Key Configuration Response 3398915 > > > > > > The suggested text follows; > > > > [START OF SUGGESTED TEXT] > > > > 11.7.3. IEEE 802.11 Key Configuration > > > > The IEEE 802.11 Key Configuration CAPWAP message is used in WTP designs i= n > which IEEE 802.11i authenticator functions are performed by the AC and > IEEE 802.11i cryptographic functions (encryption/decryption) are performe= d > by the WTPs. > > > > This CAPWAP message is sent from the AC to the WTP. It must contain eithe= r > of the following 2 message elements. > > > > > > > > > > 11.7.3.1 IEEE 802.11 4-way Handshake > > > > The IEEE 802.11 4-way Handshake message element is sent by the AC to the > WTP during the 4-way handshake. It contains Message-3 of the 4-way handsh= ake > with unassigned values as the AC is unaware of the prevailing KeyRSC > sequence counter maintained by the WTP. > > > > Message-1, Message-2 and Message-4 of the 4-way handshake are transported > within CAPWAP data packets between AC and WTP. > > > > The IEEE 802.11 4-way Handshake message element contains the following > values: > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | GTK-Flag | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Encryption-Data | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | EAPoL-Frame | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > GTK-Flag: An 8-bit flag that determines the type of KeyMIC calculation > > > > 0 =96 New GTK, KeyMIC is calculated with KeyRSC =3D 0 > > > > 1 =96 Existing GTK, KeyMIC is calculated with prevailing KeyRSC valu= e > > > > Encryption-Data: Contains PTK and/or GTK > > > > EAPoL-Frame: Contains Message-3 of 4-way handshake with unassigned fields > > > > Upon receipt of the Key Configuration message from the AC, the WTP > performs the following operations: > > > > i. Assigns the corresponding value to the KeyRSC field of > the EAPoL-Frame > > ii. Calculates KeyMIC with Encrytion-Data and KeyRSC > > iii. Updates Message-3 of 4-way handshake > > iv. Continues regular 4-way handshake with wireless terminals > > > > > > > > > > 11.7.3.2 IEEE 802.11 Group Key Handshake > > > > The IEEE 802.11 Group Key Handshake message element is sent by the AC to > the WTP during the group key handshake. It contains Message-1 of the grou= p > key handshake with unassigned values as the AC is unaware of the prevaili= ng > KeyRSC sequence counter maintained by the WTP. > > > > Message-2 of the group key handshake is transported within a CAPWAP data > packet between AC and WTP. > > > > The IEEE 802.11 Group Key Handshake message element contains the followin= g > values: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | GTK-Flag | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Encryption-Data | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | EAPoL-Frame | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > GTK-Flag: An 8-bit flag that determines the type of KeyMIC calculation > > > > 0 =96 New GTK, KeyMIC is calculated with KeyRSC =3D 0 > > > > 1 =96 Existing GTK, KeyMIC is calculated with prevailing KeyRSC valu= e > > > > Encryption-Data: Contains PTK and/or GTK > > > > EAPoL-Frame: Contains Message-1 of group key handshake with unassigned > fields > > > > Upon receipt of the Key Configuration message from AC, the WTP performs > the following operations: > > i. Assigns the corresponding value to the KeyRSC field of > the EAPoL-Frame > > ii. Calculates KeyMIC with Encrytion-Data and KeyRSC > > iii. Updates Message-1 of group key handshake > > iv. Continues regular group handshake with wireless terminals > > > > > > > > > > 11.7.4 IEEE 802.11 Key Configuration Response > > > > The IEEE 802.11 Key Configuration Response CAPWAP message is sent by the > WTP to the AC as an acknowledgement of the receipt of an IEEE 802.11 Key > Configuration Request. > > > > [END OF SUGGESTED TEXT] > > > > > > > > > Saravanan > ------=_Part_11646_32624890.1150508842482 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Saravanan,
 
I have looked through IEEE 802.11i as well as talked with others who h= ad implemented IEEE 802.11i. The treatment of the KeyRSC setting is not exp= lained as well as it could be in the IEEE 802.11i draft. In many implementa= tions, the Authenticator sets the transmit sequence counter with the new GT= K and passes them both down to the MAC. The Authenticator then transmits th= is information to the STA as part of the GTK1 EAPoL message. Both the STA a= nd the WTP will then begin using the new TSC and the group key to encrypt b= roadcast/multicast traffic.
 
To address this in CAPWAP I have updated the AddWLAN message to includ= e the transmit sequence counter for the GTK. That should address any issues= with counters and key states.
 
Cheers,
 
Mike


 
On 6/7/06, S= aravanan Govindan <Saravanan.Govindan@sg.panasonic.com> wrote:

Hi Mike,

 

Following from my earlier note, this is the suggestion for handling KeyRSC= maintained in a WTP.

 

The suggestion is to include a new IEEE 802.11 specific CAPWAP control mes= sages called "IEEE 802.11 Key Configuration".

 

Following from CAPWAP Specifications-01;

 

CAPWAP Control Message        &nbs= p;           Message Type=

            &n= bsp;            = ;            &n= bsp;    Value

 

IEEE 802.11 Key Configuration       &nb= sp;     3398914

IEEE 802.11 Key Configuration Response    3398915

 

 

The suggested text follows;

 

[START OF SUGGESTED TEXT]

 

11.7.3. IEEE 802.11 Key Configuration

 

The IEEE 802.11 Key Configuration CAPWAP message is used in WTP designs in= which IEEE 802.11i authenticator functions are performed by the AC and IEE= E=20 802.11i cryptographic functions (encryption/decryption) are performed by th= e WTPs.

 

This CAPWAP message is sent from the AC to the WTP. It must contain either= of the following 2 message elements.

 

 

 

 

11.7.3.1     IEEE 802= .11 4-way Handshake

 

<= span style=3D"FONT-SIZE: 10pt">The IEEE 802.11 4-way Handshake message elem= ent is sent by the AC to the WTP during the 4-way handshake. It contains Me= ssage-3 of the 4-way handshake with unassigned values as the AC is unaware = of the prevailing KeyRSC sequence counter maintained by the WTP.  

<= span style=3D"FONT-SIZE: 10pt"> 

<= span style=3D"FONT-SIZE: 10pt">Message-1, Message-2 and Message-4 of the 4-= way handshake are transported within CAPWAP data packets between AC and WTP= .

<= span style=3D"FONT-SIZE: 10pt"> 

<= span style=3D"FONT-SIZE: 10pt">The IEEE 802.11 4-way Handshake message elem= ent contains the following values:

<= span style=3D"FONT-SIZE: 10pt"> 

<= span style=3D"FONT-SIZE: 10pt"> 

<= span style=3D"FONT-SIZE: 10pt">      0  =             &nb= sp;    1        &nbs= p;          2   = ;            &n= bsp;   3

<= span style=3D"FONT-SIZE: 10pt">      0 1 2 3 4 5 6= 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

<= span style=3D"FONT-SIZE: 10pt">     +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<= span style=3D"FONT-SIZE: 10pt">     |    = ;GTK-Flag   |         &nb= sp;         Reserved  &nb= sp;            =      |

<= span style=3D"FONT-SIZE: 10pt">     +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<= span style=3D"FONT-SIZE: 10pt">     |   =             &nb= sp;        Encryption-Data   &= nbsp;           &nbs= p;        |

<= span style=3D"FONT-SIZE: 10pt">     +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<= span style=3D"FONT-SIZE: 10pt">     |   =             &nb= sp;          EAPoL-Frame  = ;            &n= bsp;           |

<= span style=3D"FONT-SIZE: 10pt">     +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

 

GTK-Flag: An 8-bit flag that determines the type of KeyMIC calculation

    

     0 =96 New GTK, KeyMIC is calculated with KeyRSC = =3D 0

 

     1 =96 Existing GTK, KeyMIC is calculated with pre= vailing KeyRSC value

 

Encryption-Data: Contains PTK and/or GTK

 

EAPoL-Frame: Contains Message-3 of 4-way handshake with unassigned fields<= /span>

 

<= span style=3D"FONT-SIZE: 10pt">Upon receipt of the Key Configuration messag= e from the AC, the WTP performs the following operations:

<= span style=3D"FONT-SIZE: 10pt"> 

 =    i.    &= nbsp;       = Assigns the corresponding value to the KeyRSC field of the EAPoL-Frame=20

ii.&nb= sp;          =20 Calculates KeyMIC with Encrytion-Data and = KeyRSC

iii.&n= bsp;          =20 Updates Message-3 of 4-way handshake

iv.&nb= sp;          =20 Continues regular 4-way handshake with wir= eless terminals

 

 

 

 

11.7.3.2     IEEE 802= .11 Group Key Handshake

 

<= span style=3D"FONT-SIZE: 10pt">The IEEE 802.11 Group Key Handshake message = element is sent by the AC to the WTP during the group key handshake. It con= tains Message-1 of the group key handshake with unassigned values as the AC= is unaware of the prevailing KeyRSC sequence counter maintained by the WTP= .  

<= span style=3D"FONT-SIZE: 10pt"> 

<= span style=3D"FONT-SIZE: 10pt">Message-2 of the group key handshake is tran= sported within a CAPWAP data packet between AC and WTP.

<= span style=3D"FONT-SIZE: 10pt"> 

<= span style=3D"FONT-SIZE: 10pt">The IEEE 802.11 Group Key Handshake message = element contains the following values:

 

<= span style=3D"FONT-SIZE: 10pt">      0  =             &nb= sp;    1        &nbs= p;          2   = ;            &n= bsp;   3

<= span style=3D"FONT-SIZE: 10pt">      0 1 2 3 4 5 6= 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

<= span style=3D"FONT-SIZE: 10pt">     +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<= span style=3D"FONT-SIZE: 10pt">     |    = ;GTK-Flag   |         &nb= sp;         Reserved  &nb= sp;            =      |

<= span style=3D"FONT-SIZE: 10pt">     +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<= span style=3D"FONT-SIZE: 10pt">     |   =             &nb= sp;        Encryption-Data   &= nbsp;           &nbs= p;        |

<= span style=3D"FONT-SIZE: 10pt">     +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<= span style=3D"FONT-SIZE: 10pt">     |   =             &nb= sp;          EAPoL-Frame  = ;            &n= bsp;           |

<= span style=3D"FONT-SIZE: 10pt">     +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

 

GTK-Flag: An 8-bit flag that determines the type of KeyMIC calculation

    

     0 =96 New GTK, KeyMIC is calculated with KeyRSC = =3D 0

 

     1 =96 Existing GTK, KeyMIC is calculated with pre= vailing KeyRSC value

 

Encryption-Data: Contains PTK and/or GTK

 

EAPoL-Frame: Contains Message-1 of group key handshake with unassigned fie= lds

 

<= span style=3D"FONT-SIZE: 10pt">Upon receipt of the Key Configuration messag= e from AC, the WTP performs the following operations:

 =    i.    &= nbsp;       = Assigns the corresponding value to the KeyRSC field of the EAPoL-Frame=20

ii.&nb= sp;          =20 Calculates KeyMIC with Encrytion-Data and = KeyRSC

iii.&n= bsp;          =20 Updates Message-1 of group key handshake

iv.&nb= sp;          =20 Continues regular group handshake with wir= eless terminals

 

 

 

 

11.7.4     IEEE 802.11 Key Configuration Response

 

The IEEE 802.11 Key Configuration Response CAPWAP message is sent by the W= TP to the AC as an acknowledgement of the receipt of an IEEE 802.11 Key Con= figuration Request.=20

 

[END OF SUGGESTED TEXT]

 

 

 


Saravanan


------=_Part_11646_32624890.1150508842482-- --===============0407330406== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0407330406==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 16 22:03:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrQA4-00040y-Qo for capwap-archive@lists.ietf.org; Fri, 16 Jun 2006 22:03:44 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrQA3-0008S5-BT for capwap-archive@lists.ietf.org; Fri, 16 Jun 2006 22:03:44 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 067FC4300F7 for ; Fri, 16 Jun 2006 19:03:43 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 081544300AA for ; Fri, 16 Jun 2006 19:03:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EACA91448003 for ; Fri, 16 Jun 2006 19:03:14 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by hermes.tigertech.net (Postfix) with ESMTP id 2C61F1448009 for ; Fri, 16 Jun 2006 19:03:11 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id z74so801334pyg for ; Fri, 16 Jun 2006 19:03:11 -0700 (PDT) Received: by 10.35.134.12 with SMTP id l12mr5293369pyn; Fri, 16 Jun 2006 19:03:11 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Fri, 16 Jun 2006 19:03:11 -0700 (PDT) Message-ID: <26140d940606161903m72b3ff4cmc56950a32967d095@mail.gmail.com> Date: Fri, 16 Jun 2006 22:03:11 -0400 From: "Michael Montemurro" To: capwap MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.3 tagged_above=-999.0 required=7.0 tests=HTML_10_20, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Proposed resolutions for draft-02 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0832225717==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.3 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 --===============0832225717== Content-Type: multipart/alternative; boundary="----=_Part_11866_12889781.1150509791109" ------=_Part_11866_12889781.1150509791109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I've made a series of modifications to be included in CAPWAP-02. Here's a summary of what I've done: - Issue 133, updated 4.4.13 to remain consistent with 4.4.12 - Issue 103: Merged Change-State-Event Message Element with Administrative-State Message Element. The Change State event message remains the same. - Issue 104: Made the following changes: - added a sentence to 11.9.11 (-02) to indicate that the AC would transmit one message element per band. - added an additional cause to radio administrative state message element to account for radar detection. - 802.11h would need to be implemented on the WTP since the controller could possibly reside in a different regulatory domain from the WTP. The AP would perform DFS and report its new channel to the AC using a IEEE 802.11configuration request frame. - Issue 64: TSPEC provisioning: close the issue. In a local MAC case, TSPEC's would be provisioned at the WTP; in the split MAC case, the TSPEC's would be provisioned at the AC - Issue 37: Use the vendor specific message frame type addresses this comment.. - Issue 141: Added WLAN ID and Radio ID to both message elements as requested. Cheers, Mike ------=_Part_11866_12889781.1150509791109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I've made a series of modifications to be included in CAPWAP-02. Here's a summary of what I've done:
 

- Issue 133, updated 4.4.13 to remain consistent with 4.4.12

- Issue 103: Merged Change-State-Event Message Element with Administrative-State Message Element. The Change State event message remains the same.

- Issue 104: Made the following changes:

     - added a sentence to 11.9.11 (-02) to indicate that the AC would transmit one message element per band.

    - added an additional cause to radio administrative state message element to account for radar detection.
    - 802.11h would need to be implemented on the WTP since the controller could 
       possibly reside in a different regulatory domain from the WTP. The AP would 
       perform DFS and report its new channel to the AC using a IEEE 802.11 configuration request frame.

- Issue 64: TSPEC provisioning: close the issue. In a local MAC case, TSPEC's would be provisioned at the WTP; in the split MAC case, the TSPEC's would be provisioned at the AC

- Issue 37: Use the vendor specific message frame type addresses this comment..

- Issue 141: Added WLAN ID and Radio ID to both message elements as requested.

Cheers,

Mike

 

------=_Part_11866_12889781.1150509791109-- --===============0832225717== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0832225717==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 16 22:37:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrQgR-00050u-IF for capwap-archive@lists.ietf.org; Fri, 16 Jun 2006 22:37:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrQgP-0002jS-Oj for capwap-archive@lists.ietf.org; Fri, 16 Jun 2006 22:37:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 248D94300FF for ; Fri, 16 Jun 2006 19:37:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 698FD4300AA for ; Fri, 16 Jun 2006 19:36:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5429A1448009 for ; Fri, 16 Jun 2006 19:36:33 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by hermes.tigertech.net (Postfix) with ESMTP id C8DFA144801A for ; Fri, 16 Jun 2006 19:36:30 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so795492pyu for ; Fri, 16 Jun 2006 19:36:29 -0700 (PDT) Received: by 10.35.62.19 with SMTP id p19mr5305664pyk; Fri, 16 Jun 2006 19:36:29 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Fri, 16 Jun 2006 19:36:29 -0700 (PDT) Message-ID: <26140d940606161936k1b94d0b0vfbc3f28abeb393ab@mail.gmail.com> Date: Fri, 16 Jun 2006 22:36:29 -0400 From: "Michael Montemurro" To: "Scott G Kelly" In-Reply-To: <26140d940606031107j14e8e767m66bd14bdff6b8dcb@mail.gmail.com> MIME-Version: 1.0 References: <14926662.1149270993939.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> <26140d940606031046g66a91253hd6721fce8951dcb4@mail.gmail.com> <4481CE2E.4000702@hyperthought.com> <26140d940606031107j14e8e767m66bd14bdff6b8dcb@mail.gmail.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Wrong place for "Image data" state X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0033100206==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a --===============0033100206== Content-Type: multipart/alternative; boundary="----=_Part_12075_26601986.1150511789824" ------=_Part_12075_26601986.1150511789824 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline David, Were you going to propose text to address this issue? Thanks, Mike On 6/3/06, Michael Montemurro wrote: > > In any case, I've created issue 126 to track this. > > Mike > > > On 6/3/06, Scott G Kelly wrote: > > > > Hi Mike, > > > > Michael Montemurro wrote: > > > Scott, > > > > > > At the end of your reply, you mentioned that there were missing > > details > > > here. Could you either enumerate the missing details or provide > > > additional text to address them. I'll incorporate the changes into > > > version -02 > > > > > > Cheers, > > > > > > Mike > > > > I think we need to fully specify the mechanism by which the version > > communication takes place, and also who makes the decision (currently, > > the language is a bit ambiguous, saying either the AC or WTP can intiate > > the image download, but saying nothing about how they decide and do > > contention resolution). > > > > I think David is proposing making the version information/setting part > > of the Join exchange, and transitioning directly to Image Data (without > > ever entering Configure) if appropriate (or rebooting, if the desired > > image is different than what is running, and is already stored on the > > WTP). > > > > I don't feel strongly about this. I think David is preparing a proposal, > > and that will have all the detail we need (David, please correct if I am > > > > wrong about this). > > > > Scott > > > > > > > > > > > On 6/2/06, *Scott G. Kelly* > > > wrote: > > > > > > Hi David, > > > > > > > The state machine shows that the "image data" state is > > > > entered after the "configure" state. However, the description > > > > of the state machine doesn't really match this. As currently > > > > specified, I believe that it would be clearer for the "Image > > > > Data" state to be entered from the "Join" state instead of > > > > the "Configure" > > > > state. > > > > > > This change was made as part of the state machine revisions > > > resulting from DTLS integration. The single exit from the Join > > state > > > to the Configure state was chosen for simplicity, and because > > which > > > image(s) the WTP has available (and which image should be the > > active > > > one) really is a matter of system configuration. I know someone on > > > > > this list argued that this is not configuration, but looking at it > > > this way provides a certain consistency and clean logic that is > > hard > > > to deny. > > > > > > What I think is more important though, and as you've noted in > > > previous posts, is that we have not clearly defined the criteria > > for > > > transitioning to image download. I think (based on your earlier > > > post) that you have very definite ideas on how this should be > > > managed, and I think what you've suggested makes sense. > > > > > > It seems like your suggestions would work fine with the state > > > machine as specified - in this case, the WTP sends the Configure > > > Request with it's current config, and that includes a list of > > > available images, and the current "active" image; if the AC wants > > > the WTP to reboot with a different image, this is accomplished by > > > changing the current "active" image in a Config Rsp message. > > > > > > If the AC wants the WTP to download a new image, it can follow the > > > same procedure, i.e. set the appropriate version for the current > > > active image; when the WTP determines that it does not have this > > > image stored locally, it transitions to the Image Data state, > > > fetches the new image, and reboots. > > > > > > I know there are a few missing details here, but does this address > > > > > your concerns in general? > > > > > > Scott > > > > > > > > > Scott > > > > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > > > > > > ------=_Part_12075_26601986.1150511789824 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
David,

Were you going to propose text to address this issue?
 
Thanks,
 
Mike

 
On 6/3/06, Michael Montemurro <montemurro.michael@gmail.com> wrote:
In any case, I've created issue 126 to track this.
 
Mike

 
On 6/3/06, Scott G Kelly <scott@hyperthought.com > wrote:
Hi Mike,

Michael Montemurro wrote:
> Scott,
>
> At the end of your reply, you mentioned that there were missing details
> here. Could you either enumerate the missing details or provide
> additional text to address them. I'll incorporate the changes into
> version -02
>
> Cheers,
>
> Mike

I think we need to fully specify the mechanism by which the version
communication takes place, and also who makes the decision (currently,
the language is a bit ambiguous, saying either the AC or WTP can intiate
the image download, but saying nothing about how they decide and do
contention resolution).

I think David is proposing making the version information/setting part
of the Join exchange, and transitioning directly to Image Data (without
ever entering Configure) if appropriate (or rebooting, if the desired
image is different than what is running, and is already stored on the WTP).

I don't feel strongly about this. I think David is preparing a proposal,
and that will have all the detail we need (David, please correct if I am
wrong about this).

Scott

>
>
> On 6/2/06, *Scott G. Kelly* <s.kelly@ix.netcom.com
> <mailto:s.kelly@ix.netcom.com >> wrote:
>
>     Hi David,
>
>      > The state machine shows that the "image data" state is
>      > entered after the "configure" state. However, the description
>      > of the state machine doesn't really match this. As currently
>      > specified, I believe that it would be clearer for the "Image
>      > Data" state to be entered from the "Join" state instead of
>      > the "Configure"
>      > state.
>
>     This change was made as part of the state machine revisions
>     resulting from DTLS integration. The single exit from the Join state
>     to the Configure state was chosen for simplicity, and because which
>     image(s) the WTP has available (and which image should be the active
>     one) really is a matter of system configuration. I know someone on
>     this list argued that this is not configuration, but looking at it
>     this way provides a certain consistency and clean logic that is hard
>     to deny.
>
>     What I think is more important though, and as you've noted in
>     previous posts, is that we have not clearly defined the criteria for
>     transitioning to image download. I think (based on your earlier
>     post) that you have very definite ideas on how this should be
>     managed, and I think what you've suggested makes sense.
>
>     It seems like your suggestions would work fine with the state
>     machine as specified - in this case, the WTP sends the Configure
>     Request with it's current config, and that includes a list of
>     available images, and the current "active" image; if the AC wants
>     the WTP to reboot with a different image, this is accomplished by
>     changing the current "active" image in a Config Rsp message.
>
>     If the AC wants the WTP to download a new image, it can follow the
>     same procedure, i.e. set the appropriate version for the current
>     active image; when the WTP determines that it does not have this
>     image stored locally, it transitions to the Image Data state,
>     fetches the new image, and reboots.
>
>     I know there are a few missing details here, but does this address
>     your concerns in general?
>
>     Scott
>
>
>     Scott
>
>     _________________________________________________________________
>     To unsubscribe or modify your subscription options, please visit:
>     http://lists.frascone.com/mailman/listinfo/capwap
>
>     Archives: http://lists.frascone.com/pipermail/capwap
>     <http://lists.frascone.com/pipermail/capwap>
>
>


------=_Part_12075_26601986.1150511789824-- --===============0033100206== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0033100206==-- From hunti@gelmart.com Sun Jun 18 06:07:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FruCC-0002Rj-Am for capwap-archive@ietf.org; Sun, 18 Jun 2006 06:07:56 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FruCC-000861-9V for capwap-archive@ietf.org; Sun, 18 Jun 2006 06:07:56 -0400 Received: from 136.25.98-84.rev.gaoland.net ([84.98.25.136] helo=gelmart.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FruCA-0003Px-Qy for capwap-archive@ietf.org; Sun, 18 Jun 2006 06:07:56 -0400 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 19 00:19:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsBE4-0004Cy-5y for capwap-archive@lists.ietf.org; Mon, 19 Jun 2006 00:19:00 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsBE1-000553-Rf for capwap-archive@lists.ietf.org; Mon, 19 Jun 2006 00:19:00 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 982D6430127 for ; Sun, 18 Jun 2006 21:18:56 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 2C7EC43008C for ; Sun, 18 Jun 2006 21:17:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 04A09398041 for ; Sun, 18 Jun 2006 21:17:49 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 736AD398008 for ; Sun, 18 Jun 2006 21:17:39 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060308/3.7W/jazz) with ESMTP id k5J4HXeR009607; Mon, 19 Jun 2006 13:17:33 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k5J4HZD19460; Mon, 19 Jun 2006 13:17:35 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with SMTP id k5J4HJO17508; Mon, 19 Jun 2006 13:17:19 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 19 Jun 2006 12:18:06 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDF718A6@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Thread-Index: AcaRr6xT6mQXDRTiRXGwmOmJzF77ZABovuyw From: "Saravanan Govindan" To: "Michael Montemurro" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.505 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_MESSAGE, NORMAL_HTTP_TO_IP X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1299983543==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 843ffb2d09f222e8b08c7d854819359d This is a multi-part message in MIME format. --===============1299983543== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69356.ED2063EB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69356.ED2063EB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mike,=20 =20 There are a number of designs for IEEE 802.11i. And I believe the description you noted below is one of them. In other designs, the sequence counter is maintained at the point where encryption is performed.=20 =20 >From my understanding of the update you mention to Add WLAN, the assumption seems to be the AC manages the transmit sequence counter. So by using the updated Add WLAN, the AC informs the WTP about the prevailing sequence counter value. Have I understood this right? If what I've got above is right, we are still left with the case where the sequence counter is maintained at the WTP. The Objectives highlights this as a mandatory requirement for the protocol.=20 =20 I'd appreciate if you could post the text relating to the update you mention for Add WLAN. This can help better understand how the update address both the designs.=20 =20 Cheers, =20 Saravanan =20 =20 =20 =20 =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Saturday, June 17, 2006 9:47 AM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 I have looked through IEEE 802.11i as well as talked with others who had implemented IEEE 802.11i. The treatment of the KeyRSC setting is not explained as well as it could be in the IEEE 802.11i draft. In many implementations, the Authenticator sets the transmit sequence counter with the new GTK and passes them both down to the MAC. The Authenticator then transmits this information to the STA as part of the GTK1 EAPoL message. Both the STA and the WTP will then begin using the new TSC and the group key to encrypt broadcast/multicast traffic.=20 =20 To address this in CAPWAP I have updated the AddWLAN message to include the transmit sequence counter for the GTK. That should address any issues with counters and key states. =20 Cheers, =20 Mike =20 On 6/7/06, Saravanan Govindan wrote:=20 Hi Mike,=20 =20 Following from my earlier note, this is the suggestion for handling KeyRSC maintained in a WTP.=20 =20 The suggestion is to include a new IEEE 802.11 specific CAPWAP control messages called "IEEE 802.11 Key Configuration".=20 =20 Following from CAPWAP Specifications-01; =20 CAPWAP Control Message Message Type Value =20 IEEE 802.11 Key Configuration 3398914 IEEE 802.11 Key Configuration Response 3398915 =20 =20 The suggested text follows; =20 [START OF SUGGESTED TEXT] =20 11.7.3. IEEE 802.11 Key Configuration =20 The IEEE 802.11 Key Configuration CAPWAP message is used in WTP designs in which IEEE 802.11i authenticator functions are performed by the AC and IEEE 802.11i cryptographic functions (encryption/decryption) are performed by the WTPs.=20 =20 This CAPWAP message is sent from the AC to the WTP. It must contain either of the following 2 message elements.=20 =20 =20 =20 =20 11.7.3.1 IEEE 802.11 4-way Handshake=20 =20 The IEEE 802.11 4-way Handshake message element is sent by the AC to the WTP during the 4-way handshake. It contains Message-3 of the 4-way handshake with unassigned values as the AC is unaware of the prevailing KeyRSC sequence counter maintained by the WTP. =20 =20 Message-1, Message-2 and Message-4 of the 4-way handshake are transported within CAPWAP data packets between AC and WTP.=20 =20 The IEEE 802.11 4-way Handshake message element contains the following values: =20 =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GTK-Flag | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encryption-Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAPoL-Frame | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =20 GTK-Flag: An 8-bit flag that determines the type of KeyMIC calculation =20 0 - New GTK, KeyMIC is calculated with KeyRSC =3D 0 =20 1 - Existing GTK, KeyMIC is calculated with prevailing KeyRSC value =20 Encryption-Data: Contains PTK and/or GTK =20 EAPoL-Frame: Contains Message-3 of 4-way handshake with unassigned fields =20 Upon receipt of the Key Configuration message from the AC, the WTP performs the following operations: =20 i. Assigns the corresponding value to the KeyRSC field of the EAPoL-Frame=20 ii. Calculates KeyMIC with Encrytion-Data and KeyRSC iii. Updates Message-3 of 4-way handshake iv. Continues regular 4-way handshake with wireless terminals =20 =20 =20 =20 11.7.3.2 IEEE 802.11 Group Key Handshake=20 =20 The IEEE 802.11 Group Key Handshake message element is sent by the AC to the WTP during the group key handshake. It contains Message-1 of the group key handshake with unassigned values as the AC is unaware of the prevailing KeyRSC sequence counter maintained by the WTP. =20 =20 Message-2 of the group key handshake is transported within a CAPWAP data packet between AC and WTP.=20 =20 The IEEE 802.11 Group Key Handshake message element contains the following values: =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GTK-Flag | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encryption-Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAPoL-Frame | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =20 GTK-Flag: An 8-bit flag that determines the type of KeyMIC calculation =20 0 - New GTK, KeyMIC is calculated with KeyRSC =3D 0 =20 1 - Existing GTK, KeyMIC is calculated with prevailing KeyRSC value =20 Encryption-Data: Contains PTK and/or GTK =20 EAPoL-Frame: Contains Message-1 of group key handshake with unassigned fields =20 Upon receipt of the Key Configuration message from AC, the WTP performs the following operations: i. Assigns the corresponding value to the KeyRSC field of the EAPoL-Frame=20 ii. Calculates KeyMIC with Encrytion-Data and KeyRSC iii. Updates Message-1 of group key handshake iv. Continues regular group handshake with wireless terminals =20 =20 =20 =20 11.7.4 IEEE 802.11 Key Configuration Response =20 The IEEE 802.11 Key Configuration Response CAPWAP message is sent by the WTP to the AC as an acknowledgement of the receipt of an IEEE 802.11 Key Configuration Request.=20 =20 [END OF SUGGESTED TEXT] =20 =20 =20 Saravanan =20 ------_=_NextPart_001_01C69356.ED2063EB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mike,

 

There are a number of designs for IEEE 802.11i. And I believe the description you noted below is one of them. In other = designs, the sequence counter is maintained at the point where encryption is = performed.

 

From my understanding of the update you mention to = Add WLAN, the assumption seems to be the AC manages the transmit sequence counter. = So by using the updated Add WLAN, the AC informs the WTP about the prevailing sequence counter value. Have I understood this right?

If what I’ve got above is right, we are still left with the case = where the sequence counter is maintained at the WTP. The Objectives highlights = this as a mandatory requirement for the protocol.

 

I’d appreciate if you could post the text = relating to the update you mention for Add WLAN. This can help better understand how = the update address both the designs.

 

Cheers,

 

Saravanan

 

 

 

 

 

From: = Michael Montemurro [mailto:montemurro.michael@gmail.com]
Sent: Saturday, June 17, = 2006 9:47 AM
To: Saravanan = Govindan
Cc: capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

 

Saravanan,

 

I have looked through IEEE 802.11i as well as talked with others = who had implemented IEEE 802.11i. The treatment of the KeyRSC setting is not explained as well as it could be in the IEEE 802.11i draft. In many implementations, the Authenticator sets the transmit sequence counter = with the new GTK and passes them both down to the MAC. The Authenticator then = transmits this information to the STA as part of the GTK1 EAPoL message. Both the = STA and the WTP will then begin using the new TSC and the group key to encrypt broadcast/multicast traffic.

 

To address this in CAPWAP I have updated the AddWLAN message to = include the transmit sequence counter for the GTK. That should address any = issues with counters and key states.

 

Cheers,

 

Mike



 

On 6/7/06, Saravanan Govindan <Saravanan.Govindan@sg= .panasonic.com> wrote:

Hi Mike,

 

Following from my earlier note, this is the suggestion = for handling KeyRSC maintained in a WTP.

 

The suggestion is to include a new IEEE 802.11 = specific CAPWAP control messages called "IEEE 802.11 Key = Configuration".

 

Following from CAPWAP = Specifications-01;

 

CAPWAP Control Message           =          Message Type

          &nb= sp;           &nbs= p;            = ;       Value

 

IEEE 802.11 Key Configuration          =    3398914

IEEE 802.11 Key Configuration = Response    3398915

 

 

The suggested text = follows;

 

[START OF SUGGESTED TEXT]

 

11.7.3. IEEE 802.11 Key = Configuration

 

The IEEE 802.11 Key Configuration CAPWAP message is = used in WTP designs in which IEEE 802.11i authenticator functions are performed = by the AC and IEEE 802.11i cryptographic functions (encryption/decryption) are performed by the WTPs.

 

This CAPWAP message is sent from the AC to the WTP. It = must contain either of the following 2 message elements. =

 

 

 

 

11.7.3.1     IEEE 802.11 4-way Handshake

 

The IEEE 802.11 = 4-way Handshake message element is sent by the AC to the WTP during the 4-way handshake. It contains Message-3 of the 4-way handshake with unassigned = values as the AC is unaware of the prevailing KeyRSC sequence counter = maintained by the WTP.  

 

Message-1, = Message-2 and Message-4 of the 4-way handshake are transported within CAPWAP data = packets between AC and WTP.

 

The IEEE 802.11 = 4-way Handshake message element contains the following = values:

 

 

      0            =        1            =        2            =        3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

     |    GTK-Flag   |             &= nbsp;     Reserved              &= nbsp;     |

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

     |            =             Encryption-Data               &= nbsp;        |=

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

     |            =               EAPoL-Frame =             &= nbsp;           &n= bsp;|

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

 

 

GTK-Flag: An 8-bit flag that determines the type of = KeyMIC calculation

    

     0 – New GTK, KeyMIC is calculated with KeyRSC =3D 0

 

     1 – Existing GTK, = KeyMIC is calculated with prevailing KeyRSC value

 

Encryption-Data: Contains PTK and/or = GTK

 

EAPoL-Frame: Contains Message-3 of 4-way handshake = with unassigned fields

 

Upon receipt of = the Key Configuration message from the AC, the WTP performs the following = operations:

 

    i.        = ;    Assigns the corresponding value to the = KeyRSC field of the EAPoL-Frame

ii.        = ;    Calculates KeyMIC with Encrytion-Data and = KeyRSC

iii.        = ;    Updates Message-3 of 4-way = handshake

iv.        = ;    Continues regular 4-way handshake with = wireless terminals

 

 

 

 

11.7.3.2     IEEE 802.11 Group Key Handshake

 

The IEEE 802.11 = Group Key Handshake message element is sent by the AC to the WTP during the group = key handshake. It contains Message-1 of the group key handshake with = unassigned values as the AC is unaware of the prevailing KeyRSC sequence counter = maintained by the WTP.  

 

Message-2 of the = group key handshake is transported within a CAPWAP data packet between AC and = WTP.

 

The IEEE 802.11 = Group Key Handshake message element contains the following = values:

 

      0            =        1            =        2            =        3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

     |    GTK-Flag   |             &= nbsp;     Reserved              &= nbsp;     |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

     |            =             Encryption-Data               &= nbsp;        |=

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

     |            =               EAPoL-Frame             &= nbsp;           &n= bsp;|

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

 

 

GTK-Flag: An 8-bit flag that determines the type of = KeyMIC calculation

    

     0 – New GTK, KeyMIC is calculated with KeyRSC =3D 0

 

     1 – Existing GTK, = KeyMIC is calculated with prevailing KeyRSC value

 

Encryption-Data: Contains PTK and/or = GTK

 

EAPoL-Frame: Contains Message-1 of group key handshake = with unassigned fields

 

Upon receipt of = the Key Configuration message from AC, the WTP performs the following = operations:

    i.        = ;    Assigns the corresponding value to the = KeyRSC field of the EAPoL-Frame

ii.        = ;    Calculates KeyMIC with Encrytion-Data and = KeyRSC

iii.        = ;    Updates Message-1 of group key = handshake

iv.        = ;    Continues regular group handshake with = wireless terminals

 

 

 

 

11.7.4     IEEE 802.11 Key = Configuration Response

 

The IEEE 802.11 Key Configuration Response CAPWAP = message is sent by the WTP to the AC as an acknowledgement of the receipt of an = IEEE 802.11 Key Configuration Request.

 

[END OF SUGGESTED TEXT]

 

 

 


Saravanan

 

------_=_NextPart_001_01C69356.ED2063EB-- --===============1299983543== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1299983543==-- From leathersliana@cordellcordell.com Mon Jun 19 07:33:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsI0J-0001MF-7f for capwap-archive@ietf.org; Mon, 19 Jun 2006 07:33:15 -0400 Received: from [217.216.2.104] (helo=cordellcordell.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FsI0H-0002tG-Vk for capwap-archive@ietf.org; Mon, 19 Jun 2006 07:33:15 -0400 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 19 13:29:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsNZW-0000sk-05 for capwap-archive@lists.ietf.org; Mon, 19 Jun 2006 13:29:58 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsNZT-0008Bk-AR for capwap-archive@lists.ietf.org; Mon, 19 Jun 2006 13:29:57 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 92365430121 for ; Mon, 19 Jun 2006 10:29:53 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 52CDC4300D0 for ; Mon, 19 Jun 2006 10:28:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3C5C9144800E for ; Mon, 19 Jun 2006 10:28:47 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id 2A9491448010 for ; Mon, 19 Jun 2006 10:28:41 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 19 Jun 2006 10:24:10 -0700 X-IronPort-AV: i="4.06,152,1149490800"; d="scan'208,217"; a="1828473524:sNHT3111273648" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5JHMiBU001771 for ; Mon, 19 Jun 2006 10:24:09 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5JHF3cL021526 for ; Mon, 19 Jun 2006 10:15:03 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 10:15:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jun 2006 10:15:04 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC01A7BBFE@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Thread-Index: AcaRr6xT6mQXDRTiRXGwmOmJzF77ZABovuywABtqjNA= From: "Bob O'Hara (boohara)" To: "capwap" X-OriginalArrivalTime: 19 Jun 2006 17:15:03.0675 (UTC) FILETIME=[E765C4B0:01C693C3] Authentication-Results: sj-dkim-8.cisco.com; header.From=boohara@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE, NORMAL_HTTP_TO_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1398795766==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 81ee38e455bef220e8259b2cf6016a24 This is a multi-part message in MIME format. --===============1398795766== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C693C3.E75930C7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C693C3.E75930C7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe that Mike is correct. There is no need to transfer the sequence counter from the WTP to the AC, if the AC is where the EAPOL messages are constructed and the WTP is where the sequence counters are maintained. A careful read of 802.11i on the use of that field will make this clear. -Bob =20 =20 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Sunday, June 18, 2006 9:18 PM To: Michael Montemurro Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Hi Mike,=20 =20 There are a number of designs for IEEE 802.11i. And I believe the description you noted below is one of them. In other designs, the sequence counter is maintained at the point where encryption is performed.=20 =20 >From my understanding of the update you mention to Add WLAN, the assumption seems to be the AC manages the transmit sequence counter. So by using the updated Add WLAN, the AC informs the WTP about the prevailing sequence counter value. Have I understood this right? If what I've got above is right, we are still left with the case where the sequence counter is maintained at the WTP. The Objectives highlights this as a mandatory requirement for the protocol.=20 =20 I'd appreciate if you could post the text relating to the update you mention for Add WLAN. This can help better understand how the update address both the designs.=20 =20 Cheers, =20 Saravanan =20 =20 =20 =20 =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Saturday, June 17, 2006 9:47 AM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 I have looked through IEEE 802.11i as well as talked with others who had implemented IEEE 802.11i. The treatment of the KeyRSC setting is not explained as well as it could be in the IEEE 802.11i draft. In many implementations, the Authenticator sets the transmit sequence counter with the new GTK and passes them both down to the MAC. The Authenticator then transmits this information to the STA as part of the GTK1 EAPoL message. Both the STA and the WTP will then begin using the new TSC and the group key to encrypt broadcast/multicast traffic.=20 =20 To address this in CAPWAP I have updated the AddWLAN message to include the transmit sequence counter for the GTK. That should address any issues with counters and key states. =20 Cheers, =20 Mike =20 On 6/7/06, Saravanan Govindan wrote:=20 Hi Mike,=20 =20 Following from my earlier note, this is the suggestion for handling KeyRSC maintained in a WTP.=20 =20 The suggestion is to include a new IEEE 802.11 specific CAPWAP control messages called "IEEE 802.11 Key Configuration".=20 =20 Following from CAPWAP Specifications-01; =20 CAPWAP Control Message Message Type Value =20 IEEE 802.11 Key Configuration 3398914 IEEE 802.11 Key Configuration Response 3398915 =20 =20 The suggested text follows; =20 [START OF SUGGESTED TEXT] =20 11.7.3. IEEE 802.11 Key Configuration =20 The IEEE 802.11 Key Configuration CAPWAP message is used in WTP designs in which IEEE 802.11i authenticator functions are performed by the AC and IEEE 802.11i cryptographic functions (encryption/decryption) are performed by the WTPs.=20 =20 This CAPWAP message is sent from the AC to the WTP. It must contain either of the following 2 message elements.=20 =20 =20 =20 =20 11.7.3.1 IEEE 802.11 4-way Handshake=20 =20 The IEEE 802.11 4-way Handshake message element is sent by the AC to the WTP during the 4-way handshake. It contains Message-3 of the 4-way handshake with unassigned values as the AC is unaware of the prevailing KeyRSC sequence counter maintained by the WTP. =20 =20 Message-1, Message-2 and Message-4 of the 4-way handshake are transported within CAPWAP data packets between AC and WTP.=20 =20 The IEEE 802.11 4-way Handshake message element contains the following values: =20 =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GTK-Flag | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encryption-Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAPoL-Frame | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =20 GTK-Flag: An 8-bit flag that determines the type of KeyMIC calculation =20 0 - New GTK, KeyMIC is calculated with KeyRSC =3D 0 =20 1 - Existing GTK, KeyMIC is calculated with prevailing KeyRSC value =20 Encryption-Data: Contains PTK and/or GTK =20 EAPoL-Frame: Contains Message-3 of 4-way handshake with unassigned fields =20 Upon receipt of the Key Configuration message from the AC, the WTP performs the following operations: =20 i. Assigns the corresponding value to the KeyRSC field of the EAPoL-Frame=20 ii. Calculates KeyMIC with Encrytion-Data and KeyRSC iii. Updates Message-3 of 4-way handshake iv. Continues regular 4-way handshake with wireless terminals =20 =20 =20 =20 11.7.3.2 IEEE 802.11 Group Key Handshake=20 =20 The IEEE 802.11 Group Key Handshake message element is sent by the AC to the WTP during the group key handshake. It contains Message-1 of the group key handshake with unassigned values as the AC is unaware of the prevailing KeyRSC sequence counter maintained by the WTP. =20 =20 Message-2 of the group key handshake is transported within a CAPWAP data packet between AC and WTP.=20 =20 The IEEE 802.11 Group Key Handshake message element contains the following values: =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GTK-Flag | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encryption-Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAPoL-Frame | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =20 GTK-Flag: An 8-bit flag that determines the type of KeyMIC calculation =20 0 - New GTK, KeyMIC is calculated with KeyRSC =3D 0 =20 1 - Existing GTK, KeyMIC is calculated with prevailing KeyRSC value =20 Encryption-Data: Contains PTK and/or GTK =20 EAPoL-Frame: Contains Message-1 of group key handshake with unassigned fields =20 Upon receipt of the Key Configuration message from AC, the WTP performs the following operations: i. Assigns the corresponding value to the KeyRSC field of the EAPoL-Frame=20 ii. Calculates KeyMIC with Encrytion-Data and KeyRSC iii. Updates Message-1 of group key handshake iv. Continues regular group handshake with wireless terminals =20 =20 =20 =20 11.7.4 IEEE 802.11 Key Configuration Response =20 The IEEE 802.11 Key Configuration Response CAPWAP message is sent by the WTP to the AC as an acknowledgement of the receipt of an IEEE 802.11 Key Configuration Request.=20 =20 [END OF SUGGESTED TEXT] =20 =20 =20 Saravanan =20 ------_=_NextPart_001_01C693C3.E75930C7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I believe that Mike is correct.  There = is no need=20 to transfer the sequence counter from the WTP to the AC, if the AC is = where the=20 EAPOL messages are constructed and the WTP is where the sequence = counters are=20 maintained.  A careful read of 802.11i on the use of that = field will=20 make this clear.

 -Bob
 

 

From: Saravanan Govindan=20 [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: Sunday, = June 18,=20 2006 9:18 PM
To: Michael Montemurro
Cc:=20 capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE = 802.11i=20 Considerations

Hi Mike,=20

 

There are a number of = designs for=20 IEEE 802.11i. And I believe the description you noted below is one of = them. In=20 other designs, the sequence counter is maintained at the point where = encryption=20 is performed.

 

From my understanding of = the update=20 you mention to Add WLAN, the assumption seems to be the AC manages the = transmit=20 sequence counter. So by using the updated Add WLAN, the AC informs the = WTP about=20 the prevailing sequence counter value. Have I understood this = right?

If=20 what I’ve got above is right, we are still left with the case = where the sequence=20 counter is maintained at the WTP. The Objectives highlights this as a = mandatory=20 requirement for the protocol.

 

I’d appreciate if = you could post the=20 text relating to the update you mention for Add WLAN. This can help = better=20 understand how the update address both the designs.=20

 

Cheers,

 

Saravanan

 

 

 

 

 

From: Michael=20 Montemurro [mailto:montemurro.michael@gmail.com]
Sent: Saturday, June 17, 2006 = 9:47=20 AM
To: Saravanan=20 Govindan
Cc: = capwap
Subject: Re: [Capwap] = Clarification of=20 Issue 43: IEEE 802.11i Considerations

 

Saravanan,

 

I have looked through IEEE 802.11i as well as = talked=20 with others who had implemented IEEE 802.11i. The treatment of the = KeyRSC=20 setting is not explained as well as it could be in the IEEE 802.11i = draft. In=20 many implementations, the Authenticator sets the transmit sequence = counter with=20 the new GTK and passes them both down to the MAC. The Authenticator then = transmits this information to the STA as part of the GTK1 EAPoL message. = Both=20 the STA and the WTP will then begin using the new TSC and the group key = to=20 encrypt broadcast/multicast traffic.

 

To address this in CAPWAP I have updated the = AddWLAN=20 message to include the transmit sequence counter for the GTK. That = should=20 address any issues with counters and key=20 states.

 

Cheers,

 

Mike



 

On 6/7/06, Saravanan Govindan <Saravanan.Govindan@sg= .panasonic.com>=20 wrote:

Hi Mike,=20

 

Following from = my earlier=20 note, this is the suggestion for handling KeyRSC maintained in a WTP.=20

 

The suggestion = is to=20 include a new IEEE 802.11 specific CAPWAP control messages called "IEEE = 802.11=20 Key Configuration".

 

Following from = CAPWAP=20 Specifications-01;

 

CAPWAP Control=20 Message           =         =20 Message Type

          &nb= sp;           &nbs= p;            = ;      =20 Value

 

IEEE 802.11 Key = Configuration          =   =20 3398914

IEEE 802.11 Key = Configuration Response    = 3398915

 

 

The suggested = text=20 follows;

 

[START OF = SUGGESTED=20 TEXT]

 

11.7.3. IEEE = 802.11 Key=20 Configuration

 

The IEEE 802.11 = Key=20 Configuration CAPWAP message is used in WTP designs in which IEEE = 802.11i=20 authenticator functions are performed by the AC and IEEE 802.11i = cryptographic=20 functions (encryption/decryption) are performed by the WTPs.=20

 

This CAPWAP = message is=20 sent from the AC to the WTP. It must contain either of the following 2 = message=20 elements.

 

 

 

 

11.7.3.1     IEEE=20 802.11 4-way Handshake

 

The IEEE 802.11 = 4-way=20 Handshake message element is sent by the AC to the WTP during the 4-way=20 handshake. It contains Message-3 of the 4-way handshake with unassigned = values=20 as the AC is unaware of the prevailing KeyRSC sequence counter = maintained by the=20 WTP.  

 

Message-1, = Message-2 and=20 Message-4 of the 4-way handshake are transported within CAPWAP data = packets=20 between AC and WTP.

 

The IEEE 802.11 = 4-way=20 Handshake message element contains the following=20 values:

 

 

     =20 0            =       =20 1            =       =20 2            =       =20 3

     =20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0=20 1

    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /FONT>

    =20 |    GTK-Flag   |=20             &= nbsp;     Reserved =20             &= nbsp;     |

    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /FONT>

    =20 |            =       =20      Encryption-Data  =20             &= nbsp;        |=

    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /FONT>

    =20 |            =       =20        EAPoL-Frame=20             &= nbsp;           &n= bsp;|

    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /FONT>

 

 

GTK-Flag: An = 8-bit flag=20 that determines the type of KeyMIC = calculation

    =20

    =20 0 – New GTK, KeyMIC is calculated with KeyRSC =3D = 0

 

    =20 1 – Existing GTK, KeyMIC is calculated with prevailing KeyRSC=20 value

 

Encryption-Data: Contains=20 PTK and/or GTK

 

EAPoL-Frame: = Contains=20 Message-3 of 4-way handshake with unassigned = fields

 

Upon receipt of = the Key=20 Configuration message from the AC, the WTP performs the following=20 operations:

 

   =20 i.           = =20 Assigns the = corresponding=20 value to the KeyRSC field of the EAPoL-Frame =

ii.           = =20 Calculates = KeyMIC with=20 Encrytion-Data and KeyRSC

iii.           = =20 Updates = Message-3 of=20 4-way handshake

iv.           = =20 Continues = regular 4-way=20 handshake with wireless terminals

 

 

 

 

11.7.3.2     IEEE=20 802.11 Group Key Handshake

 

The IEEE 802.11 = Group Key=20 Handshake message element is sent by the AC to the WTP during the group = key=20 handshake. It contains Message-1 of the group key handshake with = unassigned=20 values as the AC is unaware of the prevailing KeyRSC sequence counter = maintained=20 by the WTP.  

 

Message-2 of = the group=20 key handshake is transported within a CAPWAP data packet between AC and = WTP.=20

 

The IEEE 802.11 = Group Key=20 Handshake message element contains the following=20 values:

 

     =20 0            =       =20 1            =       =20 2            =       =20 3

     =20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0=20 1

    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /FONT>

    =20 |    GTK-Flag   |=20             &= nbsp;     Reserved =20             &= nbsp;     |

    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /FONT>

    =20 |            =       =20      Encryption-Data  =20             &= nbsp;        |=

    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /FONT>

    =20 |            =       =20        EAPoL-Frame=20             &= nbsp;           &n= bsp;|

    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /FONT>

 

 

GTK-Flag: An = 8-bit flag=20 that determines the type of KeyMIC = calculation

    =20

    =20 0 – New GTK, KeyMIC is calculated with KeyRSC =3D = 0

 

    =20 1 – Existing GTK, KeyMIC is calculated with prevailing KeyRSC=20 value

 

Encryption-Data: Contains=20 PTK and/or GTK

 

EAPoL-Frame: = Contains=20 Message-1 of group key handshake with unassigned=20 fields

 

Upon receipt of = the Key=20 Configuration message from AC, the WTP performs the following=20 operations:

   =20 i.           = =20 Assigns the = corresponding=20 value to the KeyRSC field of the EAPoL-Frame =

ii.           = =20 Calculates = KeyMIC with=20 Encrytion-Data and KeyRSC

iii.           = =20 Updates = Message-1 of=20 group key handshake

iv.           = =20 Continues = regular group=20 handshake with wireless terminals

 

 

 

 

11.7.4    =20 IEEE 802.11 Key Configuration Response

 

The IEEE 802.11 = Key=20 Configuration Response CAPWAP message is sent by the WTP to the AC as an = acknowledgement of the receipt of an IEEE 802.11 Key Configuration = Request.=20

 

[END OF = SUGGESTED=20 TEXT]

 

 

 


Saravanan

 

------_=_NextPart_001_01C693C3.E75930C7-- --===============1398795766== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1398795766==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 19 18:58:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsSh4-0007Nd-Ta for capwap-archive@lists.ietf.org; Mon, 19 Jun 2006 18:58:07 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsSgz-0006es-WE for capwap-archive@lists.ietf.org; Mon, 19 Jun 2006 18:58:06 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id F3DDA430121 for ; Mon, 19 Jun 2006 15:58:00 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9DCBE4300D0 for ; Mon, 19 Jun 2006 15:57:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 81CE21448005 for ; Mon, 19 Jun 2006 15:57:39 -0700 (PDT) Received: from smtpauth08.mail.atl.earthlink.net (smtpauth08.mail.atl.earthlink.net [209.86.89.68]) by hermes.tigertech.net (Postfix) with ESMTP id D44041448017 for ; Mon, 19 Jun 2006 15:57:36 -0700 (PDT) Received: from [209.86.224.33] (helo=elwamui-darkeyed.atl.sa.earthlink.net) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1FsSga-0001FP-3A for capwap@frascone.com; Mon, 19 Jun 2006 18:57:36 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Mon, 19 Jun 2006 18:57:36 -0400 Message-ID: <9840444.1150757856115.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Date: Mon, 19 Jun 2006 15:57:36 -0700 (GMT-07:00) From: "Scott G. Kelly" To: capwap Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff7109f3be3dd1a5800849adf0114c36ba329350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.33 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [Capwap] vsp definition has no length X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Here's the current vendor-specific payload definition: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Element ID | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wouldn't something like this make more sense? 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Element ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value.... +-+-+-+-+-+-+- --Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 19 19:34:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTG6-0003x8-Hf for capwap-archive@lists.ietf.org; Mon, 19 Jun 2006 19:34:18 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsTG2-0001Ai-12 for capwap-archive@lists.ietf.org; Mon, 19 Jun 2006 19:34:18 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9D492430179 for ; Mon, 19 Jun 2006 16:34:10 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E83874300D0 for ; Mon, 19 Jun 2006 16:33:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D7E5939800D for ; Mon, 19 Jun 2006 16:33:46 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A2B52398025 for ; Mon, 19 Jun 2006 16:33:43 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5JNXhGK016791; Mon, 19 Jun 2006 16:33:43 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5JNXgsi016787; Mon, 19 Jun 2006 16:33:43 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Mon, 19 Jun 2006 16:33:42 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Scott G. Kelly" In-Reply-To: <9840444.1150757856115.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap Subject: Re: [Capwap] vsp definition has no length X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be HI, You left off the outside wrapper as is specified in CAPWAP-01. Thus, you currently have, as defined in section 4.4, "CAPWAP Protocol Message Elements", and section 4.4.32, "Vendor Specific Payload" for vendor message elements: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=43 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Element ID | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^-don't need length here Thus, you don't need an additional "length". In the CAPWAP packet formats that I sent out some time ago, I proposed that there be no difference in format between "CAPWAP STD message elements" and "CAPWAP vendor specific message elements". Both would have the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Element Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Value .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Where the encoding of "message element type" is Message element type value = IANA Enterprise Number * 4096 + enterprise specific message element type number (and for CAPWAP standard, zero is used for the value IANA Enterprise number) This results in 12 bits (0-4095) for element types, and 20 bits (0-1048575) for Enterprise numbers. If you look at OUI assignments, which have been around a lot longer than enterprise numbers, they have approximately 52K allocated. Thus, 64k (16 bits), is probably not enough, and 1M (20 bits) looks big enough. Regards, /david t. perkins On Mon, 19 Jun 2006, Scott G. Kelly wrote: > Here's the current vendor-specific payload definition: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Element ID | Value... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Wouldn't something like this make more sense? > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length | Element ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value.... > +-+-+-+-+-+-+- > > > --Scott > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 19 19:59:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTeh-0002gP-N6 for capwap-archive@lists.ietf.org; Mon, 19 Jun 2006 19:59:43 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsTeg-0003d6-94 for capwap-archive@lists.ietf.org; Mon, 19 Jun 2006 19:59:43 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5EE7F43016F for ; Mon, 19 Jun 2006 16:59:41 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A446B430071 for ; Mon, 19 Jun 2006 16:59:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9478B39801A for ; Mon, 19 Jun 2006 16:59:19 -0700 (PDT) Received: from smtpauth08.mail.atl.earthlink.net (smtpauth08.mail.atl.earthlink.net [209.86.89.68]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8444B39802E for ; Mon, 19 Jun 2006 16:59:16 -0700 (PDT) Received: from [209.86.224.33] (helo=elwamui-darkeyed.atl.sa.earthlink.net) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1FsTeF-0007Ha-Fk; Mon, 19 Jun 2006 19:59:15 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Mon, 19 Jun 2006 19:59:15 -0400 Message-ID: <8284646.1150761555508.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Date: Mon, 19 Jun 2006 16:59:15 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "David T. Perkins" , "Scott G. Kelly" Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710830fe0673dfda9336ff269f8c5be1cd9350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.33 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap Subject: Re: [Capwap] vsp definition has no length X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi David, >You left off the outside wrapper as is specified in CAPWAP-01. > >Thus, you currently have, as defined in section 4.4, >"CAPWAP Protocol Message Elements", and section 4.4.32, >"Vendor Specific Payload" for vendor message elements: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type=43 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Element ID | Value... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ^-don't need length here >Thus, you don't need an additional "length". Doh! Okay, I get it now - a little slow this afternoon.... --Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 19 21:37:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsVB3-0000cU-Lb for capwap-archive@lists.ietf.org; Mon, 19 Jun 2006 21:37:13 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsVB1-0008Dk-4h for capwap-archive@lists.ietf.org; Mon, 19 Jun 2006 21:37:13 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0A9C843014A for ; Mon, 19 Jun 2006 18:37:10 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2CC4F430071 for ; Mon, 19 Jun 2006 18:36:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 08E461448019 for ; Mon, 19 Jun 2006 18:36:02 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 7A37D1448005 for ; Mon, 19 Jun 2006 18:35:57 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060308/3.7W/kings) with ESMTP id k5K1ZqbY004668; Tue, 20 Jun 2006 10:35:52 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k5K1Zso23365; Tue, 20 Jun 2006 10:35:54 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with SMTP id k5K1Zst21432; Tue, 20 Jun 2006 10:35:54 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 20 Jun 2006 09:36:38 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDF719CD@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Thread-Index: AcaRr6xT6mQXDRTiRXGwmOmJzF77ZABovuywABtqjNAAEdU2EA== From: "Saravanan Govindan" To: "Bob O'Hara (boohara)" , "capwap" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_MESSAGE, NORMAL_HTTP_TO_IP X-Spam-Level: Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0183154066==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 2a6302342db55286d442508955963936 This is a multi-part message in MIME format. --===============0183154066== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69409.879ADBE9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69409.879ADBE9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Consider the 4-way handshake in architecture designs where the WTP maintains the Key-RSC and the AC constructs EAPOL messages (this is one of the major designs brought out in the Architecture Taxonomy). Now, to construct Message 3 of the 4-way handshake, the AC computes the Key-MIC based on the prevailing Key-RSC. Since the Key-RSC is maintained by the WTP, there needs to be some way to transfer this information to the AC.=20 =20 I am open to a different way of doing this from what I've suggested earlier - using of separate Key Configuration message. My concern is only to see that this can be accomplished in the CAPWAP protocol. =20 Saravanan =20 =20 =20 ________________________________ From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Tuesday, June 20, 2006 1:15 AM To: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 I believe that Mike is correct. There is no need to transfer the sequence counter from the WTP to the AC, if the AC is where the EAPOL messages are constructed and the WTP is where the sequence counters are maintained. A careful read of 802.11i on the use of that field will make this clear. -Bob =20 =20 =20 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Sunday, June 18, 2006 9:18 PM To: Michael Montemurro Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Hi Mike,=20 =20 There are a number of designs for IEEE 802.11i. And I believe the description you noted below is one of them. In other designs, the sequence counter is maintained at the point where encryption is performed.=20 =20 >From my understanding of the update you mention to Add WLAN, the assumption seems to be the AC manages the transmit sequence counter. So by using the updated Add WLAN, the AC informs the WTP about the prevailing sequence counter value. Have I understood this right? If what I've got above is right, we are still left with the case where the sequence counter is maintained at the WTP. The Objectives highlights this as a mandatory requirement for the protocol.=20 =20 I'd appreciate if you could post the text relating to the update you mention for Add WLAN. This can help better understand how the update address both the designs.=20 =20 Cheers, =20 Saravanan =20 =20 =20 =20 =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Saturday, June 17, 2006 9:47 AM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 I have looked through IEEE 802.11i as well as talked with others who had implemented IEEE 802.11i. The treatment of the KeyRSC setting is not explained as well as it could be in the IEEE 802.11i draft. In many implementations, the Authenticator sets the transmit sequence counter with the new GTK and passes them both down to the MAC. The Authenticator then transmits this information to the STA as part of the GTK1 EAPoL message. Both the STA and the WTP will then begin using the new TSC and the group key to encrypt broadcast/multicast traffic.=20 =20 To address this in CAPWAP I have updated the AddWLAN message to include the transmit sequence counter for the GTK. That should address any issues with counters and key states. =20 Cheers, =20 Mike =20 On 6/7/06, Saravanan Govindan wrote:=20 Hi Mike,=20 =20 Following from my earlier note, this is the suggestion for handling KeyRSC maintained in a WTP.=20 =20 The suggestion is to include a new IEEE 802.11 specific CAPWAP control messages called "IEEE 802.11 Key Configuration".=20 =20 Following from CAPWAP Specifications-01; =20 CAPWAP Control Message Message Type Value =20 IEEE 802.11 Key Configuration 3398914 IEEE 802.11 Key Configuration Response 3398915 =20 =20 The suggested text follows; =20 [START OF SUGGESTED TEXT] =20 11.7.3. IEEE 802.11 Key Configuration =20 The IEEE 802.11 Key Configuration CAPWAP message is used in WTP designs in which IEEE 802.11i authenticator functions are performed by the AC and IEEE 802.11i cryptographic functions (encryption/decryption) are performed by the WTPs.=20 =20 This CAPWAP message is sent from the AC to the WTP. It must contain either of the following 2 message elements.=20 =20 =20 =20 =20 11.7.3.1 IEEE 802.11 4-way Handshake=20 =20 The IEEE 802.11 4-way Handshake message element is sent by the AC to the WTP during the 4-way handshake. It contains Message-3 of the 4-way handshake with unassigned values as the AC is unaware of the prevailing KeyRSC sequence counter maintained by the WTP. =20 =20 Message-1, Message-2 and Message-4 of the 4-way handshake are transported within CAPWAP data packets between AC and WTP.=20 =20 The IEEE 802.11 4-way Handshake message element contains the following values: =20 =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GTK-Flag | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encryption-Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAPoL-Frame | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =20 GTK-Flag: An 8-bit flag that determines the type of KeyMIC calculation =20 0 - New GTK, KeyMIC is calculated with KeyRSC =3D 0 =20 1 - Existing GTK, KeyMIC is calculated with prevailing KeyRSC value =20 Encryption-Data: Contains PTK and/or GTK =20 EAPoL-Frame: Contains Message-3 of 4-way handshake with unassigned fields =20 Upon receipt of the Key Configuration message from the AC, the WTP performs the following operations: =20 i. Assigns the corresponding value to the KeyRSC field of the EAPoL-Frame=20 ii. Calculates KeyMIC with Encrytion-Data and KeyRSC iii. Updates Message-3 of 4-way handshake iv. Continues regular 4-way handshake with wireless terminals =20 =20 =20 =20 11.7.3.2 IEEE 802.11 Group Key Handshake=20 =20 The IEEE 802.11 Group Key Handshake message element is sent by the AC to the WTP during the group key handshake. It contains Message-1 of the group key handshake with unassigned values as the AC is unaware of the prevailing KeyRSC sequence counter maintained by the WTP. =20 =20 Message-2 of the group key handshake is transported within a CAPWAP data packet between AC and WTP.=20 =20 The IEEE 802.11 Group Key Handshake message element contains the following values: =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GTK-Flag | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encryption-Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAPoL-Frame | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =20 GTK-Flag: An 8-bit flag that determines the type of KeyMIC calculation =20 0 - New GTK, KeyMIC is calculated with KeyRSC =3D 0 =20 1 - Existing GTK, KeyMIC is calculated with prevailing KeyRSC value =20 Encryption-Data: Contains PTK and/or GTK =20 EAPoL-Frame: Contains Message-1 of group key handshake with unassigned fields =20 Upon receipt of the Key Configuration message from AC, the WTP performs the following operations: i. Assigns the corresponding value to the KeyRSC field of the EAPoL-Frame=20 ii. Calculates KeyMIC with Encrytion-Data and KeyRSC iii. Updates Message-1 of group key handshake iv. Continues regular group handshake with wireless terminals =20 =20 =20 =20 11.7.4 IEEE 802.11 Key Configuration Response =20 The IEEE 802.11 Key Configuration Response CAPWAP message is sent by the WTP to the AC as an acknowledgement of the receipt of an IEEE 802.11 Key Configuration Request.=20 =20 [END OF SUGGESTED TEXT] =20 =20 =20 Saravanan =20 ------_=_NextPart_001_01C69409.879ADBE9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Consider the 4-way handshake in architecture designs = where the WTP maintains the Key-RSC and the AC constructs EAPOL messages (this = is one of the major designs brought out in the Architecture Taxonomy). Now, to construct Message 3 of the 4-way handshake, the AC computes the Key-MIC = based on the prevailing Key-RSC. Since the Key-RSC is maintained by the WTP, = there needs to be some way to transfer this information to the AC. =

 

I am open to a different way of doing this from what = I’ve suggested earlier – using of separate Key Configuration message. = My concern is only to see that this can be accomplished in the CAPWAP = protocol.

 

Saravanan

 

 

 

From: Bob = O'Hara (boohara) [mailto:boohara@cisco.com]
Sent: Tuesday, June 20, = 2006 1:15 AM
To: capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

 

I believe that Mike is = correct.  There is no need to transfer the sequence counter from the WTP to the = AC, if the AC is where the EAPOL messages are constructed and the WTP is where = the sequence counters are maintained.  A careful read of 802.11i = on the use of that field will make this clear.

 -Bob
 

 

 

From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: Sunday, June 18, = 2006 9:18 PM
To: Michael = Montemurro
Cc: capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

Hi Mike,

 

There are a number of designs for IEEE 802.11i. And I believe the description you noted below is one of them. In other = designs, the sequence counter is maintained at the point where encryption is = performed.

 

From my understanding of the update you mention to = Add WLAN, the assumption seems to be the AC manages the transmit sequence counter. = So by using the updated Add WLAN, the AC informs the WTP about the prevailing sequence counter value. Have I understood this right?

If what I’ve got above is right, we are still left with the case = where the sequence counter is maintained at the WTP. The Objectives highlights = this as a mandatory requirement for the protocol. =

 

I’d appreciate if you could post the text = relating to the update you mention for Add WLAN. This can help better understand how = the update address both the designs.

 

Cheers,

 

Saravanan

 

 

 

 

 

From: = Michael Montemurro [mailto:montemurro.michael@gmail.com]
Sent: Saturday, June 17, = 2006 9:47 AM
To: Saravanan Govindan
Cc: capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

 

Saravanan,

 

I have looked through IEEE 802.11i as well as talked with others = who had implemented IEEE 802.11i. The treatment of the KeyRSC setting is not explained as well as it could be in the IEEE 802.11i draft. In many implementations, the Authenticator sets the transmit sequence counter = with the new GTK and passes them both down to the MAC. The Authenticator then = transmits this information to the STA as part of the GTK1 EAPoL message. Both the = STA and the WTP will then begin using the new TSC and the group key to encrypt broadcast/multicast traffic.

 

To address this in CAPWAP I have updated the AddWLAN message to = include the transmit sequence counter for the GTK. That should address any = issues with counters and key states.

 

Cheers,

 

Mike



 

On 6/7/06, Saravanan = Govindan <Saravanan.Govindan@sg= .panasonic.com> wrote:

Hi Mike,

 

Following from my earlier note, this is the suggestion = for handling KeyRSC maintained in a WTP.

 

The suggestion is to include a new IEEE 802.11 = specific CAPWAP control messages called "IEEE 802.11 Key = Configuration".

 

Following from CAPWAP = Specifications-01;

 

CAPWAP Control Message           =          Message Type

          &nb= sp;           &nbs= p;            = ;       Value

 

IEEE 802.11 Key Configuration          =    3398914

IEEE 802.11 Key Configuration = Response    3398915

 

 

The suggested text = follows;

 

[START OF SUGGESTED TEXT]

 

11.7.3. IEEE 802.11 Key = Configuration

 

The IEEE 802.11 Key Configuration CAPWAP message is = used in WTP designs in which IEEE 802.11i authenticator functions are performed = by the AC and IEEE 802.11i cryptographic functions (encryption/decryption) are performed by the WTPs.

 

This CAPWAP message is sent from the AC to the WTP. It = must contain either of the following 2 message elements. =

 

 

 

 

11.7.3.1     IEEE 802.11 4-way Handshake

 

The IEEE 802.11 = 4-way Handshake message element is sent by the AC to the WTP during the 4-way handshake. It contains Message-3 of the 4-way handshake with unassigned = values as the AC is unaware of the prevailing KeyRSC sequence counter = maintained by the WTP.  

 

Message-1, = Message-2 and Message-4 of the 4-way handshake are transported within CAPWAP data = packets between AC and WTP.

 

The IEEE 802.11 = 4-way Handshake message element contains the following = values:

 

 

      0            =        1            =        2            =        3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

     |    GTK-Flag   |             &= nbsp;     Reserved              &= nbsp;     |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

     |            =             Encryption-Data               &= nbsp;        |=

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

     |            =               EAPoL-Frame             &= nbsp;           &n= bsp;|

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

 

 

GTK-Flag: An 8-bit flag that determines the type of = KeyMIC calculation

    

     0 – New GTK, KeyMIC is calculated with KeyRSC =3D 0

 

     1 – Existing GTK, = KeyMIC is calculated with prevailing KeyRSC value

 

Encryption-Data: Contains PTK and/or = GTK

 

EAPoL-Frame: Contains Message-3 of 4-way handshake = with unassigned fields

 

Upon receipt of = the Key Configuration message from the AC, the WTP performs the following = operations:

 

    i.        = ;    Assigns the corresponding value to the = KeyRSC field of the EAPoL-Frame

ii.        = ;    Calculates KeyMIC with Encrytion-Data and = KeyRSC

iii.        = ;    Updates Message-3 of 4-way = handshake

iv.        = ;    Continues regular 4-way handshake with = wireless terminals

 

 

 

 

11.7.3.2     IEEE 802.11 Group Key Handshake

 

The IEEE 802.11 = Group Key Handshake message element is sent by the AC to the WTP during the group = key handshake. It contains Message-1 of the group key handshake with = unassigned values as the AC is unaware of the prevailing KeyRSC sequence counter maintained by the WTP.  

 

Message-2 of the = group key handshake is transported within a CAPWAP data packet between AC and = WTP.

 

The IEEE 802.11 = Group Key Handshake message element contains the following = values:

 

      0            =        1            =        2            =        3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

     |    GTK-Flag   |             &= nbsp;     Reserved              &= nbsp;     |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

     |            =             Encryption-Data               &= nbsp;        |=

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

     |            =               EAPoL-Frame             &= nbsp;           &n= bsp;|

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

 

 

GTK-Flag: An 8-bit flag that determines the type of = KeyMIC calculation

    

     0 – New GTK, KeyMIC is calculated with KeyRSC =3D 0

 

     1 – Existing GTK, = KeyMIC is calculated with prevailing KeyRSC value

 

Encryption-Data: Contains PTK and/or = GTK

 

EAPoL-Frame: Contains Message-1 of group key handshake = with unassigned fields

 

Upon receipt of = the Key Configuration message from AC, the WTP performs the following = operations:

    i.        = ;    Assigns the corresponding value to the = KeyRSC field of the EAPoL-Frame

ii.        = ;    Calculates KeyMIC with Encrytion-Data and = KeyRSC

iii.        = ;    Updates Message-1 of group key = handshake

iv.        = ;    Continues regular group handshake with = wireless terminals

 

 

 

 

11.7.4     IEEE 802.11 Key = Configuration Response

 

The IEEE 802.11 Key Configuration Response CAPWAP = message is sent by the WTP to the AC as an acknowledgement of the receipt of an = IEEE 802.11 Key Configuration Request.

 

[END OF SUGGESTED TEXT]

 

 

 


Saravanan

 

------_=_NextPart_001_01C69409.879ADBE9-- --===============0183154066== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0183154066==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 19 21:43:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsVHX-0005JE-0F for capwap-archive@lists.ietf.org; Mon, 19 Jun 2006 21:43:55 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsVHT-00013s-GQ for capwap-archive@lists.ietf.org; Mon, 19 Jun 2006 21:43:54 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 261F2430160 for ; Mon, 19 Jun 2006 18:43:51 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 9D27C430071 for ; Mon, 19 Jun 2006 18:43:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6512539802C for ; Mon, 19 Jun 2006 18:43:27 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 57DFE39801A for ; Mon, 19 Jun 2006 18:43:25 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 19 Jun 2006 18:43:23 -0700 X-IronPort-AV: i="4.06,153,1149490800"; d="scan'208"; a="297500991:sNHT3313582384" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5K1hNBx005167; Mon, 19 Jun 2006 18:43:23 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5K1hNCU021029; Mon, 19 Jun 2006 18:43:23 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 18:43:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jun 2006 18:43:23 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20210874A@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] VLAN name in (section 4.4.8)Add Mobile Station Thread-Index: AcaQD0IIWvwexX8YQQST0rn+uo4uOQD6xd7Q From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" , X-OriginalArrivalTime: 20 Jun 2006 01:43:23.0345 (UTC) FILETIME=[EA9E1410:01C6940A] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] VLAN name in (section 4.4.8)Add Mobile Station X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Given we are sending a VLAN "name", the actual VLAN identifier (tag) may differ across WTPs. I don't understand the issue. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Wednesday, June 14, 2006 5:04 PM > To: capwap@frascone.com > Subject: [Capwap] VLAN name in (section 4.4.8)Add Mobile Station > > HI, > > The message element (4.4.8)Add Modile Station has subfield > "VLAN name". However, there are no CAPWAP messages or message > elements for VLAN names on a WTP to be managed by the the AC. > (A value for a VLAN Name is only approapriate for a localMAC > WTP.) Managed means to find out the list of the VLAN names, > create VLANs and apply attributes, modify VLAN attributes, > and delete VLANs. The attributes include the VLAN name, and > ports:tag pairs in the VLAN. (By the way, this is sort of an > expansion of CAPWAP, but it is the price to pay to support localMAC.) > > For example, consider a localMAC WTP with 4 802.3 ports. > It could have the following configuration: > > VLAN RED - members: port 1:untagged, port 2:tag 23, > port 4:tag 56 > VLAN GREEN - members: port 1:tag 96, port 2:tag 103 VLAN > YELLOW - members: port 1:tag 200, port 4:untagged (Port 3 is > not a member of any VLAN) > > This is not simple, esspecially since there may be > restrictions, such as 1) all ports in a VLAN must use the same tag, or > 2) a port can be either a TRUNK port or a feeder port and > feeder ports are untagged, and the VLANs on the trunk port > must be all tagged. (I've seen many different sets of limitations.) > > I'm not sure what to suggest, other than to drop support for > localMAC WTPs (only joking). > > Regards, > /david t. perkins > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 19 21:44:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsVHv-0005M1-Mb for capwap-archive@lists.ietf.org; Mon, 19 Jun 2006 21:44:19 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsVHu-00014h-7S for capwap-archive@lists.ietf.org; Mon, 19 Jun 2006 21:44:19 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D917F430127 for ; Mon, 19 Jun 2006 18:44:17 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 87C86430122 for ; Mon, 19 Jun 2006 18:43:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 79A9439802C for ; Mon, 19 Jun 2006 18:43:30 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 99F7E39801A for ; Mon, 19 Jun 2006 18:43:26 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 19 Jun 2006 18:43:26 -0700 X-IronPort-AV: i="4.06,153,1149490800"; d="scan'208"; a="297501003:sNHT34464230" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5K1hQoA025350; Mon, 19 Jun 2006 18:43:26 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5K1hQCU021051; Mon, 19 Jun 2006 18:43:26 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 18:43:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jun 2006 18:43:25 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20210874B@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Consistent range for radio ID and WLAN ID Thread-Index: AcaQQqVD7DqF1v+WQf+IzuQAdrhIvwDt9eZQ From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" , X-OriginalArrivalTime: 20 Jun 2006 01:43:26.0109 (UTC) FILETIME=[EC43D4D0:01C6940A] Authentication-Results: sj-dkim-4.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Consistent range for radio ID and WLAN ID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Note that since we don't need a full 8 bits, we opted to conserve space in the capwap header. However, as far as the rest of the protocol is concerned, we should us a consistent length, but byte aligned. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Wednesday, June 14, 2006 11:12 PM > To: capwap@frascone.com > Subject: [Capwap] Consistent range for radio ID and WLAN ID > > HI, > > I've seen several places where the range of the Radio ID and > WLAN ID is inconsistant. > > In section 4.1, in the transport header, the RID is > 5 bits (a range of 0-31), but in section 4.4.34, the max > radios and radios in use is a 8 bits (range of 0-255). Also, > in sections 4.4.8, 4.4.11, 4.4.14, 4.4.15, 4.4.17, 4.4.28, > 4.4.39, 11.10.1, 11.10.2, 11.10.5, 11.10.6, 11.10.8, 11.10.9, > 11.10.10, 11.10.11, 11.10.13, 11.10.14, 11.10.15, 11.10.16, > 11.10.17, 11.10.18, 11.10.19, 11.10.20, 11.10.21, 11.10.22, > 11.10.23, and 11.10.24 the radio ID > field is 8 bits. > > In section 11.4, WLAN is a bit map of length 16 (thus a range > of 0-15). However, in the following sections, WLAN ID is 8 > bits (a range of 0-255): > 11.10.1, 11.10.9, 11.10.10, and 11.10.11. > And in sections 11.10.5 and 11.10.21 the WLAN ID is 16 bits (0-65535) > > Regards, > /david t. perkins > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 19 22:20:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsVqu-0008KE-4f for capwap-archive@lists.ietf.org; Mon, 19 Jun 2006 22:20:28 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsVqs-0005LZ-Md for capwap-archive@lists.ietf.org; Mon, 19 Jun 2006 22:20:28 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D5DB3430129 for ; Mon, 19 Jun 2006 19:20:25 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D7A63430071 for ; Mon, 19 Jun 2006 19:20:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 19423144800C for ; Mon, 19 Jun 2006 19:20:04 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2E3E71448005 for ; Mon, 19 Jun 2006 19:20:00 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5K2K0Ae017776; Mon, 19 Jun 2006 19:20:00 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5K2JxKV017771; Mon, 19 Jun 2006 19:20:00 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Mon, 19 Jun 2006 19:19:59 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20210874A@xmb-sjc-235.amer.cisco.com> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] VLAN name in (section 4.4.8)Add Mobile Station X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 HI, How do you know the VLAN Names so you can specify an appropriate one in an Add Mobile station message. How do you configure VLANs on the WTP? On a splitMAC WTP, this is not an issue, since you configure the egress VLAN on the AC, and you configure the ports and tags in each VLAN on the AC. Of course, how you set up VLANs on the AC is a local matter, not part of the CAPWAP spec. However, it seems to me that you have to be able to configure the VLANs on a localMAC WTP via CAPWAP, since that is the only standard protocol between an AC and WTP, and you really need to configure the egress VLANs on a localMAC WTP. If you don't use CAPWAP to determine the VLAN names on a localMAC WTP, or CAPWAP to configure VLANs on a localMAC WTP, then what would you use? On Mon, 19 Jun 2006, Pat Calhoun (pacalhou) wrote: > Given we are sending a VLAN "name", the actual VLAN identifier (tag) may > differ across WTPs. I don't understand the issue. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > -----Original Message----- > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > Sent: Wednesday, June 14, 2006 5:04 PM > > To: capwap@frascone.com > > Subject: [Capwap] VLAN name in (section 4.4.8)Add Mobile Station > > > > HI, > > > > The message element (4.4.8)Add Modile Station has subfield > > "VLAN name". However, there are no CAPWAP messages or message > > elements for VLAN names on a WTP to be managed by the the AC. > > (A value for a VLAN Name is only approapriate for a localMAC > > WTP.) Managed means to find out the list of the VLAN names, > > create VLANs and apply attributes, modify VLAN attributes, > > and delete VLANs. The attributes include the VLAN name, and > > ports:tag pairs in the VLAN. (By the way, this is sort of an > > expansion of CAPWAP, but it is the price to pay to support localMAC.) > > > > For example, consider a localMAC WTP with 4 802.3 ports. > > It could have the following configuration: > > > > VLAN RED - members: port 1:untagged, port 2:tag 23, > > port 4:tag 56 > > VLAN GREEN - members: port 1:tag 96, port 2:tag 103 VLAN > > YELLOW - members: port 1:tag 200, port 4:untagged (Port 3 is > > not a member of any VLAN) > > > > This is not simple, esspecially since there may be > > restrictions, such as 1) all ports in a VLAN must use the same tag, or > > 2) a port can be either a TRUNK port or a feeder port and > > feeder ports are untagged, and the VLANs on the trunk port > > must be all tagged. (I've seen many different sets of limitations.) > > > > I'm not sure what to suggest, other than to drop support for > > localMAC WTPs (only joking). > > > > Regards, > > /david t. perkins Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 19 23:15:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsWiI-00040h-Lz for capwap-archive@lists.ietf.org; Mon, 19 Jun 2006 23:15:38 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsWiG-0004pm-5c for capwap-archive@lists.ietf.org; Mon, 19 Jun 2006 23:15:38 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1C9AF43012B for ; Mon, 19 Jun 2006 20:15:35 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 0879A43006C for ; Mon, 19 Jun 2006 20:14:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DE32C144801C for ; Mon, 19 Jun 2006 20:14:17 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id 4745B1448005 for ; Mon, 19 Jun 2006 20:14:15 -0700 (PDT) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 19 Jun 2006 20:14:14 -0700 X-IronPort-AV: i="4.06,153,1149490800"; d="scan'208,217"; a="1828833483:sNHT83319976" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k5K3EEEJ031520 for ; Mon, 19 Jun 2006 20:14:14 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5K3EEIs006152 for ; Mon, 19 Jun 2006 20:14:14 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 20:14:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jun 2006 20:14:13 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC01ACF3F4@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Thread-Index: AcaRr6xT6mQXDRTiRXGwmOmJzF77ZABovuywABtqjNAAEdU2EAAD9fFg From: "Bob O'Hara (boohara)" To: "capwap" X-OriginalArrivalTime: 20 Jun 2006 03:14:14.0370 (UTC) FILETIME=[9BAE7C20:01C69417] Authentication-Results: sj-dkim-6.cisco.com; header.From=boohara@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE, NORMAL_HTTP_TO_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0502491270==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 2bb235cc76099390bb42bc8303b00ff0 This is a multi-part message in MIME format. --===============0502491270== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69417.9B794827" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69417.9B794827 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This can be done with the current messages. It is already being done in shipping products using the LWAPP protocol, from which these messages were derived. -Bob =20 =20 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Monday, June 19, 2006 6:37 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Consider the 4-way handshake in architecture designs where the WTP maintains the Key-RSC and the AC constructs EAPOL messages (this is one of the major designs brought out in the Architecture Taxonomy). Now, to construct Message 3 of the 4-way handshake, the AC computes the Key-MIC based on the prevailing Key-RSC. Since the Key-RSC is maintained by the WTP, there needs to be some way to transfer this information to the AC.=20 =20 I am open to a different way of doing this from what I've suggested earlier - using of separate Key Configuration message. My concern is only to see that this can be accomplished in the CAPWAP protocol. =20 Saravanan =20 =20 =20 ________________________________ From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Tuesday, June 20, 2006 1:15 AM To: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 I believe that Mike is correct. There is no need to transfer the sequence counter from the WTP to the AC, if the AC is where the EAPOL messages are constructed and the WTP is where the sequence counters are maintained. A careful read of 802.11i on the use of that field will make this clear. -Bob =20 =20 =20 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Sunday, June 18, 2006 9:18 PM To: Michael Montemurro Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Hi Mike,=20 =20 There are a number of designs for IEEE 802.11i. And I believe the description you noted below is one of them. In other designs, the sequence counter is maintained at the point where encryption is performed.=20 =20 >From my understanding of the update you mention to Add WLAN, the assumption seems to be the AC manages the transmit sequence counter. So by using the updated Add WLAN, the AC informs the WTP about the prevailing sequence counter value. Have I understood this right? If what I've got above is right, we are still left with the case where the sequence counter is maintained at the WTP. The Objectives highlights this as a mandatory requirement for the protocol.=20 =20 I'd appreciate if you could post the text relating to the update you mention for Add WLAN. This can help better understand how the update address both the designs.=20 =20 Cheers, =20 Saravanan =20 =20 =20 =20 =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Saturday, June 17, 2006 9:47 AM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 I have looked through IEEE 802.11i as well as talked with others who had implemented IEEE 802.11i. The treatment of the KeyRSC setting is not explained as well as it could be in the IEEE 802.11i draft. In many implementations, the Authenticator sets the transmit sequence counter with the new GTK and passes them both down to the MAC. The Authenticator then transmits this information to the STA as part of the GTK1 EAPoL message. Both the STA and the WTP will then begin using the new TSC and the group key to encrypt broadcast/multicast traffic.=20 =20 To address this in CAPWAP I have updated the AddWLAN message to include the transmit sequence counter for the GTK. That should address any issues with counters and key states. =20 Cheers, =20 Mike =20 On 6/7/06, Saravanan Govindan wrote:=20 Hi Mike,=20 =20 Following from my earlier note, this is the suggestion for handling KeyRSC maintained in a WTP.=20 =20 The suggestion is to include a new IEEE 802.11 specific CAPWAP control messages called "IEEE 802.11 Key Configuration".=20 =20 Following from CAPWAP Specifications-01; =20 CAPWAP Control Message Message Type Value =20 IEEE 802.11 Key Configuration 3398914 IEEE 802.11 Key Configuration Response 3398915 =20 =20 The suggested text follows; =20 [START OF SUGGESTED TEXT] =20 11.7.3. IEEE 802.11 Key Configuration =20 The IEEE 802.11 Key Configuration CAPWAP message is used in WTP designs in which IEEE 802.11i authenticator functions are performed by the AC and IEEE 802.11i cryptographic functions (encryption/decryption) are performed by the WTPs.=20 =20 This CAPWAP message is sent from the AC to the WTP. It must contain either of the following 2 message elements.=20 =20 =20 =20 =20 11.7.3.1 IEEE 802.11 4-way Handshake=20 =20 The IEEE 802.11 4-way Handshake message element is sent by the AC to the WTP during the 4-way handshake. It contains Message-3 of the 4-way handshake with unassigned values as the AC is unaware of the prevailing KeyRSC sequence counter maintained by the WTP. =20 =20 Message-1, Message-2 and Message-4 of the 4-way handshake are transported within CAPWAP data packets between AC and WTP.=20 =20 The IEEE 802.11 4-way Handshake message element contains the following values: =20 =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GTK-Flag | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encryption-Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAPoL-Frame | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =20 GTK-Flag: An 8-bit flag that determines the type of KeyMIC calculation =20 0 - New GTK, KeyMIC is calculated with KeyRSC =3D 0 =20 1 - Existing GTK, KeyMIC is calculated with prevailing KeyRSC value =20 Encryption-Data: Contains PTK and/or GTK =20 EAPoL-Frame: Contains Message-3 of 4-way handshake with unassigned fields =20 Upon receipt of the Key Configuration message from the AC, the WTP performs the following operations: =20 i. Assigns the corresponding value to the KeyRSC field of the EAPoL-Frame=20 ii. Calculates KeyMIC with Encrytion-Data and KeyRSC iii. Updates Message-3 of 4-way handshake iv. Continues regular 4-way handshake with wireless terminals =20 =20 =20 =20 11.7.3.2 IEEE 802.11 Group Key Handshake=20 =20 The IEEE 802.11 Group Key Handshake message element is sent by the AC to the WTP during the group key handshake. It contains Message-1 of the group key handshake with unassigned values as the AC is unaware of the prevailing KeyRSC sequence counter maintained by the WTP. =20 =20 Message-2 of the group key handshake is transported within a CAPWAP data packet between AC and WTP.=20 =20 The IEEE 802.11 Group Key Handshake message element contains the following values: =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GTK-Flag | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encryption-Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAPoL-Frame | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =20 GTK-Flag: An 8-bit flag that determines the type of KeyMIC calculation =20 0 - New GTK, KeyMIC is calculated with KeyRSC =3D 0 =20 1 - Existing GTK, KeyMIC is calculated with prevailing KeyRSC value =20 Encryption-Data: Contains PTK and/or GTK =20 EAPoL-Frame: Contains Message-1 of group key handshake with unassigned fields =20 Upon receipt of the Key Configuration message from AC, the WTP performs the following operations: i. Assigns the corresponding value to the KeyRSC field of the EAPoL-Frame=20 ii. Calculates KeyMIC with Encrytion-Data and KeyRSC iii. Updates Message-1 of group key handshake iv. Continues regular group handshake with wireless terminals =20 =20 =20 =20 11.7.4 IEEE 802.11 Key Configuration Response =20 The IEEE 802.11 Key Configuration Response CAPWAP message is sent by the WTP to the AC as an acknowledgement of the receipt of an IEEE 802.11 Key Configuration Request.=20 =20 [END OF SUGGESTED TEXT] =20 =20 =20 Saravanan =20 ------_=_NextPart_001_01C69417.9B794827 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This can be done with the current = messages.  It is=20 already being done in shipping products using the LWAPP protocol, from = which=20 these messages were derived.

 -Bob
 

 

From: Saravanan Govindan=20 [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: Monday, = June 19,=20 2006 6:37 PM
To: Bob O'Hara (boohara); = capwap
Subject: RE:=20 [Capwap] Clarification of Issue 43: IEEE 802.11i=20 Considerations

Consider the 4-way = handshake in=20 architecture designs where the WTP maintains the Key-RSC and the AC = constructs=20 EAPOL messages (this is one of the major designs brought out in the = Architecture=20 Taxonomy). Now, to construct Message 3 of the 4-way handshake, the AC = computes=20 the Key-MIC based on the prevailing Key-RSC. Since the Key-RSC is = maintained by=20 the WTP, there needs to be some way to transfer this information to the = AC.=20

 

I am open to a different = way of=20 doing this from what I’ve suggested earlier – using of = separate Key=20 Configuration message. My concern is only to see that this can be = accomplished=20 in the CAPWAP protocol.

 

Saravanan

 

 

 

From: Bob=20 O'Hara (boohara) [mailto:boohara@cisco.com]
Sent: Tuesday, June 20, 2006 1:15 = AM
To: = capwap
Subject: Re: [Capwap] = Clarification of=20 Issue 43: IEEE 802.11i Considerations

 

I believe = that Mike is=20 correct.  There is no need to transfer the sequence counter from = the WTP to=20 the AC, if the AC is where the EAPOL messages are constructed and the = WTP is=20 where the sequence counters are maintained.  A careful read of = 802.11i=20 on the use of that field will make this = clear.

 -Bob
 =20

 

 

From:=20 Saravanan Govindan=20 [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: Sunday, June 18, 2006 9:18=20 PM
To: Michael=20 Montemurro
Cc:=20 capwap
Subject: Re: = [Capwap]=20 Clarification of Issue 43: IEEE 802.11i=20 Considerations

Hi Mike,=20

 

There are a number of = designs for=20 IEEE 802.11i. And I believe the description you noted below is one of = them. In=20 other designs, the sequence counter is maintained at the point where = encryption=20 is performed.

 

From my understanding of = the update=20 you mention to Add WLAN, the assumption seems to be the AC manages the = transmit=20 sequence counter. So by using the updated Add WLAN, the AC informs the = WTP about=20 the prevailing sequence counter value. Have I understood this = right?

If=20 what I’ve got above is right, we are still left with the case = where the sequence=20 counter is maintained at the WTP. The Objectives highlights this as a = mandatory=20 requirement for the protocol.

 

I’d appreciate if = you could post the=20 text relating to the update you mention for Add WLAN. This can help = better=20 understand how the update address both the designs.=20

 

Cheers,

 

Saravanan

 

 

 

 

 

From: Michael=20 Montemurro [mailto:montemurro.michael@gmail.com]
Sent: Saturday, June 17, 2006 = 9:47=20 AM
To: = Saravanan Govindan
Cc: capwap
Subject: Re: [Capwap] = Clarification of=20 Issue 43: IEEE 802.11i Considerations

 

Saravanan,

 

I have looked through IEEE 802.11i as well as = talked=20 with others who had implemented IEEE 802.11i. The treatment of the = KeyRSC=20 setting is not explained as well as it could be in the IEEE 802.11i = draft. In=20 many implementations, the Authenticator sets the transmit sequence = counter with=20 the new GTK and passes them both down to the MAC. The Authenticator then = transmits this information to the STA as part of the GTK1 EAPoL message. = Both=20 the STA and the WTP will then begin using the new TSC and the group key = to=20 encrypt broadcast/multicast traffic.

 

To address this in CAPWAP I have updated the = AddWLAN=20 message to include the transmit sequence counter for the GTK. That = should=20 address any issues with counters and key=20 states.

 

Cheers,

 

Mike



 

On 6/7/06, Saravanan=20 Govindan <Saravanan.Govindan@sg= .panasonic.com>=20 wrote:

Hi Mike,=20

 

Following from = my earlier=20 note, this is the suggestion for handling KeyRSC maintained in a WTP.=20

 

The suggestion = is to=20 include a new IEEE 802.11 specific CAPWAP control messages called "IEEE = 802.11=20 Key Configuration".

 

Following from = CAPWAP=20 Specifications-01;

 

CAPWAP Control=20 Message           =         =20 Message Type

          &nb= sp;           &nbs= p;            = ;      =20 Value

 

IEEE 802.11 Key = Configuration          =   =20 3398914

IEEE 802.11 Key = Configuration Response    = 3398915

 

 

The suggested = text=20 follows;

 

[START OF = SUGGESTED=20 TEXT]

 

11.7.3. IEEE = 802.11 Key=20 Configuration

 

The IEEE 802.11 = Key=20 Configuration CAPWAP message is used in WTP designs in which IEEE = 802.11i=20 authenticator functions are performed by the AC and IEEE 802.11i = cryptographic=20 functions (encryption/decryption) are performed by the WTPs.=20

 

This CAPWAP = message is=20 sent from the AC to the WTP. It must contain either of the following 2 = message=20 elements.

 

 

 

 

11.7.3.1     IEEE=20 802.11 4-way Handshake

 

The IEEE 802.11 = 4-way=20 Handshake message element is sent by the AC to the WTP during the 4-way=20 handshake. It contains Message-3 of the 4-way handshake with unassigned = values=20 as the AC is unaware of the prevailing KeyRSC sequence counter = maintained by the=20 WTP.  

 

Message-1, = Message-2 and=20 Message-4 of the 4-way handshake are transported within CAPWAP data = packets=20 between AC and WTP.

 

The IEEE 802.11 = 4-way=20 Handshake message element contains the following=20 values:

 

 

     =20 0            =       =20 1            =       =20 2            =       =20 3

     =20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0=20 1

    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /FONT>

    =20 |    GTK-Flag   |=20             &= nbsp;     Reserved =20             &= nbsp;     |

    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /FONT>

    =20 |            =       =20      Encryption-Data  =20             &= nbsp;        |=

    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /FONT>

    =20 |            =       =20        EAPoL-Frame=20             &= nbsp;           &n= bsp;|

    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /FONT>

 

 

GTK-Flag: An = 8-bit flag=20 that determines the type of KeyMIC = calculation

    =20

    =20 0 – New GTK, KeyMIC is calculated with KeyRSC =3D = 0

 

    =20 1 – Existing GTK, KeyMIC is calculated with prevailing KeyRSC=20 value

 

Encryption-Data: Contains=20 PTK and/or GTK

 

EAPoL-Frame: = Contains=20 Message-3 of 4-way handshake with unassigned = fields

 

Upon receipt of = the Key=20 Configuration message from the AC, the WTP performs the following=20 operations:

 

   =20 i.           = =20 Assigns the = corresponding=20 value to the KeyRSC field of the EAPoL-Frame =

ii.           = =20 Calculates = KeyMIC with=20 Encrytion-Data and KeyRSC

iii.           = =20 Updates = Message-3 of=20 4-way handshake

iv.           = =20 Continues = regular 4-way=20 handshake with wireless terminals

 

 

 

 

11.7.3.2     IEEE=20 802.11 Group Key Handshake

 

The IEEE 802.11 = Group Key=20 Handshake message element is sent by the AC to the WTP during the group = key=20 handshake. It contains Message-1 of the group key handshake with = unassigned=20 values as the AC is unaware of the prevailing KeyRSC sequence counter = maintained=20 by the WTP.  

 

Message-2 of = the group=20 key handshake is transported within a CAPWAP data packet between AC and = WTP.=20

 

The IEEE 802.11 = Group Key=20 Handshake message element contains the following=20 values:

 

     =20 0            =       =20 1            =       =20 2            =       =20 3

     =20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0=20 1

    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /FONT>

    =20 |    GTK-Flag   |=20             &= nbsp;     Reserved =20             &= nbsp;     |

    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /FONT>

    =20 |            =       =20      Encryption-Data  =20             &= nbsp;        |=

    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /FONT>

    =20 |            =       =20        EAPoL-Frame=20             &= nbsp;           &n= bsp;|

    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /FONT>

 

 

GTK-Flag: An = 8-bit flag=20 that determines the type of KeyMIC = calculation

    =20

    =20 0 – New GTK, KeyMIC is calculated with KeyRSC =3D = 0

 

    =20 1 – Existing GTK, KeyMIC is calculated with prevailing KeyRSC=20 value

 

Encryption-Data: Contains=20 PTK and/or GTK

 

EAPoL-Frame: = Contains=20 Message-1 of group key handshake with unassigned=20 fields

 

Upon receipt of = the Key=20 Configuration message from AC, the WTP performs the following=20 operations:

   =20 i.           = =20 Assigns the = corresponding=20 value to the KeyRSC field of the EAPoL-Frame =

ii.           = =20 Calculates = KeyMIC with=20 Encrytion-Data and KeyRSC

iii.           = =20 Updates = Message-1 of=20 group key handshake

iv.           = =20 Continues = regular group=20 handshake with wireless terminals

 

 

 

 

11.7.4    =20 IEEE 802.11 Key Configuration Response

 

The IEEE 802.11 = Key=20 Configuration Response CAPWAP message is sent by the WTP to the AC as an = acknowledgement of the receipt of an IEEE 802.11 Key Configuration = Request.=20

 

[END OF = SUGGESTED=20 TEXT]

 

 

 


Saravanan

 

------_=_NextPart_001_01C69417.9B794827-- --===============0502491270== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0502491270==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 19 23:52:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsXIB-0006X2-8y for capwap-archive@lists.ietf.org; Mon, 19 Jun 2006 23:52:43 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsXI7-0000zq-Ly for capwap-archive@lists.ietf.org; Mon, 19 Jun 2006 23:52:43 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6F7BD430115 for ; Mon, 19 Jun 2006 20:52:38 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1BFF1430071 for ; Mon, 19 Jun 2006 20:51:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A7E88398021 for ; Mon, 19 Jun 2006 20:51:28 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 27D9839801A for ; Mon, 19 Jun 2006 20:51:24 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060308/3.7W/jazz) with ESMTP id k5K3pLTi002910; Tue, 20 Jun 2006 12:51:21 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k5K3pLI13402; Tue, 20 Jun 2006 12:51:21 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with SMTP id k5K3pKR18347; Tue, 20 Jun 2006 12:51:20 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 20 Jun 2006 11:52:09 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDF71A4A@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Thread-Index: AcaRr6xT6mQXDRTiRXGwmOmJzF77ZABovuywABtqjNAAEdU2EAAD9fFgAAE0zBA= From: "Saravanan Govindan" To: "Bob O'Hara (boohara)" , "capwap" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.505 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_MESSAGE, NORMAL_HTTP_TO_IP X-Spam-Level: Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0641763582==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 40278356912741876b8e846efc245c80 This is a multi-part message in MIME format. --===============0641763582== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6941C.751B2534" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6941C.751B2534 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If this is the case, perhaps more clarification can be provided. In particular, which part of the document deals with this?=20 =20 Saravanan =20 =20 =20 =20 ________________________________ From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Tuesday, June 20, 2006 11:14 AM To: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 This can be done with the current messages. It is already being done in shipping products using the LWAPP protocol, from which these messages were derived. -Bob =20 =20 =20 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Monday, June 19, 2006 6:37 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Consider the 4-way handshake in architecture designs where the WTP maintains the Key-RSC and the AC constructs EAPOL messages (this is one of the major designs brought out in the Architecture Taxonomy). Now, to construct Message 3 of the 4-way handshake, the AC computes the Key-MIC based on the prevailing Key-RSC. Since the Key-RSC is maintained by the WTP, there needs to be some way to transfer this information to the AC.=20 =20 I am open to a different way of doing this from what I've suggested earlier - using of separate Key Configuration message. My concern is only to see that this can be accomplished in the CAPWAP protocol. =20 Saravanan =20 =20 =20 ________________________________ From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Tuesday, June 20, 2006 1:15 AM To: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 I believe that Mike is correct. There is no need to transfer the sequence counter from the WTP to the AC, if the AC is where the EAPOL messages are constructed and the WTP is where the sequence counters are maintained. A careful read of 802.11i on the use of that field will make this clear. -Bob =20 =20 =20 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Sunday, June 18, 2006 9:18 PM To: Michael Montemurro Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Hi Mike,=20 =20 There are a number of designs for IEEE 802.11i. And I believe the description you noted below is one of them. In other designs, the sequence counter is maintained at the point where encryption is performed.=20 =20 >From my understanding of the update you mention to Add WLAN, the assumption seems to be the AC manages the transmit sequence counter. So by using the updated Add WLAN, the AC informs the WTP about the prevailing sequence counter value. Have I understood this right? If what I've got above is right, we are still left with the case where the sequence counter is maintained at the WTP. The Objectives highlights this as a mandatory requirement for the protocol.=20 =20 I'd appreciate if you could post the text relating to the update you mention for Add WLAN. This can help better understand how the update address both the designs.=20 =20 Cheers, =20 Saravanan =20 =20 =20 =20 =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Saturday, June 17, 2006 9:47 AM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations =20 Saravanan, =20 I have looked through IEEE 802.11i as well as talked with others who had implemented IEEE 802.11i. The treatment of the KeyRSC setting is not explained as well as it could be in the IEEE 802.11i draft. In many implementations, the Authenticator sets the transmit sequence counter with the new GTK and passes them both down to the MAC. The Authenticator then transmits this information to the STA as part of the GTK1 EAPoL message. Both the STA and the WTP will then begin using the new TSC and the group key to encrypt broadcast/multicast traffic.=20 =20 To address this in CAPWAP I have updated the AddWLAN message to include the transmit sequence counter for the GTK. That should address any issues with counters and key states. =20 Cheers, =20 Mike =20 On 6/7/06, Saravanan Govindan wrote:=20 Hi Mike,=20 =20 Following from my earlier note, this is the suggestion for handling KeyRSC maintained in a WTP.=20 =20 The suggestion is to include a new IEEE 802.11 specific CAPWAP control messages called "IEEE 802.11 Key Configuration".=20 =20 Following from CAPWAP Specifications-01; =20 CAPWAP Control Message Message Type Value =20 IEEE 802.11 Key Configuration 3398914 IEEE 802.11 Key Configuration Response 3398915 =20 =20 The suggested text follows; =20 [START OF SUGGESTED TEXT] =20 11.7.3. IEEE 802.11 Key Configuration =20 The IEEE 802.11 Key Configuration CAPWAP message is used in WTP designs in which IEEE 802.11i authenticator functions are performed by the AC and IEEE 802.11i cryptographic functions (encryption/decryption) are performed by the WTPs.=20 =20 This CAPWAP message is sent from the AC to the WTP. It must contain either of the following 2 message elements.=20 =20 =20 =20 =20 11.7.3.1 IEEE 802.11 4-way Handshake=20 =20 The IEEE 802.11 4-way Handshake message element is sent by the AC to the WTP during the 4-way handshake. It contains Message-3 of the 4-way handshake with unassigned values as the AC is unaware of the prevailing KeyRSC sequence counter maintained by the WTP. =20 =20 Message-1, Message-2 and Message-4 of the 4-way handshake are transported within CAPWAP data packets between AC and WTP.=20 =20 The IEEE 802.11 4-way Handshake message element contains the following values: =20 =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GTK-Flag | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encryption-Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAPoL-Frame | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =20 GTK-Flag: An 8-bit flag that determines the type of KeyMIC calculation =20 0 - New GTK, KeyMIC is calculated with KeyRSC =3D 0 =20 1 - Existing GTK, KeyMIC is calculated with prevailing KeyRSC value =20 Encryption-Data: Contains PTK and/or GTK =20 EAPoL-Frame: Contains Message-3 of 4-way handshake with unassigned fields =20 Upon receipt of the Key Configuration message from the AC, the WTP performs the following operations: =20 i. Assigns the corresponding value to the KeyRSC field of the EAPoL-Frame=20 ii. Calculates KeyMIC with Encrytion-Data and KeyRSC iii. Updates Message-3 of 4-way handshake iv. Continues regular 4-way handshake with wireless terminals =20 =20 =20 =20 11.7.3.2 IEEE 802.11 Group Key Handshake=20 =20 The IEEE 802.11 Group Key Handshake message element is sent by the AC to the WTP during the group key handshake. It contains Message-1 of the group key handshake with unassigned values as the AC is unaware of the prevailing KeyRSC sequence counter maintained by the WTP. =20 =20 Message-2 of the group key handshake is transported within a CAPWAP data packet between AC and WTP.=20 =20 The IEEE 802.11 Group Key Handshake message element contains the following values: =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GTK-Flag | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encryption-Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAPoL-Frame | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =20 GTK-Flag: An 8-bit flag that determines the type of KeyMIC calculation =20 0 - New GTK, KeyMIC is calculated with KeyRSC =3D 0 =20 1 - Existing GTK, KeyMIC is calculated with prevailing KeyRSC value =20 Encryption-Data: Contains PTK and/or GTK =20 EAPoL-Frame: Contains Message-1 of group key handshake with unassigned fields =20 Upon receipt of the Key Configuration message from AC, the WTP performs the following operations: i. Assigns the corresponding value to the KeyRSC field of the EAPoL-Frame=20 ii. Calculates KeyMIC with Encrytion-Data and KeyRSC iii. Updates Message-1 of group key handshake iv. Continues regular group handshake with wireless terminals =20 =20 =20 =20 11.7.4 IEEE 802.11 Key Configuration Response =20 The IEEE 802.11 Key Configuration Response CAPWAP message is sent by the WTP to the AC as an acknowledgement of the receipt of an IEEE 802.11 Key Configuration Request.=20 =20 [END OF SUGGESTED TEXT] =20 =20 =20 Saravanan =20 ------_=_NextPart_001_01C6941C.751B2534 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If this is the case, perhaps more clarification can = be provided. In particular, which part of the document deals with this? =

 

Saravanan

 

 

 

 

From: Bob = O'Hara (boohara) [mailto:boohara@cisco.com]
Sent: Tuesday, June 20, = 2006 11:14 AM
To: capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

 

This can be done with the current messages.  It is already being done in shipping products using the = LWAPP protocol, from which these messages were = derived.

 -Bob
 

 

 

From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: Monday, June 19, = 2006 6:37 PM
To: Bob O'Hara (boohara); = capwap
Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

Consider the 4-way handshake in architecture designs = where the WTP maintains the Key-RSC and the AC constructs EAPOL messages (this = is one of the major designs brought out in the Architecture Taxonomy). Now, to construct Message 3 of the 4-way handshake, the AC computes the Key-MIC = based on the prevailing Key-RSC. Since the Key-RSC is maintained by the WTP, = there needs to be some way to transfer this information to the AC. =

 

I am open to a different way of doing this from what I’ve suggested earlier – using of separate Key Configuration message. My concern is only to see that this can be accomplished in the = CAPWAP protocol.

 

Saravanan

 

 

 

From: Bob = O'Hara (boohara) [mailto:boohara@cisco.com]
Sent: Tuesday, June 20, = 2006 1:15 AM
To: capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

 

I believe that Mike is = correct.  There is no need to transfer the sequence counter from the WTP to the = AC, if the AC is where the EAPOL messages are constructed and the WTP is where = the sequence counters are maintained.  A careful read of 802.11i = on the use of that field will make this clear.

 -Bob
 

 

 

From: Saravanan Govindan = [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: Sunday, June 18, = 2006 9:18 PM
To: Michael = Montemurro
Cc: capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

Hi Mike,

 

There are a number of designs for IEEE 802.11i. And I believe the description you noted below is one of them. In other = designs, the sequence counter is maintained at the point where encryption is = performed.

 

From my understanding of the update you mention to = Add WLAN, the assumption seems to be the AC manages the transmit sequence counter. = So by using the updated Add WLAN, the AC informs the WTP about the prevailing sequence counter value. Have I understood this right?

If what I’ve got above is right, we are still left with the case = where the sequence counter is maintained at the WTP. The Objectives highlights = this as a mandatory requirement for the protocol. =

 

I’d appreciate if you could post the text = relating to the update you mention for Add WLAN. This can help better understand how = the update address both the designs.

 

Cheers,

 

Saravanan

 

 

 

 

 

From: = Michael Montemurro [mailto:montemurro.michael@gmail.com]
Sent: Saturday, June 17, = 2006 9:47 AM
To: Saravanan Govindan
Cc: capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i = Considerations

 

Saravanan,

 

I have looked through IEEE 802.11i as well as talked with others = who had implemented IEEE 802.11i. The treatment of the KeyRSC setting is not explained as well as it could be in the IEEE 802.11i draft. In many implementations, the Authenticator sets the transmit sequence counter = with the new GTK and passes them both down to the MAC. The Authenticator then = transmits this information to the STA as part of the GTK1 EAPoL message. Both the = STA and the WTP will then begin using the new TSC and the group key to encrypt broadcast/multicast traffic.

 

To address this in CAPWAP I have updated the AddWLAN message to = include the transmit sequence counter for the GTK. That should address any = issues with counters and key states.

 

Cheers,

 

Mike



 

On 6/7/06, Saravanan = Govindan <Saravanan.Govindan@sg= .panasonic.com> wrote:

Hi Mike,

 

Following from my earlier note, this is the suggestion = for handling KeyRSC maintained in a WTP.

 

The suggestion is to include a new IEEE 802.11 = specific CAPWAP control messages called "IEEE 802.11 Key = Configuration".

 

Following from CAPWAP = Specifications-01;

 

CAPWAP Control Message           =          Message Type

          &nb= sp;           &nbs= p;            = ;       Value

 

IEEE 802.11 Key Configuration          =    3398914

IEEE 802.11 Key Configuration = Response    3398915

 

 

The suggested text = follows;

 

[START OF SUGGESTED TEXT]

 

11.7.3. IEEE 802.11 Key = Configuration

 

The IEEE 802.11 Key Configuration CAPWAP message is = used in WTP designs in which IEEE 802.11i authenticator functions are performed = by the AC and IEEE 802.11i cryptographic functions (encryption/decryption) are performed by the WTPs.

 

This CAPWAP message is sent from the AC to the WTP. It = must contain either of the following 2 message elements. =

 

 

 

 

11.7.3.1     IEEE 802.11 4-way Handshake

 

The IEEE 802.11 = 4-way Handshake message element is sent by the AC to the WTP during the 4-way handshake. It contains Message-3 of the 4-way handshake with unassigned = values as the AC is unaware of the prevailing KeyRSC sequence counter = maintained by the WTP.  

 

Message-1, = Message-2 and Message-4 of the 4-way handshake are transported within CAPWAP data = packets between AC and WTP.

 

The IEEE 802.11 = 4-way Handshake message element contains the following = values:

 

 

      0            =        1            =        2            =        3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

     |    GTK-Flag   |             &= nbsp;     Reserved              &= nbsp;     |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

     |            =             Encryption-Data   =             &= nbsp;        |=

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

     |            =               EAPoL-Frame             &= nbsp;           &n= bsp;|

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

 

 

GTK-Flag: An 8-bit flag that determines the type of = KeyMIC calculation

    

     0 – New GTK, KeyMIC is calculated with KeyRSC =3D 0

 

     1 – Existing GTK, = KeyMIC is calculated with prevailing KeyRSC value

 

Encryption-Data: Contains PTK and/or = GTK

 

EAPoL-Frame: Contains Message-3 of 4-way handshake = with unassigned fields

 

Upon receipt of = the Key Configuration message from the AC, the WTP performs the following = operations:

 

    i.        = ;    Assigns the corresponding value to the = KeyRSC field of the EAPoL-Frame

ii.        = ;    Calculates KeyMIC with Encrytion-Data and = KeyRSC

iii.        = ;    Updates Message-3 of 4-way = handshake

iv.        = ;    Continues regular 4-way handshake with = wireless terminals

 

 

 

 

11.7.3.2     IEEE 802.11 Group Key Handshake

 

The IEEE 802.11 = Group Key Handshake message element is sent by the AC to the WTP during the group = key handshake. It contains Message-1 of the group key handshake with = unassigned values as the AC is unaware of the prevailing KeyRSC sequence counter maintained by the WTP.  

 

Message-2 of the = group key handshake is transported within a CAPWAP data packet between AC and = WTP.

 

The IEEE 802.11 = Group Key Handshake message element contains the following = values:

 

      0            =        1            =        2            =        3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

     |    GTK-Flag   |             &= nbsp;     Reserved              &= nbsp;     |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

     |            =             Encryption-Data               &= nbsp;        |=

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

     |            =               EAPoL-Frame             &= nbsp;           &n= bsp;|

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

 

 

GTK-Flag: An 8-bit flag that determines the type of = KeyMIC calculation

    

     0 – New GTK, KeyMIC is calculated with KeyRSC =3D 0

 

     1 – Existing GTK, = KeyMIC is calculated with prevailing KeyRSC value

 

Encryption-Data: Contains PTK and/or = GTK

 

EAPoL-Frame: Contains Message-1 of group key handshake = with unassigned fields

 

Upon receipt of = the Key Configuration message from AC, the WTP performs the following = operations:

    i.        = ;    Assigns the corresponding value to the = KeyRSC field of the EAPoL-Frame

ii.        = ;    Calculates KeyMIC with Encrytion-Data and = KeyRSC

iii.        = ;    Updates Message-1 of group key = handshake

iv.        = ;    Continues regular group handshake with = wireless terminals

 

 

 

 

11.7.4     IEEE 802.11 Key = Configuration Response

 

The IEEE 802.11 Key Configuration Response CAPWAP = message is sent by the WTP to the AC as an acknowledgement of the receipt of an = IEEE 802.11 Key Configuration Request.

 

[END OF SUGGESTED TEXT]

 

 

 


Saravanan

 

------_=_NextPart_001_01C6941C.751B2534-- --===============0641763582== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0641763582==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 20 01:18:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsYdE-0007Ma-KL for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 01:18:32 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsYdB-00027Q-Rl for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 01:18:32 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B7A7A430115 for ; Mon, 19 Jun 2006 22:18:26 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 89B1D430071 for ; Mon, 19 Jun 2006 22:17:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5DABF144800C for ; Mon, 19 Jun 2006 22:17:59 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id 8C8DE1448017 for ; Mon, 19 Jun 2006 22:17:56 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 19 Jun 2006 22:17:55 -0700 X-IronPort-AV: i="4.06,153,1149490800"; d="scan'208"; a="297548067:sNHT33012388" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5K5HtRf017788; Mon, 19 Jun 2006 22:17:55 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5K5Htke011523; Mon, 19 Jun 2006 22:17:55 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 22:17:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jun 2006 22:17:53 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20210877F@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] VLAN name in (section 4.4.8)Add Mobile Station Thread-Index: AcaUEAj0a7Hy/bwnRdW5L/R/shcEkAAGMhOQ From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" X-OriginalArrivalTime: 20 Jun 2006 05:17:55.0130 (UTC) FILETIME=[E2CC99A0:01C69428] Authentication-Results: sj-dkim-4.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] VLAN name in (section 4.4.8)Add Mobile Station X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Ok - so your point is that the protocol doesn't allow one to configure the actual VLANs on a local MAC WTP. Fair enough. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Monday, June 19, 2006 7:20 PM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: RE: [Capwap] VLAN name in (section 4.4.8)Add Mobile Station > > HI, > > How do you know the VLAN Names so you can specify an > appropriate one in an Add Mobile station message. > > How do you configure VLANs on the WTP? > > On a splitMAC WTP, this is not an issue, since you configure > the egress VLAN on the AC, and you configure the ports and > tags in each VLAN on the AC. Of course, how you set up VLANs > on the AC is a local matter, not part of the CAPWAP spec. > However, it seems to me that you have to be able to configure > the VLANs on a localMAC WTP via CAPWAP, since that is the > only standard protocol between an AC and WTP, and you really > need to configure the egress VLANs on a localMAC WTP. > > If you don't use CAPWAP to determine the VLAN names on a > localMAC WTP, or CAPWAP to configure VLANs on a localMAC WTP, > then what would you use? > > > On Mon, 19 Jun 2006, Pat Calhoun (pacalhou) wrote: > > Given we are sending a VLAN "name", the actual VLAN > identifier (tag) > > may differ across WTPs. I don't understand the issue. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > -----Original Message----- > > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > > Sent: Wednesday, June 14, 2006 5:04 PM > > > To: capwap@frascone.com > > > Subject: [Capwap] VLAN name in (section 4.4.8)Add Mobile Station > > > > > > HI, > > > > > > The message element (4.4.8)Add Modile Station has subfield "VLAN > > > name". However, there are no CAPWAP messages or message > elements for > > > VLAN names on a WTP to be managed by the the AC. > > > (A value for a VLAN Name is only approapriate for a localMAC > > > WTP.) Managed means to find out the list of the VLAN > names, create > > > VLANs and apply attributes, modify VLAN attributes, and delete > > > VLANs. The attributes include the VLAN name, and > ports:tag pairs in > > > the VLAN. (By the way, this is sort of an expansion of > CAPWAP, but > > > it is the price to pay to support localMAC.) > > > > > > For example, consider a localMAC WTP with 4 802.3 ports. > > > It could have the following configuration: > > > > > > VLAN RED - members: port 1:untagged, port 2:tag 23, > > > port 4:tag 56 > > > VLAN GREEN - members: port 1:tag 96, port 2:tag 103 VLAN YELLOW - > > > members: port 1:tag 200, port 4:untagged (Port 3 is not a > member of > > > any VLAN) > > > > > > This is not simple, esspecially since there may be restrictions, > > > such as 1) all ports in a VLAN must use the same tag, or > > > 2) a port can be either a TRUNK port or a feeder port and feeder > > > ports are untagged, and the VLANs on the trunk port must be all > > > tagged. (I've seen many different sets of limitations.) > > > > > > I'm not sure what to suggest, other than to drop support for > > > localMAC WTPs (only joking). > > > > > > Regards, > > > /david t. perkins > > Regards, > /david t. perkins > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 20 02:40:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsZuB-0007BU-LQ for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 02:40:07 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsZu9-0002tY-2N for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 02:40:07 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 04DE4430127 for ; Mon, 19 Jun 2006 23:40:04 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4D00E43006C for ; Mon, 19 Jun 2006 23:39:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 032E51448017 for ; Mon, 19 Jun 2006 23:39:39 -0700 (PDT) Received: from huawei.com (szxga02-in.huawei.com [61.144.161.54]) by hermes.tigertech.net (Postfix) with ESMTP id 6C46C144801C for ; Mon, 19 Jun 2006 23:39:04 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1500KIYCJ5R7@szxga02-in.huawei.com> for capwap@frascone.com; Tue, 20 Jun 2006 14:54:41 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1500KACCJ591@szxga02-in.huawei.com> for capwap@frascone.com; Tue, 20 Jun 2006 14:54:41 +0800 (CST) Received: from dell60 ([10.18.7.113]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J150023SBV3BD@szxml03-in.huawei.com> for capwap@frascone.com; Tue, 20 Jun 2006 14:40:16 +0800 (CST) Date: Tue, 20 Jun 2006 12:08:41 +0530 From: sujay In-reply-to: To: "'David T. Perkins'" , "'Scott G. Kelly'" Message-id: <000001c69434$2bf3b540$7107120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: 'capwap' Subject: Re: [Capwap] vsp definition has no length X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Hi David, Are you suggesting to remove the vsp element(as in section 4.4.32) , which could be carried in any control message(as in 4.3.1.1 ), and instead have a generic vsp control message type ??? Please correct me. Regds, Sujay G My Location; http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085 &t=h&hl=en This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Tuesday, June 20, 2006 5:04 AM To: Scott G. Kelly Cc: capwap Subject: Re: [Capwap] vsp definition has no length HI, You left off the outside wrapper as is specified in CAPWAP-01. Thus, you currently have, as defined in section 4.4, "CAPWAP Protocol Message Elements", and section 4.4.32, "Vendor Specific Payload" for vendor message elements: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=43 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Element ID | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^-don't need length here Thus, you don't need an additional "length". In the CAPWAP packet formats that I sent out some time ago, I proposed that there be no difference in format between "CAPWAP STD message elements" and "CAPWAP vendor specific message elements". Both would have the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Element Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Value .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Where the encoding of "message element type" is Message element type value = IANA Enterprise Number * 4096 + enterprise specific message element type number (and for CAPWAP standard, zero is used for the value IANA Enterprise number) This results in 12 bits (0-4095) for element types, and 20 bits (0-1048575) for Enterprise numbers. If you look at OUI assignments, which have been around a lot longer than enterprise numbers, they have approximately 52K allocated. Thus, 64k (16 bits), is probably not enough, and 1M (20 bits) looks big enough. Regards, /david t. perkins On Mon, 19 Jun 2006, Scott G. Kelly wrote: > Here's the current vendor-specific payload definition: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Element ID | Value... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Wouldn't something like this make more sense? > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length | Element ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value.... > +-+-+-+-+-+-+- > > > --Scott > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 20 05:02:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsc8M-0003b7-4U for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 05:02:54 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsc8K-0004xy-Ni for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 05:02:54 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B4E14430165 for ; Tue, 20 Jun 2006 02:02:51 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9CE16430071 for ; Tue, 20 Jun 2006 02:02:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7771B43071C for ; Tue, 20 Jun 2006 02:02:31 -0700 (PDT) Received: from mrqout1.tiscali.it (mrqout1-sorbs.tiscali.it [195.130.225.22]) by hermes.tigertech.net (Postfix) with ESMTP id B43D243070C for ; Tue, 20 Jun 2006 02:02:27 -0700 (PDT) Received: from 10.39.115.29 by mrq-1 with esmtp (Exim) id 1Fsc7s-0007Az-TC; Tue, 20 Jun 2006 11:02:25 +0200 Received: from ps9 (10.39.75.79) by mail-10.mail.tiscali.sys (7.3.110.2) id 448ED7D50001E134 for capwap@frascone.com; Tue, 20 Jun 2006 11:02:24 +0200 Message-ID: <23006942.1150794139207.JavaMail.root@ps9> Date: Tue, 20 Jun 2006 11:02:19 +0200 (CEST) From: "a.levanti@tiscali.it" To: capwap@frascone.com MIME-Version: 1.0 xOriginalSenderIP: 147.163.60.5 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] issue 104 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "a.levanti@tiscali.it" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hi all, In relation to issue the 104 we think to use a new message when the WTP enters in RUN state. In this message it must send to AC informations related to all access points it hears, in which frequency they trasmitted, and the power to noise ratio. AC maintains a database where for all WTPs under its control have an entry in which there are informations sent from WTP. Therefore, AC has a one wider network's vision so that it could choose the better channel. Perhaps I lost some point of the debate, so is it possible? Thanks. Annarita Naviga senza limiti con 4 Megabps di velocita' a soli 19,95 Euro al mese, ATTIVA SUBITO e hai 2 MESI GRATIS! In piu', se sei raggiunto dalla rete Tiscali, telefoni senza pagare il canone Telecom. Comincia subito a risparmiare! http://abbonati.tiscali.it/prodotti/adsl/tc/4flat/ _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 20 08:13:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsf6p-0001k7-6P for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 08:13:31 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsf6n-0008Ts-I7 for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 08:13:31 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 75E43430092 for ; Tue, 20 Jun 2006 05:13:28 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 93589430092 for ; Tue, 20 Jun 2006 05:12:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 80C0F4309E4 for ; Tue, 20 Jun 2006 05:12:31 -0700 (PDT) X-Greylist-Status: Sender first seen 18 days 20:56:50 ago Received: from co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by hermes.tigertech.net (Postfix) with ESMTP id 645944309F1 for ; Tue, 20 Jun 2006 05:12:27 -0700 (PDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5KC9XmF028888 for ; Tue, 20 Jun 2006 08:09:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jun 2006 06:12:23 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Process in CAPWAP Thread-Index: AcaMIv6al2wcs/e8TvuwY5RhhPusZAELwwbQABULHhAAHxdIYADQACvA From: "Mani, Mahalingam (Mani)" To: "Romascanu, Dan (Dan)" , "capwap" X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: Re: [Capwap] Process in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: be922d419820e291bde1362184dc32fd Dan, The list will be prepared posted here (by June 21 5pm Pacific) prior to sen= ding to the experts. Regards, -mani -----Original Message----- From: Romascanu, Dan (Dan) = Sent: Friday, June 16, 2006 1:57 AM To: capwap Subject: Re: [Capwap] Process in CAPWAP I would suggest that the chairs draw a short list of clear questions and is= sues for clarification, including references that would help to focus the w= ork of the experts. Can we have this list prepared in the next few days? = Thanks and Regards, Dan = = > -----Original Message----- > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] = > Sent: Thursday, June 15, 2006 9:12 PM > To: capwap > Cc: david.kessens@nokia.com; Romascanu, Dan (Dan) > Subject: RE: Process in CAPWAP > = > Dan, David, > = > I certainly appreciate the difficulty that our chairs have to = > navigate the path to consensus necessary for a successful = > standard. I do not envy them their task, particularly in = > this area where we believe that the success of the CAPWAP = > standard is critical to this market area and the customers in it. > = > There are certainly enough open issues to resolve, that = > asking for expert advice on this particular issue is not = > likely to adversely affect the time for completion of our = > work. I think that this will be very helpful to us. = > = > Thank you. > = > -Bob > = > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Thursday, June 15, 2006 1:07 AM > To: Bob O'Hara (boohara) > Cc: capwap; david.kessens@nokia.com > Subject: RE: Process in CAPWAP > = > Hi Bob, > = > The ADs looked in the issue that you raised related to the = > consensus on the Mux vs Multiport issue # 115. We analyzed = > the traffic on the list and we also discussed with the WG = > chairs. Our opinion is that although the chairs suggested a = > solution for consensus the WG did not agree with it. Despite = > the chairs and WG efforts to reach a timely conclusion = > according to the current WG schedules, more work needs to be = > done to reach at minimum rough consensus on this point. > = > The chairs have the responsibility to drive the consensus = > process, and the criteria for reaching the decisions should = > be clearly explained. = > = > In order to overcome the dead-end we recommend to the WG to = > bring in the discussion opinions about the consensus criteria = > (QoS, scalability, compatibility with routing and switching = > infrastructure), their priority and recommendations from = > external experts that were less involved in the discussions = > until now, for example by consulting the Routing Area. We = > offer to approach the Routing Area ADs to have an expert = > designated to this purpose. > = > We recommend that the WG continues its work and capitalizes = > on the effort made until now to close a large number of open = > issues in the next version of the draft. This issue together = > with the other open issues should be brought for discussion = > on the list and in Montreal, and we hope that a conclusion = > based on rough consensus can be reached soon after the = > Montreal meeting, so that the impact on the Working Group = > schedules be minimized. > = > David and Dan > = > = > = > = > > -----Original Message----- > > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > > Sent: Saturday, June 10, 2006 3:16 AM > > To: Romascanu, Dan (Dan) > > Cc: capwap > > Subject: Process in CAPWAP > > = > > Dan, > > = > > A few days ago Dorothy Gellert sent an email to the working = > group on = > > behalf of the chairs, announcing a decision on a technical issue in = > > the working group. Specifically, she declared that the = > chairs decided = > > the discussion of the use of a mux header vs. the use of separate = > > ports for the differentiation of control and data traffic in the = > > protocol to be over. She also indicated that the chairs had chosen = > > the mux header as the method to be used in the protocol and set a = > > deadline of today for closing the issue. > > = > > As soon as I read her email, I replied and asked that she = > document the = > > process that the chairs used to arrive at their decision. My = > > background is in the IEEE, where the process is clear, transparent, = > > and open to all participants. CAPWAP is my first IETF = > working group. = > > My understanding of decision-making in IETF is that it is based on = > > rough consensus and that the chairs have responsibility to = > determine = > > that consensus. With that understanding, I asked Dorothy = > to document = > > what the chairs used as evidence of rough consensus on that issue, = > > since I see evidence in the postings to the list that there is more = > > support for separate ports than there is for the mux header. At a = > > minimum, there is no consensus on this issue. > > = > > Since sending that email two days ago, neither chair has = > responded. I = > > find that quite disturbing for several reasons. > > = > > First, this is an issue that has been debated extensively = > (and still = > > is being debated, regardless of the pronouncement from the = > chairs). = > > The working group deserves to know how this technical issue was = > > resolved. > > = > > Second, standardization by fiat of the chair does not seem to be in = > > keeping with the open process requirements of the IETF. > > Perhaps I am being na=EFve, but I don't believe there is a = > feted inner = > > core (FIC) that is actually developing all the IETF standards. > > = > > Third, the time allowed for any response to the email was = > only three = > > days. This is an absurdly short time, given that it is the = > start of = > > the summer vacation period in the northern hemisphere. It is quite = > > possible that many participants will not even see her email until = > > after the deadline expires. > > = > > Finally, if there is no consensus on the issue, the chairs are = > > expressing an engineering opinion and should be required to justify = > > that opinion just as any other member of the working group. = > I don't = > > believe that the IETF anoints the chairs of any working group as = > > expert and able to make technical decisions for the working group. > > = > > I would appreciate your thoughts, as the AD, and response on these = > > items. > > = > > Best regards, > > -Bob > > = > > Bob O'Hara > > = > = _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 20 09:48:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsgal-0005w0-T3 for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 09:48:31 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsgak-0001jc-Dj for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 09:48:31 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 85C0143019D for ; Tue, 20 Jun 2006 06:48:29 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 2EAE643010B for ; Tue, 20 Jun 2006 06:48:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 19C85398045 for ; Tue, 20 Jun 2006 06:48:05 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id DA64D39802C for ; Tue, 20 Jun 2006 06:48:01 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5KDm0N2018997; Tue, 20 Jun 2006 06:48:00 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5KDlxRA018992; Tue, 20 Jun 2006 06:48:00 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 20 Jun 2006 06:47:59 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: sujay In-Reply-To: <000001c69434$2bf3b540$7107120a@china.huawei.com> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: 'capwap' Subject: Re: [Capwap] vsp definition has no length X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 HI, Why yes. This was specified in the proposal for CAPWAP data packet formats that I sent June 8th. Did you miss it? Regards, /david t. perkins On Tue, 20 Jun 2006, sujay wrote: > Hi David, > > Are you suggesting to remove the vsp element(as in section 4.4.32) , > which could be carried > in any control message(as in 4.3.1.1 ), and instead have a generic vsp > control message type ??? > > Please correct me. > > Regds, > Sujay G > My Location; > http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085 > &t=h&hl=en > > > This e-mail and attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure, > reproduction, or dissemination) by persons other than the intended > recipient's) is prohibited. If you receive this e-mail in error, please > notify the sender by phone or email immediately and delete it! > > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Tuesday, June 20, 2006 5:04 AM > To: Scott G. Kelly > Cc: capwap > Subject: Re: [Capwap] vsp definition has no length > > > HI, > > You left off the outside wrapper as is specified in CAPWAP-01. > > Thus, you currently have, as defined in section 4.4, > "CAPWAP Protocol Message Elements", and section 4.4.32, > "Vendor Specific Payload" for vendor message elements: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type=43 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Element ID | Value... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ^-don't need length here Thus, you > don't need an additional "length". > > In the CAPWAP packet formats that I sent out some time ago, > I proposed that there be no difference in format between > "CAPWAP STD message elements" and "CAPWAP vendor specific message > elements". Both would have the following format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message Element Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length | Value .... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > Where the encoding of "message element type" is > Message element type value = IANA Enterprise Number * 4096 + > enterprise specific message element type number > > (and for CAPWAP standard, zero is used for the value > IANA Enterprise number) > > This results in 12 bits (0-4095) for element types, and 20 bits > (0-1048575) for Enterprise numbers. If you look at OUI assignments, > which have been around a lot longer than enterprise numbers, they have > approximately 52K allocated. Thus, 64k (16 bits), is probably not > enough, and 1M (20 bits) looks big enough. > > Regards, > /david t. perkins > > On Mon, 19 Jun 2006, Scott G. Kelly wrote: > > Here's the current vendor-specific payload definition: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Vendor Identifier | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Element ID | Value... | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > Wouldn't something like this make more sense? > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Vendor Identifier | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Length | Element ID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Value.... > > +-+-+-+-+-+-+- > > > > > > --Scott > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 20 10:02:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsgns-0003p4-Vi for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 10:02:04 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsgnp-0002zO-Af for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 10:02:04 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C1A1B430158 for ; Tue, 20 Jun 2006 07:02:00 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3F92D430092 for ; Tue, 20 Jun 2006 07:00:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 25623430CC6 for ; Tue, 20 Jun 2006 07:00:56 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by hermes.tigertech.net (Postfix) with ESMTP id 942E3430CBC for ; Tue, 20 Jun 2006 07:00:52 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x31so499295pye for ; Tue, 20 Jun 2006 07:00:51 -0700 (PDT) Received: by 10.35.93.15 with SMTP id v15mr9782664pyl; Tue, 20 Jun 2006 07:00:51 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Tue, 20 Jun 2006 07:00:51 -0700 (PDT) Message-ID: <26140d940606200700n4dee2eaana9b0adbd25f98fbd@mail.gmail.com> Date: Tue, 20 Jun 2006 10:00:51 -0400 From: "Michael Montemurro" To: "Saravanan Govindan" In-Reply-To: <5F09D220B62F79418461A978CA0921BDF71A4A@pslexc01.psl.local> MIME-Version: 1.0 References: <5F09D220B62F79418461A978CA0921BDF71A4A@pslexc01.psl.local> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1413400537==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ef4e20b714504e8d8d20eccf285dcca --===============1413400537== Content-Type: multipart/alternative; boundary="----=_Part_5603_213161.1150812051355" ------=_Part_5603_213161.1150812051355 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Saravanan, I've updated section 11.3 to deal with the GTK exchange and the handling of the KeyRSC in draft -02 to address your comments. I also provided a mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN message element as part of the Group Key exchange. We're finalizing the -02 draft this week and you should be able to look at it when we post it later this week. Cheers, Mike On 6/19/06, Saravanan Govindan wrote: > > If this is the case, perhaps more clarification can be provided. In > particular, which part of the document deals with this? > > > > Saravanan > > > > > > > > > ------------------------------ > > *From:* Bob O'Hara (boohara) [mailto:boohara@cisco.com] > *Sent:* Tuesday, June 20, 2006 11:14 AM > > *To:* capwap > *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderat= ions > > > > This can be done with the current messages. It is already being done in > shipping products using the LWAPP protocol, from which these messages wer= e > derived. > > -Bob > > > > > > ------------------------------ > > *From:* Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > *Sent:* Monday, June 19, 2006 6:37 PM > *To:* Bob O'Hara (boohara); capwap > *Subject:* RE: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderat= ions > > Consider the 4-way handshake in architecture designs where the WTP > maintains the Key-RSC and the AC constructs EAPOL messages (this is one o= f > the major designs brought out in the Architecture Taxonomy). Now, to > construct Message 3 of the 4-way handshake, the AC computes the Key-MIC > based on the prevailing Key-RSC. Since the Key-RSC is maintained by the W= TP, > there needs to be some way to transfer this information to the AC. > > > > I am open to a different way of doing this from what I've suggested > earlier =96 using of separate Key Configuration message. My concern is on= ly to > see that this can be accomplished in the CAPWAP protocol. > > > > Saravanan > > > > > > > ------------------------------ > > *From:* Bob O'Hara (boohara) [mailto:boohara@cisco.com] > *Sent:* Tuesday, June 20, 2006 1:15 AM > *To:* capwap > *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderat= ions > > > > I believe that Mike is correct. There is no need to transfer the sequenc= e > counter from the WTP to the AC, if the AC is where the EAPOL messages are > constructed and the WTP is where the sequence counters are maintained. A > careful read of 802.11i on the use of that field will make this clear. > > -Bob > > > > > > ------------------------------ > > *From:* Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > *Sent:* Sunday, June 18, 2006 9:18 PM > *To:* Michael Montemurro > *Cc:* capwap > *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderat= ions > > Hi Mike, > > > > There are a number of designs for IEEE 802.11i. And I believe the > description you noted below is one of them. In other designs, the sequenc= e > counter is maintained at the point where encryption is performed. > > > > From my understanding of the update you mention to Add WLAN, the > assumption seems to be the AC manages the transmit sequence counter. So b= y > using the updated Add WLAN, the AC informs the WTP about the prevailing > sequence counter value. Have I understood this right? > > If what I've got above is right, we are still left with the case where th= e > sequence counter is maintained at the WTP. The Objectives highlights this= as > a mandatory requirement for the protocol. > > > > I'd appreciate if you could post the text relating to the update you > mention for Add WLAN. This can help better understand how the update addr= ess > both the designs. > > > > Cheers, > > > > Saravanan > > > > > > > > > > > ------------------------------ > > *From:* Michael Montemurro [mailto:montemurro.michael@gmail.com] > *Sent:* Saturday, June 17, 2006 9:47 AM > *To:* Saravanan Govindan > *Cc:* capwap > *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderat= ions > > > > Saravanan, > > > > I have looked through IEEE 802.11i as well as talked with others who had > implemented IEEE 802.11i. The treatment of the KeyRSC setting is not > explained as well as it could be in the IEEE 802.11i draft. In many > implementations, the Authenticator sets the transmit sequence counter wit= h > the new GTK and passes them both down to the MAC. The Authenticator then > transmits this information to the STA as part of the GTK1 EAPoL message. > Both the STA and the WTP will then begin using the new TSC and the group = key > to encrypt broadcast/multicast traffic. > > > > To address this in CAPWAP I have updated the AddWLAN message to include > the transmit sequence counter for the GTK. That should address any issues > with counters and key states. > > > > Cheers, > > > > Mike > > > > > > On 6/7/06, *Saravanan Govindan* > wrote: > > Hi Mike, > > > > Following from my earlier note, this is the suggestion for handling KeyRS= C > maintained in a WTP. > > > > The suggestion is to include a new IEEE 802.11 specific CAPWAP control > messages called "IEEE 802.11 Key Configuration". > > > > Following from CAPWAP Specifications-01; > > > > CAPWAP Control Message Message Type > > Value > > > > IEEE 802.11 Key Configuration 3398914 > > IEEE 802.11 Key Configuration Response 3398915 > > > > > > The suggested text follows; > > > > [START OF SUGGESTED TEXT] > > > > 11.7.3. IEEE 802.11 Key Configuration > > > > The IEEE 802.11 Key Configuration CAPWAP message is used in WTP designs i= n > which IEEE 802.11i authenticator functions are performed by the AC and > IEEE 802.11i cryptographic functions (encryption/decryption) are performe= d > by the WTPs. > > > > This CAPWAP message is sent from the AC to the WTP. It must contain eithe= r > of the following 2 message elements. > > > > > > > > > > 11.7.3.1 IEEE 802.11 4-way Handshake > > > > The IEEE 802.11 4-way Handshake message element is sent by the AC to the > WTP during the 4-way handshake. It contains Message-3 of the 4-way handsh= ake > with unassigned values as the AC is unaware of the prevailing KeyRSC > sequence counter maintained by the WTP. > > > > Message-1, Message-2 and Message-4 of the 4-way handshake are transported > within CAPWAP data packets between AC and WTP. > > > > The IEEE 802.11 4-way Handshake message element contains the following > values: > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | GTK-Flag | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Encryption-Data | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | EAPoL-Frame | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > GTK-Flag: An 8-bit flag that determines the type of KeyMIC calculation > > > > 0 =96 New GTK, KeyMIC is calculated with KeyRSC =3D 0 > > > > 1 =96 Existing GTK, KeyMIC is calculated with prevailing KeyRSC valu= e > > > > Encryption-Data: Contains PTK and/or GTK > > > > EAPoL-Frame: Contains Message-3 of 4-way handshake with unassigned fields > > > > Upon receipt of the Key Configuration message from the AC, the WTP > performs the following operations: > > > > i. Assigns the corresponding value to the KeyRSC field of > the EAPoL-Frame > > ii. Calculates KeyMIC with Encrytion-Data and KeyRSC > > iii. Updates Message-3 of 4-way handshake > > iv. Continues regular 4-way handshake with wireless terminals > > > > > > > > > > 11.7.3.2 IEEE 802.11 Group Key Handshake > > > > The IEEE 802.11 Group Key Handshake message element is sent by the AC to > the WTP during the group key handshake. It contains Message-1 of the grou= p > key handshake with unassigned values as the AC is unaware of the prevaili= ng > KeyRSC sequence counter maintained by the WTP. > > > > Message-2 of the group key handshake is transported within a CAPWAP data > packet between AC and WTP. > > > > The IEEE 802.11 Group Key Handshake message element contains the followin= g > values: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | GTK-Flag | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Encryption-Data | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | EAPoL-Frame | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > GTK-Flag: An 8-bit flag that determines the type of KeyMIC calculation > > > > 0 =96 New GTK, KeyMIC is calculated with KeyRSC =3D 0 > > > > 1 =96 Existing GTK, KeyMIC is calculated with prevailing KeyRSC valu= e > > > > Encryption-Data: Contains PTK and/or GTK > > > > EAPoL-Frame: Contains Message-1 of group key handshake with unassigned > fields > > > > Upon receipt of the Key Configuration message from AC, the WTP performs > the following operations: > > i. Assigns the corresponding value to the KeyRSC field of > the EAPoL-Frame > > ii. Calculates KeyMIC with Encrytion-Data and KeyRSC > > iii. Updates Message-1 of group key handshake > > iv. Continues regular group handshake with wireless terminals > > > > > > > > > > 11.7.4 IEEE 802.11 Key Configuration Response > > > > The IEEE 802.11 Key Configuration Response CAPWAP message is sent by the > WTP to the AC as an acknowledgement of the receipt of an IEEE 802.11 Key > Configuration Request. > > > > [END OF SUGGESTED TEXT] > > > > > > > > > Saravanan > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_5603_213161.1150812051355 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Saravanan,
 
I've updated section 11.3 to deal with the GTK exchange and the handli= ng of the KeyRSC in draft -02 to address your comments. I also provided a m= echanism for the AC to transmit the keyRSC to the WTP using the updateWLAN = message element as part of the Group Key exchange.
 
We're finalizing the -02 draft this week and you should be able to loo= k at it when we post it later this week.
 
Cheers,
 
Mike
 
On 6/19/06, = Saravanan Govindan <Saravanan.Govindan@sg.panasonic.com> wrote:

If this is the case, perhaps more clarification can be provided= . In particular, which part of the document deals with this? =

 

Saravanan

 

 

 

 

From: Bob = O'Hara (boohara) [mailto: boohara@cisco.com]
Sent: Tuesday, June 20, 2006 11:14 AM<= /span>


To: capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11= i Considerations

This can be done with the current m= essages.  It is already being done in shipping products using the LWAP= P protocol, from which these messages were derived.

From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: Monday, June 19, 2006 6:37 PM
To: Bob O'Hara (boohara); capwap
Subject: RE: [Capwap] Clarification of Is= sue 43: IEEE=20 802.11i Considerations

Consider the 4-way handshake in architecture designs where the = WTP maintains the Key-RSC and the AC constructs EAPOL messages (this is one= of the major designs brought out in the Architecture Taxonomy). Now, to co= nstruct Message 3 of the 4-way handshake, the AC computes the Key-MIC based= on the prevailing Key-RSC. Since the Key-RSC is maintained by the WTP, the= re needs to be some way to transfer this information to the AC.=20

 

I am open to a different way of doing this from what I've sugge= sted earlier =96 using of separate Key Configuration message. My concern is= only to see that this can be accomplished in the CAPWAP protocol.

 

Saravanan

 

 

 

From: Bob = O'Hara (boohara) [mailto: boohara@cisco.com]
Sent: Tuesday, June 20, 2006 1:15 AM To: capwap
Subject: Re: [Capwap] Clarification of Is= sue 43: IEEE 802.11i Considerations

I believe that Mike is correct.&nbs= p; There is no need to transfer the sequence counter from the WTP to the AC= , if the AC is where the EAPOL messages are constructed and the WTP is wher= e the sequence counters are maintained.  A careful read of=20 802.11i on the use of that field will make this clear.

From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: Sunday, June 18, 2006 9:18 PM
To: Michael Montemurro
Cc: capwap
Su= bject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerat= ions

Hi Mike,

 

There are a number of designs for IEEE 802.11i. And I believe t= he description you noted below is one of them. In other designs, the sequen= ce counter is maintained at the point where encryption is performed.=20

 

From my understanding of the update you mention to Add WLAN, th= e assumption seems to be the AC manages the transmit sequence counter. So b= y using the updated Add WLAN, the AC informs the WTP about the prevailing s= equence counter value. Have I understood this right?

If what I've got above is right, we are still left with the case wh= ere the sequence counter is maintained at the WTP. The Objectives highlight= s this as a mandatory requirement for the protocol.

 

I'd appreciate if you could post the text relating to the updat= e you mention for Add WLAN. This can help better understand how the update = address both the designs.=20

 

Cheers,

 

Saravanan

 

 

 

 

 

From: Mich= ael Montemurro [mailto: montemurro.michael@gmail.co= m]
Sent: Saturday, = June 17, 2006 9:47 AM
To: Saravanan Govindan<= br>Cc: capwap
Subject: Re: [Capwap] Clarification o= f Issue 43: IEEE=20 802.11i Considerations

On 6/7/06, Saravanan Govindan<= /span> < Saravanan.Govindan@sg.panasonic.com> wrote:

Hi Mike,

 

Following from my earlier note, this is the suggestion for handling KeyRSC= maintained in a WTP.

 

The suggestion is to include a new IEEE 802.11 specific CAPWAP control mes= sages called "IEEE 802.11 Key Configuration".

 

Following from CAPWAP Specifications-01;

 

CAPWAP Control Message        &nbs= p;           Message Type=

            &n= bsp;            = ;            &n= bsp;    Value

 

IEEE 802.11 Key Configuration       &nb= sp;     3398914

IEEE 802.11 Key Configuration Response    3398915

 

 

The suggested text follows;

 

[START OF SUGGESTED TEXT]

 

11.7.3. IEEE 802.11 Key Configuration

 

The IEEE 802.11 Key Configuration CAPWAP message is used in WTP designs in= which IEEE 802.11i authenticator functions are performed by the AC and IEE= E=20 802.11i cryptographic functions (encryption/decryption) are performed by th= e WTPs.

 

This CAPWAP message is sent from the AC to the WTP. It must contain either= of the following 2 message elements.

 

 

 

 

11.7.3.1     IEEE 802= .11 4-way Handshake

 

<= span style=3D"FONT-SIZE: 10pt">The IEEE 802.11 4-way Handshake message elem= ent is sent by the AC to the WTP during the 4-way handshake. It contains Me= ssage-3 of the 4-way handshake with unassigned values as the AC is unaware = of the prevailing KeyRSC sequence counter maintained by the WTP.  =20

<= span style=3D"FONT-SIZE: 10pt"> 

<= span style=3D"FONT-SIZE: 10pt">Message-1, Message-2 and Message-4 of the 4-= way handshake are transported within CAPWAP data packets between AC and WTP= .

<= span style=3D"FONT-SIZE: 10pt"> 

<= span style=3D"FONT-SIZE: 10pt">The IEEE 802.11 4-way Handshake message elem= ent contains the following values:

<= span style=3D"FONT-SIZE: 10pt"> 

<= span style=3D"FONT-SIZE: 10pt"> 

<= span style=3D"FONT-SIZE: 10pt">      0  =             &nb= sp;    1        &nbs= p;          2   = ;            &n= bsp;   3

<= span style=3D"FONT-SIZE: 10pt">      0 1 2 3 4 5 6= 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

<= span style=3D"FONT-SIZE: 10pt">     +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<= span style=3D"FONT-SIZE: 10pt">     |    = ;GTK-Flag   |         &nb= sp;         Reserved  &nb= sp;            =      |

<= span style=3D"FONT-SIZE: 10pt">     +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<= span style=3D"FONT-SIZE: 10pt">     |   =             &nb= sp;        Encryption-Data   &= nbsp;           &nbs= p;        |

<= span style=3D"FONT-SIZE: 10pt">     +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<= span style=3D"FONT-SIZE: 10pt">     |   =             &nb= sp;          EAPoL-Frame  = ;            &n= bsp;           |

<= span style=3D"FONT-SIZE: 10pt">     +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

 

GTK-Flag: An 8-bit flag that determines the type of KeyMIC calculation

    

     0 =96 New GTK, KeyMIC is calculated with KeyRSC = =3D 0

 

     1 =96 Existing GTK, KeyMIC is calculated with pre= vailing KeyRSC value

 

Encryption-Data: Contains PTK and/or GTK

 

EAPoL-Frame: Contains Message-3 of 4-way handshake with unassigned fields<= /span>

 

<= span style=3D"FONT-SIZE: 10pt">Upon receipt of the Key Configuration messag= e from the AC, the WTP performs the following operations:

<= span style=3D"FONT-SIZE: 10pt"> 

    i. &nb= sp;          Assig= ns the corresponding value to the KeyRSC field of the EAPoL-Frame=20

ii.             <= /font>Calculates KeyMIC with Encrytion-Data and KeyRSC

iii.             <= /font>Updates Message-3 of 4-way handshake

iv.             <= /font>Continues regular 4-way handshake with wireless terminals=

 

 

 

 

11.7.3.2     IEEE 802= .11 Group Key Handshake

 

<= span style=3D"FONT-SIZE: 10pt">The IEEE 802.11 Group Key Handshake message = element is sent by the AC to the WTP during the group key handshake. It con= tains Message-1 of the group key handshake with unassigned values as the AC= is unaware of the prevailing KeyRSC sequence counter maintained by the WTP= .  =20

<= span style=3D"FONT-SIZE: 10pt"> 

<= span style=3D"FONT-SIZE: 10pt">Message-2 of the group key handshake is tran= sported within a CAPWAP data packet between AC and WTP.

<= span style=3D"FONT-SIZE: 10pt"> 

<= span style=3D"FONT-SIZE: 10pt">The IEEE 802.11 Group Key Handshake message = element contains the following values:

 

<= span style=3D"FONT-SIZE: 10pt">      0  =             &nb= sp;    1        &nbs= p;          2   = ;            &n= bsp;   3

<= span style=3D"FONT-SIZE: 10pt">      0 1 2 3 4 5 6= 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

<= span style=3D"FONT-SIZE: 10pt">     +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<= span style=3D"FONT-SIZE: 10pt">     |    = ;GTK-Flag   |         &nb= sp;         Reserved  &nb= sp;            =      |

<= span style=3D"FONT-SIZE: 10pt">     +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<= span style=3D"FONT-SIZE: 10pt">     |   =             &nb= sp;        Encryption-Data   &= nbsp;           &nbs= p;        |

<= span style=3D"FONT-SIZE: 10pt">     +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<= span style=3D"FONT-SIZE: 10pt">     |   =             &nb= sp;          EAPoL-Frame  = ;            &n= bsp;           |

<= span style=3D"FONT-SIZE: 10pt">     +-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

 

GTK-Flag: An 8-bit flag that determines the type of KeyMIC calculation

    

     0 =96 New GTK, KeyMIC is calculated with KeyRSC = =3D 0

 

     1 =96 Existing GTK, KeyMIC is calculated with pre= vailing KeyRSC value

 

Encryption-Data: Contains PTK and/or GTK

 

EAPoL-Frame: Contains Message-1 of group key handshake with unassigned fie= lds

 

<= span style=3D"FONT-SIZE: 10pt">Upon receipt of the Key Configuration messag= e from AC, the WTP performs the following operations:

    i. &nb= sp;          Assig= ns the corresponding value to the KeyRSC field of the EAPoL-Frame=20

ii.             <= /font>Calculates KeyMIC with Encrytion-Data and KeyRSC

iii.             <= /font>Updates Message-1 of group key handshake

iv.             <= /font>Continues regular group handshake with wireless terminals=

 

 

 

 

11.7.4     IEEE 802.11 Key Configuration Response

 

The IEEE 802.11 Key Configuration Response CAPWAP message is sent by the W= TP to the AC as an acknowledgement of the receipt of an IEEE 802.11 Key Con= figuration Request.=20

 

[END OF SUGGESTED TEXT]

 

 

 


Saravanan

http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.co= m/pipermail/capwap


------=_Part_5603_213161.1150812051355-- --===============1413400537== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1413400537==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 20 10:14:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsgzt-0004Ux-Sh for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 10:14:29 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsgzr-0004Sr-1T for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 10:14:29 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id AA1B14301BA for ; Tue, 20 Jun 2006 07:14:26 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 0FD55430092 for ; Tue, 20 Jun 2006 07:14:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0351039803F for ; Tue, 20 Jun 2006 07:14:03 -0700 (PDT) Received: from huawei.com (szxga02-in.huawei.com [61.144.161.54]) by zoidberg.tigertech.net (Postfix) with ESMTP id 83F47398046 for ; Tue, 20 Jun 2006 07:13:57 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1500F1VXLL9L@szxga02-in.huawei.com> for capwap@frascone.com; Tue, 20 Jun 2006 22:29:45 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1500IEQXLKWJ@szxga02-in.huawei.com> for capwap@frascone.com; Tue, 20 Jun 2006 22:29:45 +0800 (CST) Received: from dell60 ([10.18.7.113]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J15009RKWXJ96@szxml03-in.huawei.com> for capwap@frascone.com; Tue, 20 Jun 2006 22:15:20 +0800 (CST) Date: Tue, 20 Jun 2006 19:43:45 +0530 From: sujay In-reply-to: To: "'David T. Perkins'" Message-id: <000001c69473$be9fa040$7107120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: 'capwap' Subject: Re: [Capwap] vsp definition has no length X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Hi, Guess, I did.. I would still prefer to have the flexibility of *my* message element extensions added over any standard control message type, Simply because some extensions may (and does in my case !) fit best with a specific control message type, and not as a separate msg type altogether. Having said that, I see it is a good idea to have v.s.p message type same as any standard control message type, which is what you recommend. Of course ,keeping the v.s.p message extension still intact(4.4.32), as it is now. Regds, Sujay G My Location; http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085 &t=h&hl=en This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Tuesday, June 20, 2006 7:18 PM To: sujay Cc: 'Scott G. Kelly'; 'capwap' Subject: RE: [Capwap] vsp definition has no length HI, Why yes. This was specified in the proposal for CAPWAP data packet formats that I sent June 8th. Did you miss it? Regards, /david t. perkins On Tue, 20 Jun 2006, sujay wrote: > Hi David, > > Are you suggesting to remove the vsp element(as in section 4.4.32) , > which could be carried in any control message(as in 4.3.1.1 ), and > instead have a generic vsp control message type ??? > > Please correct me. > > Regds, > Sujay G > My Location; > http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.5250 > 85 > &t=h&hl=en > > > This e-mail and attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address > is listed above. Any use of the information contained herein in any > way (including, but not limited to, total or partial disclosure, > reproduction, or dissemination) by persons other than the intended > recipient's) is prohibited. If you receive this e-mail in error, > please notify the sender by phone or email immediately and delete it! > > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Tuesday, June 20, 2006 5:04 AM > To: Scott G. Kelly > Cc: capwap > Subject: Re: [Capwap] vsp definition has no length > > > HI, > > You left off the outside wrapper as is specified in CAPWAP-01. > > Thus, you currently have, as defined in section 4.4, > "CAPWAP Protocol Message Elements", and section 4.4.32, "Vendor > Specific Payload" for vendor message elements: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type=43 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Element ID | Value... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ^-don't need length here Thus, you > don't need an additional "length". > > In the CAPWAP packet formats that I sent out some time ago, > I proposed that there be no difference in format between > "CAPWAP STD message elements" and "CAPWAP vendor specific message > elements". Both would have the following format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message Element Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length | Value .... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > Where the encoding of "message element type" is > Message element type value = IANA Enterprise Number * 4096 + > enterprise specific message element type number > > (and for CAPWAP standard, zero is used for the value > IANA Enterprise number) > > This results in 12 bits (0-4095) for element types, and 20 bits > (0-1048575) for Enterprise numbers. If you look at OUI assignments, > which have been around a lot longer than enterprise numbers, they have > approximately 52K allocated. Thus, 64k (16 bits), is probably not > enough, and 1M (20 bits) looks big enough. > > Regards, > /david t. perkins > > On Mon, 19 Jun 2006, Scott G. Kelly wrote: > > Here's the current vendor-specific payload definition: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Vendor Identifier | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Element ID | Value... | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > Wouldn't something like this make more sense? > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Vendor Identifier | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Length | Element ID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Value.... > > +-+-+-+-+-+-+- > > > > > > --Scott > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 20 10:31:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FshGb-0005OR-7H for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 10:31:45 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FshGZ-0005Ky-KJ for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 10:31:45 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 04A4243016D for ; Tue, 20 Jun 2006 07:31:43 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id EA17A430092 for ; Tue, 20 Jun 2006 07:31:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C117E430D26 for ; Tue, 20 Jun 2006 07:31:18 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id E2B4C430D1D for ; Tue, 20 Jun 2006 07:31:16 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5KEVG4b029515; Tue, 20 Jun 2006 07:31:16 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5KEVG0m029512; Tue, 20 Jun 2006 07:31:16 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 20 Jun 2006 07:31:16 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: sujay In-Reply-To: <000001c69473$be9fa040$7107120a@china.huawei.com> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: 'capwap' Subject: Re: [Capwap] vsp definition has no length X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb HI, I'm having a difficult time understanding what you are saying. What do you mean by "I would still prefer to have the flexibility of *my* message element extensions added over any standard control message type"? Would you provide some examples to illustrate what you mean. Thanks, /david t. perkins On Tue, 20 Jun 2006, sujay wrote: > Hi, > Guess, I did.. > > I would still prefer to have the flexibility of *my* > message element extensions added over any standard > control message type, > Simply because some extensions may (and does in my case !) > fit best with a specific control message type, and not as a separate msg > type > altogether. > > Having said that, I see it is a good idea to have v.s.p message type > same > as any standard control message type, which is what you recommend. > > Of course ,keeping the v.s.p message extension still intact(4.4.32), as > it is now. > > Regds, > Sujay G > My Location; > http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085 > &t=h&hl=en > > > This e-mail and attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure, > reproduction, or dissemination) by persons other than the intended > recipient's) is prohibited. If you receive this e-mail in error, please > notify the sender by phone or email immediately and delete it! > > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Tuesday, June 20, 2006 7:18 PM > To: sujay > Cc: 'Scott G. Kelly'; 'capwap' > Subject: RE: [Capwap] vsp definition has no length > > > HI, > > Why yes. This was specified in the proposal for CAPWAP > data packet formats that I sent June 8th. Did you miss > it? > > Regards, > /david t. perkins > > On Tue, 20 Jun 2006, sujay wrote: > > > Hi David, > > > > Are you suggesting to remove the vsp element(as in section 4.4.32) , > > which could be carried in any control message(as in 4.3.1.1 ), and > > instead have a generic vsp control message type ??? > > > > Please correct me. > > > > Regds, > > Sujay G > > My Location; > > http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.5250 > > 85 > > &t=h&hl=en > > > > > > This e-mail and attachments contain confidential information from > > HUAWEI, which is intended only for the person or entity whose address > > is listed above. Any use of the information contained herein in any > > way (including, but not limited to, total or partial disclosure, > > reproduction, or dissemination) by persons other than the intended > > recipient's) is prohibited. If you receive this e-mail in error, > > please notify the sender by phone or email immediately and delete it! > > > > -----Original Message----- > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > Sent: Tuesday, June 20, 2006 5:04 AM > > To: Scott G. Kelly > > Cc: capwap > > Subject: Re: [Capwap] vsp definition has no length > > > > > > HI, > > > > You left off the outside wrapper as is specified in CAPWAP-01. > > > > Thus, you currently have, as defined in section 4.4, > > "CAPWAP Protocol Message Elements", and section 4.4.32, "Vendor > > Specific Payload" for vendor message elements: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type=43 | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Vendor Identifier | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Element ID | Value... | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > ^-don't need length here Thus, you > > don't need an additional "length". > > > > In the CAPWAP packet formats that I sent out some time ago, > > I proposed that there be no difference in format between > > "CAPWAP STD message elements" and "CAPWAP vendor specific message > > elements". Both would have the following format: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Message Element Type | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Length | Value .... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > > > Where the encoding of "message element type" is > > Message element type value = IANA Enterprise Number * 4096 + > > enterprise specific message element type number > > > > (and for CAPWAP standard, zero is used for the value > > IANA Enterprise number) > > > > This results in 12 bits (0-4095) for element types, and 20 bits > > (0-1048575) for Enterprise numbers. If you look at OUI assignments, > > which have been around a lot longer than enterprise numbers, they have > > > approximately 52K allocated. Thus, 64k (16 bits), is probably not > > enough, and 1M (20 bits) looks big enough. > > > > Regards, > > /david t. perkins > > > > On Mon, 19 Jun 2006, Scott G. Kelly wrote: > > > Here's the current vendor-specific payload definition: > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Vendor Identifier | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Element ID | Value... | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > Wouldn't something like this make more sense? > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Vendor Identifier | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Length | Element ID | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Value.... > > > +-+-+-+-+-+-+- > > > > > > > > > --Scott > > > > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 20 10:32:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FshHc-0007CC-FX for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 10:32:48 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FshHb-0005Ox-QI for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 10:32:48 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6DAA3430092 for ; Tue, 20 Jun 2006 07:32:47 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 76ACB430092 for ; Tue, 20 Jun 2006 07:32:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6AB35398008 for ; Tue, 20 Jun 2006 07:32:19 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.152]) by zoidberg.tigertech.net (Postfix) with ESMTP id 56605398046 for ; Tue, 20 Jun 2006 07:32:17 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (rwcrmhc12) with ESMTP id <20060620143215m1200947qme>; Tue, 20 Jun 2006 14:32:16 +0000 Message-ID: <449806EF.7010000@hyperthought.com> Date: Tue, 20 Jun 2006 07:32:15 -0700 From: Scott G Kelly User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: sujay References: <000001c69473$be9fa040$7107120a@china.huawei.com> In-Reply-To: <000001c69473$be9fa040$7107120a@china.huawei.com> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: 'capwap' Subject: Re: [Capwap] vsp definition has no length X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 I don't know about anyone else, but from an implementor's standpoint, I'm a little concerned about this. I know something similar to this made it into the 01 draft, but I was petty surprised when I saw it. The proposal is to include a vendor ID in *every* message element. That is, the message element type field has some bits which indicate vendor id, and some bits which indicate the actual element type. This means every message element is a VSP. I'm not sure what functionality this is intended to provide that can't be provided by a generic VSP, and the fact that we will have to check each and every message element for this condition (and deal with unexpected ones) seems pretty painful for functionality I could alternatively attain with a generic VSP. Use of VSPs should be relatively rare in a standardized, interoperable protocol. Building them right into each and every message element seems like an invitation to non-interoperability, not to mention a potential explosion in message processing complexity. Am I missing something here? What is the value in this? Thanks, Scott sujay wrote: > Hi, > Guess, I did.. > > I would still prefer to have the flexibility of *my* > message element extensions added over any standard > control message type, > Simply because some extensions may (and does in my case !) > fit best with a specific control message type, and not as a separate msg > type > altogether. > > Having said that, I see it is a good idea to have v.s.p message type > same > as any standard control message type, which is what you recommend. > > Of course ,keeping the v.s.p message extension still intact(4.4.32), as > it is now. > > Regds, > Sujay G > My Location; > http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085 > &t=h&hl=en > > > This e-mail and attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure, > reproduction, or dissemination) by persons other than the intended > recipient's) is prohibited. If you receive this e-mail in error, please > notify the sender by phone or email immediately and delete it! > > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Tuesday, June 20, 2006 7:18 PM > To: sujay > Cc: 'Scott G. Kelly'; 'capwap' > Subject: RE: [Capwap] vsp definition has no length > > > HI, > > Why yes. This was specified in the proposal for CAPWAP > data packet formats that I sent June 8th. Did you miss > it? > > Regards, > /david t. perkins > > On Tue, 20 Jun 2006, sujay wrote: > >> Hi David, >> >> Are you suggesting to remove the vsp element(as in section 4.4.32) , >> which could be carried in any control message(as in 4.3.1.1 ), and >> instead have a generic vsp control message type ??? >> >> Please correct me. >> >> Regds, >> Sujay G >> My Location; >> http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.5250 >> 85 >> &t=h&hl=en >> >> >> This e-mail and attachments contain confidential information from >> HUAWEI, which is intended only for the person or entity whose address >> is listed above. Any use of the information contained herein in any >> way (including, but not limited to, total or partial disclosure, >> reproduction, or dissemination) by persons other than the intended >> recipient's) is prohibited. If you receive this e-mail in error, >> please notify the sender by phone or email immediately and delete it! >> >> -----Original Message----- >> From: David T. Perkins [mailto:dperkins@dsperkins.com] >> Sent: Tuesday, June 20, 2006 5:04 AM >> To: Scott G. Kelly >> Cc: capwap >> Subject: Re: [Capwap] vsp definition has no length >> >> >> HI, >> >> You left off the outside wrapper as is specified in CAPWAP-01. >> >> Thus, you currently have, as defined in section 4.4, >> "CAPWAP Protocol Message Elements", and section 4.4.32, "Vendor >> Specific Payload" for vendor message elements: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type=43 | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Vendor Identifier | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Element ID | Value... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ^-don't need length here Thus, you >> don't need an additional "length". >> >> In the CAPWAP packet formats that I sent out some time ago, >> I proposed that there be no difference in format between >> "CAPWAP STD message elements" and "CAPWAP vendor specific message >> elements". Both would have the following format: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Message Element Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Length | Value .... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> >> Where the encoding of "message element type" is >> Message element type value = IANA Enterprise Number * 4096 + >> enterprise specific message element type number >> >> (and for CAPWAP standard, zero is used for the value >> IANA Enterprise number) >> >> This results in 12 bits (0-4095) for element types, and 20 bits >> (0-1048575) for Enterprise numbers. If you look at OUI assignments, >> which have been around a lot longer than enterprise numbers, they have > >> approximately 52K allocated. Thus, 64k (16 bits), is probably not >> enough, and 1M (20 bits) looks big enough. >> >> Regards, >> /david t. perkins >> >> On Mon, 19 Jun 2006, Scott G. Kelly wrote: >>> Here's the current vendor-specific payload definition: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Vendor Identifier | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Element ID | Value... | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> Wouldn't something like this make more sense? >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Vendor Identifier | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Length | Element ID | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Value.... >>> +-+-+-+-+-+-+- >>> >>> >>> --Scott >>> >>> _________________________________________________________________ >>> To unsubscribe or modify your subscription options, please visit: >>> http://lists.frascone.com/mailman/listinfo/capwap >>> >>> Archives: http://lists.frascone.com/pipermail/capwap >>> >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap >> > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 20 10:59:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fshhj-0007X5-Nu for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 10:59:47 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fshhh-0000RS-HR for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 10:59:47 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8D82643012F for ; Tue, 20 Jun 2006 07:59:44 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3423B430092 for ; Tue, 20 Jun 2006 07:59:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 23837398008 for ; Tue, 20 Jun 2006 07:59:16 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3766339804C for ; Tue, 20 Jun 2006 07:59:11 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5KExAip005095; Tue, 20 Jun 2006 07:59:10 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5KExALu005092; Tue, 20 Jun 2006 07:59:10 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 20 Jun 2006 07:59:10 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: scott G Kelly In-Reply-To: <449806EF.7010000@hyperthought.com> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: 'capwap' Subject: Re: [Capwap] vsp definition has no length X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f HI, The proposal to have a single way to encode the type of message type instead of two ways, adds nothing to the complexity of encoding or parsing of message elements. In fact it reduces complexity. Likewise, it neither encourages or discourages use of vendor defined message elements. I believe what is currently in the CAPWAP-01 document will most likely become a frequently misunderstood and inappropriately implemented portion of the specification. This was demonstrated by your question yesterday! And possibly by sujay's question today (but I'm not sure what sujay meant, and I'm waiting for a response). Regards, /david t. perkins On Tue, 20 Jun 2006, Scott G Kelly wrote: > I don't know about anyone else, but from an implementor's standpoint, > I'm a little concerned about this. I know something similar to this made > it into the 01 draft, but I was petty surprised when I saw it. > > The proposal is to include a vendor ID in *every* message element. That > is, the message element type field has some bits which indicate vendor > id, and some bits which indicate the actual element type. This means > every message element is a VSP. > > I'm not sure what functionality this is intended to provide that can't > be provided by a generic VSP, and the fact that we will have to check > each and every message element for this condition (and deal with > unexpected ones) seems pretty painful for functionality I could > alternatively attain with a generic VSP. > > Use of VSPs should be relatively rare in a standardized, interoperable > protocol. Building them right into each and every message element seems > like an invitation to non-interoperability, not to mention a potential > explosion in message processing complexity. Am I missing something here? > What is the value in this> > Thanks, > > Scott > > sujay wrote: > > Hi, > > Guess, I did.. > > > > I would still prefer to have the flexibility of *my* > > message element extensions added over any standard > > control message type, > > Simply because some extensions may (and does in my case !) > > fit best with a specific control message type, and not as a separate msg > > type > > altogether. > > > > Having said that, I see it is a good idea to have v.s.p message type > > same > > as any standard control message type, which is what you recommend. > > > > Of course ,keeping the v.s.p message extension still intact(4.4.32), as > > it is now. > > > > Regds, > > Sujay G > > My Location; > > http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085 > > &t=h&hl=en > > > > > > This e-mail and attachments contain confidential information from > > HUAWEI, which is intended only for the person or entity whose address is > > listed above. Any use of the information contained herein in any way > > (including, but not limited to, total or partial disclosure, > > reproduction, or dissemination) by persons other than the intended > > recipient's) is prohibited. If you receive this e-mail in error, please > > notify the sender by phone or email immediately and delete it! > > > > -----Original Message----- > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > Sent: Tuesday, June 20, 2006 7:18 PM > > To: sujay > > Cc: 'Scott G. Kelly'; 'capwap' > > Subject: RE: [Capwap] vsp definition has no length > > > > > > HI, > > > > Why yes. This was specified in the proposal for CAPWAP > > data packet formats that I sent June 8th. Did you miss > > it? > > > > Regards, > > /david t. perkins > > > > On Tue, 20 Jun 2006, sujay wrote: > > > >> Hi David, > >> > >> Are you suggesting to remove the vsp element(as in section 4.4.32) , > >> which could be carried in any control message(as in 4.3.1.1 ), and > >> instead have a generic vsp control message type ??? > >> > >> Please correct me. > >> > >> Regds, > >> Sujay G > >> My Location; > >> http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.5250 > >> 85 > >> &t=h&hl=en > >> > >> > >> This e-mail and attachments contain confidential information from > >> HUAWEI, which is intended only for the person or entity whose address > >> is listed above. Any use of the information contained herein in any > >> way (including, but not limited to, total or partial disclosure, > >> reproduction, or dissemination) by persons other than the intended > >> recipient's) is prohibited. If you receive this e-mail in error, > >> please notify the sender by phone or email immediately and delete it! > >> > >> -----Original Message----- > >> From: David T. Perkins [mailto:dperkins@dsperkins.com] > >> Sent: Tuesday, June 20, 2006 5:04 AM > >> To: Scott G. Kelly > >> Cc: capwap > >> Subject: Re: [Capwap] vsp definition has no length > >> > >> > >> HI, > >> > >> You left off the outside wrapper as is specified in CAPWAP-01. > >> > >> Thus, you currently have, as defined in section 4.4, > >> "CAPWAP Protocol Message Elements", and section 4.4.32, "Vendor > >> Specific Payload" for vendor message elements: > >> > >> 0 1 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Type=43 | Length | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Vendor Identifier | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Element ID | Value... | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> ^-don't need length here Thus, you > >> don't need an additional "length". > >> > >> In the CAPWAP packet formats that I sent out some time ago, > >> I proposed that there be no difference in format between > >> "CAPWAP STD message elements" and "CAPWAP vendor specific message > >> elements". Both would have the following format: > >> > >> 0 1 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Message Element Type | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Length | Value .... > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> > >> Where the encoding of "message element type" is > >> Message element type value = IANA Enterprise Number * 4096 + > >> enterprise specific message element type number > >> > >> (and for CAPWAP standard, zero is used for the value > >> IANA Enterprise number) > >> > >> This results in 12 bits (0-4095) for element types, and 20 bits > >> (0-1048575) for Enterprise numbers. If you look at OUI assignments, > >> which have been around a lot longer than enterprise numbers, they have > > > >> approximately 52K allocated. Thus, 64k (16 bits), is probably not > >> enough, and 1M (20 bits) looks big enough. > >> > >> Regards, > >> /david t. perkins > >> > >> On Mon, 19 Jun 2006, Scott G. Kelly wrote: > >>> Here's the current vendor-specific payload definition: > >>> > >>> 0 1 2 3 > >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | Vendor Identifier | > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | Element ID | Value... | > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> > >>> > >>> Wouldn't something like this make more sense? > >>> > >>> 0 1 2 3 > >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | Vendor Identifier | > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | Length | Element ID | > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | Value.... > >>> +-+-+-+-+-+-+- > >>> > >>> > >>> --Scott > >>> > >>> _________________________________________________________________ > >>> To unsubscribe or modify your subscription options, please visit: > >>> http://lists.frascone.com/mailman/listinfo/capwap > >>> > >>> Archives: http://lists.frascone.com/pipermail/capwap > >>> > >> _________________________________________________________________ > >> To unsubscribe or modify your subscription options, please visit: > >> http://lists.frascone.com/mailman/listinfo/capwap > >> > >> Archives: http://lists.frascone.com/pipermail/capwap > >> > > > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 20 12:12:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsiqF-0000uL-6Q for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 12:12:39 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsiqD-0002TZ-DO for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 12:12:39 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 814F643016F for ; Tue, 20 Jun 2006 09:12:36 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D77EA430092 for ; Tue, 20 Jun 2006 09:12:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B20A1430EF8 for ; Tue, 20 Jun 2006 09:12:03 -0700 (PDT) Received: from huawei.com (szxga02-in.huawei.com [61.144.161.54]) by hermes.tigertech.net (Postfix) with ESMTP id 813CB430EF7 for ; Tue, 20 Jun 2006 09:11:56 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J16009Y232CV5@szxga02-in.huawei.com> for capwap@frascone.com; Wed, 21 Jun 2006 00:27:48 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1600HUZ32BUG@szxga02-in.huawei.com> for capwap@frascone.com; Wed, 21 Jun 2006 00:27:48 +0800 (CST) Received: from dell60 ([10.18.7.113]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1600ER32TJHG@szxml04-in.huawei.com> for capwap@frascone.com; Wed, 21 Jun 2006 00:22:32 +0800 (CST) Date: Tue, 20 Jun 2006 21:41:48 +0530 From: sujay In-reply-to: To: "'David T. Perkins'" , 'scott G Kelly' Message-id: <000001c69484$3bf87390$7107120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: 'capwap' Subject: Re: [Capwap] vsp definition has no length X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Hi, By encoding the Vendor ID in every message makes all category ,'VSP'. It does look good but MAY cause implementation complexity, may not be required for all messages, may be unnecessary altogether if the intention of the vsp element is made clear in the draft. David; My usage of the vsp element is thus; 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=32 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Element ID | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the above can be added to any of the Control message types; (say a Discovery message !) . And assume the information carried in this message makes best sense and usage when send along with other message elements in the Discovery message i.e. Discovery Type, WTP Descriptor etc.. So in case if your proposal includes removal of this vsp element, I wouldn't suggest. Kindly correct me. Regds, Sujay G My Location; http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085 &t=h&hl=en This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Tuesday, June 20, 2006 8:29 PM To: scott G Kelly Cc: 'capwap'; sujay Subject: Re: [Capwap] vsp definition has no length HI, The proposal to have a single way to encode the type of message type instead of two ways, adds nothing to the complexity of encoding or parsing of message elements. In fact it reduces complexity. Likewise, it neither encourages or discourages use of vendor defined message elements. I believe what is currently in the CAPWAP-01 document will most likely become a frequently misunderstood and inappropriately implemented portion of the specification. This was demonstrated by your question yesterday! And possibly by sujay's question today (but I'm not sure what sujay meant, and I'm waiting for a response). Regards, /david t. perkins On Tue, 20 Jun 2006, Scott G Kelly wrote: > I don't know about anyone else, but from an implementor's standpoint, > I'm a little concerned about this. I know something similar to this made > it into the 01 draft, but I was petty surprised when I saw it. > > The proposal is to include a vendor ID in *every* message element. > That > is, the message element type field has some bits which indicate vendor > id, and some bits which indicate the actual element type. This means > every message element is a VSP. > > I'm not sure what functionality this is intended to provide that can't > be provided by a generic VSP, and the fact that we will have to check > each and every message element for this condition (and deal with > unexpected ones) seems pretty painful for functionality I could > alternatively attain with a generic VSP. > > Use of VSPs should be relatively rare in a standardized, interoperable > protocol. Building them right into each and every message element seems > like an invitation to non-interoperability, not to mention a potential > explosion in message processing complexity. Am I missing something here? > What is the value in this> > Thanks, > > Scott > > sujay wrote: > > Hi, > > Guess, I did.. > > > > I would still prefer to have the flexibility of *my* > > message element extensions added over any standard > > control message type, > > Simply because some extensions may (and does in my case !) > > fit best with a specific control message type, and not as a separate msg > > type > > altogether. > > > > Having said that, I see it is a good idea to have v.s.p message type > > same as any standard control message type, which is what you > > recommend. > > > > Of course ,keeping the v.s.p message extension still intact(4.4.32), > > as it is now. > > > > Regds, > > Sujay G > > My Location; > > http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.52 > > 5085 > > &t=h&hl=en > > > > > > This e-mail and attachments contain confidential information from > > HUAWEI, which is intended only for the person or entity whose > > address is listed above. Any use of the information contained herein > > in any way (including, but not limited to, total or partial > > disclosure, reproduction, or dissemination) by persons other than > > the intended > > recipient's) is prohibited. If you receive this e-mail in error, please > > notify the sender by phone or email immediately and delete it! > > > > -----Original Message----- > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > Sent: Tuesday, June 20, 2006 7:18 PM > > To: sujay > > Cc: 'Scott G. Kelly'; 'capwap' > > Subject: RE: [Capwap] vsp definition has no length > > > > > > HI, > > > > Why yes. This was specified in the proposal for CAPWAP > > data packet formats that I sent June 8th. Did you miss > > it? > > > > Regards, > > /david t. perkins > > > > On Tue, 20 Jun 2006, sujay wrote: > > > >> Hi David, > >> > >> Are you suggesting to remove the vsp element(as in section 4.4.32) > >> , > >> which could be carried in any control message(as in 4.3.1.1 ), and > >> instead have a generic vsp control message type ??? > >> > >> Please correct me. > >> > >> Regds, > >> Sujay G > >> My Location; > >> http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.5250 > >> 85 > >> &t=h&hl=en > >> > >> > >> This e-mail and attachments contain confidential information from > >> HUAWEI, which is intended only for the person or entity whose address > >> is listed above. Any use of the information contained herein in any > >> way (including, but not limited to, total or partial disclosure, > >> reproduction, or dissemination) by persons other than the intended > >> recipient's) is prohibited. If you receive this e-mail in error, > >> please notify the sender by phone or email immediately and delete it! > >> > >> -----Original Message----- > >> From: David T. Perkins [mailto:dperkins@dsperkins.com] > >> Sent: Tuesday, June 20, 2006 5:04 AM > >> To: Scott G. Kelly > >> Cc: capwap > >> Subject: Re: [Capwap] vsp definition has no length > >> > >> > >> HI, > >> > >> You left off the outside wrapper as is specified in CAPWAP-01. > >> > >> Thus, you currently have, as defined in section 4.4, "CAPWAP > >> Protocol Message Elements", and section 4.4.32, "Vendor Specific > >> Payload" for vendor message elements: > >> > >> 0 1 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Type=43 | Length | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Vendor Identifier | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Element ID | Value... | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> ^-don't need length here Thus, > >> you > >> don't need an additional "length". > >> > >> In the CAPWAP packet formats that I sent out some time ago, I > >> proposed that there be no difference in format between "CAPWAP STD > >> message elements" and "CAPWAP vendor specific message elements". > >> Both would have the following format: > >> > >> 0 1 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Message Element Type | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Length | Value .... > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >> > >> Where the encoding of "message element type" is > >> Message element type value = IANA Enterprise Number * 4096 + > >> enterprise specific message element type > >> number > >> > >> (and for CAPWAP standard, zero is used for the value > >> IANA Enterprise number) > >> > >> This results in 12 bits (0-4095) for element types, and 20 bits > >> (0-1048575) for Enterprise numbers. If you look at OUI assignments, > >> which have been around a lot longer than enterprise numbers, they have > > > >> approximately 52K allocated. Thus, 64k (16 bits), is probably not > >> enough, and 1M (20 bits) looks big enough. > >> > >> Regards, > >> /david t. perkins > >> > >> On Mon, 19 Jun 2006, Scott G. Kelly wrote: > >>> Here's the current vendor-specific payload definition: > >>> > >>> 0 1 2 3 > >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | Vendor Identifier | > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | Element ID | Value... | > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> > >>> > >>> Wouldn't something like this make more sense? > >>> > >>> 0 1 2 3 > >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | Vendor Identifier | > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | Length | Element ID | > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | Value.... > >>> +-+-+-+-+-+-+- > >>> > >>> > >>> --Scott > >>> > >>> _________________________________________________________________ > >>> To unsubscribe or modify your subscription options, please visit: > >>> http://lists.frascone.com/mailman/listinfo/capwap > >>> > >>> Archives: http://lists.frascone.com/pipermail/capwap > >>> > >> _________________________________________________________________ > >> To unsubscribe or modify your subscription options, please visit: > >> http://lists.frascone.com/mailman/listinfo/capwap > >> > >> Archives: http://lists.frascone.com/pipermail/capwap > >> > > > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 20 12:20:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsixf-0006Id-Uf for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 12:20:19 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsixe-0002fe-DO for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 12:20:19 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0E7E5430179 for ; Tue, 20 Jun 2006 09:20:18 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id EB7384300FB for ; Tue, 20 Jun 2006 09:19:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B961C430F19 for ; Tue, 20 Jun 2006 09:19:43 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by hermes.tigertech.net (Postfix) with ESMTP id 2EA29430F13 for ; Tue, 20 Jun 2006 09:19:39 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id c39so1615565pyd for ; Tue, 20 Jun 2006 09:19:39 -0700 (PDT) Received: by 10.35.85.1 with SMTP id n1mr9899735pyl; Tue, 20 Jun 2006 09:02:00 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Tue, 20 Jun 2006 09:02:00 -0700 (PDT) Message-ID: <26140d940606200902o3a1c1427k88b7f2fcfa1305a3@mail.gmail.com> Date: Tue, 20 Jun 2006 12:02:00 -0400 From: "Michael Montemurro" To: "Scott G. Kelly" In-Reply-To: <9840444.1150757856115.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> MIME-Version: 1.0 References: <9840444.1150757856115.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_60_70, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] vsp definition has no length X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1795625709==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b --===============1795625709== Content-Type: multipart/alternative; boundary="----=_Part_8792_999891.1150819320752" ------=_Part_8792_999891.1150819320752 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I've captured this discussion as issue 144. Cheers, Mike On 6/19/06, Scott G. Kelly wrote: > > Here's the current vendor-specific payload definition: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Element ID | Value... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Wouldn't something like this make more sense? > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length | Element ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value.... > +-+-+-+-+-+-+- > > > --Scott > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_8792_999891.1150819320752 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I've captured this discussion as issue 144.
 
Cheers,
 
Mike


 
On 6/19/06, Scott G. Kelly <s.kelly@ix.netcom.com> wrote:
Here's the current vendor-specific payload definition:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Vendor Identifier                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Element ID           |   Value...    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Wouldn't something like this make more sense?

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Vendor Identifier                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Length              |          Element ID           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Value....
+-+-+-+-+-+-+-


--Scott

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_8792_999891.1150819320752-- --===============1795625709== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1795625709==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 20 12:31:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsj8M-0004C0-6h for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 12:31:22 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsj8K-0003fv-NX for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 12:31:22 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5BCD543015A for ; Tue, 20 Jun 2006 09:31:20 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id AB2B7430092 for ; Tue, 20 Jun 2006 09:30:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 91456398050 for ; Tue, 20 Jun 2006 09:30:55 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 943AF398034 for ; Tue, 20 Jun 2006 09:30:51 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5KGUp7p030270; Tue, 20 Jun 2006 09:30:51 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5KGUpIE030267; Tue, 20 Jun 2006 09:30:51 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 20 Jun 2006 09:30:51 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: sujay In-Reply-To: <000001c69484$3bf87390$7107120a@china.huawei.com> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: 'capwap' Subject: Re: [Capwap] vsp definition has no length X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 HI, Thanks for the response. Again, all I'm proposing is that a single syntax be used for encoding standard and vendor defined message elements. See inline below. On Tue, 20 Jun 2006, sujay wrote: > Hi, > By encoding the Vendor ID in every message makes all category ,'VSP'. > It does look good but MAY cause implementation complexity, may not be > required for all messages, may be unnecessary altogether > if the intention of the vsp element is made clear in the draft. > > David; > My usage of the vsp element is thus; > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type=32 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Element ID | Value... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Again, I'm suggesting that the above (and standard message elements) be encoded as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Element Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Value .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > Where the above can be added to any of the Control message types; > (say a Discovery message !) . And assume the information > carried in this message makes best sense and usage when send along with > other message elements in the Discovery message i.e. Discovery Type, WTP > Descriptor etc.. > > So in case if your proposal includes removal of this vsp element, I > wouldn't suggest. The proposal that I sent to the list on June 8th simply changes the syntax of encoding the standard and vendor defined message types. It says NOTHING about where they can be used. > > Kindly correct me. > > Regds, > Sujay G > > > sujay wrote: > > > Hi, > > > Guess, I did.. > > > > > > I would still prefer to have the flexibility of *my* > > > message element extensions added over any standard > > > control message type, > > > Simply because some extensions may (and does in my case !) > > > fit best with a specific control message type, and not as a separate > msg > > > type > > > altogether. > > > > > > Having said that, I see it is a good idea to have v.s.p message type > > > > same as any standard control message type, which is what you > > > recommend. > > > > > > Of course ,keeping the v.s.p message extension still intact(4.4.32), > > > > as it is now. > > > > > > Regds, > > > Sujay G > > > > On Tue, 20 Jun 2006, sujay wrote: > > >> Hi David, > > >> > > >> Are you suggesting to remove the vsp element(as in section 4.4.32) > > >> , > > >> which could be carried in any control message(as in 4.3.1.1 ), and > > >> instead have a generic vsp control message type ??? > > >> > > >> Please correct me. > > >> > > >> Regds, > > >> Sujay G _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 20 13:26:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsjzu-0005XZ-Tn for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 13:26:42 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsjzr-0003hv-LL for capwap-archive@lists.ietf.org; Tue, 20 Jun 2006 13:26:42 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BD4B5430107 for ; Tue, 20 Jun 2006 10:26:38 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B8765430092 for ; Tue, 20 Jun 2006 10:26:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A9A8D39804E for ; Tue, 20 Jun 2006 10:26:09 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by zoidberg.tigertech.net (Postfix) with ESMTP id C7CD4398050 for ; Tue, 20 Jun 2006 10:26:06 -0700 (PDT) Received: from [209.86.224.43] (helo=elwamui-norfolk.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FsjzJ-00027I-L5; Tue, 20 Jun 2006 13:26:05 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Tue, 20 Jun 2006 13:26:05 -0400 Message-ID: <6317453.1150824365598.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Date: Tue, 20 Jun 2006 13:26:05 -0400 (EDT) From: "Scott G. Kelly" To: "David T. Perkins" Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff7100979e2b37a5f263cfa2cab998f6a4f7b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.43 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: 'capwap' Subject: Re: [Capwap] vsp definition has no length X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: be922d419820e291bde1362184dc32fd Hi David I think maybe I didn't phrase my concern clearly - sorry about that. I've attempted to clarify below. >The proposal to have a single way to encode the type >of message type instead of two ways, adds nothing to >the complexity of encoding or parsing of message elements. >In fact it reduces complexity. Likewise, it neither >encourages or discourages use of vendor defined message >elements. > >I believe what is currently in the CAPWAP-01 document will most >likely become a frequently misunderstood and inappropriately >implemented portion of the specification. This was >demonstrated by your question yesterday! And possibly >by sujay's question today (but I'm not sure what >sujay meant, and I'm waiting for a response). > Currently, 01 proposes that we encode message *types* like this: ------------------------------- 4.3.1.1. Message Type The Message Type field identifies the function of the CAPWAP control message. The Message Type field is comprised of an IANA Enterprise Number and a message type value field. The first two byte contain the IANA Enterprise Number (for example, the IEEE 802.11 IANA Enterprise number is 13277), and the second two bytes contain the Message Type value. The message type field can be expressed as: Message Type = IANA Enterprise Number * 256 + Message Type Value The valid values for base CAPWAP Message Types are given in the table below: ----------------------------------- ...where message types are e.g. discovery req/rsp, join req/rsp, etc. The text above says you should encode the enterprise number (aka vendor id) into the message type. One question pertains to whether this is required or not, but that's not the question I meant to raise in my email to you. I don't currently have a strong opinion one way or the other on this, though I think we should be clear about why we think this is important. But let's set this aside for the moment. The suggestion I'm concerned with in my previous email in this thread is in your email of June 8, where you proposed extending this concept to include message *element* types: ----------------------------- Message Elements: The message elements field contains, zero, one, or more message element field, which has the following format: Message Element: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Element Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Value .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Message Element Type: This field identifies a message element of a CAPWAP control message. The Message Element Type field is comprised of an IANA Enterprise Number and an enterprise specific message element type number. The first three octets is the enterprise number in network byte order, with zero being used for CAPWAP generic message types and the IEEE 802.11 IANA assigned enterprise number 13277 being used for IEEE 802.11 technology specific message element types. The last octet is the enterprise specific message element type number, which has a range from 0 to 255. The value of the message element type field can be expressed as: Message element type value = IANA Enterprise Number * 256 + enterprise specific message element type number ----------------------------- I find the idea of dealing with this during message parsing to be a little scary. You mention collapsing 2 types of messages into one, but what this looks like it is doing is creating the potential for combinatorial explosion in the potential message element combinations one might encounter for any given message type. Any message element could have any vendor id, and it's own special value. Again, from a practical perspective, how many VSP's would you expect to see in an interoperable protocol? This seems to anticipate many, but shouldn't we be striving to make this rare? Isn't that why we're here? Scott >Regards, >/david t. perkins > >On Tue, 20 Jun 2006, Scott G Kelly wrote: >> I don't know about anyone else, but from an implementor's standpoint, >> I'm a little concerned about this. I know something similar to this made >> it into the 01 draft, but I was petty surprised when I saw it. >> >> The proposal is to include a vendor ID in *every* message element. That >> is, the message element type field has some bits which indicate vendor >> id, and some bits which indicate the actual element type. This means >> every message element is a VSP. >> >> I'm not sure what functionality this is intended to provide that can't >> be provided by a generic VSP, and the fact that we will have to check >> each and every message element for this condition (and deal with >> unexpected ones) seems pretty painful for functionality I could >> alternatively attain with a generic VSP. >> >> Use of VSPs should be relatively rare in a standardized, interoperable >> protocol. Building them right into each and every message element seems >> like an invitation to non-interoperability, not to mention a potential >> explosion in message processing complexity. Am I missing something here? >> What is the value in this> >> Thanks, >> >> Scott >> >> sujay wrote: >> > Hi, >> > Guess, I did.. >> > >> > I would still prefer to have the flexibility of *my* >> > message element extensions added over any standard >> > control message type, >> > Simply because some extensions may (and does in my case !) >> > fit best with a specific control message type, and not as a separate msg >> > type >> > altogether. >> > >> > Having said that, I see it is a good idea to have v.s.p message type >> > same >> > as any standard control message type, which is what you recommend. >> > >> > Of course ,keeping the v.s.p message extension still intact(4.4.32), as >> > it is now. >> > >> > Regds, >> > Sujay G >> > My Location; >> > http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085 >> > &t=h&hl=en >> > >> > >> > This e-mail and attachments contain confidential information from >> > HUAWEI, which is intended only for the person or entity whose address is >> > listed above. Any use of the information contained herein in any way >> > (including, but not limited to, total or partial disclosure, >> > reproduction, or dissemination) by persons other than the intended >> > recipient's) is prohibited. If you receive this e-mail in error, please >> > notify the sender by phone or email immediately and delete it! >> > >> > -----Original Message----- >> > From: David T. Perkins [mailto:dperkins@dsperkins.com] >> > Sent: Tuesday, June 20, 2006 7:18 PM >> > To: sujay >> > Cc: 'Scott G. Kelly'; 'capwap' >> > Subject: RE: [Capwap] vsp definition has no length >> > >> > >> > HI, >> > >> > Why yes. This was specified in the proposal for CAPWAP >> > data packet formats that I sent June 8th. Did you miss >> > it? >> > >> > Regards, >> > /david t. perkins >> > >> > On Tue, 20 Jun 2006, sujay wrote: >> > >> >> Hi David, >> >> >> >> Are you suggesting to remove the vsp element(as in section 4.4.32) , >> >> which could be carried in any control message(as in 4.3.1.1 ), and >> >> instead have a generic vsp control message type ??? >> >> >> >> Please correct me. >> >> >> >> Regds, >> >> Sujay G >> >> My Location; >> >> http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.5250 >> >> 85 >> >> &t=h&hl=en >> >> >> >> >> >> This e-mail and attachments contain confidential information from >> >> HUAWEI, which is intended only for the person or entity whose address >> >> is listed above. Any use of the information contained herein in any >> >> way (including, but not limited to, total or partial disclosure, >> >> reproduction, or dissemination) by persons other than the intended >> >> recipient's) is prohibited. If you receive this e-mail in error, >> >> please notify the sender by phone or email immediately and delete it! >> >> >> >> -----Original Message----- >> >> From: David T. Perkins [mailto:dperkins@dsperkins.com] >> >> Sent: Tuesday, June 20, 2006 5:04 AM >> >> To: Scott G. Kelly >> >> Cc: capwap >> >> Subject: Re: [Capwap] vsp definition has no length >> >> >> >> >> >> HI, >> >> >> >> You left off the outside wrapper as is specified in CAPWAP-01. >> >> >> >> Thus, you currently have, as defined in section 4.4, >> >> "CAPWAP Protocol Message Elements", and section 4.4.32, "Vendor >> >> Specific Payload" for vendor message elements: >> >> >> >> 0 1 2 3 >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | Type=43 | Length | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | Vendor Identifier | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | Element ID | Value... | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> ^-don't need length here Thus, you >> >> don't need an additional "length". >> >> >> >> In the CAPWAP packet formats that I sent out some time ago, >> >> I proposed that there be no difference in format between >> >> "CAPWAP STD message elements" and "CAPWAP vendor specific message >> >> elements". Both would have the following format: >> >> >> >> 0 1 2 3 >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | Message Element Type | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | Length | Value .... >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> >> >> >> Where the encoding of "message element type" is >> >> Message element type value = IANA Enterprise Number * 4096 + >> >> enterprise specific message element type number >> >> >> >> (and for CAPWAP standard, zero is used for the value >> >> IANA Enterprise number) >> >> >> >> This results in 12 bits (0-4095) for element types, and 20 bits >> >> (0-1048575) for Enterprise numbers. If you look at OUI assignments, >> >> which have been around a lot longer than enterprise numbers, they have >> > >> >> approximately 52K allocated. Thus, 64k (16 bits), is probably not >> >> enough, and 1M (20 bits) looks big enough. >> >> >> >> Regards, >> >> /david t. perkins >> >> >> >> On Mon, 19 Jun 2006, Scott G. Kelly wrote: >> >>> Here's the current vendor-specific payload definition: >> >>> >> >>> 0 1 2 3 >> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>> | Vendor Identifier | >> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>> | Element ID | Value... | >> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>> >> >>> >> >>> Wouldn't something like this make more sense? >> >>> >> >>> 0 1 2 3 >> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>> | Vendor Identifier | >> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>> | Length | Element ID | >> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>> | Value.... >> >>> +-+-+-+-+-+-+- >> >>> >> >>> >> >>> --Scott >> >>> >> >>> _________________________________________________________________ >> >>> To unsubscribe or modify your subscription options, please visit: >> >>> http://lists.frascone.com/mailman/listinfo/capwap >> >>> >> >>> Archives: http://lists.frascone.com/pipermail/capwap >> >>> >> >> _________________________________________________________________ >> >> To unsubscribe or modify your subscription options, please visit: >> >> http://lists.frascone.com/mailman/listinfo/capwap >> >> >> >> Archives: http://lists.frascone.com/pipermail/capwap >> >> >> > >> > >> > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 21 01:54:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsvfT-00079X-8X for capwap-archive@lists.ietf.org; Wed, 21 Jun 2006 01:54:23 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsveR-0006Ng-UC for capwap-archive@lists.ietf.org; Wed, 21 Jun 2006 01:53:22 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BB355430092 for ; Tue, 20 Jun 2006 22:53:16 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 5924443004F for ; Tue, 20 Jun 2006 22:52:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 45284398013 for ; Tue, 20 Jun 2006 22:52:57 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9AB4239800D for ; Tue, 20 Jun 2006 22:52:54 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5L5qrl1014033 for ; Tue, 20 Jun 2006 22:52:53 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5L5qrgq014028 for ; Tue, 20 Jun 2006 22:52:53 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 20 Jun 2006 22:52:53 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [Capwap] Is local/splitMAC at WLAN or WTP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 HI, Are WTPs suppose to support concurrenty a splitMAC on one WLAN and localMAC on another WLAN? It kind of looks that way. See 11.7.1 - WLAN config request, and 11.10.1 - Add WLAN. Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 21 09:16:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2Z9-0007Rp-3h for capwap-archive@lists.ietf.org; Wed, 21 Jun 2006 09:16:19 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft2Z6-0002GP-GR for capwap-archive@lists.ietf.org; Wed, 21 Jun 2006 09:16:19 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 54A7C4300F1 for ; Wed, 21 Jun 2006 06:16:15 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1593E430071 for ; Wed, 21 Jun 2006 06:15:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D78B439800F for ; Wed, 21 Jun 2006 06:15:32 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8B8DB398056 for ; Wed, 21 Jun 2006 06:15:27 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-3.cisco.com with ESMTP; 21 Jun 2006 06:15:26 -0700 X-IronPort-AV: i="4.06,161,1149490800"; d="scan'208"; a="431090844:sNHT31508588" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5LDFQnc002090; Wed, 21 Jun 2006 06:15:26 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5LDFGJC023938; Wed, 21 Jun 2006 06:15:25 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Jun 2006 06:15:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jun 2006 06:15:24 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202108C3E@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] issue 104 Thread-Index: AcaUSFQ5lVnpzFMuSCaWqxKBPCzibgAnvGwg From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 21 Jun 2006 13:15:24.0664 (UTC) FILETIME=[C1AA4F80:01C69534] Authentication-Results: sj-dkim-5.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] issue 104 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab This is not current in scope of the working group, as it is not included in the problem statement. While interesting, we need to meet our milestones, so I would propose that we reject adding more functionality to the protocol at this time. If we want to add functionality, I would claim that support for 802.11n is MUCH more urgent, as standards based products will enter the market next year. I contend that if CAPWAP can't keep up with 802.11 innovation, and specifically those that are high profile, then it will see minimal market penetration. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: a.levanti@tiscali.it [mailto:a.levanti@tiscali.it] > Sent: Tuesday, June 20, 2006 2:02 AM > To: capwap@frascone.com > Subject: [Capwap] issue 104 > > Hi all, > In relation to issue the 104 we think to use a new message > when the WTP enters in RUN state. In this message it must > send to AC informations related to all access points it > hears, in which frequency they trasmitted, and the power to > noise ratio. AC maintains a database where for all WTPs under > its control have an entry in which there are informations > sent from WTP. Therefore, AC has a one wider network's vision > so that it could choose the better channel. > Perhaps I lost some point of the debate, so is it possible? > > Thanks. > > Annarita > > > > > > Naviga senza limiti con 4 Megabps di velocita' a soli 19,95 > Euro al mese, ATTIVA SUBITO e hai 2 MESI GRATIS! > > In piu', se sei raggiunto dalla rete Tiscali, telefoni senza > pagare il canone Telecom. Comincia subito a risparmiare! > > http://abbonati.tiscali.it/prodotti/adsl/tc/4flat/ > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 21 09:17:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2ah-0000qQ-Ka for capwap-archive@lists.ietf.org; Wed, 21 Jun 2006 09:17:55 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft2ag-0002J0-ON for capwap-archive@lists.ietf.org; Wed, 21 Jun 2006 09:17:55 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5C2134301C5 for ; Wed, 21 Jun 2006 06:17:54 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 04108430071 for ; Wed, 21 Jun 2006 06:15:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D5F5F398053 for ; Wed, 21 Jun 2006 06:15:35 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id A68F9398058 for ; Wed, 21 Jun 2006 06:15:27 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 21 Jun 2006 06:15:26 -0700 X-IronPort-AV: i="4.06,161,1149490800"; d="scan'208"; a="298457006:sNHT792533026" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5LDFQx1011250; Wed, 21 Jun 2006 06:15:26 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5LDFOIs024052; Wed, 21 Jun 2006 06:15:25 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Jun 2006 06:15:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jun 2006 06:15:23 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202108C3D@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] vsp definition has no length Thread-Index: AcaUjrWvrFQShTKiTJWk3rf0MIGd7AAWDJbw From: "Pat Calhoun (pacalhou)" To: "Scott G. Kelly" , "David T. Perkins" X-OriginalArrivalTime: 21 Jun 2006 13:15:24.0445 (UTC) FILETIME=[C188E4D0:01C69534] Authentication-Results: sj-dkim-8.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] vsp definition has no length X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2f46977da373544777a750d5247d6ccc I don't think that David's proposal actually changes, in any way, the number of VSPs we will have to deal with. All he is trying to propose, I believe, is a consistent message element format, regardless of whether it is a vsp or not. David, is this correct? While I'm not thrilled by this proposal as it does increase the length of the messages, and possibly the parsing processing, albeit not by much, I do have to admit that there is some elegance in consistency... Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > Sent: Tuesday, June 20, 2006 10:26 AM > To: David T. Perkins > Cc: 'capwap' > Subject: Re: [Capwap] vsp definition has no length > > Hi David > > I think maybe I didn't phrase my concern clearly - sorry > about that. I've attempted to clarify below. > > >The proposal to have a single way to encode the type of message type > >instead of two ways, adds nothing to the complexity of encoding or > >parsing of message elements. > >In fact it reduces complexity. Likewise, it neither encourages or > >discourages use of vendor defined message elements. > > > >I believe what is currently in the CAPWAP-01 document will > most likely > >become a frequently misunderstood and inappropriately implemented > >portion of the specification. This was demonstrated by your question > >yesterday! And possibly by sujay's question today (but I'm not sure > >what sujay meant, and I'm waiting for a response). > > > > Currently, 01 proposes that we encode message *types* like this: > > ------------------------------- > 4.3.1.1. Message Type > > The Message Type field identifies the function of the > CAPWAP control > message. The Message Type field is comprised of an IANA Enterprise > Number and a message type value field. The first two byte contain > the IANA Enterprise Number (for example, the IEEE 802.11 IANA > Enterprise number is 13277), and the second two bytes contain the > Message Type value. The message type field can be expressed as: > > Message Type = IANA Enterprise Number * 256 + Message Type Value > > The valid values for base CAPWAP Message Types are given > in the table > below: > ----------------------------------- > > ...where message types are e.g. discovery req/rsp, join > req/rsp, etc. The text above says you should encode the > enterprise number (aka vendor id) into the message type. One > question pertains to whether this is required or not, but > that's not the question I meant to raise in my email to you. > I don't currently have a strong opinion one way or the other > on this, though I think we should be clear about why we think > this is important. But let's set this aside for the moment. > > The suggestion I'm concerned with in my previous email in > this thread is in your email of June 8, where you proposed > extending this concept to include message *element* types: > > ----------------------------- > Message Elements: > The message elements field contains, zero, one, or more message > element field, which has the following format: > > Message Element: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message Element Type > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length | Value .... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > Message Element Type: This field identifies a message element > of a CAPWAP control message. The Message Element > Type field > is comprised of an IANA Enterprise Number and an > enterprise > specific message element type number. The first > three octets > is the enterprise number in network byte order, with zero > being used for CAPWAP generic message types and the > IEEE 802.11 IANA assigned enterprise number 13277 being > used for IEEE 802.11 technology specific message element > types. The last octet is the enterprise specific > message element type number, which has a range > from 0 to 255. > > The value of the message element type field can > be expressed as: > > Message element type value = IANA Enterprise > Number * 256 + > enterprise specific message element type number > ----------------------------- > > I find the idea of dealing with this during message parsing > to be a little scary. You mention collapsing 2 types of > messages into one, but what this looks like it is doing is > creating the potential for combinatorial explosion in the > potential message element combinations one might encounter > for any given message type. Any message element could have > any vendor id, and it's own special value. > > Again, from a practical perspective, how many VSP's would you > expect to see in an interoperable protocol? This seems to > anticipate many, but shouldn't we be striving to make this > rare? Isn't that why we're here? > > Scott > > > >Regards, > >/david t. perkins > > > >On Tue, 20 Jun 2006, Scott G Kelly wrote: > >> I don't know about anyone else, but from an implementor's > standpoint, > >> I'm a little concerned about this. I know something > similar to this > >> made it into the 01 draft, but I was petty surprised when I saw it. > >> > >> The proposal is to include a vendor ID in *every* message element. > >> That is, the message element type field has some bits > which indicate > >> vendor id, and some bits which indicate the actual element > type. This > >> means every message element is a VSP. > >> > >> I'm not sure what functionality this is intended to provide that > >> can't be provided by a generic VSP, and the fact that we > will have to > >> check each and every message element for this condition (and deal > >> with unexpected ones) seems pretty painful for > functionality I could > >> alternatively attain with a generic VSP. > >> > >> Use of VSPs should be relatively rare in a standardized, > >> interoperable protocol. Building them right into each and every > >> message element seems like an invitation to > non-interoperability, not > >> to mention a potential explosion in message processing > complexity. Am I missing something here? > >> What is the value in this> > >> Thanks, > >> > >> Scott > >> > >> sujay wrote: > >> > Hi, > >> > Guess, I did.. > >> > > >> > I would still prefer to have the flexibility of *my* message > >> > element extensions added over any standard control message type, > >> > Simply because some extensions may (and does in my case !) fit > >> > best with a specific control message type, and not as a separate > >> > msg type altogether. > >> > > >> > Having said that, I see it is a good idea to have v.s.p message > >> > type same as any standard control message type, which is > what you > >> > recommend. > >> > > >> > Of course ,keeping the v.s.p message extension still > >> > intact(4.4.32), as it is now. > >> > > >> > Regds, > >> > Sujay G > >> > My Location; > >> > > http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.5 > >> > 25085 > >> > &t=h&hl=en > >> > > >> > > >> > This e-mail and attachments contain confidential > information from > >> > HUAWEI, which is intended only for the person or entity whose > >> > address is listed above. Any use of the information contained > >> > herein in any way (including, but not limited to, total > or partial > >> > disclosure, reproduction, or dissemination) by persons > other than > >> > the intended > >> > recipient's) is prohibited. If you receive this e-mail in error, > >> > please notify the sender by phone or email immediately > and delete it! > >> > > >> > -----Original Message----- > >> > From: David T. Perkins [mailto:dperkins@dsperkins.com] > >> > Sent: Tuesday, June 20, 2006 7:18 PM > >> > To: sujay > >> > Cc: 'Scott G. Kelly'; 'capwap' > >> > Subject: RE: [Capwap] vsp definition has no length > >> > > >> > > >> > HI, > >> > > >> > Why yes. This was specified in the proposal for CAPWAP > data packet > >> > formats that I sent June 8th. Did you miss it? > >> > > >> > Regards, > >> > /david t. perkins > >> > > >> > On Tue, 20 Jun 2006, sujay wrote: > >> > > >> >> Hi David, > >> >> > >> >> Are you suggesting to remove the vsp element(as in > section 4.4.32) > >> >> , which could be carried in any control message(as in > 4.3.1.1 ), > >> >> and instead have a generic vsp control message type ??? > >> >> > >> >> Please correct me. > >> >> > >> >> Regds, > >> >> Sujay G > >> >> My Location; > >> >> > http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7. > >> >> 5250 > >> >> 85 > >> >> &t=h&hl=en > >> >> > >> >> > >> >> This e-mail and attachments contain confidential > information from > >> >> HUAWEI, which is intended only for the person or entity whose > >> >> address is listed above. Any use of the information contained > >> >> herein in any way (including, but not limited to, total > or partial > >> >> disclosure, reproduction, or dissemination) by persons > other than > >> >> the intended > >> >> recipient's) is prohibited. If you receive this e-mail > in error, > >> >> please notify the sender by phone or email immediately > and delete it! > >> >> > >> >> -----Original Message----- > >> >> From: David T. Perkins [mailto:dperkins@dsperkins.com] > >> >> Sent: Tuesday, June 20, 2006 5:04 AM > >> >> To: Scott G. Kelly > >> >> Cc: capwap > >> >> Subject: Re: [Capwap] vsp definition has no length > >> >> > >> >> > >> >> HI, > >> >> > >> >> You left off the outside wrapper as is specified in CAPWAP-01. > >> >> > >> >> Thus, you currently have, as defined in section 4.4, "CAPWAP > >> >> Protocol Message Elements", and section 4.4.32, "Vendor > Specific > >> >> Payload" for vendor message elements: > >> >> > >> >> 0 1 2 > 3 > >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > >> >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> | Type=43 | Length > | > >> >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> | Vendor Identifier > | > >> >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> | Element ID | Value... | > > >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >> >> ^-don't need length > here Thus, > >> >> you don't need an additional "length". > >> >> > >> >> In the CAPWAP packet formats that I sent out some time ago, I > >> >> proposed that there be no difference in format between > "CAPWAP STD > >> >> message elements" and "CAPWAP vendor specific message > elements". > >> >> Both would have the following format: > >> >> > >> >> 0 1 2 > 3 > >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > >> >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> | Message Element Type > | > >> >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >> | Length | Value .... > > >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > >> >> > >> >> Where the encoding of "message element type" is > >> >> Message element type value = IANA Enterprise Number * 4096 + > >> >> enterprise specific message element type > >> >> number > >> >> > >> >> (and for CAPWAP standard, zero is used for the value > >> >> IANA Enterprise number) > >> >> > >> >> This results in 12 bits (0-4095) for element types, and 20 bits > >> >> (0-1048575) for Enterprise numbers. If you look at OUI > >> >> assignments, which have been around a lot longer than > enterprise > >> >> numbers, they have > >> > > >> >> approximately 52K allocated. Thus, 64k (16 bits), is > probably not > >> >> enough, and 1M (20 bits) looks big enough. > >> >> > >> >> Regards, > >> >> /david t. perkins > >> >> > >> >> On Mon, 19 Jun 2006, Scott G. Kelly wrote: > >> >>> Here's the current vendor-specific payload definition: > >> >>> > >> >>> 0 1 2 > 3 > >> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > >> >>> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >>> | Vendor Identifier > | > >> >>> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >>> | Element ID | Value... | > >> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >>> > >> >>> > >> >>> Wouldn't something like this make more sense? > >> >>> > >> >>> 0 1 2 > 3 > >> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > >> >>> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >>> | Vendor Identifier > | > >> >>> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >>> | Length | Element > ID | > >> >>> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >>> | Value.... > >> >>> +-+-+-+-+-+-+- > >> >>> > >> >>> > >> >>> --Scott > >> >>> > >> >>> > _________________________________________________________________ > >> >>> To unsubscribe or modify your subscription options, > please visit: > >> >>> http://lists.frascone.com/mailman/listinfo/capwap > >> >>> > >> >>> Archives: http://lists.frascone.com/pipermail/capwap > >> >>> > >> >> > _________________________________________________________________ > >> >> To unsubscribe or modify your subscription options, > please visit: > >> >> http://lists.frascone.com/mailman/listinfo/capwap > >> >> > >> >> Archives: http://lists.frascone.com/pipermail/capwap > >> >> > >> > > >> > > >> > > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 21 09:29:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2lX-0000Fk-7Q for capwap-archive@lists.ietf.org; Wed, 21 Jun 2006 09:29:07 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft2lV-0002vF-PZ for capwap-archive@lists.ietf.org; Wed, 21 Jun 2006 09:29:07 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C8D974301A5 for ; Wed, 21 Jun 2006 06:29:04 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 360EE4300E3 for ; Wed, 21 Jun 2006 06:28:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C60F3398055 for ; Wed, 21 Jun 2006 06:28:42 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6FF8B398050 for ; Wed, 21 Jun 2006 06:28:36 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 21 Jun 2006 06:28:36 -0700 X-IronPort-AV: i="4.06,162,1149490800"; d="scan'208"; a="1829837024:sNHT38674520" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5LDSZvk024073; Wed, 21 Jun 2006 06:28:35 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5LDSRCm000325; Wed, 21 Jun 2006 06:28:35 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Jun 2006 06:28:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jun 2006 06:28:28 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202108C48@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Is local/splitMAC at WLAN or WTP Thread-Index: AcaU9wCAx2N5yxZDQ+K4oddNP/I6qQAP4qEw From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" , X-OriginalArrivalTime: 21 Jun 2006 13:28:31.0666 (UTC) FILETIME=[96C14920:01C69536] Authentication-Results: sj-dkim-4.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Is local/splitMAC at WLAN or WTP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Yes, it was intended to allow this mode of operation. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Tuesday, June 20, 2006 10:53 PM > To: capwap@frascone.com > Subject: [Capwap] Is local/splitMAC at WLAN or WTP > > HI, > > Are WTPs suppose to support concurrenty a splitMAC on one > WLAN and localMAC on another WLAN? > > It kind of looks that way. See 11.7.1 - WLAN config request, > and 11.10.1 - Add WLAN. > > Regards, > /david t. perkins > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 21 11:41:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4pT-0004pT-Hk for capwap-archive@lists.ietf.org; Wed, 21 Jun 2006 11:41:19 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4pR-0000Pu-Lu for capwap-archive@lists.ietf.org; Wed, 21 Jun 2006 11:41:19 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E91F6430128 for ; Wed, 21 Jun 2006 08:41:16 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id EF05B430092 for ; Wed, 21 Jun 2006 08:40:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E273439801C for ; Wed, 21 Jun 2006 08:40:44 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.192.81]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7D38739802A for ; Wed, 21 Jun 2006 08:40:41 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (rwcrmhc11) with ESMTP id <20060621154040m1100avkbce>; Wed, 21 Jun 2006 15:40:40 +0000 Message-ID: <44996878.8070204@hyperthought.com> Date: Wed, 21 Jun 2006 08:40:40 -0700 From: Scott G Kelly User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <4FF84B0BC277FF45AA27FE969DD956A202108C3D@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A202108C3D@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap Subject: Re: [Capwap] vsp definition has no length X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4ec3642ae9025e273a4a263d640f3300 Just giving this some more thought, and I think you guys are right: this adds consistency, and the only real drawback is increased message size. Since a VSP could theoretically appear wherever any other message element could, I guess the added parsing complexity is not as onerous as I first thought. If we adopt this approach, it obviates the need for an explicitly define VSP message element, doesn't it? Pat Calhoun (pacalhou) wrote: > I don't think that David's proposal actually changes, in any way, the > number of VSPs we will have to deal with. All he is trying to propose, I > believe, is a consistent message element format, regardless of whether > it is a vsp or not. David, is this correct? > > While I'm not thrilled by this proposal as it does increase the length > of the messages, and possibly the parsing processing, albeit not by > much, I do have to admit that there is some elegance in consistency... > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > >> -----Original Message----- >> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >> Sent: Tuesday, June 20, 2006 10:26 AM >> To: David T. Perkins >> Cc: 'capwap' >> Subject: Re: [Capwap] vsp definition has no length >> >> Hi David >> >> I think maybe I didn't phrase my concern clearly - sorry >> about that. I've attempted to clarify below. >> >>> The proposal to have a single way to encode the type of message type >>> instead of two ways, adds nothing to the complexity of encoding or >>> parsing of message elements. >>> In fact it reduces complexity. Likewise, it neither encourages or >>> discourages use of vendor defined message elements. >>> >>> I believe what is currently in the CAPWAP-01 document will >> most likely >>> become a frequently misunderstood and inappropriately implemented >>> portion of the specification. This was demonstrated by your question >>> yesterday! And possibly by sujay's question today (but I'm not sure >>> what sujay meant, and I'm waiting for a response). >>> >> Currently, 01 proposes that we encode message *types* like this: >> >> ------------------------------- >> 4.3.1.1. Message Type >> >> The Message Type field identifies the function of the >> CAPWAP control >> message. The Message Type field is comprised of an IANA Enterprise >> Number and a message type value field. The first two byte contain >> the IANA Enterprise Number (for example, the IEEE 802.11 IANA >> Enterprise number is 13277), and the second two bytes contain the >> Message Type value. The message type field can be expressed as: >> >> Message Type = IANA Enterprise Number * 256 + Message Type Value >> >> The valid values for base CAPWAP Message Types are given >> in the table >> below: >> ----------------------------------- >> >> ...where message types are e.g. discovery req/rsp, join >> req/rsp, etc. The text above says you should encode the >> enterprise number (aka vendor id) into the message type. One >> question pertains to whether this is required or not, but >> that's not the question I meant to raise in my email to you. >> I don't currently have a strong opinion one way or the other >> on this, though I think we should be clear about why we think >> this is important. But let's set this aside for the moment. >> >> The suggestion I'm concerned with in my previous email in >> this thread is in your email of June 8, where you proposed >> extending this concept to include message *element* types: >> >> ----------------------------- >> Message Elements: >> The message elements field contains, zero, one, or more message >> element field, which has the following format: >> >> Message Element: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Message Element Type >> | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Length | Value .... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> >> Message Element Type: This field identifies a message element >> of a CAPWAP control message. The Message Element >> Type field >> is comprised of an IANA Enterprise Number and an >> enterprise >> specific message element type number. The first >> three octets >> is the enterprise number in network byte order, with zero >> being used for CAPWAP generic message types and the >> IEEE 802.11 IANA assigned enterprise number 13277 being >> used for IEEE 802.11 technology specific message element >> types. The last octet is the enterprise specific >> message element type number, which has a range >> from 0 to 255. >> >> The value of the message element type field can >> be expressed as: >> >> Message element type value = IANA Enterprise >> Number * 256 + >> enterprise specific message element type number >> ----------------------------- >> >> I find the idea of dealing with this during message parsing >> to be a little scary. You mention collapsing 2 types of >> messages into one, but what this looks like it is doing is >> creating the potential for combinatorial explosion in the >> potential message element combinations one might encounter >> for any given message type. Any message element could have >> any vendor id, and it's own special value. >> >> Again, from a practical perspective, how many VSP's would you >> expect to see in an interoperable protocol? This seems to >> anticipate many, but shouldn't we be striving to make this >> rare? Isn't that why we're here? >> >> Scott >> >> >>> Regards, >>> /david t. perkins >>> >>> On Tue, 20 Jun 2006, Scott G Kelly wrote: >>>> I don't know about anyone else, but from an implementor's >> standpoint, >>>> I'm a little concerned about this. I know something >> similar to this >>>> made it into the 01 draft, but I was petty surprised when I saw it. >>>> >>>> The proposal is to include a vendor ID in *every* message element. >>>> That is, the message element type field has some bits >> which indicate >>>> vendor id, and some bits which indicate the actual element >> type. This >>>> means every message element is a VSP. >>>> >>>> I'm not sure what functionality this is intended to provide that >>>> can't be provided by a generic VSP, and the fact that we >> will have to >>>> check each and every message element for this condition (and deal >>>> with unexpected ones) seems pretty painful for >> functionality I could >>>> alternatively attain with a generic VSP. >>>> >>>> Use of VSPs should be relatively rare in a standardized, >>>> interoperable protocol. Building them right into each and every >>>> message element seems like an invitation to >> non-interoperability, not >>>> to mention a potential explosion in message processing >> complexity. Am I missing something here? >>>> What is the value in this> >>>> Thanks, >>>> >>>> Scott >>>> >>>> sujay wrote: >>>>> Hi, >>>>> Guess, I did.. >>>>> >>>>> I would still prefer to have the flexibility of *my* message >>>>> element extensions added over any standard control message type, >>>>> Simply because some extensions may (and does in my case !) fit >>>>> best with a specific control message type, and not as a separate >>>>> msg type altogether. >>>>> >>>>> Having said that, I see it is a good idea to have v.s.p message >>>>> type same as any standard control message type, which is >> what you >>>>> recommend. >>>>> >>>>> Of course ,keeping the v.s.p message extension still >>>>> intact(4.4.32), as it is now. >>>>> >>>>> Regds, >>>>> Sujay G >>>>> My Location; >>>>> >> http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.5 >>>>> 25085 >>>>> &t=h&hl=en >>>>> >>>>> >>>>> This e-mail and attachments contain confidential >> information from >>>>> HUAWEI, which is intended only for the person or entity whose >>>>> address is listed above. Any use of the information contained >>>>> herein in any way (including, but not limited to, total >> or partial >>>>> disclosure, reproduction, or dissemination) by persons >> other than >>>>> the intended >>>>> recipient's) is prohibited. If you receive this e-mail in error, >>>>> please notify the sender by phone or email immediately >> and delete it! >>>>> -----Original Message----- >>>>> From: David T. Perkins [mailto:dperkins@dsperkins.com] >>>>> Sent: Tuesday, June 20, 2006 7:18 PM >>>>> To: sujay >>>>> Cc: 'Scott G. Kelly'; 'capwap' >>>>> Subject: RE: [Capwap] vsp definition has no length >>>>> >>>>> >>>>> HI, >>>>> >>>>> Why yes. This was specified in the proposal for CAPWAP >> data packet >>>>> formats that I sent June 8th. Did you miss it? >>>>> >>>>> Regards, >>>>> /david t. perkins >>>>> >>>>> On Tue, 20 Jun 2006, sujay wrote: >>>>> >>>>>> Hi David, >>>>>> >>>>>> Are you suggesting to remove the vsp element(as in >> section 4.4.32) >>>>>> , which could be carried in any control message(as in >> 4.3.1.1 ), >>>>>> and instead have a generic vsp control message type ??? >>>>>> >>>>>> Please correct me. >>>>>> >>>>>> Regds, >>>>>> Sujay G >>>>>> My Location; >>>>>> >> http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7. >>>>>> 5250 >>>>>> 85 >>>>>> &t=h&hl=en >>>>>> >>>>>> >>>>>> This e-mail and attachments contain confidential >> information from >>>>>> HUAWEI, which is intended only for the person or entity whose >>>>>> address is listed above. Any use of the information contained >>>>>> herein in any way (including, but not limited to, total >> or partial >>>>>> disclosure, reproduction, or dissemination) by persons >> other than >>>>>> the intended >>>>>> recipient's) is prohibited. If you receive this e-mail >> in error, >>>>>> please notify the sender by phone or email immediately >> and delete it! >>>>>> -----Original Message----- >>>>>> From: David T. Perkins [mailto:dperkins@dsperkins.com] >>>>>> Sent: Tuesday, June 20, 2006 5:04 AM >>>>>> To: Scott G. Kelly >>>>>> Cc: capwap >>>>>> Subject: Re: [Capwap] vsp definition has no length >>>>>> >>>>>> >>>>>> HI, >>>>>> >>>>>> You left off the outside wrapper as is specified in CAPWAP-01. >>>>>> >>>>>> Thus, you currently have, as defined in section 4.4, "CAPWAP >>>>>> Protocol Message Elements", and section 4.4.32, "Vendor >> Specific >>>>>> Payload" for vendor message elements: >>>>>> >>>>>> 0 1 2 >> 3 >>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >> 6 7 8 9 0 1 >>>>>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | Type=43 | Length >> | >>>>>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | Vendor Identifier >> | >>>>>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | Element ID | Value... | >> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>>>>> ^-don't need length >> here Thus, >>>>>> you don't need an additional "length". >>>>>> >>>>>> In the CAPWAP packet formats that I sent out some time ago, I >>>>>> proposed that there be no difference in format between >> "CAPWAP STD >>>>>> message elements" and "CAPWAP vendor specific message >> elements". >>>>>> Both would have the following format: >>>>>> >>>>>> 0 1 2 >> 3 >>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >> 6 7 8 9 0 1 >>>>>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | Message Element Type >> | >>>>>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | Length | Value .... >> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> >>>>>> Where the encoding of "message element type" is >>>>>> Message element type value = IANA Enterprise Number * 4096 + >>>>>> enterprise specific message element type >>>>>> number >>>>>> >>>>>> (and for CAPWAP standard, zero is used for the value >>>>>> IANA Enterprise number) >>>>>> >>>>>> This results in 12 bits (0-4095) for element types, and 20 bits >>>>>> (0-1048575) for Enterprise numbers. If you look at OUI >>>>>> assignments, which have been around a lot longer than >> enterprise >>>>>> numbers, they have >>>>>> approximately 52K allocated. Thus, 64k (16 bits), is >> probably not >>>>>> enough, and 1M (20 bits) looks big enough. >>>>>> >>>>>> Regards, >>>>>> /david t. perkins >>>>>> >>>>>> On Mon, 19 Jun 2006, Scott G. Kelly wrote: >>>>>>> Here's the current vendor-specific payload definition: >>>>>>> >>>>>>> 0 1 2 >> 3 >>>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >> 6 7 8 9 0 1 >>>>>>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> | Vendor Identifier >> | >>>>>>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> | Element ID | Value... | >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> >>>>>>> >>>>>>> Wouldn't something like this make more sense? >>>>>>> >>>>>>> 0 1 2 >> 3 >>>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >> 6 7 8 9 0 1 >>>>>>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> | Vendor Identifier >> | >>>>>>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> | Length | Element >> ID | >>>>>>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>> | Value.... >>>>>>> +-+-+-+-+-+-+- >>>>>>> >>>>>>> >>>>>>> --Scott >>>>>>> >>>>>>> >> _________________________________________________________________ >>>>>>> To unsubscribe or modify your subscription options, >> please visit: >>>>>>> http://lists.frascone.com/mailman/listinfo/capwap >>>>>>> >>>>>>> Archives: http://lists.frascone.com/pipermail/capwap >>>>>>> >> _________________________________________________________________ >>>>>> To unsubscribe or modify your subscription options, >> please visit: >>>>>> http://lists.frascone.com/mailman/listinfo/capwap >>>>>> >>>>>> Archives: http://lists.frascone.com/pipermail/capwap >>>>>> >>>>> >>> >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap >> > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 21 13:26:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6T5-0000IJ-Ve for capwap-archive@lists.ietf.org; Wed, 21 Jun 2006 13:26:19 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft6T4-0004Ag-Hu for capwap-archive@lists.ietf.org; Wed, 21 Jun 2006 13:26:19 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8C792430108 for ; Wed, 21 Jun 2006 10:26:17 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D9547430093 for ; Wed, 21 Jun 2006 10:25:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C7CEC39804D for ; Wed, 21 Jun 2006 10:25:53 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id B0CBC39800B for ; Wed, 21 Jun 2006 10:25:51 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 21 Jun 2006 10:25:51 -0700 X-IronPort-AV: i="4.06,162,1149490800"; d="scan'208"; a="298633656:sNHT34257392" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5LHPpCW029884; Wed, 21 Jun 2006 10:25:51 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5LHPoke028797; Wed, 21 Jun 2006 10:25:50 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Jun 2006 10:25:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jun 2006 10:25:48 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202108D81@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] vsp definition has no length Thread-Index: AcaVSRoLcGUck6J2Q4aTC9BPABrS4wADpkcw From: "Pat Calhoun (pacalhou)" To: "Scott G Kelly" X-OriginalArrivalTime: 21 Jun 2006 17:25:50.0796 (UTC) FILETIME=[BDF018C0:01C69557] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] vsp definition has no length X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad > If we adopt this approach, it obviates the need for an > explicitly define VSP message element, doesn't it? Yes it would. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 21 15:14:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft8AA-00046r-70 for capwap-archive@lists.ietf.org; Wed, 21 Jun 2006 15:14:54 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft8A7-0007VJ-0W for capwap-archive@lists.ietf.org; Wed, 21 Jun 2006 15:14:54 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 576A44300FB for ; Wed, 21 Jun 2006 12:14:50 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id F26194300D9 for ; Wed, 21 Jun 2006 12:14:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CAE461448003 for ; Wed, 21 Jun 2006 12:14:11 -0700 (PDT) X-Greylist-Status: Sender first seen 1 day 03:12:03 ago Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by hermes.tigertech.net (Postfix) with ESMTP id D083A1448033 for ; Wed, 21 Jun 2006 12:14:06 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x66so62095pye for ; Wed, 21 Jun 2006 12:14:05 -0700 (PDT) Received: by 10.35.18.18 with SMTP id v18mr175552pyi; Wed, 21 Jun 2006 12:14:05 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Wed, 21 Jun 2006 12:14:05 -0700 (PDT) Message-ID: <26140d940606211214p4137447p718c0fea59e19190@mail.gmail.com> Date: Wed, 21 Jun 2006 15:14:05 -0400 From: "Michael Montemurro" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20210877F@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A20210877F@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=3.5 tagged_above=-999.0 required=7.0 tests=HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, RCVD_IN_BL_SPAMCOP_NET, SPF_HELO_PASS, SPF_PASS X-Spam-Level: *** Cc: capwap@frascone.com Subject: Re: [Capwap] VLAN name in (section 4.4.8)Add Mobile Station X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1431683147==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 2.4 (++) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 --===============1431683147== Content-Type: multipart/alternative; boundary="----=_Part_6642_30075380.1150917245768" ------=_Part_6642_30075380.1150917245768 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline We could add a VLAN tag field to the Add WLAN message element. Cheers, Mike On 6/20/06, Pat Calhoun (pacalhou) wrote: > > Ok - so your point is that the protocol doesn't allow one to configure > the actual VLANs on a local MAC WTP. > > Fair enough. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > Sent: Monday, June 19, 2006 7:20 PM > > To: Pat Calhoun (pacalhou) > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] VLAN name in (section 4.4.8)Add Mobile Station > > > > HI, > > > > How do you know the VLAN Names so you can specify an > > appropriate one in an Add Mobile station message. > > > > How do you configure VLANs on the WTP? > > > > On a splitMAC WTP, this is not an issue, since you configure > > the egress VLAN on the AC, and you configure the ports and > > tags in each VLAN on the AC. Of course, how you set up VLANs > > on the AC is a local matter, not part of the CAPWAP spec. > > However, it seems to me that you have to be able to configure > > the VLANs on a localMAC WTP via CAPWAP, since that is the > > only standard protocol between an AC and WTP, and you really > > need to configure the egress VLANs on a localMAC WTP. > > > > If you don't use CAPWAP to determine the VLAN names on a > > localMAC WTP, or CAPWAP to configure VLANs on a localMAC WTP, > > then what would you use? > > > > > > On Mon, 19 Jun 2006, Pat Calhoun (pacalhou) wrote: > > > Given we are sending a VLAN "name", the actual VLAN > > identifier (tag) > > > may differ across WTPs. I don't understand the issue. > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > -----Original Message----- > > > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > > > Sent: Wednesday, June 14, 2006 5:04 PM > > > > To: capwap@frascone.com > > > > Subject: [Capwap] VLAN name in (section 4.4.8)Add Mobile Station > > > > > > > > HI, > > > > > > > > The message element (4.4.8)Add Modile Station has subfield "VLAN > > > > name". However, there are no CAPWAP messages or message > > elements for > > > > VLAN names on a WTP to be managed by the the AC. > > > > (A value for a VLAN Name is only approapriate for a localMAC > > > > WTP.) Managed means to find out the list of the VLAN > > names, create > > > > VLANs and apply attributes, modify VLAN attributes, and delete > > > > VLANs. The attributes include the VLAN name, and > > ports:tag pairs in > > > > the VLAN. (By the way, this is sort of an expansion of > > CAPWAP, but > > > > it is the price to pay to support localMAC.) > > > > > > > > For example, consider a localMAC WTP with 4 802.3 ports. > > > > It could have the following configuration: > > > > > > > > VLAN RED - members: port 1:untagged, port 2:tag 23, > > > > port 4:tag 56 > > > > VLAN GREEN - members: port 1:tag 96, port 2:tag 103 VLAN YELLOW - > > > > members: port 1:tag 200, port 4:untagged (Port 3 is not a > > member of > > > > any VLAN) > > > > > > > > This is not simple, esspecially since there may be restrictions, > > > > such as 1) all ports in a VLAN must use the same tag, or > > > > 2) a port can be either a TRUNK port or a feeder port and feeder > > > > ports are untagged, and the VLANs on the trunk port must be all > > > > tagged. (I've seen many different sets of limitations.) > > > > > > > > I'm not sure what to suggest, other than to drop support for > > > > localMAC WTPs (only joking). > > > > > > > > Regards, > > > > /david t. perkins > > > > Regards, > > /david t. perkins > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_6642_30075380.1150917245768 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
We could add a VLAN tag field to the Add WLAN message element.
 
Cheers,
 
Mike

 
On 6/20/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
Ok - so your point is that the protocol doesn't allow one to configure
the actual VLANs on a local MAC WTP.

Fair enough.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems



> -----Original Message-----
> From: David T. Perkins [mailto: dperkins@dsperkins.com]
> Sent: Monday, June 19, 2006 7:20 PM
> To: Pat Calhoun (pacalhou)
> Cc: capwap@frascone.com
> Subject: RE: [Capwap] VLAN name in (section 4.4.8)Add Mobile Station
>
> HI,
>
> How do you know the VLAN Names so you can specify an
> appropriate one in an Add Mobile station message.
>
> How do you configure VLANs on the WTP?
>
> On a splitMAC WTP, this is not an issue, since you configure
> the egress VLAN on the AC, and you configure the ports and
> tags in each VLAN on the AC. Of course, how you set up VLANs
> on the AC is a local matter, not part of the CAPWAP spec.
> However, it seems to me that you have to be able to configure
> the VLANs on a localMAC WTP via CAPWAP, since that is the
> only standard protocol between an AC and WTP, and you really
> need to configure the egress VLANs on a localMAC WTP.
>
> If you don't use CAPWAP to determine the VLAN names on a
> localMAC WTP, or CAPWAP to configure VLANs on a localMAC WTP,
> then what would you use?
>
>
> On Mon, 19 Jun 2006, Pat Calhoun (pacalhou) wrote:
> > Given we are sending a VLAN "name", the actual VLAN
> identifier (tag)
> > may differ across WTPs. I don't understand the issue.
> >
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit Cisco Systems
> > > -----Original Message-----
> > > From: David T. Perkins [mailto:dperkins@dsperkins.com]
> > > Sent: Wednesday, June 14, 2006 5:04 PM
> > > To: capwap@frascone.com
> > > Subject: [Capwap] VLAN name in (section 4.4.8)Add Mobile Station
> > >
> > > HI,
> > >
> > > The message element (4.4.8)Add Modile Station has subfield "VLAN
> > > name". However, there are no CAPWAP messages or message
> elements for
> > > VLAN names on a WTP to be managed by the the AC.
> > > (A value for a VLAN Name is only approapriate for a localMAC
> > > WTP.) Managed means to find out the list of the VLAN
> names, create
> > > VLANs and apply attributes, modify VLAN attributes, and delete
> > > VLANs. The attributes include the VLAN name, and
> ports:tag pairs in
> > > the VLAN. (By the way, this is sort of an expansion of
> CAPWAP, but
> > > it is the price to pay to support localMAC.)
> > >
> > > For example, consider a localMAC WTP with 4 802.3 ports.
> > > It could have the following configuration:
> > >
> > > VLAN RED - members: port 1:untagged, port 2:tag 23,
> > >                     port 4:tag 56
> > > VLAN GREEN - members: port 1:tag 96, port 2:tag 103 VLAN YELLOW -
> > > members: port 1:tag 200, port 4:untagged (Port 3 is not a
> member of
> > > any VLAN)
> > >
> > > This is not simple, esspecially since there may be restrictions,
> > > such as 1) all ports in a VLAN must use the same tag, or
> > > 2) a port can be either a TRUNK port or a feeder port and feeder
> > > ports are untagged, and the VLANs on the trunk port must be all
> > > tagged. (I've seen many different sets of limitations.)
> > >
> > > I'm not sure what to suggest, other than to drop support for
> > > localMAC WTPs (only joking).
> > >
> > > Regards,
> > > /david t. perkins
>
> Regards,
> /david t. perkins
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_6642_30075380.1150917245768-- --===============1431683147== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1431683147==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 21 20:14:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtCpf-0005MS-1E for capwap-archive@lists.ietf.org; Wed, 21 Jun 2006 20:14:03 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtCpd-0001Ri-Oe for capwap-archive@lists.ietf.org; Wed, 21 Jun 2006 20:14:03 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DC3E8430165 for ; Wed, 21 Jun 2006 17:14:00 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E2A2D430054 for ; Wed, 21 Jun 2006 17:13:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D847739801C for ; Wed, 21 Jun 2006 17:13:27 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id F0842398009 for ; Wed, 21 Jun 2006 17:13:23 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5M0DNXc015317 for ; Wed, 21 Jun 2006 17:13:23 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5M0DMbg015314 for ; Wed, 21 Jun 2006 17:13:23 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 21 Jun 2006 17:13:22 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [Capwap] Additional "unprotected" control messages X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 HI, Note, in addition to Discovery Request/Response, CAPWAP-01 has Primary-Discovery Request/Response messages that are unprotected by DTLS. Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 21 20:15:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtCr9-0006kr-Am for capwap-archive@lists.ietf.org; Wed, 21 Jun 2006 20:15:35 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtCr5-0001ar-LC for capwap-archive@lists.ietf.org; Wed, 21 Jun 2006 20:15:35 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3D2CE4300C5 for ; Wed, 21 Jun 2006 17:15:31 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B5495430077 for ; Wed, 21 Jun 2006 17:13:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BC7341448014 for ; Wed, 21 Jun 2006 17:13:38 -0700 (PDT) X-Greylist-Status: Sender first seen 4 mons 27 days 08:25:52 ago Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by hermes.tigertech.net (Postfix) with ESMTP id C5DE11448003 for ; Wed, 21 Jun 2006 17:13:34 -0700 (PDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5M09d1L024581 for ; Wed, 21 Jun 2006 20:09:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jun 2006 18:13:32 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Process in CAPWAP Thread-Index: AcaMIv6al2wcs/e8TvuwY5RhhPusZAELwwbQABULHhAAHxdIYADQACvAAEuAkrA= From: "Mani, Mahalingam (Mani)" To: "capwap" X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: Re: [Capwap] Process in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 [The posting has been delayed till around midnight tonight (same TZ)]. -mani -----Original Message----- From: Mani, Mahalingam (Mani) = Sent: Tuesday, June 20, 2006 5:12 AM To: Romascanu, Dan (Dan); capwap Subject: Re: [Capwap] Process in CAPWAP Dan, The list will be prepared posted here (by June 21 5pm Pacific) prior to sen= ding to the experts. Regards, -mani -----Original Message----- From: Romascanu, Dan (Dan) = Sent: Friday, June 16, 2006 1:57 AM To: capwap Subject: Re: [Capwap] Process in CAPWAP I would suggest that the chairs draw a short list of clear questions and is= sues for clarification, including references that would help to focus the w= ork of the experts. Can we have this list prepared in the next few days? = Thanks and Regards, Dan = = > -----Original Message----- > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] = > Sent: Thursday, June 15, 2006 9:12 PM > To: capwap > Cc: david.kessens@nokia.com; Romascanu, Dan (Dan) > Subject: RE: Process in CAPWAP > = > Dan, David, > = > I certainly appreciate the difficulty that our chairs have to = > navigate the path to consensus necessary for a successful = > standard. I do not envy them their task, particularly in = > this area where we believe that the success of the CAPWAP = > standard is critical to this market area and the customers in it. > = > There are certainly enough open issues to resolve, that = > asking for expert advice on this particular issue is not = > likely to adversely affect the time for completion of our = > work. I think that this will be very helpful to us. = > = > Thank you. > = > -Bob > = > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Thursday, June 15, 2006 1:07 AM > To: Bob O'Hara (boohara) > Cc: capwap; david.kessens@nokia.com > Subject: RE: Process in CAPWAP > = > Hi Bob, > = > The ADs looked in the issue that you raised related to the = > consensus on the Mux vs Multiport issue # 115. We analyzed = > the traffic on the list and we also discussed with the WG = > chairs. Our opinion is that although the chairs suggested a = > solution for consensus the WG did not agree with it. Despite = > the chairs and WG efforts to reach a timely conclusion = > according to the current WG schedules, more work needs to be = > done to reach at minimum rough consensus on this point. > = > The chairs have the responsibility to drive the consensus = > process, and the criteria for reaching the decisions should = > be clearly explained. = > = > In order to overcome the dead-end we recommend to the WG to = > bring in the discussion opinions about the consensus criteria = > (QoS, scalability, compatibility with routing and switching = > infrastructure), their priority and recommendations from = > external experts that were less involved in the discussions = > until now, for example by consulting the Routing Area. We = > offer to approach the Routing Area ADs to have an expert = > designated to this purpose. > = > We recommend that the WG continues its work and capitalizes = > on the effort made until now to close a large number of open = > issues in the next version of the draft. This issue together = > with the other open issues should be brought for discussion = > on the list and in Montreal, and we hope that a conclusion = > based on rough consensus can be reached soon after the = > Montreal meeting, so that the impact on the Working Group = > schedules be minimized. > = > David and Dan > = > = > = > = > > -----Original Message----- > > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > > Sent: Saturday, June 10, 2006 3:16 AM > > To: Romascanu, Dan (Dan) > > Cc: capwap > > Subject: Process in CAPWAP > > = > > Dan, > > = > > A few days ago Dorothy Gellert sent an email to the working = > group on = > > behalf of the chairs, announcing a decision on a technical issue in = > > the working group. Specifically, she declared that the = > chairs decided = > > the discussion of the use of a mux header vs. the use of separate = > > ports for the differentiation of control and data traffic in the = > > protocol to be over. She also indicated that the chairs had chosen = > > the mux header as the method to be used in the protocol and set a = > > deadline of today for closing the issue. > > = > > As soon as I read her email, I replied and asked that she = > document the = > > process that the chairs used to arrive at their decision. My = > > background is in the IEEE, where the process is clear, transparent, = > > and open to all participants. CAPWAP is my first IETF = > working group. = > > My understanding of decision-making in IETF is that it is based on = > > rough consensus and that the chairs have responsibility to = > determine = > > that consensus. With that understanding, I asked Dorothy = > to document = > > what the chairs used as evidence of rough consensus on that issue, = > > since I see evidence in the postings to the list that there is more = > > support for separate ports than there is for the mux header. At a = > > minimum, there is no consensus on this issue. > > = > > Since sending that email two days ago, neither chair has = > responded. I = > > find that quite disturbing for several reasons. > > = > > First, this is an issue that has been debated extensively = > (and still = > > is being debated, regardless of the pronouncement from the = > chairs). = > > The working group deserves to know how this technical issue was = > > resolved. > > = > > Second, standardization by fiat of the chair does not seem to be in = > > keeping with the open process requirements of the IETF. > > Perhaps I am being na=EFve, but I don't believe there is a = > feted inner = > > core (FIC) that is actually developing all the IETF standards. > > = > > Third, the time allowed for any response to the email was = > only three = > > days. This is an absurdly short time, given that it is the = > start of = > > the summer vacation period in the northern hemisphere. It is quite = > > possible that many participants will not even see her email until = > > after the deadline expires. > > = > > Finally, if there is no consensus on the issue, the chairs are = > > expressing an engineering opinion and should be required to justify = > > that opinion just as any other member of the working group. = > I don't = > > believe that the IETF anoints the chairs of any working group as = > > expert and able to make technical decisions for the working group. > > = > > I would appreciate your thoughts, as the AD, and response on these = > > items. > > = > > Best regards, > > -Bob > > = > > Bob O'Hara > > = > = _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 22 02:29:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtIgw-00053C-VA for capwap-archive@lists.ietf.org; Thu, 22 Jun 2006 02:29:26 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtIgu-0005Lo-Gh for capwap-archive@lists.ietf.org; Thu, 22 Jun 2006 02:29:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 673A743006C for ; Wed, 21 Jun 2006 23:29:23 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id F2556430054 for ; Wed, 21 Jun 2006 23:28:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D53A9144801E for ; Wed, 21 Jun 2006 23:28:47 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.204]) by hermes.tigertech.net (Postfix) with ESMTP id 1DC00144801D for ; Wed, 21 Jun 2006 23:28:44 -0700 (PDT) Received: by nz-out-0102.google.com with SMTP id s1so417414nze for ; Wed, 21 Jun 2006 23:28:43 -0700 (PDT) Received: by 10.37.12.66 with SMTP id p66mr1462356nzi; Wed, 21 Jun 2006 23:28:43 -0700 (PDT) Received: by 10.36.20.6 with HTTP; Wed, 21 Jun 2006 23:28:43 -0700 (PDT) Message-ID: <5bfe7a820606212328x5aca8a45oc73d051627cbe646@mail.gmail.com> Date: Wed, 21 Jun 2006 23:28:43 -0700 From: "Dorothy Stanley" To: capwap MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.0 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: [Capwap] Proposed text for issue resolution X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0253735004==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.0 (+) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 --===============0253735004== Content-Type: multipart/alternative; boundary="----=_Part_289_18495764.1150957723301" ------=_Part_289_18495764.1150957723301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, Draft -02 of the CAPWAP protocol specification will be published shortly, and we are looking forward to resolving as many issues as possible in the next revision, -03, tentatively targeted for late August. With this mail, we'd like to (1) Thank all those who have contributed proposed text for issue resolution to date. We'll be sending out a list of the issues that have been resolved in -02, and your contributions enabled forward progress on the draft. (2) Ask for volunteers to develop and post text reflecting the changes that would need to be made to draft-02 to incorporate the proposed single port and dual port alternative solutions (see issue 115, "To MUX or not to MUX" and issue 82, "UDP port assignment(s) for control and data traffic"). To date we have not seen proposed draft text for either alternative, and would like to avoid a situation where say at the end of July the WG has not seen and been able to review a reasonably solid draft of text that would need to be incorporated. Available text would also help quantify/define the work involved. Thank you, The editors -Pat Calhoun, Mike Montemurro, Dorothy Stanley ------=_Part_289_18495764.1150957723301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline All,

Draft -02 of the CAPWAP protocol specification will be published shortly,
and we are looking forward to resolving as many issues as possible in the
next revision, -03, tentatively targeted for late August.

With this  mail, we'd like to

(1) Thank all those who have contributed proposed text for issue resolution to date.
We'll be sending out a list of the issues that have been resolved in -02, and
your contributions enabled forward progress on the draft.

(2) Ask for volunteers to develop and post text reflecting
the changes that would need to be made to draft-02 to incorporate
the proposed single port and dual port alternative solutions
(see issue 115,  "To MUX or not to MUX" and
issue 82, "UDP port assignment(s) for control and data traffic").

To date we have not seen proposed draft text
for either alternative, and would like to avoid a situation where
say at the end of July the WG has not seen and been able to review a reasonably
solid draft of text that would need to be incorporated. Available text would
also help quantify/define the work involved.

Thank you,

The editors -Pat Calhoun, Mike Montemurro, Dorothy Stanley
------=_Part_289_18495764.1150957723301-- --===============0253735004== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0253735004==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 22 10:14:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtPx1-0000wC-O3 for capwap-archive@lists.ietf.org; Thu, 22 Jun 2006 10:14:31 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtPwx-0007SF-Oc for capwap-archive@lists.ietf.org; Thu, 22 Jun 2006 10:14:31 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 81BE043012C for ; Thu, 22 Jun 2006 07:14:24 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1CF8243006C for ; Thu, 22 Jun 2006 07:13:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D8959430D20 for ; Thu, 22 Jun 2006 07:13:27 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id C75D0430D2F for ; Thu, 22 Jun 2006 07:13:24 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 22 Jun 2006 07:13:23 -0700 X-IronPort-AV: i="4.06,166,1149490800"; d="scan'208,217"; a="299194574:sNHT58086288" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k5MEDNBc022717; Thu, 22 Jun 2006 07:13:23 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5MEDNCU012909; Thu, 22 Jun 2006 07:13:23 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Jun 2006 07:13:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 Jun 2006 07:13:22 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2021090DB@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] VLAN name in (section 4.4.8)Add Mobile Station Thread-Index: AcaVZt9E6TMGeTIiTN2YA2Rwp9ks9wAnw0vA From: "Pat Calhoun (pacalhou)" To: "Michael Montemurro" X-OriginalArrivalTime: 22 Jun 2006 14:13:23.0459 (UTC) FILETIME=[059A0D30:01C69606] Authentication-Results: sj-dkim-1.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 43 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_30_40, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] VLAN name in (section 4.4.8)Add Mobile Station X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1172895071==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86 This is a multi-part message in MIME format. --===============1172895071== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69606.054BF052" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69606.054BF052 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Or some additional message elements in the configuration phase to plumb the VLANs. The Add WLAN should point to the configured VLANs. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Wednesday, June 21, 2006 12:14 PM To: Pat Calhoun (pacalhou) Cc: David T. Perkins; capwap@frascone.com Subject: Re: [Capwap] VLAN name in (section 4.4.8)Add Mobile Station =09 =09 We could add a VLAN tag field to the Add WLAN message element. =20 Cheers, =20 Mike =09 =20 On 6/20/06, Pat Calhoun (pacalhou) wrote:=20 Ok - so your point is that the protocol doesn't allow one to configure the actual VLANs on a local MAC WTP.=20 =09 Fair enough. =09 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =09 =09 =09 > -----Original Message----- > From: David T. Perkins [mailto: dperkins@dsperkins.com ] > Sent: Monday, June 19, 2006 7:20 PM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: RE: [Capwap] VLAN name in (section 4.4.8)Add Mobile Station > > HI, > > How do you know the VLAN Names so you can specify an > appropriate one in an Add Mobile station message. > > How do you configure VLANs on the WTP?=20 > > On a splitMAC WTP, this is not an issue, since you configure > the egress VLAN on the AC, and you configure the ports and > tags in each VLAN on the AC. Of course, how you set up VLANs > on the AC is a local matter, not part of the CAPWAP spec.=20 > However, it seems to me that you have to be able to configure > the VLANs on a localMAC WTP via CAPWAP, since that is the > only standard protocol between an AC and WTP, and you really > need to configure the egress VLANs on a localMAC WTP.=20 > > If you don't use CAPWAP to determine the VLAN names on a > localMAC WTP, or CAPWAP to configure VLANs on a localMAC WTP, > then what would you use? > > > On Mon, 19 Jun 2006, Pat Calhoun (pacalhou) wrote:=20 > > Given we are sending a VLAN "name", the actual VLAN > identifier (tag) > > may differ across WTPs. I don't understand the issue. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > -----Original Message----- > > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > > Sent: Wednesday, June 14, 2006 5:04 PM > > > To: capwap@frascone.com > > > Subject: [Capwap] VLAN name in (section 4.4.8)Add Mobile Station > > > > > > HI, > > > > > > The message element (4.4.8)Add Modile Station has subfield "VLAN > > > name". However, there are no CAPWAP messages or message > elements for > > > VLAN names on a WTP to be managed by the the AC.=20 > > > (A value for a VLAN Name is only approapriate for a localMAC > > > WTP.) Managed means to find out the list of the VLAN > names, create > > > VLANs and apply attributes, modify VLAN attributes, and delete=20 > > > VLANs. The attributes include the VLAN name, and > ports:tag pairs in > > > the VLAN. (By the way, this is sort of an expansion of > CAPWAP, but > > > it is the price to pay to support localMAC.)=20 > > > > > > For example, consider a localMAC WTP with 4 802.3 ports. > > > It could have the following configuration: > > > > > > VLAN RED - members: port 1:untagged, port 2:tag 23,=20 > > > port 4:tag 56 > > > VLAN GREEN - members: port 1:tag 96, port 2:tag 103 VLAN YELLOW - > > > members: port 1:tag 200, port 4:untagged (Port 3 is not a > member of=20 > > > any VLAN) > > > > > > This is not simple, esspecially since there may be restrictions, > > > such as 1) all ports in a VLAN must use the same tag, or > > > 2) a port can be either a TRUNK port or a feeder port and feeder=20 > > > ports are untagged, and the VLANs on the trunk port must be all > > > tagged. (I've seen many different sets of limitations.) > > > > > > I'm not sure what to suggest, other than to drop support for=20 > > > localMAC WTPs (only joking). > > > > > > Regards, > > > /david t. perkins > > Regards, > /david t. perkins > =09 _________________________________________________________________=20 To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap =09 ------_=_NextPart_001_01C69606.054BF052 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Or=20 some additional message elements in the configuration phase to plumb the = VLANs.=20 The Add WLAN should point to the configured VLANs.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Wednesday, June = 21,=20 2006 12:14 PM
To: Pat Calhoun (pacalhou)
Cc: David = T.=20 Perkins; capwap@frascone.com
Subject: Re: [Capwap] VLAN name = in=20 (section 4.4.8)Add Mobile Station

We could add a VLAN tag field to the Add WLAN message = element.
 
Cheers,
 
Mike

 
On 6/20/06, Pat Calhoun=20 (pacalhou) <pcalhoun@cisco.com> = wrote:=20
Ok=20 - so your point is that the protocol doesn't allow one to = configure
the=20 actual VLANs on a local MAC WTP.

Fair enough.

Pat=20 Calhoun
CTO, Wireless Networking Business Unit
Cisco=20 Systems



> -----Original Message-----
> From: = David=20 T. Perkins [mailto:=20 dperkins@dsperkins.com]
> Sent: Monday, June 19, 2006 7:20 = PM
> To: Pat Calhoun (pacalhou)
> Cc: capwap@frascone.com
> = Subject:=20 RE: [Capwap] VLAN name in (section 4.4.8)Add Mobile = Station
>
>=20 HI,
>
> How do you know the VLAN Names so you can = specify=20 an
> appropriate one in an Add Mobile station = message.
>
>=20 How do you configure VLANs on the WTP?
>
> On a = splitMAC WTP,=20 this is not an issue, since you configure
> the egress VLAN on = the AC,=20 and you configure the ports and
> tags in each VLAN on the AC. = Of=20 course, how you set up VLANs
> on the AC is a local matter, = not part=20 of the CAPWAP spec.
> However, it seems to me that you have = to be=20 able to configure
> the VLANs on a localMAC WTP via CAPWAP, = since that=20 is the
> only standard protocol between an AC and WTP, and you = really
> need to configure the egress VLANs on a localMAC WTP. =
>
> If you don't use CAPWAP to determine the VLAN names = on=20 a
> localMAC WTP, or CAPWAP to configure VLANs on a localMAC=20 WTP,
> then what would you use?
>
>
> On = Mon, 19 Jun=20 2006, Pat Calhoun (pacalhou) wrote:
> > Given we are = sending a=20 VLAN "name", the actual VLAN
> identifier (tag)
> > = may=20 differ across WTPs. I don't understand the issue.
> = >
> >=20 Pat Calhoun
> > CTO, Wireless Networking Business Unit = Cisco=20 Systems
> > > -----Original Message-----
> > = >=20 From: David T. Perkins [mailto:dperkins@dsperkins.com]
>= ;=20 > > Sent: Wednesday, June 14, 2006 5:04 PM
> > > = To: capwap@frascone.com
> = > >=20 Subject: [Capwap] VLAN name in (section 4.4.8)Add Mobile = Station
>=20 > >
> > > HI,
> > >
> > > = The=20 message element (4.4.8)Add Modile Station has subfield "VLAN
> = >=20 > name". However, there are no CAPWAP messages or message
> = elements for
> > > VLAN names on a WTP to be managed by = the the=20 AC.
> > > (A value for a VLAN Name is only approapriate = for a=20 localMAC
> > > WTP.) Managed means to find out the list = of the=20 VLAN
> names, create
> > > VLANs and apply = attributes,=20 modify VLAN attributes, and delete
> > > VLANs. The = attributes=20 include the VLAN name, and
> ports:tag pairs in
> > = > the=20 VLAN. (By the way, this is sort of an expansion of
> CAPWAP,=20 but
> > > it is the price to pay to support localMAC.) =
>=20 > >
> > > For example, consider a localMAC WTP = with 4=20 802.3 ports.
> > > It could have the following=20 configuration:
> > >
> > > VLAN RED - = members: port=20 1:untagged, port 2:tag 23,
> >=20 = >           &nb= sp;        =20 port 4:tag 56
> > > VLAN GREEN - members: port 1:tag 96, = port=20 2:tag 103 VLAN YELLOW -
> > > members: port 1:tag 200, = port=20 4:untagged (Port 3 is not a
> member of
> > > any = VLAN)
> > >
> > > This is not simple, = esspecially=20 since there may be restrictions,
> > > such as 1) all = ports in a=20 VLAN must use the same tag, or
> > > 2) a port can be = either a=20 TRUNK port or a feeder port and feeder
> > > ports are=20 untagged, and the VLANs on the trunk port must be all
> > = >=20 tagged. (I've seen many different sets of limitations.)
> > = >
> > > I'm not sure what to suggest, other than to = drop=20 support for
> > > localMAC WTPs (only joking).
> = >=20 >
> > > Regards,
> > > /david t.=20 perkins
>
> Regards,
> /david t.=20 = perkins
>
______________________________________________________= ___________=20
To unsubscribe or modify your subscription options, please = visit:
http://lists.f= rascone.com/mailman/listinfo/capwap

Archives:=20 http://lists.frascone= .com/pipermail/capwap

<= /HTML> ------_=_NextPart_001_01C69606.054BF052-- --===============1172895071== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1172895071==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 22 11:27:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtR5s-0000cV-JU for capwap-archive@lists.ietf.org; Thu, 22 Jun 2006 11:27:44 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtR5r-00023V-5p for capwap-archive@lists.ietf.org; Thu, 22 Jun 2006 11:27:44 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1E2AF430121 for ; Thu, 22 Jun 2006 08:27:42 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9FC0D430054 for ; Thu, 22 Jun 2006 08:27:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E2153430E57 for ; Thu, 22 Jun 2006 08:27:15 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by hermes.tigertech.net (Postfix) with ESMTP id 5462C430E51 for ; Thu, 22 Jun 2006 08:27:11 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id z74so373703pyg for ; Thu, 22 Jun 2006 08:27:10 -0700 (PDT) Received: by 10.35.27.1 with SMTP id e1mr1211680pyj; Thu, 22 Jun 2006 08:27:10 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Thu, 22 Jun 2006 08:27:10 -0700 (PDT) Message-ID: <26140d940606220827m1e88b826xbdf4bb03a36fe501@mail.gmail.com> Date: Thu, 22 Jun 2006 11:27:10 -0400 From: "Michael Montemurro" To: capwap MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: Dorothy.Gellert@nokia.com Subject: [Capwap] draft-ietf-capwap-protocol-specifciation-02.txt submission X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1280982058==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab --===============1280982058== Content-Type: multipart/alternative; boundary="----=_Part_14519_10314832.1150990030765" ------=_Part_14519_10314832.1150990030765 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, draft-ietf-capwap-protocol-specifciation-02.txt has been submitted to internet-drafts and should be available shortly. We would like to take this time to thank everyone who contributed to resolving the issues that have been addressed in this draft. We encourage everyone to review the updated draft and point out any other issues in the submission. The issues that have been addressed in this draft include: 129, 128, 125, 43, 80, 100, 136, 133, 126, 103, 104, 64, 37, 141, 77, 120, 119, 118, 83, 66, 117, 107, 18, 123, 116, 130, 134, 132, 124, 106, 98, 97, 78, 45, 84, 81, 74, 2, 63, 85, 86, and 105. Thanks, Dorothy, Pat and Mike ------=_Part_14519_10314832.1150990030765 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
All,
 
draft-ietf-capwap-protocol-specifciation-02.txt has been submitted to internet-drafts and should be available shortly. We would like to take this time to thank everyone who contributed to resolving the issues that have been addressed in this draft. We encourage everyone to review the updated draft and point out any other issues in the submission.
 
The issues that have been addressed in this draft include: 129, 128, 125, 43, 80, 100, 136, 133, 126, 103, 104, 64, 37, 141, 77, 120, 119, 118, 83, 66, 117, 107, 18, 123, 116, 130, 134, 132, 124, 106, 98, 97, 78, 45, 84, 81, 74, 2, 63, 85, 86, and 105.
 
Thanks,
 
Dorothy, Pat and Mike
------=_Part_14519_10314832.1150990030765-- --===============1280982058== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1280982058==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 22 12:16:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtRrQ-00058r-2I for capwap-archive@lists.ietf.org; Thu, 22 Jun 2006 12:16:52 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtRrO-0007H3-Li for capwap-archive@lists.ietf.org; Thu, 22 Jun 2006 12:16:52 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E8A1A430121 for ; Thu, 22 Jun 2006 09:16:49 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 36884430054 for ; Thu, 22 Jun 2006 09:16:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E5173430F2A for ; Thu, 22 Jun 2006 09:16:16 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 712EA430F26 for ; Thu, 22 Jun 2006 09:16:13 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5MGGCod013004; Thu, 22 Jun 2006 09:16:12 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5MGGCiB013000; Thu, 22 Jun 2006 09:16:12 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 22 Jun 2006 09:16:12 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Michael Montemurro In-Reply-To: <26140d940606220827m1e88b826xbdf4bb03a36fe501@mail.gmail.com> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap , Dorothy.Gellert@nokia.com Subject: Re: [Capwap] draft-ietf-capwap-protocol-specifciation-02.txt submission X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 HI, Well, in a few minutes I'll be sending out a 22 page document that summarizes the CAPWAP operations and has extensive DISCUSS comments. I'll go look at the CAPWAP-02 document, and try to provide comments on it before the IETF meeting. On Thu, 22 Jun 2006, Michael Montemurro wrote: > All, > > draft-ietf-capwap-protocol-specifciation-02.txt has been submitted to > internet-drafts and should be available shortly. We would like to take this > time to thank everyone who contributed to resolving the issues that have > been addressed in this draft. We encourage everyone to review the updated > draft and point out any other issues in the submission. > > The issues that have been addressed in this draft include: 129, 128, 125, > 43, 80, 100, 136, 133, 126, 103, 104, 64, 37, 141, 77, 120, 119, 118, 83, > 66, 117, 107, 18, 123, 116, 130, 134, 132, 124, 106, 98, 97, 78, 45, 84, 81, > 74, 2, 63, 85, 86, and 105. > > Thanks, > > Dorothy, Pat and Mike > Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 22 18:13:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtXR0-0004M7-99 for capwap-archive@lists.ietf.org; Thu, 22 Jun 2006 18:13:58 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtXQv-0002sC-Dd for capwap-archive@lists.ietf.org; Thu, 22 Jun 2006 18:13:58 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 491824300FB for ; Thu, 22 Jun 2006 15:13:52 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 2C5DC430063 for ; Thu, 22 Jun 2006 15:13:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 19DA2398030 for ; Thu, 22 Jun 2006 15:13:26 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by zoidberg.tigertech.net (Postfix) with ESMTP id A0C7839805A for ; Thu, 22 Jun 2006 15:13:16 -0700 (PDT) Received: from [209.86.224.44] (helo=elwamui-ovcar.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FtXQJ-0006Yl-NS; Thu, 22 Jun 2006 18:13:15 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Thu, 22 Jun 2006 18:13:15 -0400 Message-ID: <31437786.1151014395644.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> Date: Thu, 22 Jun 2006 18:13:15 -0400 (EDT) From: "Scott G. Kelly" To: Dorothy Stanley Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff71057650561f3ba4bcd5225831ae2f77c3d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.44 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Proposed text for issue resolution X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Hi Dorothy, Dorothy Stanley wrote: >All, > > Draft -02 of the CAPWAP protocol specification will be published shortly, and we are looking > forward to resolving as many issues as possible in the next revision, -03, tentatively targeted > for late August. > > With this mail, we'd like to > > (1) Thank all those who have contributed proposed text for issue resolution to date. > We'll be sending out a list of the issues that have been resolved in -02, and your contributions > enabled forward progress on the draft. > > (2) Ask for volunteers to develop and post text reflecting the changes that would need to be made > to draft-02 to incorporate the proposed single port and dual port alternative solutions > > (see issue 115, "To MUX or not to MUX" and issue 82, "UDP port assignment(s) for control and > data traffic"). > > To date we have not seen proposed draft text for either alternative, and would like to avoid a > situation where say at the end of July the WG has not seen and been able to review a reasonably > solid draft of text that would need to be incorporated. Available text would also help quantify/define > the work involved. > > Thank you, > > The editors -Pat Calhoun, Mike Montemurro, Dorothy Stanley Text for the single-port approach follows: ------------------------------------------------------------------------------------------------------ 3. CAPWAP Transport (No Change) (no changes to introductory paragraph) 3.1. UDP Transport (replaces existing text) Communication between a WTP and an AC is established according to the standard UDP client/server model. A datagram protocol has the following advantages as compared to a connection-oriented protocol like TCP: o UDP provides the CAPWAP protocol with fine-grained control over retransmit timeouts, latency, responsiveness, etc. This is important both for control packets (e.g. echo request/response) and data packets (e.g. tunneled data packets carrying real-time protocols such as VoIP). o UDP provides for a lighter-weight implementation; a WTP need not implement a TCP stack if this is not desirable for other reasons. o The CAPWAP protocol is designed as a synchronous request-response protocol, so providing reliability at layer 4 is redundant CAPWAP protocol packets sent between the WTP and the AC use well known UDP port 12222. 3.2 Transport Protocol Data Unit (new section) The CAPWAP protocol uses 3 distinct Transport Protocol Data Unit (Transport PDU) types: Discovery, Control, and Data. The Transport PDU type header is defined below in the CAPWAP Packet Formats section. 3.3. AC Discovery (no changes to current AC Discovery text) 3.4. Fragmentation/Reassembly (no changes to current frag/reassem text) 4. CAPWAP Packet Formats This section contains the CAPWAP protocol packet formats. A CAPWAP protocol packet consists of a CAPWAP Transport Layer packet header followed by a CAPWAP message. The CAPWAP message can be of type Discovery, Control or Data, where Discovery packets are intended for discovering ACs on the network, Control packets carry signaling, and Data packets carry user payloads. The frame formats for CAPWAP Discovery packets, Data packets, and for DTLS encapsulated CAPWAP Data and Control packets are as shown below: CAPWAP Discovery Packet: +-----------------------------------------------+ | IP |UDP |PDU | CAPWAP | Control | Message | | Hdr |Hdr |Hdr | Header | Header | Element(s) | +-----------------------------------------------+ CAPWAP Data Packet : +--------------------------------------+ | IP |UDP |PDU | CAPWAP | Wireless | | Hdr |Hdr |Hdr | Header | Payload | +--------------------------------------+ CAPWAP + Optional DTLS Data Packet Security: +----------------------------------------------------+ | IP |UDP |PDU | DTLS | CAPWAP | Wireless | DTLS | | Hdr |Hdr |Hdr | Hdr | Hdr | Payload | Trailer| +----------------------------------------------------+ |<------authenticated------->| |<---------encrypted--------->| CAPWAP Control Packet (DTLS Security Required): +----------------------------------------------------------------+ | IP |UDP |PDU | DTLS | CAPWAP | Control | Message | DTLS | | Hdr |Hdr |Hdr | Hdr | Header | Header | Element(s) | Trailer | +----------------------------------------------------------------+ |<--------authenticated--------------->| |<--------------encrypted---------------->| UDP: All CAPWAP packets are encapsulated within UDP. Section Section 3.1 defines the specific UDP usage. PDU Header: All CAPWAP protocol packets use a common Transport PDU header that immediately follows the UDP header. This header is defined in section 4.1 CAPWAP Header: All CAPWAP protocol packets use a common transport header that immediately follows the MUX header in unsecured packets, and the DTLS header in secured packets. The CAPWAP transport header is defined in Section 4.2. Wireless Payload: A CAPWAP protocol packet that contains a wireless payload is known as a data frame. The CAPWAP protocol does not dictate the format of the wireless payload, which is defined by the appropriate wireless standard. Additional information is in Section 4.3. Control Header: The CAPWAP protocol includes a signalling component, known as the CAPWAP control protocol. All CAPWAP control packets include a Control Header, which is defined in Section 4.4.1. Message Elements: A CAPWAP Control packet includes one or more message elements, which are found immediately following the control header. These message elements are in a Type/Length/value style header, defined in Section 4.5. 4.1 CAPWAP Transport PDU Header CAPWAP currently defines 3 distinct Transport PDU types: Discovery, Control, and Data. The Transport PDU header is provided as a transport-independent way to delineate between these. The functionality provided by the Transport PDU header currently only requires a few bits; however, it is defined as a 32-bit value for byte alignment. The least significant bits are currently defined: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESERVED | P | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following values are defined for P (PDU type): 0 - RESERVED (do not use) 1 - CAPWAP Control 2 - CAPWAP Data 3 - CAPWAP Discovery The reserved portion of the Transport PDU header MUST be all zeroes. (increment remaining 4.x subsections by one) 12. NAT Considerations Since all CAPWAP protocol communication is UDP-based, is initiated by the WTP, and since CAPWAP provides a channel keepalive facility, the presence of a middlebox which translates the WTP address will be nearly transparent. The only requirement is that the EchoInterval timer is configured to be less than the NAT binding lifetime of the middlebox. NAT binding lifetimes are not standardized, and there is some variability in practice. For practical operational reasons, such bindings are typically not less than 30 seconds, and frequently are 60 seconds or more. Thus, setting the CAPWAP EchoInterval timer to a value of 30 seconds or less should suffice in most situations. However, lack of standardization implies that some experimentation may be required under some circumstances. Hence, CAPWAP implementations MUST provide the ability to configure the EchoInterval timer in order to support NAT traversal. Note that some NAT devices may, under heavy load conditions, arbitrarily delete datagram NAT bindings. If this occurs, neither control nor data will pass until a new binding is created, and this requires a transmission from the WTP to the AC. Note that this is guaranteed to occur within no more than EchoInterval seconds, so such binding losses, while certain to cause operational "blips" whenever they occur, are also self-healing. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 22 18:50:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtY0X-0004w8-EN for capwap-archive@lists.ietf.org; Thu, 22 Jun 2006 18:50:41 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtY0V-0003VW-UA for capwap-archive@lists.ietf.org; Thu, 22 Jun 2006 18:50:41 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4193F4300AE for ; Thu, 22 Jun 2006 15:50:39 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 5E20A430063 for ; Thu, 22 Jun 2006 15:50:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 52CDF398030 for ; Thu, 22 Jun 2006 15:50:09 -0700 (PDT) Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by zoidberg.tigertech.net (Postfix) with ESMTP id F23A939801E for ; Thu, 22 Jun 2006 15:50:03 -0700 (PDT) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5MMo2Rx025059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtXzu-0007tI-37; Thu, 22 Jun 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 22 Jun 2006 18:50:02 -0400 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.334 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO, MIME_BOUND_NEXTPART, NO_REAL_NAME X-Spam-Level: Cc: capwap@frascone.com Subject: [Capwap] I-D ACTION:draft-ietf-capwap-protocol-specification-02.txt X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.3 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Control And Provisioning of Wireless Access Points Working Group of the IETF. Title : CAPWAP Protocol Specification Author(s) : P. Calhoun, et al. Filename : draft-ietf-capwap-protocol-specification-02.txt Pages : 151 Date : 2006-6-22 Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralized controller and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the IETF CAPWAP working group protocol requirements. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol, including an extension which supports the IEEE 802.11 wireless LAN protocol. Future extensions will enable support of additional wireless technologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-capwap-protocol-specification-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-capwap-protocol-specification-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-capwap-protocol-specification-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-22155032.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-capwap-protocol-specification-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-capwap-protocol-specification-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-22155032.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --NextPart-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 22 21:20:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtaLI-0004Jf-Ti for capwap-archive@lists.ietf.org; Thu, 22 Jun 2006 21:20:16 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtYf4-0000gD-Tx for capwap-archive@lists.ietf.org; Thu, 22 Jun 2006 19:32:35 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtYex-0001hI-RQ for capwap-archive@lists.ietf.org; Thu, 22 Jun 2006 19:32:34 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 40AFD4300EA for ; Thu, 22 Jun 2006 16:32:26 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 43443430063 for ; Thu, 22 Jun 2006 16:31:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 38DB639801C for ; Thu, 22 Jun 2006 16:31:30 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C9CD939802D for ; Thu, 22 Jun 2006 16:31:24 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5MNVOaa028623 for ; Thu, 22 Jun 2006 16:31:24 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5MNVNbZ028618 for ; Thu, 22 Jun 2006 16:31:24 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 22 Jun 2006 16:31:23 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2133786286-2085581730-1151019083=:29535" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [Capwap] A commentary on CAPWAP-01 operations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 300e10ad8b872a99fb6568cfb33e5272 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2133786286-2085581730-1151019083=:29535 Content-Type: TEXT/PLAIN; charset=US-ASCII HI, I've attached a long file that summarizes the operations in CAPWAP-01. Enjoy, /david t. perkins ---2133786286-2085581730-1151019083=:29535 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="capwapOps01.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="capwapOps01.txt" ZmlsZTogY2Fwd2FwT3BzMDEudHh0LCBkdHA6MS1qdW4tMjAwNiwgZHRwOjIy LWp1bi0yMDA2DQ0KDQ0KU3VtbWFyeSBvZiBPcGVyYXRpb25zIGluIENBUFdB UC0wMQ0NCg0NClRoZSBiZWxvdyBpcyBhIHN1bW1hcnkgb2YgdGhlIG9wZXJh dGlvbnMgKG1lc3NhZ2UgdHlwZXMpLCBhbmQNDQphc3NvY2lhdGVkIG1lc3Nh Z2UgZWxlbWVudHMuDQ0KDQ0KRWFjaCBtZXNzYWdlIHR5cGUgZGVzY3JpcHRp b24gc3BlY2lmaWVzOg0NCiBhKSB0aGUgc2VjdGlvbiBvZiBDQVBXQVAtMDEg d2hlcmUgZGVmaW5lZA0NCiBiKSB0aGUgbmFtZQ0NCiBjKSB0aGUgYXNzaWdu ZWQgbWVzc2FnZSB0eXBlDQ0KIGQpIHN0YXRlIHdoZXJlIHNlbnQNDQogZSkg dGhlIHNlbmRlciBhbmQgcmVjZWl2ZXINDQogZikgYSBzaG9ydCBkZXNjcmlw dGlvbg0NCiBlKSBhIGxpc3Qgb2YgbWVzc2FnZSBlbGVtZW50cw0NCg0NCkVh Y2ggbWVzc2FnZSBlbGVtZW50IGRlc2NyaXB0aW9uIHNwZWNpZmllczoNDQog YSkgcG9zc2libHkgIihPKSIgdG8gaW5kaWNhdGUgYXMgb3B0aW9uYWwNDQog YikgcG9zc2libHkgIihNKSIgdG8gaW5kaWNhdGUgaXQgbWF5IGJlIHNwZWNp ZmVkDQ0KICAgIG1vcmUgdGhhbiBvbmUgaW4gdGhlIG1lc3NhZ2UNDQogYykg dGhlIHNlY3Rpb24gb2YgQ0FQV0FQLTAxIHdoZXJlIGRlZmluZWQNDQogZCkg dGhlIG5hbWUNDQogZSkgYSBzaG9ydCBkZXNjcmlwdGlvbiAod2l0aCBzdWJm aWVsZHMgc3BlY2lmaWVkLCBhbmQgdmFsdWVzIGZvciBlbnVtcykNDQoNDQpU aHJvdWdob3V0IHRoZSBkb2N1bWVudCwgd2hlcmUgdGhlcmUgYXJlIHByb2Js ZW1zIG9yIGNvbmNlcm5zLA0NCnRoZXJlIGlzIGEgIkRJU0NVU1MiIGluIHRo ZSB0ZXh0Lg0NCg0NCg0NCkdsb2JhbCBESVNDVVNTIGl0ZW1zOg0NCiAxKSBD YW4gbWVzc2FnZSBlbGVtZW50cyBiZSBpbiBhbnkgb3JkZXI/IChJIGJlbGll dmUgdGhleSBzaG91bGQgYmUpDQ0KIDIpIEFyZSBhbGwgc3BlY2lmaWVkIG1l c3NhZ2UgZWxlbWVudHMgcmVxdWlyZWQ/IChUaGUgb2J2aW91cyBhbnN3ZXIN DQogICAgaXMgInllcyIsIGJ1dCB0aGlzIGRvY3VtZW50IGRvZXNuJ3QgZGlz Y3VzcyB2ZXJzaW9uaW5nLiBGb3IgZXhhbXBsZSwNDQogICAgd2hhdCBpZiBp biBhIG5ldyB2ZXJzaW9uIG9mIENBUFdBUCBhbiBhZGRpdGlvbmFsIG1lc3Nh Z2UgZWxlbWVudA0NCiAgICB3YXMgdG8gYmUgYWRkZWQuIFdvdWxkIGEgbmV3 IG1lc3NhZ2UgdHlwZSBiZSBjcmVhdGVkIGFuZCB0aGUNDQogICAgYWRkaXRp b25hbCBtZXNzYWdlIGVsZW1lbnQgYWRkZWQgdG8gaXQsIG9yIHRoZSBleGlz dGluZyB0eXBlDQ0KICAgIHJldXNlZD8pDQ0KIDMpIENBUFdBUC0wMSBkb2Vz bid0IGRvIGEgZ29vZCBqb2Igb2YgaW5kaWNhdGluZyB3aGljaCBtZXNzYWdl DQ0KICAgIGVsZW1lbnRzIGNhbiBiZSByZXBlYXRlZC4NDQogNCkgQ2FuICJh ZGRpdGlvbmFsIiBtZXNzYWdlIGVsZW1lbnRzIGJlIGFkZGVkIHRvIGEgbWVz c2FnZT8NDQogICAgKEkgYmVsaWV2ZSBzbyBmb3IgcmVwb3J0aW5nIGNhcGFi aWxpdGllcywgc3RhdGlzdGljcywgYW5kDQ0KICAgIGV2ZW50cy4gRm9yIGNv bmZpZ3VyYXRpb24sIHRoZXJlIGlzIG5vdGhpbmcgaW4gdGhlIHByb3RvY29s DQ0KICAgIHRoYXQgc2F5cyB3aGF0IGhhcHBlbnMgd2hlbiBvbmUgZW5kIGdl dHMgYW4gY29uZmlndXJhdGlvbg0NCiAgICBlbGVtZW50IGl0IGRvZXNuJ3Qg a25vdyBhYm91dC4gU2hvdWxkIGl0IGJlIGlnbm9yZWQsIGFuZCB0aGUNDQog ICAgb3RoZXIgZWxlbWVudHMgcHJvY2Vzc2VkLCBvciBzaG91bGQgdGhlIGNv bXBsZXRlIG9wZXJhdGlvbg0NCiAgICBmYWlsZWQ/KQ0NCiA1KSBUaGUgY29u ZmlnIGhhcyBhIGNvbmNlcHQgb2YgImRlZmF1bHQgdmFsdWUiIGZvciBlYWNo DQ0KICAgIGNvbmZpZ3VyYXRpb24gYXR0cmlidXRlLiBIb3dldmVyLCB0aGUg ZGVmYXVsdCB2YWx1ZXMNDQogICAgYXJlIG5vdCBjbGVhcmx5IHNwZWNpZmll ZC4gVGhpcyBuZWVkcyB0byBiZSByZXNvbHZlZA0NCiAgICB0byBiZSBhYmxl IHRvIHN1cHBvcnQgImRlZmF1bHQgdmFsdWVzIi4NDQogNikgdGhlIGRvY3Vt ZW50YXRpb24gb2Ygd2hpY2ggImJpbmRpbmcgc3BlY2lmaWMiIG1lc3NhZ2UN DQogICAgZWxlbWVudHMgYXJlIHRvIGJlIGluY2x1ZGVkIHdpdGggQ0FQV0FQ IG1lc3NhZ2VzDQ0KICAgIGlzIG5vdCBjb25zaXN0ZW50LCBhbmQgaXMgZGlm ZmljdWx0IHRvIGZvbGxvdy4NDQogNykgVGhlcmUgYXJlIHNvbWUgbWVzc2Fn ZSBlbGVtZW50cyB0aGF0IGNhdXNlICJhY3Rpb25zIi4NDQogICAgVGhpcyBh cHByb2FjaCB0byBwcm90b2NvbCBkZXNpZ24gaXMgcHJvYmxlbWF0aWMNDQog ICAgYW5kIHNob3VsZCBiZSBlbGltaW5hdGVkLg0NCiA4KSBUaGUgbWVzc2Fn ZSB0eXBlcyBhcmUgaW5jb25zaXN0ZW50bHkgbmFtZWQsIGFuZCBkbw0NCiAg ICBub3QgZm9sbG93IHRoZSBjb252ZW50aW9ucyBvZiB3ZWxsIGRlc2lnbmVk IHByb3RvY29scy4NDQogICAgQ2FuIHRoZSBvcGVyYXRpb25zIGJlIG5hbWVk IGNvbnNpc3RlbnRseSB3aXRoIHRoZQ0NCiAgICAgZm9sbG93aW5nIHRlcm1p bm9sb2d5DQ0KICAgICAgIDEpIHJlcXVlc3QvcmVzcG9uc2UgKHVzZWQgdG8g Z2V0L3NldC9wZXJmb3JtIGFjdGlvbikNDQogICAgICAgMikgcmVwb3J0L2Fj ayAodXNlIHRvIHRlbGwgdGhlIG90aGVyIHNpZGUgc29tZXRoaW5nKQ0NCiA5 KSBNYW55IG9mIHRoZSBjb25maWd1cmF0aW9uIGl0ZW1zLCBhbmQgc3RhdHVz IGl0ZW1zDQ0KICAgIGFyZSBub3QgbGlzdGVkIGluIG9uZSBzZWN0aW9uIHdp dGggZGVmaW5pdGlvbnMuDQ0KICAgIChXZWxsIG1ha2UgaXQgdHdvIHNlY3Rp b25zIC0gb25lIGZvciBDQVBXQVAgYW5kIHRoZQ0NCiAgICBvdGhlciB3aGlj aCBpcyAiYmluZGluZyIgc3BlY2lmaWMuKSBGb3IgZXhhbXBsZSwNDQogICAg bm90IGFsbCBvZiB0aGUgdGltZSBwZXJpb2QgbGVuZ3RocyBhcmUgaWRlbnRp ZmllZA0NCiAgICBhbmQgc3BlY2lmaWVkIGluIHNlY3Rpb24gNC41Lg0NCiAx MCkgZWFjaCBvcGVyYXRpb24gc2hvdWxkIGhhdmUgbGlzdGVkIGluIHdoaWNo IHN0YXRlcyBpdA0NCiAgICAgY2FuIGJlIHNlbnQgYW5kIHJlY2VpdmVkDQ0K IDExKSBBbGwgc3RyaW5ncywgc3VjaCBhcyBXVFAgbG9jYXRpb24sIHNob3Vs ZCBiZSBjaGFuZ2VkDQ0KICAgICBmcm9tIFVTLUFTQ0lJIGVuY29kaW5nIHRv IFVURi04IGVuY29kaW5nLg0NCiAxMikgVGhlIHRlcm0gIm1vYmlsZSIgaXMg bm90IHJlYWxseSBhY2N1cmF0ZSB3aGVuIGRlc2NyaWJpbmcNDQogICAgIHdp cmVsZXNzIGludGVyZmFjZXMsIHNpbmNlIHdpcmVsZXNzIGRvZXMgbm90IGlt cGx5DQ0KICAgICBtb2JpbGUuIENhbiB3ZSBqdXN0IHVzZSB0aGUgdGVjaGll IHRlcm0gIlNUQSINDQogICAgIGluc3RlYWQuDQ0KDQ0KU3VtbWFyeSBvZiBD QVBXQVAgT3BlcmF0aW9ucw0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NDQoNDQooNS4xKURpc2NvdmVyeSBSZXF1ZXN0KDEpIChEaXNjb3Zlcnkg c3RhdGUpIChXVFAtPkFDKQ0NCiAgRGVzY3I6IHVzZWQgYnkgV1RQIHRvICJk aXNjb3ZlciIgdGhlIEFDIHRoYXQgd2lsbCBjb250cm9sIGl0DQ0KICBNZXNz YWdlIGVsZW1lbnRzOg0NCiAgICAxKSAoNC40LjE5KURpc2NvdmVyeSB0eXBl IC0gaW5kaWNhdGVzIGhvdyB0aGUgdHJhbnNwb3J0IGFkZHJlc3Mgb2YNDQog ICAgICAgICAgICAgICAgICAgIHRoZSBBQyB3YXMgb2J0YWluZWQsIHdpdGgg dmFsdWVzOg0NCiAgICAgICAgICAgICAgICAgICAgMCAtIEJyb2FkY2FzdA0N CiAgICAgICAgICAgICAgICAgICAgMSAtIENvbmZpZ3VyZWQNDQogICAgMikg KDQuNC4zNClXVFAgRGVzY3JpcHRvciAtIGluZGljYXRlcyBiYXNpYyBpbmZv IGFib3V0IGEgV1RQLg0NCiAgICAgICAgICAgICAgICAgICAgVmFsdWUgaGFz IHN1YmZpZWxkczoNDQogICAgICAgICAgICAgICAgICAgIERJU0NVU1M6IHRo aXMgaXMgd2F5IHRvbyBtdWNoIGluZm8uDQ0KICAgICAgICAgICAgICAgICAg ICAgICAgTmVlZCBvbmx5IDEpIHZlbmRvciBJRCwgMikgV1RQIG1vZGVsLA0N CiAgICAgICAgICAgICAgICAgICAgICAgIDMpIG1heWJlIFdUUCBzZXJpYWwg bnVtYmVyLCA0KSBtYXliZQ0NCiAgICAgICAgICAgICAgICAgICAgICAgIFdU UCBzb2Z0d2FyZSB2ZXJzaW9uLCBhbmQgNSkgbWF5YmUNDQogICAgICAgICAg ICAgICAgICAgICAgICBXVFAgYm9vdCBsb2FkZXIgdmVyc2lvbg0NCiAgICAg ICAgICAgICAgICAgICAgYSkgbWF4IHN1cHBvcnRlZCByYWRpb3MNDQogICAg ICAgICAgICAgICAgICAgIGIpIG51bWJlciBvZiByYWRpb3MgcHJlc2VudA0N CiAgICAgICAgICAgICAgICAgICAgYykgV1RQIHRvIEFDIGVuY3J5cHRpb24g Y2FwYWJpbGl0aWVzIChESVNDVVNTOg0NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICBub3Qgc3VyZSB0aGlzIGlzIHdlbGwgc3BlY2lmaWVkKQ0NCiAg ICAgICAgICAgICAgICAgICAgZCkgdmVuZG9yIGlkZW50aWZpZXINDQogICAg ICAgICAgICAgICAgICAgIGUpIFdUUCBtb2RlbA0NCiAgICAgICAgICAgICAg ICAgICAgZikgV1RQIHNlcmlhbCBudW1iZXINDQogICAgICAgICAgICAgICAg ICAgIGcpIFdUUCBtYWluIGNpcmN1aXQgYm9hcmQgaWRlbnRpZmllcg0NCiAg ICAgICAgICAgICAgICAgICAgaCkgV1RQIG1haW4gY2lyY3VpdCBib2FyZCBy ZXZpc2lvbg0NCiAgICAgICAgICAgICAgICAgICAgaSkgV1RQIGhhcmR3YXJl IHZlcnNpb24gKERJU0NVU1M6IHRoaXMgc2hvdWxkIGJlDQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGEgc3RyaW5nIGFuZCBub3QgYSBudW1iZXIp DQ0KICAgICAgICAgICAgICAgICAgICBqKSBXVFAgc29mdHdhcmUgdmVyc2lv biAoRElTQ1VTUzogdGhpcyBzaG91bGQgYmUNDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgYSBzdHJpbmcgYW5kIG5vdCBhIG51bWJlcikNDQogICAg ICAgICAgICAgICAgICAgIGspIFdUUCBib290IGxvYWRlciB2ZXJzaW9uIChE SVNDVVNTOiB0aGlzIHNob3VsZCBiZQ0NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICBhIHN0cmluZyBhbmQgbm90IGEgbnVtYmVyKQ0NCiAgICBESVND VVNTOiBkb24ndCBuZWVkIHRoaXMgaW5mbyBoZXJlLiBOZWVkIGl0IGF0IGpv aW4gdGltZSENDQogICAgMykgKDQuNC4zNilXVFAgRnJhbWUgRW5jYXBzdWxh dGlvbiB0eXBlIC0gdXNlciB0cmFmZmljIGJyaWRnaW5nDQ0KICAgICAgICAg ICAgICAgICAgICBhbmQgZW5jYXBzdWxhdGlvbiB0eXBlLiBUaGUgdmFsdWVz IGFyZToNDQogICAgICAgICAgICAgICAgICAgIDEgLSBMb2NhbCBCcmlkZ2lu ZzogIExvY2FsIEJyaWRnaW5nIGFsbG93cyB0aGUgV1RQIHRvDQ0KICAgICAg ICAgICAgICAgICAgICAgICAgcGVyZm9ybSB0aGUgYnJpZGdpbmcgZnVuY3Rp b24uICBUaGlzIHZhbHVlIE1VU1QgTk9UDQ0KICAgICAgICAgICAgICAgICAg ICAgICAgYmUgdXNlZCB3aGVuIHRoZSBXVFAgTUFDIFR5cGUgaXMgc2V0IHRv IFNwbGl0LU1BQy4NDQogICAgICAgICAgICAgICAgICAgIDIgLSA4MDIuMyBC cmlkZ2luZzogIDgwMi4zIEJyaWRnaW5nIHJlcXVpcmVzIHRoZSBXVFANDQog ICAgICAgICAgICAgICAgICAgICAgICBhbmQgQUMgdG8gZW5jYXBzdWxhdGUg YWxsIHVzZXIgcGF5bG9hZCBhcyBuYXRpdmUNDQogICAgICAgICAgICAgICAg ICAgICAgICBJRUVFIDgwMi4zIGZyYW1lcy4gVGhpcyB2YWx1ZSBNVVNUIE5P VCBiZSB1c2VkDQ0KICAgICAgICAgICAgICAgICAgICAgICAgd2hlbiB0aGUg V1RQIE1BQyBUeXBlIGlzIHNldCB0byBTcGxpdC1NQUMuDQ0KICAgICAgICAg ICAgICAgICAgICA0IC0gTmF0aXZlIEJyaWRnaW5nOiAgTmF0aXZlIEJyaWRn aW5nIHJlcXVpcmVzIHRoZQ0NCiAgICAgICAgICAgICAgICAgICAgICAgIFdU UCBhbmQgQUMgdG8gZW5jYXBzdWxhdGUgYWxsIHVzZXIgcGF5bG9hZHMgYXMN DQogICAgICAgICAgICAgICAgICAgICAgICBuYXRpdmUgd2lyZWxlc3MgZnJh bWVzLCBhcyBkZWZpbmVkIGJ5IHRoZSB3aXJlbGVzcw0NCiAgICAgICAgICAg ICAgICAgICAgICAgIGJpbmRpbmcuDQ0KICAgICAgICAgICAgICAgICAgICA3 IC0gQWxsOiAgVGhlIFdUUCBpcyBjYXBhYmxlIG9mIHN1cHBvcnRpbmcgYWxs IGZyYW1lDQ0KICAgICAgICAgICAgICAgICAgICAgICAgZW5jYXBzdWxhdGlv biB0eXBlcy4NDQogICAgICAgICAgICAgICAgICAgIERJU0NVU1M6IGlzIHRo aXMgYSBiaXQgc3RyaW5nIG9mIGNhcGFiaWxpdGllcywgb3INDQogICAgICAg ICAgICAgICAgICAgICAgICBhbiBlbnVtPw0NCiAgICA0KSAoNC40LjM4KVdU UCBNQUMgVHlwZSAtIHRoZSBzdXBwb3J0ZWQgTUFDIHR5cGVzLiBUaGUgdmFs dWVzIGFyZToNDQogICAgICAgICAgICAgICAgICAgIDAgLSBMb2NhbC1NQUM6 ICBMb2NhbC1NQUMgaXMgdGhlIGRlZmF1bHQgbW9kZSB0aGF0DQ0KICAgICAg ICAgICAgICAgICAgICAgICAgTVVTVCBiZSBzdXBwb3J0ZWQgYnkgYWxsIFdU UHMuDQ0KICAgICAgICAgICAgICAgICAgICAxIC0gU3BsaXQtTUFDOiAgU3Bs aXQtTUFDIHN1cHBvcnQgaXMgb3B0aW9uYWwsIGFuZA0NCiAgICAgICAgICAg ICAgICAgICAgICAgIGFsbG93cyB0aGUgQUMgdG8gcmVjZWl2ZSBhbmQgcHJv Y2VzcyBuYXRpdmUNDQogICAgICAgICAgICAgICAgICAgICAgICB3aXJlbGVz cyBmcmFtZXMuDQ0KICAgICAgICAgICAgICAgICAgICAyIC0gQm90aDogIFdU UCBpcyBjYXBhYmxlIG9mIHN1cHBvcnRpbmcgYm90aCBMb2NhbC1NQUMNDQog ICAgICAgICAgICAgICAgICAgICAgICBhbmQgU3BsaXQtTUFDLg0NCiAgICAg ICAgICAgICAgICAgICAgRElTQ1VTUzogaXMgdGhpcyBhIGJpdCBzdHJpbmcg b2YgY2FwYWJpbGl0aWVzLCBvcg0NCiAgICAgICAgICAgICAgICAgICAgICAg IGFuIEVOVU0/DQ0KICAgIDUpIChNKSg0LjQuMzkpV1RQIFJhZGlvIEluZm9y bWF0aW9uIC0gb25lIGZvciBlYWNoIGluc3RhbGxlZCByYWRpbw0NCiAgICAg ICAgICAgICAgICAgICAgaW4gdGhlIFdUUCwgdGhlIHZhbHVlIGhhcyBzdWJm aWVsZHM6DQ0KICAgICAgICAgICAgICAgICAgICBhKSByYWRpbyBJRA0NCiAg ICAgICAgICAgICAgICAgICAgYikgUmFkaW8gdHlwZSwgYSBiaXQgZmllbGQg d2l0aCB2YWx1ZXM6DQ0KICAgICAgICAgICAgICAgICAgICAgICAgMSAtIDgw Mi4xMWINDQogICAgICAgICAgICAgICAgICAgICAgICAyIC0gODAyLjExYQ0N CiAgICAgICAgICAgICAgICAgICAgICAgIDQgLSA4MDIuMTFnDQ0KICAgICAg ICAgICAgICAgICAgICAgICAgOCAtIDgwMi4xMW4NDQoNDQooNS4yKURpc2Nv dmVyeSBSZXNwb25zZSgyKSAobm8gc3RhdGUpIChBQy0+V1RQKQ0NCiAgRGVz Y3I6IHVzZWQgYnkgYW4gQUMgdG8gcmVzcG9uZCB0byBhIFdUUCAiZGlzY292 ZXIiIHJlcXVlc3QNDQogICAgICAgICAoRElTQ1VTUzogdGhpcyBpcyBicm9r ZW4uIFRoZSBBQyBTSE9VTEQgTk9UIGJlIHByb3ZpZGluZw0NCiAgICAgICAg ICAgICAgICAgICAgYW55IGluZm8gdG8gYSBXVFAgKG9yIHNvbWV0aGluZyB0 aGF0IGNsYWltcw0NCiAgICAgICAgICAgICAgICAgICAgdG8gYmUgYSBXVFAp LiBBbHNvLCB0aGUgQUMgc2hvdWxkIHRlbGwgdGhlDQ0KICAgICAgICAgICAg ICAgICAgICBXVFAgd2hhdCB0byBkbyBuZXh0LCB3aXRoIGNob2ljZXM6IDEp IE9rIHRvDQ0KICAgICAgICAgICAgICAgICAgICB0cnkgdG8gam9pbiwgMikg ZG9uJ3QgdHJ5IHRvIGpvaW4sIDMpIHRyeQ0NCiAgICAgICAgICAgICAgICAg ICAgZGlzY292ZXIgb24gYSBsaXN0IG9mIHJldHVybmVkIEFDcykNDQogIE1l c3NhZ2UgZWxlbWVudHM6DQ0KICAgIDEpICg0LjQuMSlBQyBEZXNjcmlwdG9y IC0gaW5kaWNhdGVzIGJhc2ljIGluZm8gYWJvdXQgYW4gQUMuDQ0KICAgICAg ICAgICAgICAgICAgICBESVNDVVNTOiB0aGlzIHNob3VsZCBORVZFUiBiZSBy ZXR1cm5lZA0NCiAgICAgICAgICAgICAgICAgICAgVGhlIHZhbHVlIGhhcyBz dWJmaWVsZHM6DQ0KICAgICAgICAgICAgICAgICAgICBhKSBoYXJkd2FyZSB2 ZXJzaW9uDQ0KICAgICAgICAgICAgICAgICAgICBiKSBzb2Z0d2FyZSB2ZXJz aW9uDQ0KICAgICAgICAgICAgICAgICAgICBjKSB0aGUgbnVtYmVyIG9mIFNU QXMgY3VycmVudGx5IGFzc29jaWF0ZWQgd2l0aA0NCiAgICAgICAgICAgICAg ICAgICAgICAgIGFsbCBXVFAgY29ubmVjdGVkIHRvIHRoZSBBQw0NCiAgICAg ICAgICAgICAgICAgICAgZCkgdGhlIG1heCBudW1iZXIgb2YgU1RBIGFzc29j aWF0aW9ucw0NCiAgICAgICAgICAgICAgICAgICAgICAgIHN1cHBvcnRlZCBi eSB0aGUgQUMNDQogICAgICAgICAgICAgICAgICAgIGUpIHRoZSBudW1iZXIg b2YgV1RQcyBjdXJyZW50bHkgY29ubmVjdGVkDQ0KICAgICAgICAgICAgICAg ICAgICAgICAgdG8gdGhlIEFDDQ0KICAgICAgICAgICAgICAgICAgICBmKSB0 aGUgbWF4IG51bWJlciBvZiBXVFAgY29ubmVjdGlvbnMNDQogICAgICAgICAg ICAgICAgICAgICAgICBzdXBwb3J0ZWQgYnkgdGhlIEFDDQ0KICAgICAgICAg ICAgICAgICAgICBnKSBhIGJpdCBtYXAgb2Ygc2VjdXJpdHkgc2NoZW1lcw0N CiAgICAgICAgICAgICAgICAgICAgICAgIGZvciBXVFAgYXV0aGVudGljYXRp b24gc3VwcG9ydGVkDQ0KICAgICAgICAgICAgICAgICAgICAgICAgYnkgdGhl IEFDLCB0aGUgdmFsdWVzIGFyZToNDQogICAgICAgICAgICAgICAgICAgICAg ICAxIC0gWC41MDkgQ2VydGlmaWNhdGUgQmFzZWQNDQogICAgICAgICAgICAg ICAgICAgICAgICAyIC0gUHJlLVNoYXJlZCBTZWNyZXQNDQogICAgMikgKDQu NC40KUFDIG5hbWUgLSBhIHZhbHVlIGluIHRleHQgZm9ybWF0IG9mIHRoZSBB QydzIG5hbWUNDQogICAgICAgICAgICAgICAgICAgIChESVNDVVNTOiBpcyB0 aGlzIGp1c3QgdGV4dCwgb2YgYSBGUUROPykNDQogICAgMykgKE0pKDQuNC40 MClBQyBJUHY0IGFkZHIgY29udHJvbCBpbnRlcmZhY2UgYW5kIFdUUCBjb3Vu dCAtIG9uZQ0NCiAgICAgICAgICAgICAgICAgICAgZm9yIGVhY2ggY29udHJv bCBpbnRlcmZhY2Ugb24gdGhlIEFDIHRoYXQgaGFzDQ0KICAgICAgICAgICAg ICAgICAgICBhbiBJUHY0IGFkZHJlc3MuIFRoZSB2YWx1ZSBoYXMgc3ViZmll bGRzOg0NCiAgICAgICAgICAgICAgICAgICAgYSkgSVB2NCBhZGRyZXNzIG9m IHRoZSBpbnRlcmZhY2UNDQogICAgICAgICAgICAgICAgICAgIGIpIGN1cnJl bnQgbnVtYmVyIG9mIFdUUHMgY29ubmVjdGVkDQ0KICAgICAgICAgICAgICAg ICAgICAgICAgb24gdGhlIGNvbnRyb2wgaW50ZXJmYWNlDQ0KICAgIDQpIChN KSg0LjQuNDEpQUMgSVB2NiBhZGRyIGNvbnRyb2wgaW50ZXJmYWNlIGFuZCBX VFAgY291bnQtIG9uZQ0NCiAgICAgICAgICAgICAgICAgICAgZm9yIGVhY2gg Y29udHJvbCBpbnRlcmZhY2Ugb24gdGhlIEFDIHRoYXQgaGFzDQ0KICAgICAg ICAgICAgICAgICAgICBhbiBJUHY2IGFkZHJlc3MuIFRoZSB2YWx1ZSBoYXMg c3ViZmllbGRzOg0NCiAgICAgICAgICAgICAgICAgICAgYSkgSVB2NiBhZGRy ZXNzIG9mIHRoZSBpbnRlcmZhY2UNDQogICAgICAgICAgICAgICAgICAgIGIp IGN1cnJlbnQgbnVtYmVyIG9mIFdUUHMgY29ubmVjdGVkDQ0KICAgICAgICAg ICAgICAgICAgICAgICAgb24gdGhlIGNvbnRyb2wgaW50ZXJmYWNlDQ0KDQ0K KDUuMylQcmltYXJ5IERpc2NvdmVyeSBSZXF1ZXN0KDE5KSAtIERJU0NVU1M6 IFJlbW92ZSBiZWNhdXNlIGl0IGlzDQ0KICAgICAgICAgbm90IGFwcHJvcHJp YXRlIGZvciB0aGlzIHZlcnNpb24gb2YgQ0FQV0FQDQ0KDQ0KKDUuNClQcmlt YXJ5IERpc2NvdmVyeSBSZXNwb25zZSgyMCkgLSBESVNDVVNTOiBSZW1vdmUg YmVjYXVzZSBpdCBpcw0NCiAgICAgICAgIG5vdCBhcHByb3ByaWF0ZSBmb3Ig dGhpcyB2ZXJzaW9uIG9mIENBUFdBUA0NCg0NCig2LjEpSm9pbiBSZXF1ZXN0 KDMpIChKb2luIHN0YXRlKSAoV1RQLT5BQykNDQogIERlc2NyOiBBZnRlciBh IFdUUCBoYXMgcmVjZWl2ZWQgb25lIG9yIG1vcmUgcG9zaXRpdmUgRGlzY292 ZXJ5DQ0KICAgICAgICAgUmVzcG9uc2VzLCB0aGUgV1RQIG9wZW5zIGEgRFRM UyBzZXNzaW9uIGFuZCBzZW5kcyBhDQ0KICAgICAgICAgSm9pbiBSZXF1ZXN0 IHRvIHRoZSBzZWxlY3RlZCBBQyB0byBlc3RhYmxpc2ggYSBjb250cm9sDQ0K ICAgICAgICAgY2hhbm5lbC4NDQogIE1lc3NhZ2UgZWxlbWVudHM6DQ0KICAg IDEpICg0LjQuMjYpV1RQIExvY2F0aW9uIC0gYSB0ZXh0IHN0cmluZyBzcGVj aWZ5aW5nIHRoZSBsb2NhdGlvbg0NCiAgICAgICAgICAgICAgICAgICAgb2Yg dGhlIFdUUCAoRElTQ1VTUzogdGhpcyBhICJzY3JhdGNoIHBhZCIsDQ0KICAg ICAgICAgICAgICAgICAgICBhbmQgdGhlIGRlZmluaXRpb24gc2hvdWxkIHNh eSBzbykNDQogICAgMikgKDQuNC4zMClTZXNzaW9uIElEIC0gYSByYW5kb20g MzItYml0IHVuc2lnbmVkIGludGVnZXINDQogICAgICAgICAgICAgICAgICAg IChESVNDVVNTOiBub3Qgc3VyZSB0aGlzIGlzIG5lZWRlZCwgc2luY2UNDQog ICAgICAgICAgICAgICAgICAgIGl0IGlzIG5vdCB1c2VkIGVsc2V3aGVyZSkN DQogICAgMykgKDQuNC4zNClXVFAgRGVzY3JpcHRvciAtIGluZGljYXRlcyBi YXNpYyBpbmZvIGFib3V0IGEgV1RQLg0NCiAgICAgICAgICAgICAgICAgICAg VmFsdWUgaGFzIHN1YmZpZWxkczoNDQogICAgICAgICAgICAgICAgICAgIERJ U0NVU1M6IGFmdGVyIHRoZSBEVExTIHNlc3Npb24gaXMgdXAsDQ0KICAgICAg ICAgICAgICAgICAgICAgICAgdGhlbiBPSyB0byBwcm92aWRlIGFsbCBvZiB0 aGlzIGluZm8NDQogICAgICAgICAgICAgICAgICAgIGEpIG1heCBzdXBwb3J0 ZWQgcmFkaW9zDQ0KICAgICAgICAgICAgICAgICAgICBiKSBudW1iZXIgb2Yg cmFkaW9zIHByZXNlbnQNDQogICAgICAgICAgICAgICAgICAgIGMpIFdUUCB0 byBBQyBlbmNyeXB0aW9uIGNhcGFiaWxpdGllcyAoRElTQ1VTUzoNDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgbm90IHN1cmUgdGhpcyBpcyB3ZWxs IHNwZWNpZmllZCkNDQogICAgICAgICAgICAgICAgICAgIGQpIHZlbmRvciBp ZGVudGlmaWVyDQ0KICAgICAgICAgICAgICAgICAgICBlKSBXVFAgbW9kZWwN DQogICAgICAgICAgICAgICAgICAgIGYpIFdUUCBzZXJpYWwgbnVtYmVyDQ0K ICAgICAgICAgICAgICAgICAgICBnKSBXVFAgbWFpbiBjaXJjdWl0IGJvYXJk IGlkZW50aWZpZXINDQogICAgICAgICAgICAgICAgICAgIGgpIFdUUCBtYWlu IGNpcmN1aXQgYm9hcmQgcmV2aXNpb24NDQogICAgICAgICAgICAgICAgICAg IGkpIFdUUCBoYXJkd2FyZSB2ZXJzaW9uIChESVNDVVNTOiB0aGlzIHNob3Vs ZCBiZQ0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBhIHN0cmluZyBh bmQgbm90IGEgbnVtYmVyKQ0NCiAgICAgICAgICAgICAgICAgICAgaikgV1RQ IHNvZnR3YXJlIHZlcnNpb24gKERJU0NVU1M6IHRoaXMgc2hvdWxkIGJlDQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGEgc3RyaW5nIGFuZCBub3Qg YSBudW1iZXIpDQ0KICAgICAgICAgICAgICAgICAgICBrKSBXVFAgYm9vdCBs b2FkZXIgdmVyc2lvbiAoRElTQ1VTUzogdGhpcyBzaG91bGQgYmUNDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgYSBzdHJpbmcgYW5kIG5vdCBhIG51 bWJlcikNDQogICAgICAgICAgICAgICAgICAgIERJU0NVU1M6IG5lZWQgdG8g c2VuZCAiY29tbW9uIG5hbWUiIGFzIGZvdW5kDQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGluIHRoZSBXVFAgQ0VSVCBzbyB0aGF0IHRoZSBBQw0N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICBjYW4gdmVyaWZ5DQ0KICAg IDQpICg0LjQuMzcpV1RQIElQdjQgQWRkciAtIHRoZSBJUHY0IGFkZHJlc3Mg b2YgdGhlIFdUUCAodXNlZA0NCiAgICAgICAgICAgICAgICAgICAgdG8gZGV0 ZXJtaW5lIGlmIGdvaW5nIHRocm91Z2ggYSBOQVQpDQ0KICAgIDUpICg0LjQu NDIpV1RQIE5hbWUgLSBhIHZhbHVlIGluIHRleHQgZm9ybWF0IG9mIHRoZSBX VFAncyBuYW1lDQ0KICAgICAgICAgICAgICAgICAgICAoRElTQ1VTUzogaXMg dGhpcyBqdXN0IGFyYml0cmFyeSB0ZXh0LCBvciBhIEZRRE4/KQ0NCiAgICA2 KSAoTSkoNC40LjM5KVdUUCBSYWRpbyBJbmZvcm1hdGlvbiAtIG9uZSBmb3Ig ZWFjaCBpbnN0YWxsZWQgcmFkaW8NDQogICAgICAgICAgICAgICAgICAgIGlu IHRoZSBXVFAsIHRoZSB2YWx1ZSBoYXMgc3ViZmllbGRzOg0NCiAgICAgICAg ICAgICAgICAgICAgYSkgcmFkaW8gSUQNDQogICAgICAgICAgICAgICAgICAg IGIpIFJhZGlvIHR5cGUsIGEgYml0IGZpZWxkIHdpdGggdmFsdWVzOg0NCiAg ICAgICAgICAgICAgICAgICAgICAgIDEgLSA4MDIuMTFiDQ0KICAgICAgICAg ICAgICAgICAgICAgICAgMiAtIDgwMi4xMWENDQogICAgICAgICAgICAgICAg ICAgICAgICA0IC0gODAyLjExZw0NCiAgICAgICAgICAgICAgICAgICAgICAg IDggLSA4MDIuMTFuDQ0KDQ0KKDYuMilKb2luIFJlc3BvbnNlKDQpIChKb2lu IHN0YXRlKSAoQUMtPldUUCkNDQogIERlc2NyOiBBZnRlciBhbiBBQyBoYXMg cmVjZWl2ZWQgYSBKb2luIFJlcXVlc3QgbWVzc2FnZSwgaXQNDQogICAgICAg ICByZXNwb25kcyB3aXRoIGEgSm9pbiBSZXNwb25zZSBtZXNzYWdlLg0NCiAg TWVzc2FnZSBlbGVtZW50czoNDQogICAgMSkgKDQuNC4yOSlSZXN1bHQgY29k ZSAtIGluZGljYXRlcyBpZiB0aGUgQUMgYWNjZXB0ZWQgb3INDQogICAgICAg ICAgICAgICAgICAgIGZhaWxlZCB0aGUgam9pbiByZXF1ZXN0LiBUaGUgdmFs dWVzIGFyZToNDQogICAgICAgICAgICAgICAgICAgIDAgLSBTdWNjZXNzDQ0K ICAgICAgICAgICAgICAgICAgICAxIC0gRmFpbHVyZSAoQUMgTGlzdCBtZXNz YWdlIGVsZW1lbnQNDQogICAgICAgICAgICAgICAgICAgICAgICBNVVNUIGJl IHByZXNlbnQpIChESVNDVVNTOiB0aGlzIHNlZW1zIGJvZ3VzKQ0NCiAgICAg ICAgICAgICAgICAgICAgMiAtIFN1Y2Nlc3MgKE5BVCBkZXRlY3RlZCkNDQog ICAgICAgICAgICAgICAgICAgIDMgLSBGYWlsdXJlICh1bnNwZWNpZmllZCkN DQogICAgICAgICAgICAgICAgICAgIDQgLSBGYWlsdXJlIChKb2luIEZhaWx1 cmUsIFJlc291cmNlIERlcGxldGlvbikNDQogICAgICAgICAgICAgICAgICAg IDUgLSBGYWlsdXJlIChKb2luIEZhaWx1cmUsIFVua25vd24gU291cmNlKQ0N CiAgICAgICAgICAgICAgICAgICAgNiAtIEZhaWx1cmUgKEpvaW4gRmFpbHVy ZSwgSW5jb3JyZWN0IERhdGEpDQ0KICAgICAgICAgICAgICAgICAgICA3IC0g RmFpbHVyZSAoSm9pbiBGYWlsdXJlLCBTZXNzaW9uIElEIGFscmVhZHkNDQog ICAgICAgICAgICAgICAgICAgICAgICBpbiB1c2UpDQ0KICAgICAgICAgICAg ICAgICAgICBESVNDVVNTOiB0aGVyZSBhcmUgb3RoZXIgY2FzZXMgbGlrZQ0N CiAgICAgICAgICAgICAgICAgICAgICAgICAgIm5vdCBzdXBwb3J0ZWQgV1RQ IGhhcmR3YXJlIg0NCiAgICAyKSAoNC40LjIpQUMgSVB2NCBhZGRyIGxpc3Qg LSBhIGxpc3Qgb2YgQUNzDQ0KICAgICAgICAgICAgICAgICAgICAoRElTQ1VT UzogdGhlIGRlc2NyaXB0aW9uIHNheXMgdGhlc2UNDQogICAgICAgICAgICAg ICAgICAgIGFyZSAiQUNzIGluIGEgY2x1c3RlciIuIEhvd2V2ZXIsDQ0KICAg ICAgICAgICAgICAgICAgICBtdWx0aS1BQyBpcyBub3QgZGVmaW5lZCwgbm9y IGlzDQ0KICAgICAgICAgICAgICAgICAgICAiY2x1c3RlciIuIFRoZSBzZW1h bnRpY3MgYXJlIG5vdA0NCiAgICAgICAgICAgICAgICAgICAgd2VsbCBkZWZp bmVkIGhlcmUuIERvZXMgdGhpcyBsaXN0DQ0KICAgICAgICAgICAgICAgICAg ICBpbmNsdWRlIHRoZSBBQyB0aGF0IGFuc3dlcmVkPw0NCiAgICAgICAgICAg ICAgICAgICAgSXMgdGhpcyBwcmVzZW50IGlmIHRoZSBsaXN0IGlzDQ0KICAg ICAgICAgICAgICAgICAgICBlbXB0eT8pIFRoZSBsaXN0IGlzIGFuIGFycmF5 IG9mDQ0KICAgICAgICAgICAgICAgICAgICBJUHY0IGFkZHJlc3Nlcy4NDQog ICAgMykgKDQuNC4zKUFDIElQdjYgbGlzdCAtIGEgbGlzdCBvZiBBQ3MNDQog ICAgICAgICAgICAgICAgICAgIChESVNDVVNTOiBzYW1lIGFzICM0IGFib3Zl LCBwbHVzLA0NCiAgICAgICAgICAgICAgICAgICAgaG93IGFyZSBJUHY0IGFu ZCBJUHY2IGFkZHJlc3Nlcw0NCiAgICAgICAgICAgICAgICAgICAgcHJpb3Jp dGl6ZWQ/KSBUaGUgbGlzdCBpcyBhbiBhcnJheQ0NCiAgICAgICAgICAgICAg ICAgICAgb2YgSVB2NiBhZGRyZXNzZXMuDQ0KICAgIDQpICg0LjQuMzApU2Vz c2lvbiBJRCAtIGFuIHJhbmRvbSAzMi1iaXQgdW5zaWduZWQgaW50ZWdlcg0N CiAgICAgICAgICAgICAgICAgICAgKERJU0NVU1M6IHRoaXMgZG9lc24ndCBz ZWVtIHRvIGJlIG5lZWRlZD8NDQogICAgICAgICAgICAgICAgICAgIElmIGl0 IGlzLCBpcyB0aGUgdmFsdWUgdGhlIHNhbWUgYXMNDQogICAgICAgICAgICAg ICAgICAgIHZhbHVlIGluIHRoZSByZXF1ZXN0PykNDQoNDQooNy4xKUVjaG8g UmVxdWVzdCgxMykgKGFueSBub3JtYWwgc3RhdGUpIChBQy0+V1RQIGFuZCBX VFAtPkFDKQ0NCiAgRGVzY3I6IGEga2VlcCBhbGl2ZSBtZWNoYW5pc20gZm9y IENBUFdBUCBjb250cm9sIG1lc3NhZ2VzDQ0KICAgICAgICAoRElTQ1VTUzog V2h5IGlzIHRoaXMgY2FsbGVkICJlY2hvIiwgd2hlbiBubyBkYXRhDQ0KICAg ICAgICAgICAgICAgICAgICBpcyBzZW50IGFuZCByZXR1cm5lZD8gSG93IGFi b3V0ICJoZWFydGJlYXQiLA0NCiAgICAgICAgICAgICAgICAgICAgb3IgImtl ZXAtYWxpdmUiPw0NCiAgTWVzc2FnZSBlbGVtZW50czogLS1ub25lLS0NDQoN DQooNy4yKUVjaG8gUmVzcG9uc2UoMTQpIChhbnkgbm9ybWFsIHN0YXRlKSAo V1RQLT5BQyBhbmQgQUMtPldUUCkNDQogIERlc2NyOiBBIHJlc3BvbnNlIHRv IGFuIEVjaG8gUmVxdWVzdA0NCiAgTWVzc2FnZSBlbGVtZW50czogLS1ub25l LS0NDQoNDQooOC4yKUNvbmZpZ3VyYXRpb24gU3RhdHVzIFJlcG9ydCg1KSAo Y29uZmlndXJlIHN0YXRlKSAoV1RQLT5BQykNDQogIERlc2NyOiBBZnRlciB0 aGUgIkpvaW4iIHN0YXRlLCBhIFdUUCBlbnRlcnMgdGhlICJDb25maWd1cmUi DQ0KICAgICAgICAgc3RhdGUgYW5kIHNlbmRzIHRoZSBBQyB0aGUgdmFsdWVz IG9mIGNvbmZpZ3VyYXRpb24NDQogICAgICAgICBhdHRyaWJ1dGVzIHRoYXQg YXJlIG5vdCB0aGUgZGVmYXVsdCB2YWx1ZXMuDQ0KICAgICAgICAgKERJU0NV U1M6IHRoaXMgaGFzIHNldmVyYWwgcHJvYmxlbXMuIEZpcnN0LCB0aGUNDQog ICAgICAgICBDQVBXQVAgc3BlYyBkb2VzIG5vdCBzcGVjaWZ5IHdoYXQgaXMg dGhlIENBUFdBUA0NCiAgICAgICAgIGRlZmF1bHQgdmFsdWVzLiBTZWNvbmRs eSwgd2hhdCBpZiB0aGUgdmFsdWVzDQ0KICAgICAgICAgZG9uJ3QgZml0IGlu IG9uZSBtZXNzYWdlPyBGaW5hbGx5LCB3aGF0IGlzIHRoZQ0NCiAgICAgICAg IEFDIHN1cHBvc2UgdG8gZG8gaWYgaXQgcmVjZWl2ZXMgYSBjb25maWd1cmF0 aW9uDQ0KICAgICAgICAgbWVzc2FnZSBlbGVtZW50IHRoYXQgaXQgZG9lc24n dCBrbm93IHdoYXQgdG8NDQogICAgICAgICBkbyB3aXRoLCBzdWNoIGFzIGEg V1RQIGNvbmZvcm1pbmcgdG8gYSBtb3JlIHJlY2VudA0NCiAgICAgICAgIHZl cnNpb24gb2YgQ0FQV0FQIHdoZXJlIG5ldyBjb25maWcgbWVzc2FnZSBlbGVt ZW50cw0NCiAgICAgICAgIGhhdmUgYmVlbiBhZGRlZCwgb3IgdGhlIFdUUCBy ZXR1cm5zIHZlbmRvciBzcGVjaWZpYw0NCiAgICAgICAgIG1lc3NhZ2UgZWxl bWVudHMgdGhhdCB0aGUgQUMgZG9lc24ndCB1bmRlcnN0YW5kPykNDQogIE1l c3NhZ2UgZWxlbWVudHM6DQ0KICAgIDEpICg0LjQuNClBQyBOYW1lIC0gYSB2 YWx1ZSBpbiB0ZXh0IGZvcm1hdCBvZiB0aGUgQUMncyBuYW1lDQ0KICAgICAg ICAgICAgICAgICAgICAoRElTQ1VTUzogaXMgdGhpcyBqdXN0IHRleHQsIG9m IGEgRlFETj8pDQ0KICAgIDIpIChNKSg0LjQuNSlBQyBOYW1lIHdpdGggaW5k ZXggLSBhbiBpbmRleCAoYW4gQUMgcHJlZmVyZW5jZSkNDQogICAgICAgICAg ICAgICAgICAgIGFuZCBBQyBuYW1lIGluIHRleHQgZm9ybWF0IGZvciBlYWNo IGNvbmZpZ3VyZWQNDQogICAgICAgICAgICAgICAgICAgIEFDLiAoRElTQ1VT UzogdGhpcyBpcyBtZXNzZWQgdXAuIEhvdyBhcmUgQUMNDQogICAgICAgICAg ICAgICAgICAgIGFkZHJlc3NlcyBhbmQgbmFtZXMgcGFpcmVkLiBBbHNvLCB0 aGlzIGlzDQ0KICAgICAgICAgICAgICAgICAgICBtdWx0aS1BQywgd2hpY2gg aXMgbm90IHdlbGwgZGVmaW5lZC4pDQ0KICAgICAgICAgICAgICAgICAgICBU aGUgdmFsdWUgaGFzIHN1YmZpZWxkczoNDQogICAgICAgICAgICAgICAgICAg IGEpIGluZGV4DQ0KICAgICAgICAgICAgICAgICAgICBiKSBBQyBuYW1lDQ0K ICAgIDMpIChNKSg0LjQuMjgpUmFkaW8gQWRtaW5pc3RyYXRpdmUgU3RhdGUg LSBmb3IgZWFjaCByYWRpby4NDQogICAgICAgICAgICAgICAgICAgIFRoZSB2 YWx1ZSBoYXMgc3ViZmllbGRzOg0NCiAgICAgICAgICAgICAgICAgICAgYSkg cmFkaW8gSUQNDQogICAgICAgICAgICAgICAgICAgIGIpIGFkbWluIHN0YXRl LCB3aGljaCBoYXMgdmFsdWVzOg0NCiAgICAgICAgICAgICAgICAgICAgICAg IDEgLSBlbmFibGVkDQ0KICAgICAgICAgICAgICAgICAgICAgICAgMiAtIGRp c2FibGVkDQ0KICAgIDQpICg0LjQuMzEpU3RhdGlzdGljcyBUaW1lciAtIHRo ZSB2YWx1ZSBvZiB0aGUgc3RhdGlzdGljcw0NCiAgICAgICAgICAgICAgICAg ICAgdGltZXIgKHdob3NlIHZhbHVlIHNwZWNpZmllcyB0aGUgbGVuZ3RoIG9m DQ0KICAgICAgICAgICAgICAgICAgICBzdGF0aXN0aWNzIHJlcG9ydGluZyBw ZXJpb2QpIGluIHVuaXRzIG9mDQ0KICAgICAgICAgICAgICAgICAgICBzZWNv bmRzDQ0KICAgIDUpIChNKSg0LjQuMzMpV1RQIEJvYXJkIERhdGEgLSAoRElT Q1VTUzogdGhpcyBzaG91bGQgYmUNDQogICAgICAgICAgICAgICAgICAgIHBh cnQgb2YgdGhlIEpvaW4gUmVxdWVzdCwgc2luY2UgaXQgaXMNDQogICAgICAg ICAgICAgICAgICAgIGNhcGFiaWxpdHkgYW5kIG5vdCBjb25maWd1cmF0aW9u LikNDQogICAgICAgICAgICAgICAgICAgIGluZm9ybWF0aW9uIGFib3V0IGVh Y2ggYm9hcmQgKG90aGVyIHRoYW4gdGhlDQ0KICAgICAgICAgICAgICAgICAg ICBtYWluIGJvYXJkKS4gVGhlIHN1YmZpZWxkcyBhcmU6DQ0KICAgICAgICAg ICAgICAgICAgICBhKSB2ZW5kb3IgSUQgLSBhbiBJQU5BIGFzc2lnbmVkIGVu dGVycHJpc2UgSUQNDQogICAgICAgICAgICAgICAgICAgIGIpIGEgbGlzdCBv ZiBpbmZvLCB3aXRoIHN1YmZpZWxkczoNDQogICAgICAgICAgICAgICAgICAg ICAgICAxKSB0eXBlLCB3aXRoIHZhbHVlOg0NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAwIC0gV1RQIE1vZGVsIChyZXF1aXJlZCkNDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgMSAtIFdUUCBTZXJpYWwgbnVtYmVyIChy ZXF1aXJlZCkNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgMiAtIFdU UCBCb2FyZCBJZCAoYSBoYXJkd2FyZSBpZGVudGlmaWVyKSAob3B0aW9uYWwp DQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDMgLSBXVFAgQm9hcmQg cmV2aXNpb24NDQogICAgICAgICAgICAgICAgICAgICAgICAyKSBsZW5ndGgg b2YgdmFsdWUNDQogICAgICAgICAgICAgICAgICAgICAgICAzKSB2YWx1ZSAo RElTQ1VTUzogdGhpcyBzaG91bGQgYmUgaW4gdGV4dA0NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgZm9ybWF0LCBidXQgQ0FQV0FQIGRvZXNu J3Qgc2F5KQ0NCiAgICA2KSAoNC40LjQ0KVdUUCBTdGF0aWMgSVB2NCBhZGRy ZXNzIGluZm8gLSB0aGUgdmFsdWUgaGFzIHN1YmZpZWxkczoNDQogICAgICAg ICAgICAgICAgICAgIGEpIElQdjQgYWRkcmVzcw0NCiAgICAgICAgICAgICAg ICAgICAgYikgSVB2NCBuZXRtYXNrDQ0KICAgICAgICAgICAgICAgICAgICBj KSBJUHY0IGRlZmF1bHQgcm91dGVyDQ0KICAgICAgICAgICAgICAgICAgICBk KSBhY3Rpb24vc3RhdHVzIGZpZWxkIChESVNDVVNTOiB0aGlzIGlzIHNpbGx5 Lg0NCiAgICAgICAgICAgICAgICAgICAgICAgIEl0IGlzIHVzZWQgdG8gY2xl YXIgYSBzdGF0aWMgdmFsdWUuDQ0KICAgICAgICAgICAgICAgICAgICAgICAg SnVzdCBzZXQgdGhlIElQdjQgYWRkciB0byAwLjAuMC4wLCB0byBjbGVhcikN DQogICAgNykgKDQuNC40MylXVFAgUmVib290IFN0YXRpc3RpY3MgLSBhIGxp c3Qgb2YgY291bnRlcnMNDQogICAgICAgICAgICAgICAgICAgIGZvciBlYWNo IGNhdXNlIG9mIFdUUCByZWJvb3QuIChESVNDVVNTOg0NCiAgICAgICAgICAg ICAgICAgICAgdGhpcyBpcyBqdXN0IHNpbGx5ISBJdCBpcyBub3QgY29uZmln dXJhdGlvbg0NCiAgICAgICAgICAgICAgICAgICAgaW5mbywgYW5kIGl0IHNo b3VsZCByZWFsbHkgYmUgcGFydCBvZg0NCiAgICAgICAgICAgICAgICAgICAg YSBKb2luIFJlcXVlc3Qgb3BlcmF0aW9uLiBBbHNvLCB0aGUNDQogICAgICAg ICAgICAgICAgICAgIGNvdW50ZXJzIHNob3VsZCBiZSBsaXN0ZWQgYW5kIGRl c2NyaWJlZA0NCiAgICAgICAgICAgICAgICAgICAgaW4gc2VjdGlvbiA0LjYh KSBUaGUgY291bnRlcnMgdmFsdWVzDQ0KICAgICAgICAgICAgICAgICAgICBh cmUgdWludDE2LCB3aXRoIHRoZSB2YWx1ZSAweGZmZmYgbWVhbmluZw0NCiAg ICAgICAgICAgICAgICAgICAgIm5vdCBhdmFpbGFibGUiLiBUaGUgc3ViZmll bGRzIGFyZToNDQogICAgICAgICAgICAgICAgICAgIGEpIENyYXNoIGNvdW50 IC0gbnVtYmVyIG9mIHJlYm9vdHMgZHVlDQ0KICAgICAgICAgICAgICAgICAg ICAgICAgdG8gV1RQIGNyYXNoIChESVNDVVNTIC0gbWF5YmUgc3BsaXQNDQog ICAgICAgICAgICAgICAgICAgICAgICB0aGlzIHRvIGRpZmZlcmVudCB0eXBl cyBvZiBjcmFzaGVzKQ0NCiAgICAgICAgICAgICAgICAgICAgYikgQUMgaW5p dGlhdGVkIGNvdW50IC0gbnVtYmVyIG9mIHRpbWVzDQ0KICAgICAgICAgICAg ICAgICAgICAgICAgV1RQIGhhZCB0byByZWJvb3QgZHVlIHRvIGNoYW5nZSBp bg0NCiAgICAgICAgICAgICAgICAgICAgICAgIGNvbmZpZyBvciBleHBsaWNp dCByZWJvb3QgcmVxdWVzdA0NCiAgICAgICAgICAgICAgICAgICAgICAgIChE SVNDVVNTOiBzZXBhcmF0ZSBjb3VudGVycyB3b3VsZCBiZQ0NCiAgICAgICAg ICAgICAgICAgICAgICAgIG11Y2ggYmV0dGVyLiBUaGVzZSBhcmUgYSkgSW1h Z2UgZG93bmxvYWQsDQ0KICAgICAgICAgICAgICAgICAgICAgICAgYikgaW1h Z2UgY2hhbmdlLCBjKSBleHBsaWNpdCByZWJvb3QsDQ0KICAgICAgICAgICAg ICAgICAgICAgICAgZCkgY29uZmlnIGNoYW5nZShkb24ndCBrbm93IGFib3V0 IHRoaXMpKQ0NCiAgICAgICAgICAgICAgICAgICAgYykgU2Vzc2lvbiBmYWls dXJlIGNvdW50IC0gdGhlIG51bWJlciBvZg0NCiAgICAgICAgICAgICAgICAg ICAgICAgIHRpbWVzIHRoZSBEVExTIHNlc3Npb24gYmV0d2VlbiB0aGUNDQog ICAgICAgICAgICAgICAgICAgICAgICBXVFAgYW5kIEFDIGZhaWxlZCBhbmQg dGhlIFdUUCByZXN0YXJ0ZWQNDQogICAgICAgICAgICAgICAgICAgICAgICBp dCAoRElTQ1VTUzogZG9lcyB0aGlzIGltcGx5IHRoZSBXVFANDQogICAgICAg ICAgICAgICAgICAgICAgICBhbHNvIHJlYm9vdGVkPykNDQogICAgICAgICAg ICAgICAgICAgIGQpIENhdXNlIG9mIGxhc3QgV1RQIHJlYm9vdCwgd2l0aCB2 YWx1ZXM6DQ0KICAgICAgICAgICAgICAgICAgICAgICAgMCAtIFNlc3Npb24g RmFpbHVyZQ0NCiAgICAgICAgICAgICAgICAgICAgICAgIDEgLSBBQw0NCiAg ICAgICAgICAgICAgICAgICAgICAgIDIgLSBXVFAgQ3Jhc2gNDQogICAgICAg ICAgICAgICAgICAgICAgICAyNTUgLSBub3Qgc3VwcG9ydGVkIChvciBjb3Vs ZCBub3QNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJlIGRl dGVybWluZWQpDQ0KICAgIDgpIChNKSAoMTEuMTAuMilJRUVFIDgwMi4xMSBB bnRlbm5hKHNlZSAxMS45LjMpIC0gdGhlIGNvbmZpZ3VyYXRpb24NDQogICAg ICAgICAgICAgICAgICAgIG9mIHRoZSBhbnRlbm5hcyBmb3IgZWFjaCByYWRp byBvZiB0aGUgV1RQLiBUaGUgdmFsdWUNDQogICAgICAgICAgICAgICAgICAg IGhhcyBzdWJmaWVsZHM6DQ0KICAgICAgICAgICAgICAgICAgICBhKSByYWRp byBJRA0NCiAgICAgICAgICAgICAgICAgICAgYikgZGl2ZXJzaXR5IC0gaW5k aWNhdGVzIGlmIHRoZSBhbnRlbm5hIGlzIHRvDQ0KICAgICAgICAgICAgICAg ICAgICAgICAgcHJvdmlkZSByZWNlaXZlIGRpdmVyc2l0eS4gVGhlIHZhbHVl cyBhcmU6DQ0KICAgICAgICAgICAgICAgICAgICAgICAgMCAtIERpc2FibGVk DQ0KICAgICAgICAgICAgICAgICAgICAgICAgMSAtIEVuYWJsZWQNDQogICAg ICAgICAgICAgICAgICAgIGMpIGNvbWJpbmVyIC0gdGhlIGNvbWJpbmVyIHNl bGVjdGlvbi4gVGhlIHZhbHVlcyBhcmU6DQ0KICAgICAgICAgICAgICAgICAg ICAgICAgMSAtIFNlY3Rvcml6ZWQgKExlZnQpDQ0KICAgICAgICAgICAgICAg ICAgICAgICAgMiAtIFNlY3Rvcml6ZWQgKFJpZ2h0KQ0NCiAgICAgICAgICAg ICAgICAgICAgICAgIDMgLSBPbW5pDQ0KICAgICAgICAgICAgICAgICAgICAg ICAgNCAtIE1JTU8NDQogICAgICAgICAgICAgICAgICAgIGQpIGFudGVubmEg Y291bnQgLSBudW1iZXIgaWYgYW50ZW5uYSBzZWxlY3Rpb24gZmllbGRzDQ0K ICAgICAgICAgICAgICAgICAgICBlKSBhbnRlbm5hIHNlbGVjdGlvbiAtIGFu IGFycmF5IG9mIHNlbGVjdGlvbiwgd2l0aA0NCiAgICAgICAgICAgICAgICAg ICAgICAgIGVhY2ggaGF2ZSB2YWx1ZSBmcm9tOg0NCiAgICAgICAgICAgICAg ICAgICAgICAgIDEgLSBJbnRlcm5hbCBBbnRlbm5hDQ0KICAgICAgICAgICAg ICAgICAgICAgICAgMiAtIEV4dGVybmFsIEFudGVubmENDQogICAgOSkgKE0p ICgxMS4xMC42KUlFRUUgODAyLjExIERpcmVjdCBTZXF1ZW5jZSBDb250cm9s KHNlZSAxMS45LjMpIC0gdGhlDQ0KICAgICAgICAgICAgICAgICAgICB2YWx1 ZSBoYXMgc3ViZmllbGRzOg0NCiAgICAgICAgICAgICAgICAgICAgYSkgcmFk aW8gSUQNDQogICAgICAgICAgICAgICAgICAgIGIpIHJlc2VydmVkICg4IGJp dHMpDQ0KICAgICAgICAgICAgICAgICAgICBjKSBjdXJyZW50IGNoYW5uZWwg LSB0aGUgY3VycmVudCBvcGVyYXRpbmcgZnJlcQ0NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICBvZiB0aGUgRFNTUyBQSFkNDQogICAgICAgICAgICAg ICAgICAgIGQpIGN1cnJlbnQgQ0NBIC0gdGhlIHZhbHVlcyBhcmU6DQ0KICAg ICAgICAgICAgICAgICAgICAgICAgMSAtIGVuZXJneSBkZXRlY3Qgb25seSAo ZWRvbmx5KQ0NCiAgICAgICAgICAgICAgICAgICAgICAgIDIgLSBjYXJyaWVy IHNlbnNlIG9ubHkgKGNzb25seSkNDQogICAgICAgICAgICAgICAgICAgICAg ICA0IC0gY2FycmllciBzZW5zZSBhbmQgZW5lcmd5IGRldGVjdCAoZWRhbmRj cykNDQogICAgICAgICAgICAgICAgICAgICAgICA4IC0gY2FycmllciBzZW5z ZSB3aXRoIHRpbWVyIChjc3dpdGh0aW1lcikNDQogICAgICAgICAgICAgICAg ICAgICAgICAxNiAtIGhpZ2ggcmF0ZSBjYXJyaWVyIHNlbnNlIGFuZCBlbmVy Z3kNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRldGVjdCAo aHJjc2FuZGVkKQ0NCiAgICAgICAgICAgICAgICAgICAgZSkgRW5lcmd5IGRl dGVjdCB0aHJlc2hvbGQgKERJU0NVU1M6IHdoYXQNDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGFyZSB0aGUgdW5pdHMgYW5kIHJhbmdlPykN DQogICAgMTApIChNKSAoMTEuMTAuOClJRUVFIDgwMi4xMSBNQUMgT3BlcmF0 aW9uKHNlZSAxMS45LjMpIC0gdGhlIHZhbHVlDQ0KICAgICAgICAgICAgICAg ICAgICBoYXMgc3ViZmllbGRzOg0NCiAgICAgICAgICAgICAgICAgICAgYSkg cmFkaW8gSUQNDQogICAgICAgICAgICAgICAgICAgIGIpIHJlc2VydmVkDQ0K ICAgICAgICAgICAgICAgICAgICBjKSBSVFMgdGhyZXNob2xkIC0gY291bnQg b2Ygb2N0ZXRzDQ0KICAgICAgICAgICAgICAgICAgICBkKSBzaG9ydCByZXRy eSAtIHRoZSBtYXggbnVtYmVyIG9mIHR4IGF0dGVtcHRzDQ0KICAgICAgICAg ICAgICAgICAgICBlKSBsb25nIHJldHJ5IC0gdGhlIG1heCBudW1iZXIgb2Yg dHggYXR0ZW1wdHMNDQogICAgICAgICAgICAgICAgICAgIGYpIGZyYWdtZW50 YXRpb24gdGhyZXNob2xkIC0gY291bnQgb2Ygb2N0ZXRzDQ0KICAgICAgICAg ICAgICAgICAgICBnKSBUeCBNU0RVIGxpZmV0aW1lIC0gZWxhcHNlZCB0aW1l IGluIFRVcw0NCiAgICAgICAgICAgICAgICAgICAgaCkgUnggTVNEVSBsaWZl dGltZSAtIGVsYXBzZWQgdGltZSBpbiBUVXMNDQogICAgMTEpIChNKSAoMTEu MTAuMTMpSUVFRSA4MDIuMTEgTXVsdGktZG9tYWluIENhcGFiaWxpdHkoc2Vl IDExLjkuMykgLSB0aGUNDQogICAgICAgICAgICAgICAgICAgIHZhbHVlIGhh cyBzdWJmaWVsZHM6DQ0KICAgICAgICAgICAgICAgICAgICBhKSByYWRpbyBJ RA0NCiAgICAgICAgICAgICAgICAgICAgYikgcmVzZXJ2ZWQgKDggYml0cykN DQogICAgICAgICAgICAgICAgICAgIGMpIGZpcnN0IGNoYW5uZWwgbnVtYmVy DQ0KICAgICAgICAgICAgICAgICAgICBkKSBudW1iZXIgb2YgY2hhbm5lbHMN DQogICAgICAgICAgICAgICAgICAgIGUpIG1heCBUeCBwb3dlciBsZXZlbCAt IGluIHVuaXRzIG9mIGRCbQ0NCiAgICAxMikgKE0pICgxMS4xMC4xNClJRUVF IDgwMi4xMSBPRkRNIENvbnRyb2wgLSBmaW5pc2ggKHNlZSAxMS45LjMpIC0g dGhlDQ0KICAgICAgICAgICAgICAgICAgICB2YWx1ZSBoYXMgc3ViZmllbGRz Og0NCiAgICAgICAgICAgICAgICAgICAgYSkgcmFkaW8gSUQNDQogICAgICAg ICAgICAgICAgICAgIGIpIHJlc2VydmVkICg4IGJpdHMpDQ0KICAgICAgICAg ICAgICAgICAgICBjKSBjdXJyZW50IGNoYW5uZWwgLSBvcGVyYXRpbmcgZnJl cXVlbmN5IG9mIE9GRE0gUEhZDQ0KICAgICAgICAgICAgICAgICAgICBkKSBi YW5kcyBzdXBwb3J0ZWQgLSBhIGJpdCBmaWVsZCAoRElTQ1VTUzogdGhlcmUN DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgaXMgbWlzc2luZyBpbmZv IGhlcmUgLSB0eXBvPykNDQogICAgICAgICAgICAgICAgICAgIGUpIFRJIHRo cmVzaG9sZCAtIChESVNDVVNTOiBuZWVkIHVuaXRzKQ0NCiAgICAxMykgKE0p ICgxMS4xMC4xNylJRUVFIDgwMi4xMSBTdXBwb3J0ZWQgUmF0ZXMoc2VlIDEx LjkuMykgLSB0aGUgdmFsdWUNDQogICAgICAgICAgICAgICAgICAgIGhhcyBz dWJmaWVsZHM6DQ0KICAgICAgICAgICAgICAgICAgICBhKSByYWRpbyBJRA0N CiAgICAgICAgICAgICAgICAgICAgYikgbGlzdCBvZiBzdXBwb3J0ZWQgcmF0 ZXMgKERJU0NVU1M6IHdoYXQgaXMgdGhlIGZvcm1hdD8pDQ0KICAgIDE0KSAo TSkgKDExLjEwLjE4KUlFRUUgODAyLjExIFR4IFBvd2VyKHNlZSAxMS45LjMp IC0gdGhlIHZhbHVlIA0NCiAgICAgICAgICAgICAgICAgICAgaGFzIHN1YmZp ZWxkczoNDQogICAgICAgICAgICAgICAgICAgIGEpIHJhZGlvIElEDQ0KICAg ICAgICAgICAgICAgICAgICBiKSByZXNlcnZlZCAoOCBiaXRzKQ0NCiAgICAg ICAgICAgICAgICAgICAgYykgQ3VycmVudCBUeCBQb3dlciAtIGluIHVuaXRz IG9mIG1XDQ0KICAgIDE1KSAoTSkgKDExLjEwLjE5KUlFRUUgODAyLjExIFR4 IFBvd2VyIExldmVsKHNlZSAxMS45LjMpIC0gYSBsaXN0IG9mDQ0KICAgICAg ICAgICAgICAgICAgICBzdXBwb3J0ZWQgcG93ZXIgbGV2ZWxzLiBUaGUgdmFs dWUgaGFzIHN1YmZpZWxkczoNDQogICAgICAgICAgICAgICAgICAgIGEpIHJh ZGlvIElEDQ0KICAgICAgICAgICAgICAgICAgICBiKSBudW1iZXIgb2YgbGV2 ZWxzDQ0KICAgICAgICAgICAgICAgICAgICBjKSBhbiBhcnJheSBvZiBsZXZl bHMgLSBlYWNoIGVsZW1lbnQgaXMgYQ0NCiAgICAgICAgICAgICAgICAgICAg ICAgIHBvd2VyIGxldmVsIGluIG1XLg0NCiAgICAxNikgKE0pICgxMS4xMC4y NClJRUVFIDgwMi4xMSBXVFAgUmFkaW8gQ29uZmlndXJhdGlvbihzZWUgMTEu OS4zKSAtDQ0KICAgICAgICAgICAgICAgICAgICB0aGUgdmFsdWUgaGFzIHN1 YmZpZWxkczoNDQogICAgICAgICAgICAgICAgICAgIGEpIHJhZGlvIElEDQ0K ICAgICAgICAgICAgICAgICAgICBiKSByZXNlcnZlZCAoOCBiaXRzKQ0NCiAg ICAgICAgICAgICAgICAgICAgYykgbnVtYmVyIG9mIEJTU0lEcw0NCiAgICAg ICAgICAgICAgICAgICAgZCkgRFRJTSBwZXJpb2QgLSBpbiB1bml0cyBvZiBi ZWFjb24gaW50ZXJ2YWxzDQ0KICAgICAgICAgICAgICAgICAgICBlKSBCU1NJ RCAtIGJhc2UgQlNTSUQgKERJU0NVU1M6IHRoaXMgc2hvdWxkDQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBjb21lIGxhc3QgYW5kIGJlIGFu IGFycmF5IG9mDQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBC U1NJRCB2YWx1ZXMgb2YgbGVuZ3RoICJudW1iZXINDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIG9mIEJTU0lEcyIuIElmIGEgdmFsdWUgZm9y DQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhIEJTU0lEIG5l ZWRzIHRvIGJlIGFzc2lnbmVkLA0NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgdGhlbiB0aGUgQlNTSUQgdmFsdWUgc2hvdWxkIGJlDQ0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwMDowMDowMDowMDowMDow MCkNDQogICAgICAgICAgICAgICAgICAgIGYpIGJlYWNvbiBwZXJpb2QgLSBp biB1bml0cyBvZiBUVXMNDQogICAgICAgICAgICAgICAgICAgIGcpIGNvdW50 cnkgY29kZSAtIHR3byBjaGFyIGNvZGUgZnJvbSBJU08vSUVDIDMxNjYtMSwN DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZvbGxvd2VkIGJ5 IGNoYXJhY3RlcjoNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IChESVNDVVNTOiBJJ20gY29uZnVzZWQsIGlzIGl0IDEsIDIsIDMNDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDI1NSBvciAiICIsICJPIiwg IkkiLCAweDI1NSkNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICIgIiAgLSBhbGwgZW52aXJvbnMgb2YgY291bnRyeQ0NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIk8iIC0gb3V0ZG9vciByZWd1bGF0aW9u cw0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIkkiIC0gaW5k b29yIHJlZ3VsYXRpb25zDQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAweDI1NSAtIG5vdCB1c2VkDQ0KICAgIERJU0NVU1M6IHRoZXJlIHNl ZW1zIGxpa2UgYW4gYXdmdWwgbG90IG9mIGFkZGl0aW9uYWwNDQogICAgICAg IGNvbmZpZ3VyYXRpb24gbWVzc2FnZSBlbGVtZW50cyB0aGF0IG5lZWQgdG8N DQogICAgICAgIGJlIHNwZWNpZmllZCBoZXJlIQ0NCg0NCig4LjMpQ29uZmln dXJlIFN0YXR1cyBBY2soNikgKGNvbmZpZ3VyZSBzdGF0ZSkgKEFDLT5XVFAp DQ0KICBEZXNjcjogVGhpcyB0aGUgcmVzcG9uc2UgYnkgdGhlIEFDIHRvIGEg V1RQIHRvDQ0KICAgICAgICAgc3BlY2lmeSByZXF1aXJlZCBjb25maWd1cmF0 aW9uIGluZm9ybWF0aW9uDQ0KICAgICAgICAgYW5kIHRvIG9wdGlvbmFsbHkg c3BlY2lmeSBjaGFuZ2VzIHRvIHRoZQ0NCiAgICAgICAgIGNvbmZpZ3VyYXRp b24gcHJlc2VudGx5IG9uIHRoZSBXVFANDQogICAgICAgICAoRElTQ1VTUzog VGhpcyBpcyBqdXN0IEJST0tFTiBiZWNhdXNlIGFueSBjb25maWd1cmF0aW9u DQ0KICAgICAgICAgIGNoYW5nZSBvcGVyYXRpb24gbWF5IGZhaWwgYW5kIHRo ZXJlIGlzIG5vDQ0KICAgICAgICAgIHJlc3BvbnNlIHRvIHRoZSBjb25maWd1 cmF0aW9uIGNoYW5nZXMNDQogICAgICAgICAgc3BlY2lmaWVkIGluIHRoaXMg Y29tbWFuZC4gQWxzbywgYWxsIHRoZQ0NCiAgICAgICAgICBjb25maWd1cmF0 aW9uIHZhbHVlcyBtYXkgbm90IGZpdCBpbiB0d28gcGFja2V0cy4NDQogICAg ICAgICAgVGhpcyBvcGVyYXRpb24gTkVFRFMgVE8gQkUgQ0hBTkdFRCBzbyB0 aGF0DQ0KICAgICAgICAgIGl0IGp1c3QgQUNLcyBjb25maWd1cmF0aW9uIHJl cG9ydHMgZnJvbQ0NCiAgICAgICAgICB0aGUgV1RQLiBBbiBBQyBjYW4gdGhl biB1c2UgIkNvbmZpZ3VyYXRpb24NDQogICAgICAgICAgVXBkYXRlIiByZXF1 ZXN0IHRvIGNoYW5nZSB0aGUgY29uZmlndXJhdGlvbg0NCiAgICAgICAgICBv biB0aGUgV1RQLCBhbmQgdGhlbiB3aGVuIGZpbmlzaGVkLCB1c2UNDQogICAg ICAgICAgYSBuZXcgIlN0YXJ0IE9wZXJhdGlvbiIgcmVxdWVzdCB0byBwdXQN DQogICAgICAgICAgdGhlIFdUUCBpbiB0aGUgUlVOIHN0YXRlLikNDQogICAg ICAgICAoRElTQ1VTUzogd2h5IGFyZSB0aGUgbWVzc2FnZSBlbGVtZW50cyAo b3RoZXIgdGhhdA0NCiAgICAgICAgICB0aGUgY2FwYWJpbGl0eSBvbmVzKSB0 aGUgc2FtZSBhcyBpbiB0aGUgcmVxdWVzdD8pDQ0KICBNZXNzYWdlIGVsZW1l bnRzOg0NCiAgICAxKSAoNC40LjIpQUMgSVB2NCBhZGRyIGxpc3QgLSBhIGxp c3Qgb2YgQUNzLiBUaGUgbGlzdCBpcyBhbg0NCiAgICAgICAgICAgICAgICAg ICAgYXJyYXkgb2YgSVB2NCBhZGRyZXNzZXMuDQ0KICAgIDIpICg0LjQuMylB QyBJUHY2IGFkZHIgbGlzdCAtIGEgbGlzdCBvZiBBQ3MuIFRoZSBsaXN0IGlz IGFuDQ0KICAgICAgICAgICAgICAgICAgICBhcnJheSBvZiBJUHY2IGFkZHJl c3Nlcy4NDQogICAgMykgKDQuNC4xMClDQVBXQVAgVGltZXJzIC0gdGhlIHZh bHVlIGhhcyBzdWJmaWVsZHM6DQ0KICAgICAgICAgICAgICAgICAgICBhKSBE aXNjb3ZlcnlJbnRlcnZhbCAoNC41LjEpDQ0KICAgICAgICAgICAgICAgICAg ICBiKSBFY2hvSW50ZXJ2YWwgKDQuNS40KQ0NCiAgICA0KSAoTSkoNC40LjEx KUNoYW5nZSBTdGF0ZSBFdmVudCAtIChESVNDVVNTOiB0aGlzIHNlZW1zIGlu YXBwcm9wcmlhdGUuDQ0KICAgICAgICAgICAgICAgICAgICBUaGUgKDQuNC4y OClSYWRpbyBBZG1pbiBTdGF0ZSBtZXNzYWdlIGVsZW1lbnQNDQogICAgICAg ICAgICAgICAgICAgIHNob3VsZCBiZSB1c2VkIGluc3RlYWQuKQ0NCiAgICAg ICAgICAgICAgICAgICAgVGhlIHZhbHVlIGhhcyBzdWJmaWVsZHM6DQ0KICAg ICAgICAgICAgICAgICAgICBhKSByYWRpbyBJRA0NCiAgICAgICAgICAgICAg ICAgICAgYikgc3RhdGUgKG9uIG9yIG9mZikNDQogICAgICAgICAgICAgICAg ICAgIGMpIGNhdXNlLCB3aXRoIHZhbHVlczoNDQogICAgICAgICAgICAgICAg ICAgICAgICAwIC0gbm9ybWFsDQ0KICAgICAgICAgICAgICAgICAgICAgICAg MSAtIHJhZGlvIGZhaWx1cmUNDQogICAgICAgICAgICAgICAgICAgICAgICAy IC0gc29mdHdhcmUgZmFpbHVyZQ0NCiAgICA1KSAoTSkgKDQuNC4xNSlEZWNy eXB0aW9uIEVycm9yIFJlcG9ydCBQZXJpb2QgLSB0aGUgdmFsdWUNDQogICAg ICAgICAgICAgICAgICAgIGhhcyBzdWJmaWVsZHM6DQ0KICAgICAgICAgICAg ICAgICAgICBhKSByYWRpbyBJRA0NCiAgICAgICAgICAgICAgICAgICAgYikg cmVwb3J0IGludGVydmFsIC0gdGhlIHRpbWUgaW4gc2Vjb25kcw0NCiAgICAg ICAgICAgICAgICAgICAgICAgIGZvciB0aGUgZnJlcXVlbmN5IG9mIHNlbmRp bmcNDQogICAgICAgICAgICAgICAgICAgICAgICBkZWNyeXB0aW9uIGVycm9y IHJlcG9ydCBtZXNzYWdlcw0NCiAgICAgICAgICAgICAgICAgICAgKERJU0NV U1M6IHNob3VsZG4ndCB0aGlzIHRpbWVyIGJlDQ0KICAgICAgICAgICAgICAg ICAgICBkZXNjcmliZWQgaW4gc2VjdGlvbiA0LjUgb3INDQogICAgICAgICAg ICAgICAgICAgIHNlY3Rpb24gMTE/KQ0NCiAgICA2KSAoNC40LjIyKUlkbGUg VGltZW91dCAtIHRoZSB0aW1lb3V0IHBlcmlvZCBmb3IgU1RBcw0NCiAgICAg ICAgICAgICAgICAgICAgY29ubmVjdGVkIHRvIGFueSByYWRpbyAoRElTQ1VT UzogZG9lcw0NCiAgICAgICAgICAgICAgICAgICAgaXQgbWFrZSBzZW5zZSB0 byBoYXZlIGEgc2luZ2xlIHZhbHVlDQ0KICAgICAgICAgICAgICAgICAgICBm b3IgYWxsIHJhZGlvcywgb3IgYSBkZWZhdWx0IHRoYXQNDQogICAgICAgICAg ICAgICAgICAgIGNhbiBiZSBvdmVycmlkZGVuIHBlciByYWRpbykgKERJU0NV U1M6DQ0KICAgICAgICAgICAgICAgICAgICB0aGlzIG5lZWRzIHRvIGJlIHNw ZWNpZmllZCBpbiBzZWN0aW9uDQ0KICAgICAgICAgICAgICAgICAgICA0LjUp DQ0KICAgIDcpICg0LjQuMzUpV1RQIEZhbGxiYWNrIC0gSWYgVFJVRSwgdGhl biBpZiBhIFdUUCBkZXRlY3RzDQ0KICAgICAgICAgICAgICAgICAgICBpdHMg cHJlZmVycmVkIEFDIChhbmQgaXQgaXMgbm90IGNvbm5lY3RlZA0NCiAgICAg ICAgICAgICAgICAgICAgdG8gaXQpIHRoZW4gdGhlIFdUUCBkaXNjb25uZWN0 cyBmcm9tIHRoZQ0NCiAgICAgICAgICAgICAgICAgICAgY3VycmVudCBBQyBh bmQgYXR0ZW1wdHMgdG8gcmVjb25uZWN0IHRvDQ0KICAgICAgICAgICAgICAg ICAgICB0aGUgcHJlZmVycmVkIEFDLiAoRElTQ1VTUzogdGhlIHNlbWFudGlj cw0NCiAgICAgICAgICAgICAgICAgICAgYXJlIG5vdCB3ZWxsIHNwZWNpZmll ZC4gVGhpcyBzaG91bGQgYmUNDQogICAgICAgICAgICAgICAgICAgIHJlbW92 ZWQuKQ0NCiAgICA4KSAoTSkgKDExLjEwLjIpSUVFRSA4MDIuMTEgQW50ZW5u YShzZWUgMTEuOS4zKSAtIHRoZSBjb25maWd1cmF0aW9uDQ0KICAgICAgICAg ICAgICAgICAgICBvZiB0aGUgYW50ZW5uYXMgZm9yIGVhY2ggcmFkaW8gb2Yg dGhlIFdUUC4gVGhlIHZhbHVlDQ0KICAgICAgICAgICAgICAgICAgICBzdWJm aWVsZHM6DQ0KICAgICAgICAgICAgICAgICAgICBhKSByYWRpbyBJRA0NCiAg ICAgICAgICAgICAgICAgICAgYikgZGl2ZXJzaXR5IC0gaW5kaWNhdGVzIGlm IHRoZSBhbnRlbm5hIGlzIHRvDQ0KICAgICAgICAgICAgICAgICAgICAgICAg cHJvdmlkZSByZWNlaXZlIGRpdmVyc2l0eS4gVGhlIHZhbHVlcyBhcmU6DQ0K ICAgICAgICAgICAgICAgICAgICAgICAgMCAtIERpc2FibGVkDQ0KICAgICAg ICAgICAgICAgICAgICAgICAgMSAtIEVuYWJsZWQNDQogICAgICAgICAgICAg ICAgICAgIGMpIGNvbWJpbmVyLCB3aXRoIHZhbHVlczoNDQogICAgICAgICAg ICAgICAgICAgICAgICAxIC0gU2VjdG9yaXplZCAoTGVmdCkNDQogICAgICAg ICAgICAgICAgICAgICAgICAyIC0gU2VjdG9yaXplZCAoUmlnaHQpDQ0KICAg ICAgICAgICAgICAgICAgICAgICAgMyAtIE9tbmkNDQogICAgICAgICAgICAg ICAgICAgICAgICA0IC0gTUlNTw0NCiAgICAgICAgICAgICAgICAgICAgZCkg YW50ZW5uYSBjb3VudCAoMC0yNTUpDQ0KICAgICAgICAgICAgICAgICAgICBl KSBhbnRlbm5hIHNlbGVjdGlvbiAtIGFuIGFycmF5IG9mIHNlbGVjdGlvbiwg d2l0aA0NCiAgICAgICAgICAgICAgICAgICAgICAgIGVhY2ggaGF2ZSB2YWx1 ZSBmcm9tOg0NCiAgICAgICAgICAgICAgICAgICAgICAgIDEgLSBJbnRlcm5h bCBBbnRlbm5hDQ0KICAgICAgICAgICAgICAgICAgICAgICAgMiAtIEV4dGVy bmFsIEFudGVubmENDQogICAgOSkgKE0pICgxMS4xMC40KUlFRUUgODAyLjEx IEJyb2FkY2FzdCBQcm9iZSBNb2RlKHNlZSAxMS45LjMpIC0gaW5kaWNhdGVz DQ0KICAgICAgICAgICAgICAgICAgICBpZiB0aGUgV1RQIHdpbGwgcmVzcG9u ZCB0byBicm9hZGNhc3QgTlVMTCBTU0lEDQ0KICAgICAgICAgICAgICAgICAg ICBwcm9iZSByZXF1ZXN0cywgd2l0aCB2YWx1ZXM6DQ0KICAgICAgICAgICAg ICAgICAgICAgICAgMCAtIG5vDQ0KICAgICAgICAgICAgICAgICAgICAgICAg MSAtIHllcw0NCiAgICAxMCkgKE0pICgxMS4xMC42KUlFRUUgODAyLjExIERp cmVjdCBTZXF1ZW5jZSBDb250cm9sKHNlZSAxMS45LjMpIC0gdGhlDQ0KICAg ICAgICAgICAgICAgICAgICB2YWx1ZSBoYXMgc3ViZmllbGRzOg0NCiAgICAg ICAgICAgICAgICAgICAgYSkgcmFkaW8gSUQNDQogICAgICAgICAgICAgICAg ICAgIGIpIHJlc2VydmVkICg4IGJpdHMpDQ0KICAgICAgICAgICAgICAgICAg ICBjKSBjdXJyZW50IGNoYW5uZWwgLSB0aGUgY3VycmVudCBvcGVyYXRpbmcg ZnJlcQ0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBvZiB0aGUgRFNT UyBQSFkNDQogICAgICAgICAgICAgICAgICAgIGQpIGN1cnJlbnQgQ0NBIC0g dGhlIHZhbHVlcyBhcmU6DQ0KICAgICAgICAgICAgICAgICAgICAgICAgMSAt IGVuZXJneSBkZXRlY3Qgb25seSAoZWRvbmx5KQ0NCiAgICAgICAgICAgICAg ICAgICAgICAgIDIgLSBjYXJyaWVyIHNlbnNlIG9ubHkgKGNzb25seSkNDQog ICAgICAgICAgICAgICAgICAgICAgICA0IC0gY2FycmllciBzZW5zZSBhbmQg ZW5lcmd5IGRldGVjdCAoZWRhbmRjcykNDQogICAgICAgICAgICAgICAgICAg ICAgICA4IC0gY2FycmllciBzZW5zZSB3aXRoIHRpbWVyIChjc3dpdGh0aW1l cikNDQogICAgICAgICAgICAgICAgICAgICAgICAxNiAtIGhpZ2ggcmF0ZSBj YXJyaWVyIHNlbnNlIGFuZCBlbmVyZ3kNDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGRldGVjdCAoaHJjc2FuZGVkKQ0NCiAgICAgICAgICAg ICAgICAgICAgZSkgRW5lcmd5IGRldGVjdCB0aHJlc2hvbGQgKERJU0NVU1M6 IHdoYXQNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFyZSB0 aGUgdW5pdHMgYW5kIHJhbmdlPykNDQogICAgMTEpIChNKSAoMTEuMTAuOClJ RUVFIDgwMi4xMSBNQUMgT3BlcmF0aW9uKHNlZSAxMS45LjMpIC0gdGhlIHZh bHVlDQ0KICAgICAgICAgICAgICAgICAgICBoYXMgc3ViZmllbGRzOg0NCiAg ICAgICAgICAgICAgICAgICAgYSkgcmFkaW8gSUQNDQogICAgICAgICAgICAg ICAgICAgIGIpIHJlc2VydmVkDQ0KICAgICAgICAgICAgICAgICAgICBjKSBS VFMgdGhyZXNob2xkIC0gY291bnQgb2Ygb2N0ZXRzDQ0KICAgICAgICAgICAg ICAgICAgICBkKSBzaG9ydCByZXRyeSAtIHRoZSBtYXggbnVtYmVyIG9mIHR4 IGF0dGVtcHRzDQ0KICAgICAgICAgICAgICAgICAgICBlKSBsb25nIHJldHJ5 IC0gdGhlIG1heCBudW1iZXIgb2YgdHggYXR0ZW1wdHMNDQogICAgICAgICAg ICAgICAgICAgIGYpIGZyYWdtZW50YXRpb24gdGhyZXNob2xkIC0gY291bnQg b2Ygb2N0ZXRzDQ0KICAgICAgICAgICAgICAgICAgICBnKSBUeCBNU0RVIGxp ZmV0aW1lIC0gZWxhcHNlZCB0aW1lIGluIFRVcw0NCiAgICAgICAgICAgICAg ICAgICAgaCkgUnggTVNEVSBsaWZldGltZSAtIGVsYXBzZWQgdGltZSBpbiBU VXMNDQogICAgMTIpIChNKSAoMTEuMTAuMTMpSUVFRSA4MDIuMTEgTXVsdGkt ZG9tYWluIENhcGFiaWxpdHkoc2VlIDExLjkuMykgLSB0aGUNDQogICAgICAg ICAgICAgICAgICAgIHZhbHVlIGhhcyBzdWJmaWVsZHM6DQ0KICAgICAgICAg ICAgICAgICAgICBhKSByYWRpbyBJRA0NCiAgICAgICAgICAgICAgICAgICAg YikgcmVzZXJ2ZWQgKDggYml0cykNDQogICAgICAgICAgICAgICAgICAgIGMp IGZpcnN0IGNoYW5uZWwgbnVtYmVyDQ0KICAgICAgICAgICAgICAgICAgICBk KSBudW1iZXIgb2YgY2hhbm5lbHMNDQogICAgICAgICAgICAgICAgICAgIGUp IG1heCBUeCBwb3dlciBsZXZlbCAtIGluIHVuaXRzIG9mIGRCbQ0NCiAgICAx MykgKE0pICgxMS4xMC4xNClJRUVFIDgwMi4xMSBPRkRNIENvbnRyb2woc2Vl IDExLjkuMykgdGhlIHZhbHVlDQ0KICAgICAgICAgICAgICAgICAgICBoYXMg c3ViZmllbGRzOg0NCiAgICAgICAgICAgICAgICAgICAgYSkgcmFkaW8gSUQN DQogICAgICAgICAgICAgICAgICAgIGIpIHJlc2VydmVkICg4IGJpdHMpDQ0K ICAgICAgICAgICAgICAgICAgICBjKSBjdXJyZW50IGNoYW5uZWwgLSBvcGVy YXRpbmcgZnJlcXVlbmN5IG9mIE9GRE0gUEhZDQ0KICAgICAgICAgICAgICAg ICAgICBkKSBiYW5kcyBzdXBwb3J0ZWQgLSBhIGJpdCBmaWVsZCAoRElTQ1VT UzogdGhlcmUNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgaXMgbWlz c2luZyBpbmZvIGhlcmUgLSB0eXBvPykNDQogICAgICAgICAgICAgICAgICAg IGUpIFRJIHRocmVzaG9sZCAtIChESVNDVVNTOiBuZWVkIHVuaXRzKQ0NCiAg ICAxNCkgKE0pICgxMS4xMC4xNSlJRUVFIDgwMi4xMSBSYXRlIFNldChzZWUg MTEuOS4zKSAtIChESVNDVVNTOiB0aGlzDQ0KICAgICAgICAgICAgICAgICAg ICBzZWVtcyB0byBiZSBhIG1pc3Rha2UgaW4gdGFibGUgZnJvbSAxMS45LjMp DQ0KICAgICAgICAgICAgICAgICAgICB0aGUgdmFsdWUgaGFzIHN1YmZpZWxk czoNDQogICAgICAgICAgICAgICAgICAgIGEpIHJhZGlvIElEDQ0KICAgICAg ICAgICAgICAgICAgICBiKSByYXRlcyBzZXQgLSAoRElTQ1VTUzogaG93IHRo aXMgaXMgZW5jb2RlZA0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBu ZWVkcyB0byBiZSBzcGVjaWZpZWQpDQ0KICAgIDE1KSAoTSkgKDExLjEwLjE3 KUlFRUUgODAyLjExIFN1cHBvcnRlZCBSYXRlcyhzZWUgMTEuOS4zKSAtIHRo ZSB2YWx1ZQ0NCiAgICAgICAgICAgICAgICAgICAgaGFzIHN1YmZpZWxkczoN DQogICAgICAgICAgICAgICAgICAgIGEpIHJhZGlvIElEDQ0KICAgICAgICAg ICAgICAgICAgICBiKSBsaXN0IG9mIHN1cHBvcnRlZCByYXRlcyAoRElTQ1VT Uzogd2hhdCBpcyB0aGUgZm9ybWF0PykNDQoNDQogICAgMTYpIChNKSAoMTEu MTAuMTgpSUVFRSA4MDIuMTEgVHggUG93ZXIoc2VlIDExLjkuMykgLSB0aGUg dmFsdWUNDQogICAgICAgICAgICAgICAgICAgIGhhcyBzdWJmaWVsZHM6DQ0K ICAgICAgICAgICAgICAgICAgICBhKSByYWRpbyBJRA0NCiAgICAgICAgICAg ICAgICAgICAgYikgcmVzZXJ2ZWQgKDggYml0cykNDQogICAgICAgICAgICAg ICAgICAgIGMpIEN1cnJlbnQgVHggUG93ZXIgLSBpbiB1bml0cyBvZiBtVw0N CiAgICAxNykgKE0pICgxMS4xMC4yMilJRUVFIDgwMi4xMSBXVFAgUXVhbGl0 eSBvZiBTZXJ2aWNlKHNlZSAxMS45LjMpIC0NDQogICAgICAgICAgICAgICAg ICAgIHRoZSB2YWx1ZSBoYXMgc3ViZmllbGRzOg0NCiAgICAgICAgICAgICAg ICAgICAgYSkgcmFkaW8gSUQNDQogICAgICAgICAgICAgICAgICAgIGIpIHRh ZyBwYWNrZXRzLCB3aXRoIHZhbHVlczoNDQogICAgICAgICAgICAgICAgICAg ICAgICAwIC0gVW50YWdnZWQNDQogICAgICAgICAgICAgICAgICAgICAgICAx IC0gODAyLjFQDQ0KICAgICAgICAgICAgICAgICAgICAgICAgMiAtIERTQ1AN DQogICAgICAgICAgICAgICAgICAgIGMpIGFycmF5KGluZGljZXMgb2Y6IFZv aWNlLCBWaWRlbywgQmVzdCBFZmZvcnQsDQ0KICAgICAgICAgICAgICAgICAg ICAgICBhbmQgQmFja2dyb3VuZCksIHdpdGggc3ViZmllbGRzOg0NCiAgICAg ICAgICAgICAgICAgICAgICAgMSkgcXVldWUgZGVwdGggLSBwYWNrZXRzDQ0K ICAgICAgICAgICAgICAgICAgICAgICAyKSBDV01pbiAtIG1pbiBzaXplIG9m IGNvbnRlbnRpb24gd2luZG93DQ0KICAgICAgICAgICAgICAgICAgICAgICAz KSBDV01heCAtIG1heCBzaXplIG9mIGNvbnRlbnRpb24gd2luZG93DQ0KICAg ICAgICAgICAgICAgICAgICAgICA0KSBBSUZTIC0gaW50ZXItZnJhbWUgc3Bh Y2luZyAoRElTQ1VTUzp1bml0cz8pDQ0KICAgICAgICAgICAgICAgICAgICAg ICA1KSBEb3QxUCB0YWcNDQogICAgICAgICAgICAgICAgICAgICAgIDYpIERT Q1AgdGFnDQ0KICAgIDE4KSAoTSkgKDExLjEwLjI0KUlFRUUgODAyLjExIFdU UCBSYWRpbyBDb25maWd1cmF0aW9uKHNlZSAxMS45LjMpIC0NDQogICAgICAg ICAgICAgICAgICAgIHRoZSB2YWx1ZSBoYXMgc3ViZmllbGRzOg0NCiAgICAg ICAgICAgICAgICAgICAgYSkgcmFkaW8gSUQNDQogICAgICAgICAgICAgICAg ICAgIGIpIHJlc2VydmVkICg4IGJpdHMpDQ0KICAgICAgICAgICAgICAgICAg ICBjKSBudW1iZXIgb2YgQlNTSURzDQ0KICAgICAgICAgICAgICAgICAgICBk KSBEVElNIHBlcmlvZCAtIGluIHVuaXRzIG9mIGJlYWNvbiBpbnRlcnZhbHMN DQogICAgICAgICAgICAgICAgICAgIGUpIEJTU0lEIC0gYmFzZSBCU1NJRCAo RElTQ1VTUzogdGhpcyBzaG91bGQNDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGNvbWUgbGFzdCBhbmQgYmUgYW4gYXJyYXkgb2YNDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJTU0lEIHZhbHVlcyBvZiBs ZW5ndGggIm51bWJlcg0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgb2YgQlNTSURzIi4gSWYgYSB2YWx1ZSBmb3INDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGEgQlNTSUQgbmVlZHMgdG8gYmUgYXNzaWdu ZWQsDQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGVuIHRo ZSBCU1NJRCB2YWx1ZSBzaG91bGQgYmUNDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDAwOjAwOjAwOjAwOjAwOjAwKQ0NCiAgICAgICAgICAg ICAgICAgICAgZikgYmVhY29uIHBlcmlvZCAtIGluIHVuaXRzIG9mIFRVcw0N CiAgICAgICAgICAgICAgICAgICAgZykgY291bnRyeSBjb2RlIC0gdHdvIGNo YXIgY29kZSBmcm9tIElTTy9JRUMgMzE2Ni0xLA0NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgZm9sbG93ZWQgYnkgY2hhcmFjdGVyOg0NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKERJU0NVU1M6IEknbSBj b25mdXNlZCwgaXMgaXQgMSwgMiwgMw0NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgMjU1IG9yICIgIiwgIk8iLCAiSSIsIDB4MjU1KQ0NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIiAiICAtIGFsbCBlbnZp cm9ucyBvZiBjb3VudHJ5DQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAiTyIgLSBvdXRkb29yIHJlZ3VsYXRpb25zDQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAiSSIgLSBpbmRvb3IgcmVndWxhdGlvbnMN DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDB4MjU1IC0gbm90 IHVzZWQpDQ0KDQ0KKDguNClDb25maWd1cmF0aW9uIFVwZGF0ZSBSZXF1ZXN0 KDcpIChjb25maWd1cmUgYW5kIHJ1biBzdGF0ZXMpIChBQy0+V1RQKQ0NCiAg RGVzY3I6IENvbmZpZ3VyZSBVcGRhdGUgUmVxdWVzdHMgYXJlIHVzZWQgYnkg YW4gQUMgdG8gY2hhbmdlIHRoZQ0NCiAgICAgICAgIGNvbmZpZ3VyYXRpb24g b2YgdGhlIFdUUC4gVGhpcyBjYW4gYmUgZG9uZSBpbiB0aGUgImNvbmZpZ3Vy ZSINDQogICAgICAgICBvciAicnVuIiBzdGF0ZXMuIE5vdGUgdGhhdCBpbiBh ZGRpdGlvbiB0byBzZW5kaW5nIGEgcmVzcG9uc2UsDQ0KICAgICAgICAgdGhl IFdUUCBtYXkgYWxzbyBzZW5kIGEgIkNoYW5nZSBTdGF0ZSBFdmVudCBSZXBv cnQiIGRlcGVuZGluZw0NCiAgICAgICAgIG9uIHRoZSBjb25maWd1cmF0aW9u IGF0dHJpYnV0ZSBjaGFuZ2VkLg0NCiAgTWVzc2FnZSBlbGVtZW50czoNDQog ICAgQW55IGNvbWJpbmF0aW9uIG9mIHRoZSBjb25maWd1cmF0aW9uIG1lc3Nh Z2UgZWxlbWVudHMNDQogICAgY2FuIGJlIHNwZWNpZmllZCBhcyBhIHBhcmFt ZXRlci4gKERJU0NVU1M6IHdoYXQgaWYgdGhlDQ0KICAgIHNhbWUgb25lIGlz IHNwZWNpZmllZCBtdWx0aXBsZSB0aW1lcyB3aXRoIGRpZmZlcmVudA0NCiAg ICB2YWx1ZXMuIERvZXMgdGhlIGxhc3Qgb25lIHdpbiwgb3IgaXMgaXQgYW4g ZXJyb3I/DQ0KICAgIEFsc28sIGFyZSBhbGwgb2YgdGhlIHZhbHVlcyBhcHBs aWVkLCBvciBub25lIGFwcGxpZWQNDQogICAgaWYgYW55IGVycm9yPykNDQog ICAgMSkgKDQuNC4yKUFDIElQdjQgTGlzdCAtIGEgbGlzdCBvZiBBQ3MuIFRo ZSBsaXN0IGlzIGFuIGFycmF5IG9mDQ0KICAgICAgICAgICAgICAgICAgICBJ UHY0IGFkZHJlc3Nlcy4NDQogICAgMikgKDQuNC4zKUFDIElQdjYgTGlzdCAt IGEgbGlzdCBvZiBBQ3MuIFRoZSBsaXN0IGlzIGFuIGFycmF5IG9mDQ0KICAg ICAgICAgICAgICAgICAgICBJUHY0IGFkZHJlc3Nlcy4NDQogICAgMykgKDQu NC41KUFDIE5hbWUgd2l0aCBJbmRleCAtIGFuIGluZGV4IChhbiBBQyBwcmVm ZXJlbmNlKQ0NCiAgICAgICAgICAgICAgICAgICAgYW5kIEFDIG5hbWUgaW4g dGV4dCBmb3JtYXQgZm9yIGVhY2ggY29uZmlndXJlZA0NCiAgICAgICAgICAg ICAgICAgICAgQUMuIChESVNDVVNTOiB0aGlzIGlzIG1lc3NlZCB1cC4gSG93 IGFyZSBBQw0NCiAgICAgICAgICAgICAgICAgICAgYWRkcmVzc2VzIGFuZCBu YW1lcyBwYWlyZWQuIEFsc28sIHRoaXMgaXMNDQogICAgICAgICAgICAgICAg ICAgIG11bHRpLUFDLCB3aGljaCBpcyBub3Qgd2VsbCBkZWZpbmVkLikNDQog ICAgICAgICAgICAgICAgICAgIFRoZSB2YWx1ZSBoYXMgc3ViZmllbGRzOg0N CiAgICAgICAgICAgICAgICAgICAgYSkgaW5kZXgNDQogICAgICAgICAgICAg ICAgICAgIGIpIEFDIG5hbWUNDQogICAgNCkgKDQuNC42KUFDIFRpbWVzdGFt cCAtIHRoZSBBQydzIGN1cnJlbnQgdGltZSAoRElTQ1VTUzogdGhpcyBpcw0N CiAgICAgICAgICAgICAgICAgICAgbm90IHJlYWxseSAiY29uZmlndXJhdGlv biIuIEl0IHNlZW1zIGxpa2UNDQogICAgICAgICAgICAgICAgICAgIHRoZSBq b2luIHJlc3BvbnNlIHdvdWxkIGJlIGEgYmV0dGVyIHBsYWNlDQ0KICAgICAg ICAgICAgICAgICAgICBmb3IgdGhpcywgc2luY2UgdGhlIFdUUCdzIHRpbWUg b2YgZGF5IGlzDQ0KICAgICAgICAgICAgICAgICAgICBub3QgcmV0cmlldmFi bGUuKQ0NCiAgICA1KSAoNC40LjcpQWRkIE1BQyBBQ0wgRW50cnkgLSAoRElT Q1VTUzogdGhpcyBpcyBzbyBzdHJhbmdlLg0NCiAgICAgICAgICAgICAgICAg ICAgVGhpcyBsaXN0IGlzIG1hbmFnZWQgbGlrZSBubyBvdGhlciBjb25maWd1 cmF0aW9uDQ0KICAgICAgICAgICAgICAgICAgICBkYXRhLiBBbHNvIHNlZSAo NC40LjkpLCAoNC40LjE2KSwgYW5kICg0LjQuMTgpLikNDQogICAgICAgICAg ICAgICAgICAgIGEgdm9sYXRpbGUgbGlzdCBvZiBNQUMgYWRkcmVzcyB3aGlj aA0NCiAgICAgICAgICAgICAgICAgICAgc2hvdWxkIG5vdCBoYXZlIHNlcnZp Y2UgcHJvdmlkZWQuIFRoZSB2YWx1ZQ0NCiAgICAgICAgICAgICAgICAgICAg aGFzIHN1YmZpZWxkczoNDQogICAgICAgICAgICAgICAgICAgIGEpIG51bWJl ciBvZiBlbnRyaWVzDQ0KICAgICAgICAgICAgICAgICAgICBiKSBhbiBhcnJh eSBvZiBNQUMgYWRkcmVzc2VzDQ0KICAgIDYpICg0LjQuOSlBZGQgU3RhdGlj IE1BQyBBQ0wgRW50cnkgLSBhIG5vbnZvbGF0aWxlIChzYXZlIGluIENPTkZJ RykNDQogICAgICAgICAgICAgICAgICAgIGxpc3Qgb2YgIE1BQyBhZGRyZXNz IHdoaWNoIHNob3VsZCBub3QgaGF2ZSBzZXJ2aWNlDQ0KICAgICAgICAgICAg ICAgICAgICBwcm92aWRlZC4gVGhlIHZhbHVlIGhhcyBzdWJmaWVsZHM6DQ0K ICAgICAgICAgICAgICAgICAgICBhKSBudW1iZXIgb2YgZW50cmllcw0NCiAg ICAgICAgICAgICAgICAgICAgYikgYW4gYXJyYXkgb2YgTUFDIGFkZHJlc3Nl cw0NCiAgICA3KSAoNC40LjEwKUNBUFdBUCBUaW1lcnMgLSB0aGUgdmFsdWUg aGFzIHN1YmZpZWxkczoNDQogICAgICAgICAgICAgICAgICAgIGEpIERpc2Nv dmVyeUludGVydmFsICg0LjUuMSkNDQogICAgICAgICAgICAgICAgICAgIGIp IEVjaG9JbnRlcnZhbCAoNC41LjQpDQ0KICAgIDgpIChNKSAoNC40LjExKUNo YW5nZSBTdGF0ZSBFdmVudCAtIChESVNDVVNTOiB0aGlzIHNlZW1zIGxpa2UN DQogICAgICAgICAgICAgICAgICAgIGEgdHlwby4gQWxyZWFkeSBoYXZlICg0 LjQuMjgpLikNDQogICAgICAgICAgICAgICAgICAgIHRoZSB2YWx1ZSBoYXMg c3ViZmllbGRzOg0NCiAgICAgICAgICAgICAgICAgICAgYSkgcmFkaW8gSUQN DQogICAgICAgICAgICAgICAgICAgIGIpIHN0YXRlIChvbiBvciBvZmYpDQ0K ICAgICAgICAgICAgICAgICAgICBjKSBjYXVzZSwgd2l0aCB2YWx1ZXM6DQ0K ICAgICAgICAgICAgICAgICAgICAgICAgMCAtIG5vcm1hbA0NCiAgICAgICAg ICAgICAgICAgICAgICAgIDEgLSByYWRpbyBmYWlsdXJlDQ0KICAgICAgICAg ICAgICAgICAgICAgICAgMiAtIHNvZnR3YXJlIGZhaWx1cmUNDQogICAgOSkg KE0pICg0LjQuMTUpRGVjcnlwdGlvbiBFcnJvciBSZXBvcnQgUGVyaW9kIC0g dGhlIHZhbHVlDQ0KICAgICAgICAgICAgICAgICAgICBoYXMgc3ViZmllbGRz Og0NCiAgICAgICAgICAgICAgICAgICAgYSkgcmFkaW8gSUQNDQogICAgICAg ICAgICAgICAgICAgIGIpIHJlcG9ydCBpbnRlcnZhbCAtIHRoZSB0aW1lIGlu IHNlY29uZHMNDQogICAgICAgICAgICAgICAgICAgICAgICBmb3IgdGhlIGZy ZXF1ZW5jeSBvZiBzZW5kaW5nDQ0KICAgICAgICAgICAgICAgICAgICAgICAg ZGVjcnlwdGlvbiBlcnJvciByZXBvcnQgbWVzc2FnZXMNDQogICAgICAgICAg ICAgICAgICAgIChESVNDVVNTOiBzaG91bGRuJ3QgdGhpcyB0aW1lciBiZQ0N CiAgICAgICAgICAgICAgICAgICAgZGVzY3JpYmVkIGluIHNlY3Rpb24gNC41 IG9yDQ0KICAgICAgICAgICAgICAgICAgICBzZWN0aW9uIDExPykNDQogICAx MCkgKE0pICg0LjQuMTYpRGVsZXRlIE1BQyBBQ0wgRW50cnkgLSBhIGxpc3Qg b2YgTUFDIGFkZHJlc3MgdG8gZGVsZXRlDQ0KICAgICAgICAgICAgICAgICAg ICBmcm9tIHRoZSB2b2xhdGlsZSBBQ0wgbGlzdC4gVGhlIHZhbHVlDQ0KICAg ICAgICAgICAgICAgICAgICBoYXMgc3ViZmllbGRzOg0NCiAgICAgICAgICAg ICAgICAgICAgYSkgbnVtYmVyIG9mIGVudHJpZXMNDQogICAgICAgICAgICAg ICAgICAgIGIpIGFuIGFycmF5IG9mIE1BQyBhZGRyZXNzZXMNDQogICAxMSkg KE0pICg0LjQuMTgpRGVsZXRlIFN0YXRpYyBNQUMgQUNMIEVudHJ5IC0gYSBs aXN0IG9mIE1BQyBhZGRyZXNzIHRvDQ0KICAgICAgICAgICAgICAgICAgICBk ZWxldGUgZnJvbSB0aGUgbm9uLXZvbGF0aWxlIEFDTCBsaXN0LiBUaGUNDQog ICAgICAgICAgICAgICAgICAgIHZhbHVlIGhhcyBzdWJmaWVsZHM6DQ0KICAg ICAgICAgICAgICAgICAgICBhKSBudW1iZXIgb2YgZW50cmllcw0NCiAgICAg ICAgICAgICAgICAgICAgYikgYW4gYXJyYXkgb2YgTUFDIGFkZHJlc3Nlcw0N CiAgIDEyKSAoNC40LjIyKUlkbGUgVGltZW91dCAtIHRoZSB0aW1lb3V0IHBl cmlvZCBmb3IgU1RBcw0NCiAgICAgICAgICAgICAgICAgICAgY29ubmVjdGVk IHRvIGFueSByYWRpbw0NCiAgIDEzKSAoNC40LjI2KVdUUCBMb2NhdGlvbiAt IGEgdGV4dCBzdHJpbmcgc3BlY2lmeWluZyB0aGUgbG9jYXRpb24NDQogICAg ICAgICAgICAgICAgICAgIG9mIHRoZSBXVFAgKERJU0NVU1M6IHRoaXMgYSAi c2NyYXRjaCBwYWQiLA0NCiAgICAgICAgICAgICAgICAgICAgYW5kIHRoZSBk ZWZpbml0aW9uIHNob3VsZCBzYXkgc28pDQ0KICAgMTQpIChNKSAoNC40LjI4 KVJhZGlvIEFkbWluaXN0cmF0aXZlIFN0YXRlIC0gZm9yIGEgcmFkaW8uIFRo ZQ0NCiAgICAgICAgICAgICAgICAgICAgdmFsdWUgaGFzIHN1YmZpZWxkczoN DQogICAgICAgICAgICAgICAgICAgIGEpIHJhZGlvIElEDQ0KICAgICAgICAg ICAgICAgICAgICBiKSBhZG1pbiBzdGF0ZSwgd2hpY2ggaGFzIHZhbHVlczoN DQogICAgICAgICAgICAgICAgICAgICAgICAxIC0gZW5hYmxlZA0NCiAgICAg ICAgICAgICAgICAgICAgICAgIDIgLSBkaXNhYmxlZA0NCiAgIDE1KSAoNC40 LjMxKVN0YXRpc3RpY3MgVGltZXIgLSB0aGUgdmFsdWUgb2YgdGhlIHN0YXRp c3RpY3MNDQogICAgICAgICAgICAgICAgICAgIHRpbWVyICh3aG9zZSB2YWx1 ZSBzcGVjaWZpZXMgdGhlIGxlbmd0aCBvZg0NCiAgICAgICAgICAgICAgICAg ICAgc3RhdGlzdGljcyByZXBvcnRpbmcgcGVyaW9kKSBpbiB1bml0cyBvZg0N CiAgICAgICAgICAgICAgICAgICAgc2Vjb25kcw0NCiAgIDE2KSAoNC40LjM1 KVdUUCBGYWxsYmFjayAtIElmIFRSVUUsIHRoZW4gaWYgYSBXVFAgZGV0ZWN0 cw0NCiAgICAgICAgICAgICAgICAgICAgaXRzIHByZWZlcnJlZCBBQyAoYW5k IGl0IGlzIG5vdCBjb25uZWN0ZWQNDQogICAgICAgICAgICAgICAgICAgIHRv IGl0KSB0aGVuIHRoZSBXVFAgZGlzY29ubmVjdHMgZnJvbSB0aGUNDQogICAg ICAgICAgICAgICAgICAgIGN1cnJlbnQgQUMgYW5kIGF0dGVtcHRzIHRvIHJl Y29ubmVjdCB0bw0NCiAgICAgICAgICAgICAgICAgICAgdGhlIHByZWZlcnJl ZCBBQy4gKERJU0NVU1M6IHRoZSBzZW1hbnRpY3MNDQogICAgICAgICAgICAg ICAgICAgIGFyZSBub3Qgd2VsbCBzcGVjaWZpZWQuIFRoaXMgc2hvdWxkIGJl DQ0KICAgICAgICAgICAgICAgICAgICByZW1vdmVkLikNDQogICAxNykgKDQu NC40MilXVFAgTmFtZSAtIGEgdmFsdWUgaW4gdGV4dCBmb3JtYXQgb2YgdGhl IFdUUCdzIG5hbWUNDQogICAxOCkgKE0pICgxMS4xMC4yKUlFRUUgODAyLjEx IEFudGVubmEgLSB0aGUgY29uZmlndXJhdGlvbiBvZg0NCiAgICAgICAgICAg ICAgICAgICAgdGhlIGFudGVubmFzIGZvciB0aGUgV1RQLiBUaGUgdmFsdWUg aGFzDQ0KICAgICAgICAgICAgICAgICAgICBzdWJmaWVsZHM6DQ0KICAgICAg ICAgICAgICAgICAgICBhKSByYWRpbyBJRA0NCiAgICAgICAgICAgICAgICAg ICAgYikgZGl2ZXJzaXR5IC0gaW5kaWNhdGVzIGlmIHRoZSBhbnRlbm5hIGlz IHRvDQ0KICAgICAgICAgICAgICAgICAgICAgICAgcHJvdmlkZSByZWNlaXZl IGRpdmVyc2l0eS4gVGhlIHZhbHVlcyBhcmU6DQ0KICAgICAgICAgICAgICAg ICAgICAgICAgMCAtIERpc2FibGVkDQ0KICAgICAgICAgICAgICAgICAgICAg ICAgMSAtIEVuYWJsZWQNDQogICAgICAgICAgICAgICAgICAgIGMpIGNvbWJp bmVyLCB3aXRoIHZhbHVlczoNDQogICAgICAgICAgICAgICAgICAgICAgICAx IC0gU2VjdG9yaXplZCAoTGVmdCkNDQogICAgICAgICAgICAgICAgICAgICAg ICAyIC0gU2VjdG9yaXplZCAoUmlnaHQpDQ0KICAgICAgICAgICAgICAgICAg ICAgICAgMyAtIE9tbmkNDQogICAgICAgICAgICAgICAgICAgICAgICA0IC0g TUlNTw0NCiAgICAgICAgICAgICAgICAgICAgZCkgYW50ZW5uYSBjb3VudCAo MC0yNTUpDQ0KICAgICAgICAgICAgICAgICAgICBlKSBhbnRlbm5hIHNlbGVj dGlvbiAtIGFuIGFycmF5IG9mIHNlbGVjdGlvbiwgd2l0aA0NCiAgICAgICAg ICAgICAgICAgICAgICAgIGVhY2ggaGF2ZSB2YWx1ZSBmcm9tOg0NCiAgICAg ICAgICAgICAgICAgICAgICAgIDEgLSBJbnRlcm5hbCBBbnRlbm5hDQ0KICAg ICAgICAgICAgICAgICAgICAgICAgMiAtIEV4dGVybmFsIEFudGVubmENDQog ICAxOSkgKDExLjEwLjQpSUVFRSA4MDIuMTEgQnJvYWRjYXN0IFByb2JlIE1v ZGUoc2VlIDExLjkuMykgLSBpbmRpY2F0ZXMNDQogICAgICAgICAgICAgICAg ICAgIGlmIHRoZSBXVFAgd2lsbCByZXNwb25kIHRvIGJyb2FkY2FzdCBOVUxM IFNTSUQNDQogICAgICAgICAgICAgICAgICAgIHByb2JlIHJlcXVlc3RzLCB3 aXRoIHZhbHVlczoNDQogICAgICAgICAgICAgICAgICAgICAgICAwIC0gbm8N DQogICAgICAgICAgICAgICAgICAgICAgICAxIC0geWVzDQ0KICAgMjApIChN KSAoMTEuMTAuNilJRUVFIDgwMi4xMSBEaXJlY3QgU2VxdWVuY2UgQ29udHJv bChzZWUgMTEuOS4zKSAtIHRoZQ0NCiAgICAgICAgICAgICAgICAgICAgdmFs dWUgaGFzIHN1YmZpZWxkczoNDQogICAgICAgICAgICAgICAgICAgIGEpIHJh ZGlvIElEDQ0KICAgICAgICAgICAgICAgICAgICBiKSByZXNlcnZlZCAoOCBi aXRzKQ0NCiAgICAgICAgICAgICAgICAgICAgYykgY3VycmVudCBjaGFubmVs IC0gdGhlIGN1cnJlbnQgb3BlcmF0aW5nIGZyZXENDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgb2YgdGhlIERTU1MgUEhZDQ0KICAgICAgICAgICAg ICAgICAgICBkKSBjdXJyZW50IENDQSAtIHRoZSB2YWx1ZXMgYXJlOg0NCiAg ICAgICAgICAgICAgICAgICAgICAgIDEgLSBlbmVyZ3kgZGV0ZWN0IG9ubHkg KGVkb25seSkNDQogICAgICAgICAgICAgICAgICAgICAgICAyIC0gY2Fycmll ciBzZW5zZSBvbmx5IChjc29ubHkpDQ0KICAgICAgICAgICAgICAgICAgICAg ICAgNCAtIGNhcnJpZXIgc2Vuc2UgYW5kIGVuZXJneSBkZXRlY3QgKGVkYW5k Y3MpDQ0KICAgICAgICAgICAgICAgICAgICAgICAgOCAtIGNhcnJpZXIgc2Vu c2Ugd2l0aCB0aW1lciAoY3N3aXRodGltZXIpDQ0KICAgICAgICAgICAgICAg ICAgICAgICAgMTYgLSBoaWdoIHJhdGUgY2FycmllciBzZW5zZSBhbmQgZW5l cmd5DQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZXRlY3Qg KGhyY3NhbmRlZCkNDQogICAgICAgICAgICAgICAgICAgIGUpIEVuZXJneSBk ZXRlY3QgdGhyZXNob2xkIChESVNDVVNTOiB3aGF0DQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBhcmUgdGhlIHVuaXRzIGFuZCByYW5nZT8p DQ0KICAgMjEpIChNKSAoMTEuMTAuOClJRUVFIDgwMi4xMSBNQUMgT3BlcmF0 aW9uKHNlZSAxMS45LjMpIC0gdGhlIHZhbHVlDQ0KICAgICAgICAgICAgICAg ICAgICBoYXMgc3ViZmllbGRzOg0NCiAgICAgICAgICAgICAgICAgICAgYSkg cmFkaW8gSUQNDQogICAgICAgICAgICAgICAgICAgIGIpIHJlc2VydmVkDQ0K ICAgICAgICAgICAgICAgICAgICBjKSBSVFMgdGhyZXNob2xkIC0gY291bnQg b2Ygb2N0ZXRzDQ0KICAgICAgICAgICAgICAgICAgICBkKSBzaG9ydCByZXRy eSAtIHRoZSBtYXggbnVtYmVyIG9mIHR4IGF0dGVtcHRzDQ0KICAgICAgICAg ICAgICAgICAgICBlKSBsb25nIHJldHJ5IC0gdGhlIG1heCBudW1iZXIgb2Yg dHggYXR0ZW1wdHMNDQogICAgICAgICAgICAgICAgICAgIGYpIGZyYWdtZW50 YXRpb24gdGhyZXNob2xkIC0gY291bnQgb2Ygb2N0ZXRzDQ0KICAgICAgICAg ICAgICAgICAgICBnKSBUeCBNU0RVIGxpZmV0aW1lIC0gZWxhcHNlZCB0aW1l IGluIFRVcw0NCiAgICAgICAgICAgICAgICAgICAgaCkgUnggTVNEVSBsaWZl dGltZSAtIGVsYXBzZWQgdGltZSBpbiBUVXMNDQogICAyMikgKE0pICgxMS4x MC4xMClJRUVFIDgwMi4xMSBNSUMgRXJyb3IgUmVwb3J0IEZyb20gTW9iaWxl KHNlZSAxMS45LjMpIC0NDQogICAgICAgICAgICAgICAgICAgIChESVNDVVNT OiB0aGlzIGxvb2tzIHRvIGJlIGFuIGVycm9yLCBub3QNDQogICAgICAgICAg ICAgICAgICAgIHN1cmUgd2hhdCBtZXNzYWdlIGl0IHNob3VsZCBiZSBpbikN DQogICAgICAgICAgICAgICAgICAgIHRoZSB2YWx1ZSBoYXMgc3ViZmllbGRz Og0NCiAgICAgICAgICAgICAgICAgICAgYSkgY2xpZW50IE1BQyBhZGRyZXNz DQ0KICAgICAgICAgICAgICAgICAgICBiKSBCU1NJRA0NCiAgICAgICAgICAg ICAgICAgICAgYykgcmFkaW8gSUQNDQogICAgICAgICAgICAgICAgICAgIGQp IFdMQU4gSUQgKERJU0NVU1M6IHRoaXMgc2VlbXMgcmVkdW5kYW50IHdpdGgg QlNTSUQpDQ0KICAgMjMpIChNKSAoMTEuMTAuMTMpSUVFRSA4MDIuMTEgTXVs dGktZG9tYWluIENhcGFiaWxpdHkoc2VlIDExLjkuMykgLSANDQogICAgICAg ICAgICAgICAgICAgIHRoZSB2YWx1ZSBoYXMgc3ViZmllbGRzOg0NCiAgICAg ICAgICAgICAgICAgICAgYSkgcmFkaW8gSUQNDQogICAgICAgICAgICAgICAg ICAgIGIpIHJlc2VydmVkICg4IGJpdHMpDQ0KICAgICAgICAgICAgICAgICAg ICBjKSBmaXJzdCBjaGFubmVsIG51bWJlcg0NCiAgICAgICAgICAgICAgICAg ICAgZCkgbnVtYmVyIG9mIGNoYW5uZWxzDQ0KICAgICAgICAgICAgICAgICAg ICBlKSBtYXggVHggcG93ZXIgbGV2ZWwgLSBpbiB1bml0cyBvZiBkQm0NDQog ICAyNCkgKE0pICgxMS4xMC4xNClJRUVFIDgwMi4xMSBPRkRNIENvbnRyb2wo c2VlIDExLjkuMykgLSB0aGUgdmFsdWUNDQogICAgICAgICAgICAgICAgICAg IGhhcyBzdWJmaWVsZHM6DQ0KICAgICAgICAgICAgICAgICAgICBhKSByYWRp byBJRA0NCiAgICAgICAgICAgICAgICAgICAgYikgcmVzZXJ2ZWQgKDggYml0 cykNDQogICAgICAgICAgICAgICAgICAgIGMpIGN1cnJlbnQgY2hhbm5lbCAt IG9wZXJhdGluZyBmcmVxdWVuY3kgb2YgT0ZETSBQSFkNDQogICAgICAgICAg ICAgICAgICAgIGQpIGJhbmRzIHN1cHBvcnRlZCAtIGEgYml0IGZpZWxkIChE SVNDVVNTOiB0aGVyZQ0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBp cyBtaXNzaW5nIGluZm8gaGVyZSAtIHR5cG8/KQ0NCiAgICAgICAgICAgICAg ICAgICAgZSkgVEkgdGhyZXNob2xkIC0gKERJU0NVU1M6IG5lZWQgdW5pdHMp DQ0KICAgMjUpIChNKSAoMTEuMTAuMTUpSUVFRSA4MDIuMTEgUmF0ZSBTZXQo c2VlIDExLjkuMykgLSB0aGUgdmFsdWUNDQogICAgICAgICAgICAgICAgICAg IGhhcyBzdWJmaWVsZHM6DQ0KICAgICAgICAgICAgICAgICAgICBhKSByYWRp byBJRA0NCiAgICAgICAgICAgICAgICAgICAgYikgcmF0ZXMgc2V0IC0gKERJ U0NVU1M6IGhvdyB0aGlzIGlzIGVuY29kZWQNDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgbmVlZHMgdG8gYmUgc3BlY2lmaWVkKQ0NCiAgIDI2KSAo TSkgKDExLjEwLjE4KUlFRUUgODAyLjExIFR4IFBvd2VyKHNlZSAxMS45LjMp IC0gdGhlIHZhbHVlDQ0KICAgICAgICAgICAgICAgICAgICBoYXMgc3ViZmll bGRzOg0NCiAgICAgICAgICAgICAgICAgICAgYSkgcmFkaW8gSUQNDQogICAg ICAgICAgICAgICAgICAgIGIpIHJlc2VydmVkICg4IGJpdHMpDQ0KICAgICAg ICAgICAgICAgICAgICBjKSBDdXJyZW50IFR4IFBvd2VyIC0gaW4gdW5pdHMg b2YgbVcNDQogICAyNykgKE0pICgxMS4xMC4yMilJRUVFIDgwMi4xMSBXVFAg UXVhbGl0eSBvZiBTZXJ2aWNlKHNlZSAxMS45LjMpIC0NDQogICAgICAgICAg ICAgICAgICAgIHRoZSB2YWx1ZSBoYXMgc3ViZmllbGRzOg0NCiAgICAgICAg ICAgICAgICAgICAgYSkgcmFkaW8gSUQNDQogICAgICAgICAgICAgICAgICAg IGIpIHRhZyBwYWNrZXRzLCB3aXRoIHZhbHVlczoNDQogICAgICAgICAgICAg ICAgICAgICAgICAwIC0gVW50YWdnZWQNDQogICAgICAgICAgICAgICAgICAg ICAgICAxIC0gODAyLjFQDQ0KICAgICAgICAgICAgICAgICAgICAgICAgMiAt IERTQ1ANDQogICAgICAgICAgICAgICAgICAgIGMpIGFycmF5KGluZGljZXMg b2Y6IFZvaWNlLCBWaWRlbywgQmVzdCBFZmZvcnQsDQ0KICAgICAgICAgICAg ICAgICAgICAgICBhbmQgQmFja2dyb3VuZCksIHdpdGggc3ViZmllbGRzOg0N CiAgICAgICAgICAgICAgICAgICAgICAgMSkgcXVldWUgZGVwdGggLSBwYWNr ZXRzDQ0KICAgICAgICAgICAgICAgICAgICAgICAyKSBDV01pbiAtIG1pbiBz aXplIG9mIGNvbnRlbnRpb24gd2luZG93DQ0KICAgICAgICAgICAgICAgICAg ICAgICAzKSBDV01heCAtIG1heCBzaXplIG9mIGNvbnRlbnRpb24gd2luZG93 DQ0KICAgICAgICAgICAgICAgICAgICAgICA0KSBBSUZTIC0gaW50ZXItZnJh bWUgc3BhY2luZyAoRElTQ1VTUzp1bml0cz8pDQ0KICAgICAgICAgICAgICAg ICAgICAgICA1KSBEb3QxUCB0YWcNDQogICAgICAgICAgICAgICAgICAgICAg IDYpIERTQ1AgdGFnDQ0KICAgMjgpIChNKSAoMTEuMTAuMjQpSUVFRSA4MDIu MTEgV1RQIFJhZGlvIENvbmZpZ3VyYXRpb24oc2VlIDExLjkuMykgLQ0NCiAg ICAgICAgICAgICAgICAgICAgdGhlIHZhbHVlIGhhcyBzdWJmaWVsZHM6DQ0K ICAgICAgICAgICAgICAgICAgICBhKSByYWRpbyBJRA0NCiAgICAgICAgICAg ICAgICAgICAgYikgcmVzZXJ2ZWQgKDggYml0cykNDQogICAgICAgICAgICAg ICAgICAgIGMpIG51bWJlciBvZiBCU1NJRHMNDQogICAgICAgICAgICAgICAg ICAgIGQpIERUSU0gcGVyaW9kIC0gaW4gdW5pdHMgb2YgYmVhY29uIGludGVy dmFscw0NCiAgICAgICAgICAgICAgICAgICAgZSkgQlNTSUQgLSBiYXNlIEJT U0lEIChESVNDVVNTOiB0aGlzIHNob3VsZA0NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgY29tZSBsYXN0IGFuZCBiZSBhbiBhcnJheSBvZg0N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQlNTSUQgdmFsdWVz IG9mIGxlbmd0aCAibnVtYmVyDQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBvZiBCU1NJRHMiLiBJZiBhIHZhbHVlIGZvcg0NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgYSBCU1NJRCBuZWVkcyB0byBiZSBh c3NpZ25lZCwNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRo ZW4gdGhlIEJTU0lEIHZhbHVlIHNob3VsZCBiZQ0NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgMDA6MDA6MDA6MDA6MDA6MDApDQ0KICAgICAg ICAgICAgICAgICAgICBmKSBiZWFjb24gcGVyaW9kIC0gaW4gdW5pdHMgb2Yg VFVzDQ0KICAgICAgICAgICAgICAgICAgICBnKSBjb3VudHJ5IGNvZGUgLSB0 d28gY2hhciBjb2RlIGZyb20gSVNPL0lFQyAzMTY2LTEsDQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBmb2xsb3dlZCBieSBjaGFyYWN0ZXI6 DQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoRElTQ1VTUzog SSdtIGNvbmZ1c2VkLCBpcyBpdCAxLCAyLCAzDQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAyNTUgb3IgIiAiLCAiTyIsICJJIiwgMHgyNTUp DQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiICIgIC0gYWxs IGVudmlyb25zIG9mIGNvdW50cnkNDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICJPIiAtIG91dGRvb3IgcmVndWxhdGlvbnMNDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICJJIiAtIGluZG9vciByZWd1bGF0 aW9ucw0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMHgyNTUg LSBub3QgdXNlZCkNDQoNDQooOC41KUNvbmZpZ3VyYXRpb24gVXBkYXRlIFJl c3BvbnNlKDgpIChjb25maWd1cmUgYW5kIHJ1biBzdGF0ZXMpIChXVFAtPkFD KQ0NCiAgRGVzY3I6IFRoZSByZXNwb25zZSBieSBhIFdUUCB0byBjb25maWcg dXBkYXRlIHJlcXVlc3QNDQogIE1lc3NhZ2UgZWxlbWVudHM6DQ0KICAgIChE SVNDVVNTOiB0aGUgY29uZmlnIHVwZGF0ZSByZXF1ZXN0IGNhbiBjb250YWlu IG1hbnkgY29uZmlndXJhdGlvbg0NCiAgICAgICAgYXR0cmlidXRlcy4gSWYg dGhlcmUgaXMgYSBmYWlsdXJlLCBpcyBpdCBhbGwgb3Igbm9uZT8gSG93DQ0K ICAgICAgICBkbyB5b3Uga25vdyB3aGljaCBhdHRyaWJ1dGUgZmFpbGVkPykN DQogICAgKERJU0NVU1M6IHRvZGF5LCB0aGVyZSBhcmUgcHJpbWFyaWx5IHR3 byB0eXBlcyBvZiBjb25maWd1cmF0aW9uDQ0KICAgICAgICBtb2RlbHMuIFRo ZSBmaXJzdCBpcyB3aGVuIGNvbmZpZyBpcyBjaGFuZ2VkLCBpdCBpcyBvbmx5 IGNoYW5nZWQNDQogICAgICAgIGluIHRoZSB2b2xhdGlsZSBjb3B5ICh0aGUg bWVtb3J5IG9yIHJ1bm5pbmcpLiBBbiBleHBsaWNpdCBjb21tYW5kDQ0KICAg ICAgICBpcyBuZWVkZWQgdG8gc2F2ZSB0aGUgY29uZmlnIHRvIG5vbnZvbGF0 aWxlIHN0b3JhZ2UuIFRoZSBzZWNvbmQNDQogICAgICAgIG1vZGVsIGhhcyBj b25maWcgYm90aCBydW5uaW5nICh2b2xhdGlsZSkgYW5kIHNhdmVkIChub252 b2xhdGlsZSkNDQogICAgICAgIGNvbmZpZyBjaGFuZ2VkIHdoZW4gYSBjb25m aWcgY2hhbmdlIGlzIG1hZGUuIEFuZCB0aGVyZSBtaWdodA0NCiAgICAgICAg YmUgYSBzcGVjaWFsIGNvbW1hbmQgdG8gaGF2ZSBhIGNvbmZpZyBjaGFuZ2Ug YXBwbHkgdG8gb25seQ0NCiAgICAgICAgb25lLiBJbiB0aGlzIGNhc2UsIHRo ZXJlIGlzIG5vIG5lZWQgZm9yIGEgInNhdmUgY29uZmlnIHRvDQ0KICAgICAg ICBub252b2xhdGlsZSIgY29tbWFuZC4gSXQgaXMgbm90IGNsZWFyIHdoYXQg aXMgc3VwcG9zZQ0NCiAgICAgICAgdG8gYmUgc3VwcG9ydGVkIGhlcmUgaW4g Q0FQV0FQLCBhbmQgaG93IGRvZXMgQ0FQV0FQDQ0KICAgICAgICBzdXBwb3J0 IGRldmljZXMgd2l0aCBubyBvciB2ZXJ5IGxpbWl0ZWQgbm9udm9sYXRpbGUN DQogICAgICAgIHN0b3JhZ2UgZm9yIGNvbmZpZyEpIA0NCiAgICAxKSAoNC40 LjI5KVJlc3VsdCBjb2RlIC0gaW5kaWNhdGVzIGlmIHRoZSBXVFAgYWNjZXB0 ZWQgb3INDQogICAgICAgICAgICAgICAgICAgIGZhaWxlZCB0aGUgY29uZmln dXJhdGlvbiB1cGRhdGUgcmVxdWVzdC4NDQogICAgICAgICAgICAgICAgICAg IFRoZSB2YWx1ZXMgYXJlOg0NCiAgICAgICAgICAgICAgICAgICAgMCAtIFN1 Y2Nlc3MNDQogICAgICAgICAgICAgICAgICAgIDEgLSBGYWlsdXJlIChBQyBM aXN0IG1lc3NhZ2UgZWxlbWVudA0NCiAgICAgICAgICAgICAgICAgICAgICAg IE1VU1QgYmUgcHJlc2VudCkgKERJU0NVU1M6IHRoaXMgc2VlbXMgYm9ndXMp DQ0KICAgICAgICAgICAgICAgICAgICAoRElTQ1VTUzogdGhlc2UgYXJlIGJv Z3VzLCBleGNlcHQgZm9yIGpvaW4pDQ0KICAgICAgICAgICAgICAgICAgICAy IC0gU3VjY2VzcyAoTkFUIGRldGVjdGVkKQ0NCiAgICAgICAgICAgICAgICAg ICAgMyAtIEZhaWx1cmUgKHVuc3BlY2lmaWVkKQ0NCiAgICAgICAgICAgICAg ICAgICAgNCAtIEZhaWx1cmUgKEpvaW4gRmFpbHVyZSwgUmVzb3VyY2UgRGVw bGV0aW9uKQ0NCiAgICAgICAgICAgICAgICAgICAgNSAtIEZhaWx1cmUgKEpv aW4gRmFpbHVyZSwgVW5rbm93biBTb3VyY2UpDQ0KICAgICAgICAgICAgICAg ICAgICA2IC0gRmFpbHVyZSAoSm9pbiBGYWlsdXJlLCBJbmNvcnJlY3QgRGF0 YSkNDQogICAgICAgICAgICAgICAgICAgIDcgLSBGYWlsdXJlIChKb2luIEZh aWx1cmUsIFNlc3Npb24gSUQgYWxyZWFkeQ0NCiAgICAgICAgICAgICAgICAg ICAgICAgIGluIHVzZSkNDQogICAgICAgICAgICAgICAgICAgIChESVNDVVNT OiB0aGVyZSBhcmUgcGxlbnR5IG9mIG90aGVyIGZhaWx1cmUgY2FzZXMpDQ0K ICAgIDIpIChPKSg0LjQuMilBQyBJUHY0IGFkZHIgbGlzdCAtIGEgbGlzdCBv ZiBBQ3MuIFRoZSBsaXN0IGlzIGFuDQ0KICAgICAgICAgICAgICAgICAgICBh cnJheSBvZiBJUHY0IGFkZHJlc3Nlcy4NDQogICAgMykgKE8pKDQuNC4zKUFD IElQdjYgYWRkciBsaXN0IC0gYSBsaXN0IG9mIEFDcy4gVGhlIGxpc3QgaXMg YW4NDQogICAgICAgICAgICAgICAgICAgIGFycmF5IG9mIElQdjYgYWRkcmVz c2VzLg0NCg0NCig4LjYpQ2hhbmdlIFN0YXRlIEV2ZW50IFJlcG9ydCgxMSkg KGNvbmZpZ3VyZSBhbmQgcnVuIHN0YXRlcykgKFdUUC0+QUMpDQ0KICBEZXNj cjogVGhpcyBpcyBzZW50IGJ5IGEgV1RQIHRvIHJlcG9ydCBhIGNoYW5nZSBp biB0aGUgb3BlcmF0aW9uYWwNDQogICAgICAgICBzdGF0ZSBvZiB0aGUgV1RQ LCBpbmNsdWRpbmcgYW55IFdUUCByYWRpb3MuIChESVNDVVNTOiB3ZWxsDQ0K ICAgICAgICAgYXMgZGVmaW5lZCwgaXQgb25seSByZXBvcnRzIGEgY2hhbmdl IG9mIG9wZXJhdGlvbmFsDQ0KICAgICAgICAgc3RhdGUgb2YgcmFkaW9zLiBJ dCdzIG5vdCBjbGVhciBpZiBvbmx5IGEgc2luZ2xlDQ0KICAgICAgICAgcmFk aW8sIG9yIG11bHRpcGxlIHJhZGlvcyBjYW4gYmUgbWVzc2FnZSBlbGVtZW50 cw0NCiAgICAgICAgIGluIHRoaXMgcmVwb3J0LiBJdCBzZWVtcyBsaWtlIGl0 IHNob3VsZCBiZSBPSyB0bw0NCiAgICAgICAgIHNwZWNpZnkgbXVsdGlwbGUg cmFkaW9zLiBBbHNvLCBpdCBzZWVtcyBsaWtlIHRoaXMNDQogICAgICAgICBj b3VsZCBiZSB1c2VkIHRvIHJlcG9ydCBjaGFuZ2VzIGluIG9wZXJhdGlvbmFs IHN0YXRlDQ0KICAgICAgICAgb2Ygb3RoZXIgY29tcG9uZW50cywgc3VjaCBh cyB0ZW1wZXJhdHVyZSBvdXQgb2Ygbm9ybWFsDQ0KICAgICAgICAgcmFuZ2Us IG9yIHZvbHRhZ2Ugb3V0IG9mIG5vcm1hbCByYW5nZS4pDQ0KICAgICAgICAg KERJU0NVU1M6IFRoaXMgc2VlbXMgYSBsaXR0bGUgc2lsbHkgdG8gYmUgc2Vu dCBpbiB0aGUNDQogICAgICAgICAiY29uZmlndXJlIiBzdGF0ZS4gSXQgc2Vl bXMgb25seSBhcHByb3ByaWF0ZSBmb3INDQogICAgICAgICB0aGUgInJ1biIg c3RhdGUuIFNvbWUgbWlnaHQgYXJndWUgdGhhdCBldmVuIGluIHRoZQ0NCiAg ICAgICAgICJydW4iIHN0YXRlIGl0IHNob3VsZG4ndCBiZSBzZW50IGFmdGVy IGEgImNvbmZpZw0NCiAgICAgICAgIHVwZGF0ZSIgcmVxdWVzdCB0aGF0IGNo YW5nZXMgdGhlIG9wZXJhdGlvbmFsIHN0YXRlLg0NCiAgICAgICAgIEhvd2V2 ZXIsIGluIHRoZSAicnVuIiBzdGF0ZSwgaXQgbWF5IHRha2UgYSB3aGlsZQ0N CiAgICAgICAgIHRvIGhhdmUgdGhlIG9wZXJhdGlvbmFsIHN0YXRlIGNoYW5n ZSB0byBmb2xsb3cgdGhlDQ0KICAgICAgICAgYWRtaW4gc3RhdGUuIFRodXMs IEkgdGhpbmsgaXQgaXMgT0sgaW4gdGhlICJydW4iDQ0KICAgICAgICAgc3Rh dGUgYWZ0ZXIgY29uZmlnIGNoYW5nZXMuIikNDQogIE1lc3NhZ2UgZWxlbWVu dHM6DQ0KICAgIDEpICg0LjQuMTEpQ2hhbmdlIFN0YXRlIElkZW50aWZpZXIg LSB0aGUgdmFsdWUgaGFzIHN1YmZpZWxkczoNDQogICAgICAgICAgICAgICAg ICAgIGEpIHJhZGlvIElEDQ0KICAgICAgICAgICAgICAgICAgICBiKSBzdGF0 ZSAob24gb3Igb2ZmKQ0NCiAgICAgICAgICAgICAgICAgICAgYykgY2F1c2Us IHdpdGggdmFsdWVzOg0NCiAgICAgICAgICAgICAgICAgICAgICAgIDAgLSBu b3JtYWwNDQogICAgICAgICAgICAgICAgICAgICAgICAxIC0gcmFkaW8gZmFp bHVyZQ0NCiAgICAgICAgICAgICAgICAgICAgICAgIDIgLSBzb2Z0d2FyZSBm YWlsdXJlDQ0KDQ0KKDguNylDaGFuZ2UgU3RhdGUgRXZlbnQgQWNrKDEyKSAo Y29uZmlndXJlIGFuZCBydW4gc3RhdGVzKSAoQUMtPldUUCkNDQogIERlc2Ny OiBTZW50IGJ5IHRoZSBBQyB0byBhY2tub3dsZWRnZSB0aGF0IGl0IHJlY2Vp dmVkDQ0KICAgICAgICAgYSAiY2hhbmdlIHN0YXRlIGV2ZW50IHJlcG9ydCIN DQogIE1lc3NhZ2UgZWxlbWVudHM6IC0tbm9uZS0tDQ0KDQ0KKDguOClDbGVh ciBDb25maWcgUmVxdWVzdCgyMykgKGNvbmZpZyBhbmQgcnVuIHN0YXRlKSAo QUMtPldUUCkNDQogIERlc2NyOiBUaGlzIHJlcXVlc3QgaXMgdXNlZCB0byBj YXVzZSBhIFdUUCB0byByZXNldCBpdCdzDQ0KICAgICAgICAgY29uZmlndXJh dGlvbiBiYWNrIHRvIHRoZSAibWFudWZhY3R1cmluZyBkZWZhdWx0Ii4NDQog ICAgICAgICAoRElTQ1VTUzogdGhpcyBvcGVyYXRpb24gaGFzIHNldmVyYWwg cHJvYmxlbXMsIHdoaWNoDQ0KICAgICAgICAgaW5jbHVkZToNDQogICAgICAg ICAgMSkgY3VycmVudGx5LCB0aGUgQ0FQV0FQLTAxIHNwZWMgc2F5cyB0aGF0 IHRoaXMNDQogICAgICAgICAgICAgY2FuIG9ubHkgYmUgZG9uZSBpbiB0aGUg InJ1biIgc3RhdGUuIFRoaXMgaXMNDQogICAgICAgICAgICAgc2lsbHkuIEl0 IHNob3VsZCBhbHNvIGJlIHBvc3NpYmxlIGluIHRoZQ0NCiAgICAgICAgICAg ICAiY29uZmlndXJlIiBzdGF0ZS4NDQogICAgICAgICAgMikgdGhlIHZhbHVl IG9mICJtYW51ZmFjdHVyaW5nIGRlZmF1bHRzIiBpcw0NCiAgICAgICAgICAg ICBub3QgZGVmaW5lZCwgYW5kIGEgcG9vciB0ZXJtIHRvIHVzZSwgc2luY2UN DQogICAgICAgICAgICAgaXQgaW1wbGllcyB0aGF0IHRoYXQgZWFjaCBtYW51 ZmFjdHVyZXIgY2FuDQ0KICAgICAgICAgICAgIGhhdmUgZGlmZmVyZW50IHZh bHVlcy4gSWYgc28sIHRoZW4gdGhlIEFDDQ0KICAgICAgICAgICAgIHdpbGwg aGF2ZSBubyBrbm93bGVkZ2Ugb2YgdGhlIGNvbmZpZyBvbiB0aGUNDQogICAg ICAgICAgICAgV1RQISBUaGUgcHJvYmxlbSBvZiAiZGVmYXVsdCBjb25maWcg dmFsdWVzIg0NCiAgICAgICAgICAgICBoYXMgYWxyZWFkeSBiZSBtZW50aW9u ZWQgYWJvdmUuIEFmdGVyIGVhY2gNDQogICAgICAgICAgICAgY29uZmlnIGF0 dHJpYnV0ZSBoYXMgYmVlbiBkZWZpbmVkIHdpdGggYQ0NCiAgICAgICAgICAg ICBkZWZhdWx0IHZhbHVlLCB0aGVuIHRoZSBwcm9wZXIgdGVybSB3b3VsZA0N CiAgICAgICAgICAgICBiZSAiQ0FQV0FQIGNvbmZpZyBkZWZhdWx0cyIuDQ0K ICAgICAgICAgIDMpIFRoaXMgb3BlcmF0aW9uIGlzIG5vdCBkZWZpbmVkIHRv IGhhdmUgYQ0NCiAgICAgICAgICAgICByZXNwb25zZS4gVGhpcyBpcyBicm9r ZW4sIHNpbmNlIGFueSBjb25maWcNDQogICAgICAgICAgICAgY2hhbmdlIGNh biBmYWlsLiBBbHNvLCBpdCBpcyBub3QgZGVmaW5lZA0NCiAgICAgICAgICAg ICB3aGF0IGhhcHBlbnMgbmV4dC4gRG9lcyB0aGlzIGNhdXNlIHRoZQ0NCiAg ICAgICAgICAgICBXVFAgdG8gcmVib290IGFuIHN0YXJ0IGEgImNsZWFuIGRp c2NvdmVyeSI/DQ0KICAgICAgICAgIDQpIFNlZSBjb21tZW50cyBvbiAoOS4z KVJlc2V0KQ0NCiAgTWVzc2FnZSBlbGVtZW50czogLS1ub25lLS0NDQoNDQoo OS4xYSlJbWFnZSBEYXRhIFJlcXVlc3QoMTUpIChqb2luL2NvbmZpZ3VyZSBh bmQgcnVuIHN0YXRlcykgKFdUUC0+QUMpDQ0KICBEZXNjcjogVGhpcyByZXF1 ZXN0IGlzIHVzZWQgYnkgdGhlIFdUUCB0byB0ZWxsIHRoZSBBQyB0aGF0IGl0 DQ0KICAgICAgICAgc2hvdWxkIHN0YXJ0IGRvd24gbG9hZGluZyBhbmQgaW1h Z2UsIGFuZCB0byBzcGVjaWZ5IHRoZQ0NCiAgICAgICAgIG5hbWUgb2YgdGhl IGltYWdlIGZpbGUuIE9uIHN1Y2Nlc3MgcmVzcG9uc2UsIHRoZQ0NCiAgICAg ICAgIFdUUCAoYW5kIEFDKSB0cmFuc2l0aW9uIHRvIHRoZSAiaW1hZ2UgZGF0 YSIgc3RhdGUNDQogICAgICAgICB3aGVyZSB0aGUgQUMgdXNlcyByZXBlYXRl ZCAiSW1hZ2UgRGF0YSBSZXF1ZXN0Ig0NCiAgICAgICAgIG9wZXJhdGlvbnMg dG8gdHJhbnNmZXIgZWFjaCBvZiB0aGUgaW1hZ2UuDQ0KICAgICAgICAgKERJ U0NVU1M6IFllcywgdGhlcmUgYXJlIGFjdHVhbGx5IHRocmVlIGRpZmZlcmVu dA0NCiAgICAgICAgICJJbWFnZSBEYXRhIFJlcXVlc3QiIG1lc3NhZ2VzLiBX aGljaCBvbmUgaXMgZGV0ZXJtaW5lZA0NCiAgICAgICAgIGJ5IHdoaWNoIG9m IHRoZSB0aHJlZSBtZXNzYWdlIGVsZW1lbnRzIGlzIGNvbnRhaW5lZC4NDQog ICAgICAgICBUaGlzIGlzIGNvbXBsZXRlbHkgc2lsbHkhIFRoZXJlIHNob3Vs ZCBiZSB0aHJlZQ0NCiAgICAgICAgIHNlcGFyYXRlIG9wZXJhdGlvbnMhIEFk ZGl0aW9uYWxseSwgaG93IGRvZXMgdGhlDQ0KICAgICAgICAgV1RQIGtub3cg d2hpY2ggaW1hZ2UgdG8gZ2V0PyBUaGUgQUMgc2hvdWxkIGJlDQ0KICAgICAg ICAgbWFraW5nIHRoYXQgZGVjaXNpb24uKQ0NCiAgTWVzc2FnZSBlbGVtZW50 czoNDQogICAgMSkgKDQuNC4yNClJbWFnZSBGaWxlbmFtZSAtIGEgdGV4dCBz dHJpbmcgdGhhdCBpcyBhIGZpbGUgbmFtZQ0NCiAgICAgICAgICAgICAgICAg ICAgKERJU0NVU1M6IHRoaXMgaXMgdmVyeSBwcm9ibGVtYXRpYykNDQoNDQoo OS4yYSlJbWFnZSBEYXRhIFJlc3BvbnNlKDE2KSAoam9pbi9jb25maWd1cmUg YW5kIHJ1biBzdGF0ZXMpIChBQy0+V1RQKQ0NCiAgRGVzY3I6IFRoaXMgaXMg dGhlIEFDJ3MgcmVzcG9uc2UgdG8gYW4gIkltYWdlIERhdGEgUmVxdWVzdCIg bWVzc2FnZQ0NCiAgICAgICAgIHRoYXQgY29udGFpbnMgYW4gImltYWdlIGZp bGVuYW1lICg0LjQuMjQpIiBtZXNzYWdlIGVsZW1lbnQuDQ0KICAgICAgICAg VGhlIEFDIGFmdGVyIHNlbmRpbmcsIGFuZCB0aGUgV1RQIGFmdGVyIHJlY2Vp dmluZw0NCiAgICAgICAgIHRyYW5zaXRpb25zIHRvIHRoZSAiaW1hZ2UgZGF0 YSIgc3RhdGUuDQ0KICBNZXNzYWdlIGVsZW1lbnRzOiAtLW5vbmUtLSAoRElT Q1VTUzogdGhpcyBpcyBzaWxseS4gVGhpcyBvcGVyYXRpb24gY2FuDQ0KICAg ICAgICAgZmFpbCEgVGhlcmUgbmVlZHMgdG8gYmUgbWVzc2FnZSBlbGVtZW50 IHRoYXQgaW5kaWNhdGVzIHRoZQ0NCiAgICAgICAgIHJlc3VsdC4pDQ0KDQ0K KDkuMWIpSW1hZ2UgRGF0YSBSZXF1ZXN0KDE1KSAoaW1hZ2UgZGF0YSBzdGF0 ZSkgKEFDLT5XVFApDQ0KICBEZXNjcjogVGhpcyByZXF1ZXN0IGlzIHVzZWQg YnkgYW4gQUMgdG8gc2VuZCBhIGJsb2NrIG9mIGFuDQ0KICAgICAgICAgaW1h Z2UgZmlsZSB0byBhIFdUUC4gKERJU0NVU1M6IFRoaXMgaXMgdGhlIHNlY29u ZCB1c2Ugb2YNDQogICAgICAgICB0aGlzIG1lc3NhZ2Ugb3BlcmF0aW9uIGNv ZGUuKSBUaGUgbGFzdCBibG9jayBoYXMgYQ0NCiAgICAgICAgIHNpemUgbGVz cyB0aGFuIDEwMjQgKHdoaWNoIGNhbiBpbmNsdWRlIDApIHRvIGluZGljYXRl DQ0KICAgICAgICAgdGhhdCB0aGUgaW1hZ2UgdHJhbnNmZXIgaXMgY29tcGxl dGUuIEFsc28sIHRoZQ0NCiAgICAgICAgIEFDIG1heSBzcGVjaWZ5IHRoYXQg dGhlIHRyYW5zZmVyIG9wZXJhdGlvbiBpcw0NCiAgICAgICAgIGFib3J0ZWQu IEFmdGVyIHRoZSBpbWFnZSB0cmFuc2ZlciBpcyBjb21wbGV0ZWQNDQogICAg ICAgICAob3IgYWJvcnRlZCksIHRoZSBEVExTIHNlc3Npb25zIGlzIGNsb3Nl ZCBhbmQNDQogICAgICAgICB0aGUgV1RQIHN0YXJ0cyBvdmVyLiAoRElTQ1VT Uzogd2hlbiBzdGFydGluZyBvdmVyDQ0KICAgICAgICAgYWdhaW4gYXQgdGhl IFdUUCBzdGFydCBzdGF0ZSwgdGhlIFdUUCBzaG91bGRuJ3QNDQogICAgICAg ICB1c2UgdGhlICJub3JtYWwiIGRpc2NvdmVyeSBwcm9jZXNzLCBidXQgaW5z dGVhZA0NCiAgICAgICAgICJmYXN0IHRyYWNrIiBhIGNvbm5lY3Rpb24gYmFj ayB0byB0aGUgQUMgdGhhdA0NCiAgICAgICAgIGp1c3QgZG93bmxvYWRlZCB0 aGUgaW1hZ2UuIFdpdGggYSBsaXR0bGUgbW9yZQ0NCiAgICAgICAgIHdvcmss IHdlIGNvdWxkIHByb2JhYmx5IGZpZ3VyZSBvdXQgYSB3YXkgdG8NDQogICAg ICAgICByZXVzZSB0aGUgb2xkIERUTFMgc2Vzc2lvbi4pDQ0KICBNZXNzYWdl IGVsZW1lbnRzOg0NCiAgICAxKSAoNC40LjIzKUltYWdlIERhdGEgLSBoYXMg dGhlIGZvbGxvd2luZyBzdWJmaWVsZHM6DQ0KICAgICAgICBhKSBvcGNvZGUg LSBpbmRpY2F0ZXMgZWl0aGVyIGltYWdlIGRhdGEgb3IgdHJhbnNmZXIgYWJv cnRlZA0NCiAgICAgICAgICAgICAgICAgICAgKERJU0NVU1M6IGlmIHRoaXMg aXMgaGVyZSwgbWlnaHQgYXMgd2VsbCBhbHNvDQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGhhdmUgYSB2YWx1ZSB0aGF0IGluZGljYXRlcyBsYXN0 DQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJsb2NrIG9mIHRoZSBp bWFnZSBmaWxlLCBpbnN0ZWFkIG9mDQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGxvb2tpbmcgYXQgdGhlIGJsb2NrIHNpemUuKQ0NCiAgICAgICAg YikgY2hlY2tzdW0gLSBhIDE2LWJpdCBjaGVja3N1bSBvZiB0aGUgaW1hZ2Ug YmxvY2sgdGhhdA0NCiAgICAgICAgICAgICAgICAgICAgICAgIGZvbGxvd3Mg KERJU0NVU1M6IHRoaXMgaXMgcmVhbCBzaWxseSBiZWNhdXNlDQ0KICAgICAg ICAgICAgICAgICAgICAgICAgRFRMUyBhbHJlYWR5IHByb3ZpZGVzICJwcm90 ZWN0aW9uIGZyb20NDQogICAgICAgICAgICAgICAgICAgICAgICBwYWNrZXQg bW9kaWZpY2F0aW9uIi4gV2hhdCBpcyByZWFsbHkgbmVlZGVkDQ0KICAgICAg ICAgICAgICAgICAgICAgICAgaXMgdGhlIE1ENS9TSEExL1NIQTI1NiBoYXNo IGZvciB0aGUgZmlsZS4NDQogICAgICAgICAgICAgICAgICAgICAgICBUaGlz IGZpZWxkIHNob3VsZCBiZSBkcm9wcGVkLikNDQogICAgICAgIGMpIGJsb2Nr IG9mIGltYWdlIGRhdGEgLSBlaXRoZXIgMTAyNCBvY3RldHMgZnJvbSB0aGUg ZmlsZSwNDQogICAgICAgICAgICAgICAgICAgICAgICBleGNlcHQgZm9yIHRo ZSBsYXN0IGJsb2NrICh3aGljaCBpcw0NCiAgICAgICAgICAgICAgICAgICAg ICAgIHplcm8gb2N0ZXRzIHdoZW4gdGhlIGZpbGUgc2l6ZSBpcyBhIG11bHRp cGxlDQ0KICAgICAgICAgICAgICAgICAgICAgICAgb2YgMTAyNCkNDQogICAg ICAgIERJU0NVU1M6IHNpbmNlIHRoaXMgb3BlcmF0aW9uIGRvZXMgbm90IGhh dmUgdGhlIGJsb2NrIG51bWJlcg0NCiAgICAgICAgICAgICAgYXMgYSBwYXJh bWV0ZXIsIHRoZSBXVFAgbXVzdCBkZXRlcm1pbmUgdGhlIGJsb2NrDQ0KICAg ICAgICAgICAgICBudW1iZXIgdmlhIHRoZSBDQVBXQVAgbWVzc2FnZSBoZWFk ZXIgc2VxdWVuY2UgbnVtYmVyLg0NCiAgICAgICAgICAgICAgTk9URTogRFRM UyBkb2VzIG5vdCBwcm92aWRlIGluLW9yZGVyIGRlbGl2ZXJ5IG9mDQ0KICAg ICAgICAgICAgICBwYWNrZXRzLiBBbHNvLCB0aGlzIHJlcXVpcmVzIHRoZSBX VFAgdG8gcmVtZW1iZXIgc3RhdGUuDQ0KICAgICAgICAgICAgICBUaGlzIG1l c3NhZ2UgZWxlbWVudCBzaG91bGQgYmUgcmUtZW5naW5lZXJlZCB0byBoYXZl IHRoZQ0NCiAgICAgICAgICAgICAgZm9sbG93aW5nIHN1YmZpZWxkczoNDQog ICAgICAgICAgICAgIGEpIG9wY29kZSAtIDQgYml0cywgaGFzIHZhbHVlczoN DQogICAgICAgICAgICAgICAgICAgIGFib3J0KDApIC0gYWJvcnQgdGhlIGlt YWdlIHRyYW5zZmVyIG9wZXJhdGlvbg0NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGFuZCBlaXRoZXIgZGlzY2FyZCB0aGUgcGFydGlh bA0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGltYWdl LCBvciBtYXJrIHBhcnRpYWwgc2F2ZWQNDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBpbWFnZSBhcyAibm90IHByZXNlbnQiDQ0KICAg ICAgICAgICAgICAgICAgICBmaW5pc2hlZCgxKSAtIHBheWxvYWQgc3ViZmll bGQgY29udGFpbnMgdGhlIGhhc2goZGlnZXN0KQ0NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIG9mIHRoZSBpbWFnZSAoTUQ1LCBTSEEx LCBTSEEyNTYpLA0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHRoZSB2ZXJzaW9uLCBhbmQgZGF0ZS4gVGhlIFdUUCBzaG91bGQNDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb21wdXRlIHRo ZSBkaWdlc3QsIGFuZCBjaGVjayB3aXRoDQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgdGhlIHNwZWNpZmllZCBvbmUuDQ0KICAgICAg ICAgICAgICAgICAgICAxMDI0IGRhdGEgYmxvY2soMikgLSBwYXlsb2FkIHN1 YmZpZWxkIGNvbnRhaW5zDQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgYSBjb21wbGV0ZSBvciBwYXJ0aWFsIDEwMjQgb2N0ZXQNDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkYXRhIGJsb2Nr ICh0aHVzIG1heCBpbWFnZSBzaXplDQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgaXMgMl4oMjQrMTApPTJeMzQ9MTZHKQ0NCiAgICAg ICAgICAgICAgICAgICAgNTEyIGRhdGEgYmxvY2soMykgLSBwYXlsb2FkIHN1 YmZpZWxkIGNvbnRhaW5zDQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgYSBjb21wbGV0ZSBvciBwYXJ0aWFsIDUxMiBvY3RldA0NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRhdGEgYmxvY2sg KHRodXMgbWF4IGltYWdlIHNpemUNDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBpcyAyXigyNCs5KT0yXjMzPThHKQ0NCiAgICAgICAg ICAgICAgICAgICAgMjU2IGRhdGEgYmxvY2soNCkgLSBwYXlsb2FkIHN1YmZp ZWxkIGNvbnRhaW5zDQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgYSBjb21wbGV0ZSBvciBwYXJ0aWFsIDI1NiBvY3RldA0NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRhdGEgYmxvY2sgKHRo dXMgbWF4IGltYWdlIHNpemUNDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBpcyAyXigyNCs4KT0yXjMyPTRHKQ0NCiAgICAgICAgICAg ICAgYikgc2xvdCB0byBzdG9yZSBpbWFnZSAtIDQgYml0cywgaGFzIHZhbHVl cyAwIC0gMTUuDQ0KICAgICAgICAgICAgICAgICAgICAwIC0gbm9ucGVyc2lz dGVudCBtZW1vcnkNDQogICAgICAgICAgICAgICAgICAgIDEtMTUgLSBwZXJz aXN0ZW50IHNsb3QgKGltcGxlbWVudGF0aW9uIGRlcGVuZGVudCkNDQogICAg ICAgICAgICAgIGMpIGJsb2NrIG51bWJlciAtIDMgb2N0ZXRzICgyNCBiaXRz KSwgdGhlIGJsb2NrIG51bWJlcg0NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGluIHRoZSBpbWFnZSAob3IgemVybyB3aGVuIHRoZQ0N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBheWxvYWQg aXMgbm90IGEgYmxvY2sgb2YgdGhlIGltYWdlDQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgZmlsZSkNDQogICAgICAgICAgICAgIGQp IHBheWxvYWQgLSByZXN0IG9mIHRoZSBtZXNzYWdlIGVsZW1lbnQuIFdoZW4N DQogICAgICAgICAgICAgICAgICAgIG9wY29kZSBpcyAnZmluaXNoZWQoMSkn LCB0aGUgcGF5bG9hZCBjb250YWlucw0NCiAgICAgICAgICAgICAgICAgICAg dGhlIGZvbGxvd2luZyBwaWVjZXMgb2YgaW5mbyBpbiBmb3JtYXQNDQogICAg ICAgICAgICAgICAgICAgICJ0eXBlKDEgb2N0ZXQpLCBsZW5ndGgoMSBvY3Rl dCksIHZhbHVlKGxlbmd0aCBvY3RldHMpIg0NCiAgICAgICAgICAgICAgICAg ICAgVGhlIG9uZSBvZiB0aGUgaGFzaCB0eXBlcyBtdXN0IGJlDQ0KICAgICAg ICAgICAgICAgICAgICBjaG9zZW4sIGZvbGxvd2VkIGJ5IHRoZSBzb2Z0d2Fy ZSB2ZXJzaW9uLA0NCiAgICAgICAgICAgICAgICAgICAgYW5kIGRhdGUuIFRo ZSB2YWx1ZXMgZm9yIHR5cGUgYXJlOg0NCiAgICAgICAgICAgICAgICAgICAg ICAwIC0gbm8gaGFzaA0NCiAgICAgICAgICAgICAgICAgICAgICAxIC0gTUQ1 IGhhc2gNDQogICAgICAgICAgICAgICAgICAgICAgMiAtIFNIQTEgaGFzaA0N CiAgICAgICAgICAgICAgICAgICAgICAzIC0gU0hBMjU2IGhhc2gNDQogICAg ICAgICAgICAgICAgICAgICAgNCAtIHNvZnR3YXJlIHZlcnNpb24NDQogICAg ICAgICAgICAgICAgICAgICAgNSAtIGltYWdlIGRhdGUNDQogICAgICAgICAg ICAgICAgICAgIFdoZW4gdGhlIHBheWxvYWQgaXMgYSBibG9jaywgdGhlbiB0 aGUgcGF5bG9hZA0NCiAgICAgICAgICAgICAgICAgICAgaXMgZnJvbSAxIHRv IG1heCBibG9jayBsZW5ndGggb2N0ZXRzIGZvcg0NCiAgICAgICAgICAgICAg ICAgICAgdGhlIGZpbGUuDQ0KDQ0KKDkuMmIpSW1hZ2UgRGF0YSBSZXNwb25z ZSgxNikgKGltYWdlIGRhdGEgc3RhdGUpIChXVFAtPkFDKQ0NCiAgRGVzY3I6 IFRoaXMgaXMgdGhlIFdUUCdzIHJlc3BvbnNlIHRvIGFuICJJbWFnZSBEYXRh IFJlcXVlc3QiIG1lc3NhZ2UNDQogICAgICAgICB0aGF0IGNvbnRhaW5zIGFu ICJpbWFnZSBkYXRhICg0LjQuMjMpIiBtZXNzYWdlIGVsZW1lbnQuDQ0KICBN ZXNzYWdlIGVsZW1lbnRzOiAtLW5vbmUtLSAoRElTQ1VTUzogdGhpcyBpcyBz aWxseS4gVGhpcyBvcGVyYXRpb24NDQogICAgICAgICBjYW4gZmFpbCEgIEZv ciBleGFtcGxlLCB0aGUgV1RQIGNhbiBydW4gb3V0IG9mIHNwYWNlIHRvIHN0 b3JlDQ0KICAgICAgICAgdGhlIGJsb2NrLCBvciB0aGVyZSBjb3VsZCBiZSBh IGZhaWx1cmUgaW4gd3JpdGluZyB0aGUgYmxvY2sNDQogICAgICAgICB0byBz dG9yYWdlLiAoT3IgYXMgIkltYWdlIERhdGEgUmVxdWVzdCIoOS4xYSkgaXMN DQogICAgICAgICBwcmVzZW50bHkgc3BlY2lmaWVkLCB0aGUgY2hlY2tzdW0g bWF0Y2ggY291bGQgZmFpbC4pIFRoZXJlDQ0KICAgICAgICAgbmVlZHMgdG8g YmUgbWVzc2FnZSBlbGVtZW50IHRoYXQgaW5kaWNhdGVzIHRoZSByZXN1bHQu KQ0NCiAgICAgICAgIE5vdGU6IGRvbid0IG5lZWQgYSBibG9jayBudW1iZXIg ZmllbGQsIHNpbmNlIHJlcXVlc3QNDQogICAgICAgICBhbmQgcmVzcG9uc2Vz IGFyZSBwYWlyZWQuKQ0NCg0NCig5LjFjKUltYWdlIERhdGEgUmVxdWVzdCgx NSkgKHJ1biBzdGF0ZSkgKEFDLT5XVFApDQ0KICBEZXNjcjogVGhpcyByZXF1 ZXN0IGlzIHVzZWQgYnkgYW4gQUMgaW4gdGhlIHJ1biBzdGF0ZSB0byBjYXVz ZSB0aGUNDQogICAgICAgICB0aGUgV1RQIHNlbmQgYSAiSW1hZ2UgRGF0YSBS ZXF1ZXN0IiAoOS4xLmEpIHRvIHRoZSBBQy4NDQogIE1lc3NhZ2UgZWxlbWVu dHM6DQ0KICAgIDEpICg0LjQuMjUpSW5pdGlhdGUgRG93bmxvYWQgLSB0aGlz IG1lc3NhZ2UgZWxlbWVudCBpcyBqdXN0DQ0KICAgICAgICAgICAgICAgICAg ICBhIHRyaWdnZXIgdG8gaW5kaWNhdGUgdGhlIHR5cGUgb2YgIkltYWdlDQ0K ICAgICAgICAgICAgICAgICAgICBEYXRhIFJlcXVlc3QiLiBUaGF0IGlzLCBp dCBoYXMgbm8gY29udGVudC4NDQogICAgICAgICAgICAgICAgICAgIERJU0NV U1M6IHNpbGx5IGJleW9uZCBiZWxpZWYuDQ0KDQ0KKDkuMmMpSW1hZ2UgRGF0 YSBSZXNwb25zZSgxNikgKHJ1biBzdGF0ZSkgKFdUUC0+QUMpDQ0KICBEZXNj cjogVGhpcyBpcyB0aGUgV1RQJ3MgcmVzcG9uc2UgdG8gYW4gIkltYWdlIERh dGEgUmVxdWVzdCIgbWVzc2FnZQ0NCiAgICAgICAgIHRoYXQgY29udGFpbnMg YW4gImltYWdlIGZpbGVuYW1lICg0LjQuMjUpIiBtZXNzYWdlIGVsZW1lbnQu DQ0KICBNZXNzYWdlIGVsZW1lbnRzOiAtLW5vbmUtLSAoRElTQ1VTUzogdGhp cyBpcyBzaWxseS4gVGhpcyBvcGVyYXRpb24gY2FuDQ0KICAgICAgICAgZmFp bCEgVGhlcmUgbmVlZHMgdG8gYmUgbWVzc2FnZSBlbGVtZW50IHRoYXQgaW5k aWNhdGVzIHRoZQ0NCiAgICAgICAgIHJlc3VsdC4pDQ0KDQ0KKDkuMylSZXNl dCBSZXF1ZXN0KDE3KSAocnVuIHN0YXRlKSAoQUMtPldUUCkNDQogIERlc2Ny OiBUaGlzIGlzIHVzZWQgYnkgYW4gQUMgaW4gdGhlIHJ1biBzdGF0ZSB0byBy ZXNldCBhIFdUUC4NDQogIE1lc3NhZ2UgZWxlbWVudHM6IC0tbm9uZS0tIChE SVNDVVNTOiBpdCBzZWVtcyBiZXR0ZXIgdG8gZWxpbWluYXRlDQ0KICAgICAg ICAgdGhlICJDbGVhciBDb25maWcgcmVxdWVzdCIoOC44KSBvcGVyYXRpb24g YW5kIGFkZCBhDQ0KICAgICAgICAgcGFyYW1ldGVyIHRvIHRoaXMgb3BlcmF0 aW9uLiBBbHNvLCBpdCB3b3VsZCBiZQ0NCiAgICAgICAgIHVzZWZ1bCB0byBo YXZlIHRoZSBwYXJhbWV0ZXIgdGVsbCB0aGUgV1RQIHdoYXQNDQogICAgICAg ICBkbyBvbiBkaXNjb3ZlcnkgYWZ0ZXIgdGhlIG5leHQgYm9vdC4gVGh1cywN DQogICAgICAgICBzdWdnZXN0IGEgcGFyYW1ldGVyIHRoYXQgaXMgYW4gb3Bj b2RlIHdpdGgNDQogICAgICAgICB0aGUgZm9sbG93aW5nIHZhbHVlczoNDQog ICAgICAgICAgIDAgLSBjbGVhciBjb25maWcgYmFjayB0byBDQVBXQVAgZGVm YXVsdHMgYW5kIHJlYm9vdA0NCiAgICAgICAgICAgICAgICh3aGljaCBhbHNv IGltcGxpZXMgYSAiZmlyc3QgdGltZSIgZGlzY292ZXJ5KQ0NCiAgICAgICAg ICAgMSAtIHJlYm9vdCBhbmQgcmVjb25uZWN0IHRvIHRoZSBjdXJyZW50IEFD DQ0KICAgICAgICAgICAgICAgKHdoaWNoIG1lYW5zIGEgImZhc3QgdHJhY3Qg ZGlzY292ZXJ5IikNDQogICAgICAgICAgIDIgLSByZWJvb3QgYW5kIHVzZSBj b25maWd1cmVkIEFDcyBkdXJpbmcNDQogICAgICAgICAgICAgICBkaXNjb3Zl cnkNDQogICAgICAgICAgIDMgLSByZWJvb3QgYW5kIGlnbm9yZSBjb25maWd1 cmVkIEFDcyBkdXJpbmcNDQogICAgICAgICAgICAgICBkaXNjb3ZlcnkpDQ0K DQ0KKDkuNClSZXNldCBSZXNwb25zZSgxOCkgKHJ1biBzdGF0ZSkgKFdUUC0+ QUMpDQ0KICBEZXNjcjogVGhpcyBpcyB0aGUgV1RQJ3MgcmVzcG9uc2UgdG8g YSByZXNldCByZXF1ZXN0Lg0NCiAgTWVzc2FnZSBlbGVtZW50czogLS1ub25l LS0gKERJU0NVU1M6IHRoaXMgaXMgc2lsbHkuIFRoaXMgb3BlcmF0aW9uIGNh bg0NCiAgICAgICAgIGZhaWwhIFRoZXJlIG5lZWRzIHRvIGJlIG1lc3NhZ2Ug ZWxlbWVudCB0aGF0IGluZGljYXRlcyB0aGUNDQogICAgICAgICByZXN1bHQu KQ0NCg0NCig5LjUpV1RQIEV2ZW50IFJlcG9ydCg5KSAocnVuIHN0YXRlKSAo V1RQLT5BQykNDQogIERlc2NyOiBBIFdUUCBpbiB0aGUgcnVuIHN0YXRlIHNl bmRzIGFuIGV2ZW50IHJlcG9ydCBtZXNzYWdlDQ0KICAgICAgICAgdG8gYW4g QUMgYmFzZWQgb24gYSB0aW1lIHBlcmlvZCBlbGFwc2luZyBvciBhbg0NCiAg ICAgICAgIGFzeW5jaHJvbm91cyBldmVudCBvY2N1cnJpbmcuIChESVNDVVNT OiBjYW4gbW9yZQ0NCiAgICAgICAgIHRoYW4gb25lIGV2ZW50IHJlcG9ydGVk IGluIHRoZSBzYW1lIG1lc3NhZ2U/IFRoYXQgaXMsDQ0KICAgICAgICAgY2Fu IGEgbWVzc2FnZSBjb250YWluIG1vcmUgdGhhbiBvbmUgbWVzc2FnZSBlbGVt ZW50PykNDQogIE1lc3NhZ2UgZWxlbWVudHM6DQ0KICAgIDEpICg0LjQuMTQp RGVjcnlwdGlvbiBFcnJvciBSZXBvcnQgLSBhIGxpc3QgcGVyIHJhZGlvLA0N CiAgICAgICAgICAgICAgICAgICAgb2YgTUFDIGFkZHJlc3NlcyB0aGF0IGhh ZCBkZWNyeXB0aW9uDQ0KICAgICAgICAgICAgICAgICAgICBlcnJvcnMgaW4g dGhlIHJlcG9ydGluZyBwZXJpb2QuIFRoZQ0NCiAgICAgICAgICAgICAgICAg ICAgdmFsdWUgaGFzIHN1YmZpZWxkczoNDQogICAgICAgICAgICAgICAgICAg IGEpIHJhZGlvIElEDQ0KICAgICAgICAgICAgICAgICAgICBiKSBudW1iZXIg b2YgTUFDIGFkZHJlc3Nlcw0NCiAgICAgICAgICAgICAgICAgICAgYykgYW4g YXJyYXkgb2YgTUFDIGFkZHJlc3Nlcw0NCiAgICAyKSAoNC40LjIwKUR1cGxp Y2F0ZSBJUHY0IEFkZHJlc3MgLSB0aGUgTUFDIGFkZHJlc3Mgb2YNDQogICAg ICAgICAgICAgICAgICAgIGFub3RoZXIgZGV2aWNlIHRoYXQgaGFzIGJlZW4g ZGV0ZWN0ZWQNDQogICAgICAgICAgICAgICAgICAgIHVzaW5nIGFuIElQdjQg YWRkcmVzcyB1c2VkIGJ5IHRoZSBXVFANDQogICAgICAgICAgICAgICAgICAg IChESVNDVVNTOiBob3cgb2Z0ZW4gaXMgdGhpcyByZXBvcnRlZA0NCiAgICAg ICAgICAgICAgICAgICAgaWYgdGhlIGNvbmRpdGlvbiByZW1haW5zPykgVGhl IHZhbHVlDQ0KICAgICAgICAgICAgICAgICAgICBoYXMgc3ViZmllbGRzOg0N CiAgICAgICAgICAgICAgICAgICAgYSkgSVB2NCBhZGRyZXNzDQ0KICAgICAg ICAgICAgICAgICAgICBiKSBNQUMgYWRkcmVzcw0NCiAgICAzKSAoNC40LjIx KUR1cGxpY2F0ZSBJUHY2IEFkZHJlc3MgLSB0aGUgTUFDIGFkZHJlc3Mgb2YN DQogICAgICAgICAgICAgICAgICAgIGFub3RoZXIgZGV2aWNlIHRoYXQgaGFz IGJlZW4gZGV0ZWN0ZWQNDQogICAgICAgICAgICAgICAgICAgIHVzaW5nIGFu IElQdjYgYWRkcmVzcyB1c2VkIGJ5IHRoZSBXVFANDQogICAgICAgICAgICAg ICAgICAgIChESVNDVVNTOiBob3cgb2Z0ZW4gaXMgdGhpcyByZXBvcnRlZA0N CiAgICAgICAgICAgICAgICAgICAgaWYgdGhlIGNvbmRpdGlvbiByZW1haW5z PykgVGhlIHZhbHVlDQ0KICAgICAgICAgICAgICAgICAgICBoYXMgc3ViZmll bGRzOg0NCiAgICAgICAgICAgICAgICAgICAgYSkgSVB2NiBhZGRyZXNzDQ0K ICAgICAgICAgICAgICAgICAgICBiKSBNQUMgYWRkcmVzcw0NCiAgICA0KSAo MTEuMTAuOSlJRUVFIDgwMi4xMSBNSUMgQ291bnRlcm1lYXN1cmVzKHNlZSAx MS45LjIpIC0gYSBNSUMNDQogICAgICAgICAgICAgICAgICAgIGZhaWx1cmUg aGFzIGJlZW4gZGV0ZWN0ZWQuIFRoZSB2YWx1ZQ0NCiAgICAgICAgICAgICAg ICAgICAgaGFzIHN1YmZpZWxkczoNDQogICAgICAgICAgICAgICAgICAgIGEp IHJhZGlvIElEDQ0KICAgICAgICAgICAgICAgICAgICBiKSBXTEFOIElEDQ0K ICAgICAgICAgICAgICAgICAgICBjKSBNQUMgYWRkcmVzcyBvZiBTVEEgd2l0 aCBNSUMgZmFpbHVyZQ0NCiAgICA1KSAoMTEuMTAuMTYpSUVFRSA4MDIuMTEg U3RhdGlzdGljcyAoc2VlIDExLjkuMikgLSBhIHBlcmlvZGljIHJlcG9ydA0N CiAgICAgICAgICAgICAgICAgICAgb2Ygc3RhdGlzdGljcy4gVGhlIHZhbHVl IGhhcyBzdWJmaWVsZHM6DQ0KICAgICAgICAgICAgICAgICAgICBhKSByYWRp byBJRA0NCiAgICAgICAgICAgICAgICAgICAgYikgcmVzZXJ2ZWQgKDI0IGJp dHMpDQ0KICAgICAgICAgICAgICAgICAgICBjKSBUeCBGcmFnbWVudCBDb3Vu dA0NCiAgICAgICAgICAgICAgICAgICAgZCkgTXVsdGljYXN0IFR4IENvdW50 DQ0KICAgICAgICAgICAgICAgICAgICBlKSBGYWlsZWQgQ291bnQNDQogICAg ICAgICAgICAgICAgICAgIGYpIFJldHJ5IENvdW50DQ0KICAgICAgICAgICAg ICAgICAgICBnKSBNdWx0aXBsZSBSZXRyeSBDb3VudA0NCiAgICAgICAgICAg ICAgICAgICAgaCkgRnJhbWUgRHVwbGljYXRlIENvdW50DQ0KICAgICAgICAg ICAgICAgICAgICBpKSBSVFMgU3VjY2VzcyBDb3VudA0NCiAgICAgICAgICAg ICAgICAgICAgaikgUlRTIEZhaWx1cmUgQ291bnQNDQogICAgICAgICAgICAg ICAgICAgIGspIEFDSyBGYWlsdXJlIENvdW50DQ0KICAgICAgICAgICAgICAg ICAgICBsKSBSeCBGcmFnbWVudCBDb3VudA0NCiAgICAgICAgICAgICAgICAg ICAgbSkgTXVsdGljYXN0IFJYIENvdW50DQ0KICAgICAgICAgICAgICAgICAg ICBuKSBGQ1MgRXJyb3IgIENvdW50DQ0KICAgICAgICAgICAgICAgICAgICBv KSBUeCBGcmFtZSBDb3VudA0NCiAgICAgICAgICAgICAgICAgICAgcCkgRGVj cnlwdGlvbiBFcnJvcnMNDQogICAgNikgKDExLjEwLjIzKUlFRUUgODAyLjEx IFdUUCBSYWRpbyBGYWlsIEFsYXJtIEluZGljYXRpb24gKHNlZSAxMS45LjIp IC0NDQogICAgICAgICAgICAgICAgICAgIGEgcmVwb3J0IHRoYXQgYSByYWRp byBoYXMgZmFpbGVkLiBUaGUgdmFsdWUNDQogICAgICAgICAgICAgICAgICAg IGhhcyBzdWJmaWVsZHM6DQ0KICAgICAgICAgICAgICAgICAgICBhKSByYWRp byBJRA0NCiAgICAgICAgICAgICAgICAgICAgYikgdHlwZSBvZiBmYWlsdXJl LCB3aXRoIHZhbHVlczoNDQogICAgICAgICAgICAgICAgICAgICAgICAxIC0g UmVjZWl2ZXINDQogICAgICAgICAgICAgICAgICAgICAgICAyIC0gVHJhbnNt aXR0ZXINDQogICAgICAgICAgICAgICAgICAgIGMpIHN0YXR1cywgd2l0aCB2 YWx1ZXM6DQ0KICAgICAgICAgICAgICAgICAgICAgICAgMCAtIGEgZmFpbHVy ZSBoYXMgb2NjdXJyZWQNDQogICAgICAgICAgICAgICAgICAgICAgICAxIC0g dGhlIGZhaWx1cmUgbm8gbG9uZ2VyIGV4aXN0cw0NCiAgICAgICAgICAgICAg ICAgICAgZCkgcGFkIC0gb25lIG9jdGV0DQ0KICAgIERJU0NVU1M6IHRoZSBs aXN0IG9mIGV2ZW50cyBzZWVtcyB1bmRlcnN0YXRlZCENDQoNDQooOS42KVdU UCBFdmVudCBBY2soMTApIChydW4gc3RhdGUpIChBQy0+V1RQKQ0NCiAgRGVz Y3I6IEFuIGFja25vd2xlZGdlbWVudCB0aGF0IHRoZSBBQyByZWNlaXZlZCB0 aGUNDQogICAgICAgICBldmVudCByZXBvcnQgZnJvbSB0aGUgV1RQLg0NCiAg TWVzc2FnZSBlbGVtZW50czogLS1ub25lLS0NDQoNDQooOS43KURhdGEgVHJh bnNmZXIgUmVxdWVzdCgyMSkgKHJ1biBzdGF0ZSkgKFdUUC0+QUMpDQ0KICBE ZXNjcjogVGhpcyBpcyB1c2VkIHRvIHNlbmQgZGVidWdnaW5nIGluZm9ybWF0 aW9uIChwcmVzZW50bHksIG9ubHkNDQogICAgICAgICAiV1RQIGNyYXNoIGRh dGEiIGFuZCAiV1RQIG1lbW9yeSBkdW1wIiBmcm9tIGFuIFdUUCB0byBhbiBB Qy4NDQogICAgICAgICAoRElTQ1VTUzogdGhpcyBvcGVyYXRpb24gaXMgcXVp dGUgdW5kZXIgc3BlY2lmaWVkLiBJbiBzb21lIHdheXMNDQogICAgICAgICBp dCBpcyBsaWtlIHRoZSBpbWFnZSB0cmFuc2ZlciBvcGVyYXRpb24sIGJ1dCB3 aXRoIGRpZmZlcmVudA0NCiAgICAgICAgIHRhcmdldHMuIEl0IGlzIG5vdCBj bGVhciBob3cgaXQgd291bGQgYmUgdXNlZCBpZiB0aGUgaW5mb3JtYXRpb24N DQogICAgICAgICB3aWxsIG5vdCBmaXQgaW4gb25lIG1lc3NhZ2UuIEFsc28s IGFzIHNwZWNpZmllZCwgdGhlIFdUUA0NCiAgICAgICAgIGRlY2lkZXMgd2hl biB0byBwZXJmb3JtIHRoaXMgb3BlcmF0aW9uLCBpbnN0ZWFkIG9mIGJlaW5n DQ0KICAgICAgICAgZG9uZSBpbiByZXNwb25zZSB0byBhbiBBQyByZXF1ZXN0 LiBCb3R0b20gbGluZTogaXQgYXBwZWFycw0NCiAgICAgICAgIGxpa2UgYSAi bmljZSB0byBoYXZlIGZlYXR1cmUiLCBidXQgbm90IHJlcXVpcmVkLiBBbmQg aXQgbmVlZHMNDQogICAgICAgICB3b3JrIHRvIGJlIG1hZGUgcmVhbGx5IHVz ZWZ1bC4pDQ0KICAgICAgICAgKERJU0NVU1M6IGluIGZ1cnRoZXIgcmV2aWV3 LCBpdCBhcHBlYXJzIHRoYXQgc2VjdGlvbiA5Ljcgb2YNDQogICAgICAgICBD QVBXQVAtMDEgZG9lcyBub3QgY2hhcmFjdGVyaXplIHRoaXMgb3BlcmF0aW9u IGNvcnJlY3RseS4NDQogICAgICAgICBJdCBzaG91bGQgYmUNDQogICAgICAg ICAgICAtICg5LjdhKURhdGEgVHJhbnNmZXIgVHlwZSBSZXF1ZXN0KDIxKSAo cnVuIHN0YXRlKSAoQUMtPldUUCkNDQogICAgICAgICAgICAgIERpc2M6IHVz ZWQgYnkgYW4gQUMgdG8gcmVxdWVzdCBkZWJ1ZyBpbmZvIGZyb20gV1RQDQ0K ICAgICAgICAgICAgICBQYXJtOiAoNC40LjEzKURhdGEgVHJhbnNmZXIgTW9k ZSAtIGluZm8gdG8gcmV0dXJuDQ0KICAgICAgICAgICAgLSAoOS43YilEYXRh IFRyYW5zZmVyIFJlcXVlc3QoMjEpIChydW4gc3RhdGUpIChXVFAtPkFDKQ0N CiAgICAgICAgICAgICAgRGlzYzogdXNlZCBieSBhIFdUUCB0byB0cmFuc2Zl ciBkZWJ1ZyBpbmZvIHRvIEFDDQ0KICAgICAgICAgICAgICBQYXJtOiAoNC40 LjEyKURhdGEgVHJhbnNmZXIgRGF0YSAtIGEgY2h1bmsgb2YgZGVidWcgZGF0 YSkNDQogIE1lc3NhZ2UgZWxlbWVudHM6DQ0KICAgIDEpICg0LjQuMTMpRGF0 YSBUcmFuc2ZlciBNb2RlIC0gdGhlIGluZm8gdG8gcmV0dXJuIHdpdGggdmFs dWVzOg0NCiAgICAgICAgICAgICAgICAgICAgMSAtIFdUUCBDcmFzaCBEYXRh DQ0KICAgICAgICAgICAgICAgICAgICAyIC0gV1RQIE1lbW9yeSBEdW1wDQ0K ICAgIDIpICg0LjQuMTIpRGF0YSBUcmFuc2ZlciBEYXRhIC0gYSBibG9jayBv ZiBkYXRhIHRvIHJldHVybi4gVGhlDQ0KICAgICAgICAgICAgICAgICAgICB2 YWx1ZSBoYXMgc3ViZmllbGRzOg0NCiAgICAgICAgICAgICAgICAgICAgYSkg ZGF0YSB0eXBlLCB3aXRoIHZhbHVlczoNDQogICAgICAgICAgICAgICAgICAg ICAgICAxIC0gV1RQIENyYXNoIERhdGENDQogICAgICAgICAgICAgICAgICAg ICAgICAyIC0gV1RQIE1lbW9yeSBEdW1wDQ0KICAgICAgICAgICAgICAgICAg ICBiKSBkYXRhIGJsb2NrIGxlbmd0aCAoOCBiaXRzLCB0aHVzIHJhbmdlIDAt MjU1KQ0NCiAgICAgICAgICAgICAgICAgICAgYykgYmxvY2sgb2YgZGF0YQ0N CiAgICAgICAgICAgICAgICAgICAgKERJU0NVU1M6IHRoaXMgaXMgc28gYnJv a2VuISBXaHkgaXMgaXQgc28NDQogICAgICAgICAgICAgICAgICAgIGRpZmZl cmVudCBmcm9tIGltYWdlIHRyYW5zZmVyPyBIb3cgZG8geW91IHRyYW5zZmVy DQ0KICAgICAgICAgICAgICAgICAgICBtb3JlIHRoYW4gMjU1IG9jdGV0cz8g ZXRjLCBldGMpDQ0KKDkuOClEYXRhIFRyYW5zZmVyIFJlc3BvbnNlKDIyKSAo cnVuIHN0YXRlKSAoQUMtPldUUCkNDQogIERlc2NyOiBUaGUgcmVzcG9uc2Ug dG8gYSAiRGF0YSBUcmFuc2ZlciBSZXF1ZXN0IiBtZXNzYWdlDQ0KICAgICAg ICAgKERJU0NVU1M6IFNlZSBESVNDVVNTIGZvciBEYXRhIFRyYW5zZmVyIFJl cXVlc3QuKQ0NCiAgTWVzc2FnZSBlbGVtZW50czogLS1ub25lLS0gKERJU0NV U1M6IFRoZSBkYXRhIHRyYW5zZmVyIHJlcXVlc3QgY2FuIGZhaWwuDQ0KICAg ICAgICAgVGhlcmUgbmVlZHMgdG8gYmUgc29tZSBpbmRpY2F0aW9uLikNDQoN DQooMTAuMSlNb2JpbGUgQ29uZmlnIFJlcXVlc3QoMjQpIChydW4gc3RhdGUp IChBQy0+V1RQKQ0NCiAgRGVzY3I6IFRoaXMgbWVzc2FnZSBpcyB1c2VkIHRv IGNyZWF0ZSwgbW9kaWZ5IG9yIGRlbGV0ZQ0NCiAgICAgICAgIFNUQSBzZXNz aW9uIHN0YXRlIG9uIGEgV1RQLiAoRElTQ1VTUzogdGhlIGFjdHVhbA0NCiAg ICAgICAgIGRldGFpbHMgb2YgaG93IHRoaXMgd29ya3Mgb24gYm90aCBzcGxp dE1BQyBhbmQNDQogICAgICAgICBlc3BlY2lhbGx5IGxvY2FsTUFDIGFyZSBu b3Qgd2VsbCBzcGVjaWZpZWQuDQ0KICAgICAgICAgVGhhdCBpcywgb25seSB0 aGUgZmlndXJlcyBhbmQgdGV4dCBpbiBzZWN0aW9ucw0NCiAgICAgICAgIDEx LjEuMSBhbmQgMTEuMS4yIHByb3ZpZGUgYW55IGNsdWUgYXMgdG8gZXZlbnRz DQ0KICAgICAgICAgdGhhdCB3b3VsZCBjYXVzZSBhbiBBQyB0byBzZW5kIHRo aXMgbWVzc2FnZSB0eXBlLg0NCiAgICAgICAgIEFsc28sIHRoZXJlIGFyZSBy ZXN0cmljdGlvbnMgb24gY29tYmluYXRpb25zDQ0KICAgICAgICAgb2YgcGFy YW1ldGVycyB0aGF0IGNhbiBiZSBpbmNsdWRlZCBpbiB0aGUNDQogICAgICAg ICBtZXNzYWdlLikNDQogICAgICAgICAoRElTQ1VTUzogaXQgZG9lc24ndCBz YXkgaWYgb25lIG1lc3NhZ2UgY2FuIGJlIHVzZWQNDQogICAgICAgICB0byB1 cGRhdGUgbW9yZSB0aGFuIG9uZSBTVEEuIEl0IHNob3VsZCBiZSBhYmxlLikN DQogIE1lc3NhZ2UgZWxlbWVudHM6DQ0KICAgIDEpICg0LjQuOClBZGQgTW9i aWxlIC0gYWRkcyBhIFNUQSBzZXNzaW9uLiBUaGUgdmFsdWUgaGFzIHN1YmZp ZWxkczoNDQogICAgICAgICAgICAgICAgICAgIGEpIHJhZGlvIElEDQ0KICAg ICAgICAgICAgICAgICAgICBiKSBTVEEgTUFDIGFkZHJlc3MNDQogICAgICAg ICAgICAgICAgICAgIGMpIFZMQU4gbmFtZSAoemVybyBsZW5ndGggZm9yIHNw bGl0TUFDIFdUUHMsIGFuZA0NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBvcHRpb25hbGx5IG5vbnplcm8gbGVuZ3RoIGZvciBsb2NhbE1BQyBXVFBz KQ0NCiAgICAyKSAoNC40LjE3KURlbGV0ZSBNb2JpbGUgLSBkZWxldGVzIGEg U1RBIHNlc3Npb24uIFRoZSB2YWx1ZSBoYXMNDQogICAgICAgICAgICAgICAg ICAgIHN1YmZpZWxkczoNDQogICAgICAgICAgICAgICAgICAgIGEpIHJhZGlv IElEDQ0KICAgICAgICAgICAgICAgICAgICBiKSBTVEEgTUFDIGFkZHJlc3MN DQogICAgMykgKDExLjEwLjExKUlFRUUgODAyLjExIE1vYmlsZShzZWUgMTEu OS4xKSAtIDgwMi4xMSBpbmZvIHRvDQ0KICAgICAgICAgICAgICAgICAgICBh dWdtZW50IGEgKDQuNC44KUFkZCBNb2JpbGUgbWVzc2FnZSBlbGVtZW50Lg0N CiAgICAgICAgICAgICAgICAgICAgVGhlIHZhbHVlIGhhcyBzdWJmaWVsZHM6 DQ0KICAgICAgICAgICAgICAgICAgICBhKSByYWRpbyBJRA0NCiAgICAgICAg ICAgICAgICAgICAgRElTQ1VTUzogc2hvdWxkbid0IHRoZSBTVEEgTUFDIGFk ZHJlc3MgYmUgaW5jbHVkZWQNDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHNvIHRoaXMgbWVzc2FnZSBlbGVtZW50IGNhbiBiZSBtYXRjaGVkDQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3aXRoIGEgKDQuNC44KUFk ZCBNb2JpbGUgbWVzc2FnZSBlbGVtZW50Pw0NCiAgICAgICAgICAgICAgICAg ICAgYikgYXNzb2NpYXRpb24gSUQgLSAxNi1iaXQgdmFsdWUgZnJvbSBJRUVF IDgwMi4xMQ0NCiAgICAgICAgICAgICAgICAgICAgYykgZmxhZ3MgLSAoOCBi aXRzKSBtdXN0IGJlIHNldCB0byB6ZXJvDQ0KICAgICAgICAgICAgICAgICAg ICBkKSBjYXBhYmlsaXRpZXMgLSB0aGUgMTYtYml0IHZhbHVlIG9mIHRoZSBJ RUVFIDgwMi4xMQ0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICJjYXBhYmlsaXRpZXMiIGZpZWxkDQ0KICAgICAgICAgICAgICAgICAg ICBlKSBXTEFOIElEDQ0KICAgICAgICAgICAgICAgICAgICBmKSBzdXBwb3J0 ZWQgUmF0ZXMgLSBhIHZhcmlhYmxlIGxlbmd0aCBlbmNvZGluZw0NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9mIHRoZSBzdXBwb3J0 ZWQgcmF0ZXMgZm9yDQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgdXNlIHdpdGggdGhlIFNUQQ0NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIChESVNDVVNTOiB3aGF0IGlzIHRoZSBlbmNvZGlu Zz8NDQogICAgNCkgKDExLjEwLjEyKUlFRUUgODAyLjExIE1vYmlsZSBTZXNz aW9uIEtleShzZWUgMTEuOS4xICYgMTEuOS4zKSAtDQ0KICAgICAgICAgICAg ICAgICAgICA4MDIuMTEga2V5aW5nIGluZm8gdG8gYXVnbWVudCBhICg0LjQu OClBZGQgTW9iaWxlDQ0KICAgICAgICAgICAgICAgICAgICBtZXNzYWdlIGVs ZW1lbnQuIFRoZSB2YWx1ZSBoYXMgc3ViZmllbGRzOg0NCiAgICAgICAgICAg ICAgICAgICAgYSkgU1RBIE1BQyBhZGRyZXNzDQ0KICAgICAgICAgICAgICAg ICAgICBiKSBFIC0gMSBiaXQgZmllbGQgdG8gaW5kaWNhdGUgb25seSBFQVAg ZnJhbWVzDQ0KICAgICAgICAgICAgICAgICAgICBjKSBDIC0gMSBiaXQgZmll bGQgdG8gaW5kaWNhdGUgZW5jcnlwdGlvbiBkb25lDQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGJ5IHRoZSBBQw0NCiAgICAgICAgICAgICAgICAg ICAgZCkgZmxhZ3MgLSAxNC1iaXRzLCBtdXN0IGJlIHplcm8NDQogICAgICAg ICAgICAgICAgICAgIGUpIGVuY3J5cHRpb24gcG9saWN5IC0gaGFzIHZhbHVl czoNDQogICAgICAgICAgICAgICAgICAgICAgIDAgLSBFbmNyeXB0IFdFUCAx MDQ6IEFsbCBwYWNrZXRzIHRvL2Zyb20gdGhlIFNUQQ0NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBtb2JpbGUgc3RhdGlvbiBtdXN0IGJlIGVuY3J5 cHRlZCB1c2luZyBzdGFuZGFyZA0NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAxMDQgYml0IFdFUC4NDQogICAgICAgICAgICAgICAgICAgICAgIDEg LSBDbGVhciBUZXh0OiBBbGwgcGFja2V0cyB0by9mcm9tIHRoZSBTVEEgZG8g bm90DQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlcXVpcmUgYW55 IGFkZGl0aW9uYWwgY3J5cHRvIHByb2Nlc3NpbmcgYnkNDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgdGhlIFdUUC4NDQogICAgICAgICAgICAgICAg ICAgICAgIDIgLSBFbmNyeXB0IFdFUCA0MDogQWxsIHBhY2tldHMgdG8vZnJv bSB0aGUgU1RBDQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIG11c3Qg YmUgZW5jcnlwdGVkIHVzaW5nIHN0YW5kYXJkIDQwIGJpdCBXRVAuDQ0KICAg ICAgICAgICAgICAgICAgICAgICAzIC0gRW5jcnlwdCBXRVAgMTI4OiBBbGwg cGFja2V0cyB0by9mcm9tIHRoZSBTVEENDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgbXVzdCBiZSBlbmNyeXB0ZWQgdXNpbmcgc3RhbmRhcmQgMTI4 IGJpdCBXRVAuDQ0KICAgICAgICAgICAgICAgICAgICAgICA0IC0gRW5jcnlw dCBBRVMtQ0NNUCAxMjg6IEFsbCBwYWNrZXRzIHRvL2Zyb20gdGhlIFNUQQ0N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICBtdXN0IGJlIGVuY3J5cHRl ZCB1c2luZyAxMjggYml0IEFFUyBDQ01QDQ0KICAgICAgICAgICAgICAgICAg ICAgICA1IC0gRW5jcnlwdCBUS0lQLU1JQzogQWxsIHBhY2tldHMgdG8vZnJv bSB0aGUgU1RBDQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIG11c3Qg YmUgZW5jcnlwdGVkIHVzaW5nIFRLSVAgYW5kIGF1dGhlbnRpY2F0ZWQNDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgdXNpbmcgTWljaGFlbA0NCiAg ICAgICAgICAgICAgICAgICAgZikgcGFpcndpc2UgVFNDIC0gNiBvY3RldCBU cmFuc21pdCBTZXF1ZW5jZSBDb3VudGVyIChUU0MpDQ0KICAgICAgICAgICAg ICAgICAgICBnKSBwYWlyd2lzZSBSU0MgLSA2IGJ5dGUgUmVjZWl2ZSBTZXF1 ZW5jZSBDb3VudGVyIChSU0MpDQ0KICAgICAgICAgICAgICAgICAgICBoKSBz ZXNzaW9uIGtleSAtIFRoZSBzZXNzaW9uIGtleSB0aGUgV1RQIGlzIHRvIHVz ZSB3aGVuDQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVuY3J5cHRp bmcgdHJhZmZpYyB0by9mcm9tIHRoZSBTVEEuIEZvcg0NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBkeW5hbWljYWxseSBjcmVhdGVkIGtleXMsIHRo aXMgaXMgY29tbW9ubHkga25vd24NDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgYXMgYSBQYWlyd2lzZSBUcmFuc2llbnQgS2V5IChQVEspLg0NCiAg ICA1KSAoMTEuMTAuMjApSUVFRSA4MDIuMTEgVXBkYXRlIE1vYmlsZSBRb1Mo c2VlIDExLjkuMykgLSBTZXQgdGhlDQ0KICAgICAgICAgICAgICAgICAgICBx dWFsaXR5IG9mIHNlcnZpY2UgcG9saWN5IGZvciBhIFNUQS4NDQogICAgICAg ICAgICAgICAgICAgIChESVNDVVNTOiBpcyB0aGlzIGZvciBkYXRhIHRyYWZm aWMgdG8gdGhlIEFDPw0NCiAgICAgICAgICAgICAgICAgICAgSWYgc28sIHRo ZW4gd2h5IGlzIHRoaXMgYW4gODAyLjExIG1lc3NhZ2UgZWxlbWVudCkNDQog ICAgICAgICAgICAgICAgICAgIFRoZSB2YWx1ZSBoYXMgc3ViZmllbGRzOg0N CiAgICAgICAgICAgICAgICAgICAgYSkgcmFkaW8gSUQNDQogICAgICAgICAg ICAgICAgICAgIGIpIFNUQSBNQUMgYWRkcmVzcw0NCiAgICAgICAgICAgICAg ICAgICAgYykgRFNQIHRhZyAtIFRoZSBEU0NQIGxhYmVsIHRvIHVzZSBpZiBw YWNrZXRzIGFyZQ0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHRvIGJlIERTQ1AgdGFnZ2VkLg0NCiAgICAgICAgICAgICAgICAgICAg ZCkgODAyLjFQIHRhZyAtIFRoZSA4MDIuMVAgcHJlY2VkZW5jZSB2YWx1ZSB0 byB1c2UgaWYNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBwYWNrZXRzIGFyZSB0byBiZSBJRUVFIDgwMi4xUCB0YWdnZWQuDQ0KICAg IDYpICgxMS4xMC4yNSlTdGF0aW9uIFFPUyBQcm9maWxlKHNlZSAxMS45LjEp IC0gc3BlY2lmaWVzIHRoZSBtYXgNDQogICAgICAgICAgICAgICAgICAgIHZh bHVlIHRoYXQgY2FuIGJlIHVzZWQgZm9yIDgwMi4xMWUgcHJpb3JpdHkgdGFn Lg0NCiAgICAgICAgICAgICAgICAgICAgVGhlIG1lc3NhZ2UgZWxlbWVudCB2 YWx1ZSBoYXMgc3ViZmllbGRzOg0NCiAgICAgICAgICAgICAgICAgICAgRElT Q1VTUzogb3RoZXIgc2ltaWxhciBtZXNzYWdlIGVsZW1lbnRzDQ0KICAgICAg ICAgICAgICAgICAgICBoYXZlIHJhZGlvIElEIGFzIGEgc3ViZmllbGQuIFdo eSBub3QgaGVyZT8NDQogICAgICAgICAgICAgICAgICAgIGEpIFNUQSBNQUMg YWRkcmVzcw0NCiAgICAgICAgICAgICAgICAgICAgYikgODAyLjFQIHByZWNl ZGVuY2UgdGFnDQ0KKDEwLjIpTW9iaWxlIENvbmZpZyBSZXNwb25zZSgyNSkg KHJ1biBzdGF0ZSkgKFdUUC0+QUMpDQ0KICBEZXNjcjogVGhlIHJlc3BvbnNl IHRvIGEgIk1vYmlsZSBDb25maWcgUmVxdWVzdCIgbWVzc2FnZS4NDQogICAg ICAgICAoRElTQ1VTUzogdGhlIHJlc3VsdCBjb2RlcyBkb24ndCBzcGVjaWZ5 IHdoeSB0aGUNDQogICAgICAgICBvcGVyYXRpb24gZmFpbGVkLCBvciBpbmRp Y2F0ZSB3aGljaCBtZXNzYWdlIGVsZW1lbnQNDQogICAgICAgICBjb250YWlu ZWQgdGhlIHByb2JsZW0uKQ0NCiAgTWVzc2FnZSBlbGVtZW50czoNDQogICAg MSkgKDQuNC4yOSlSZXN1bHQgQ29kZQ0NCg0NCigxMS43LjEpSUVFRSA4MDIu MTEgV0xBTiBDb25maWcgUmVxdWVzdCgzMzk4OTEyKDEzMjc3OjApKSAocnVu IHN0YXRlKSAoQUMtPldUUCkNDQogIERlc2NyOiBUaGUgbWVzc2FnZSBpcyB1 c2VkIHRvIG1hbmFnZSA4MDIuMTEgV0xBTiBjb25maWd1cmF0aW9uLCB3aGlj aA0NCiAgICAgICAgIGlzIGNyZWF0aW9uLCBkZWxldGlvbiBhbmQgbW9kaWZp Y2F0aW9uIG9mIGF0dHJpYnV0ZXMuDQ0KICAgICAgICAgKERJU0NVU1M6IHdo eSBpcyBhIG5ldyBtZXNzYWdlIHR5cGUgdGhhdCBpcyA4MDIuMTEgc3BlY2lm aWMNDQogICAgICAgICBuZWVkZWQgdG8gbW9kaWZ5IDgwMi4xMSBXTEFOcz8g SXQgc2VlbXMgbGlrZSB0aGUgZXhpc3RpbmcNDQogICAgICAgICAiKDguNClD b25maWd1cmF0aW9uIFVwZGF0ZSBSZXF1ZXN0IiBtZXNzYWdlIGNvdWxkIGJl IHVzZWQuKQ0NCiAgTWVzc2FnZSBlbGVtZW50czoNDQogICAgRElTQ1VTUzog bm90ZSBoZXJlIHRoZXJlIGFyZSBpbmZvcm1hdGlvbiBlbGVtZW50cyB0byBj cmVhdGUsDQ0KICAgICAgICAgICAgIGRlbGV0ZSwgYW5kIG1vZGlmeSBXTEFO cy4gSG93ZXZlciwgZm9yIG1lc3NhZ2UgdHlwZQ0NCiAgICAgICAgICAgICAi KDEwLjEpTW9iaWxlIENvbmZpZyBSZXF1ZXN0IiwgdGhlcmUgaXMgb25seSBh ZGQNDQogICAgICAgICAgICAgYW5kIGRlbGV0ZSAoYW5kIHRoZSAiYWRkIiB1 c2VkIHRvIG1vZGlmeSkuDQ0KICAgIDEpICgxMS4xMC4xKUlFRUUgODAyLjEx IEFkZCBXTEFOIC0gY3JlYXRlcyBvZiBtb2RpZmllcyBhIFdMQU4uIFRoZQ0N CiAgICAgICAgICAgICAgICAgICAgdmFsdWUgaGFzIHN1YmZpZWxkczoNDQog ICAgICAgICAgICAgICAgICAgIGEpIHJhZGlvIElEDQ0KICAgICAgICAgICAg ICAgICAgICBiKSBXTEFOIElEDQ0KICAgICAgICAgICAgICAgICAgICBjKSBy ZXNlcnZlZCAtICgxNiBiaXRzLCBtdXN0IGJlIHNldCB0byB6ZXJvKQ0NCiAg ICAgICAgICAgICAgICAgICAgZCkgZW5jcnlwdGlvbiBwb2xpY3ksIHdpdGgg dmFsdWVzOg0NCiAgICAgICAgICAgICAgICAgICAgICAgMCAtIEVuY3J5cHQg V0VQIDEwNDogQWxsIHBhY2tldHMgdG8vZnJvbSB0aGUgU1RBDQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgIG11c3QgYmUgZW5jcnlwdGVkIHVzaW5n IHN0YW5kYXJkIDEwNCBiaXQgV0VQLg0NCiAgICAgICAgICAgICAgICAgICAg ICAgMSAtIENsZWFyIFRleHQ6IEFsbCBwYWNrZXRzIHRvL2Zyb20gdGhlIFNU QQ0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBkbyBub3QgcmVxdWly ZSBhbnkgYWRkaXRpb25hbCBjcnlwdG8gcHJvY2Vzc2luZw0NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICBieSB0aGUgV1RQLg0NCiAgICAgICAgICAg ICAgICAgICAgICAgMiAtIEVuY3J5cHQgV0VQIDQwOiBBbGwgcGFja2V0cyB0 by9mcm9tIHRoZSBTVEENDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg bXVzdCBiZSBlbmNyeXB0ZWQgdXNpbmcgc3RhbmRhcmQgNDAgYml0IFdFUC4N DQogICAgICAgICAgICAgICAgICAgICAgIDMgLSBFbmNyeXB0IFdFUCAxMjg6 IEFsbCBwYWNrZXRzIHRvL2Zyb20gdGhlIFNUQQ0NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICBtdXN0IGJlIGVuY3J5cHRlZCB1c2luZyBzdGFuZGFy ZCAxMjggYml0IFdFUC4NDQogICAgICAgICAgICAgICAgICAgICAgIDQgLSBF bmNyeXB0IEFFUy1DQ01QIDEyODogQWxsIHBhY2tldHMgdG8vZnJvbSB0aGUg U1RBDQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIG11c3QgYmUgZW5j cnlwdGVkIHVzaW5nIDEyOCBiaXQgQUVTIENDTVANDQogICAgICAgICAgICAg ICAgICAgICAgIDUgLSBFbmNyeXB0IFRLSVAtTUlDOiBBbGwgcGFja2V0cyB0 by9mcm9tIHRoZSBTVEENDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg bXVzdCBiZSBlbmNyeXB0ZWQgdXNpbmcgVEtJUCBhbmQgYXV0aGVudGljYXRl ZA0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB1c2luZyBNaWNoYWVs DQ0KICAgICAgICAgICAgICAgICAgICBlKSBrZXkgLSBhIDMyIG9jdGV0IHNl c3Npb24ga2V5DQ0KICAgICAgICAgICAgICAgICAgICBmKSBrZXkgaW5kZXgg LSBpbmRleCBhc3NvY2lhdGVkIHdpdGggdGhlIGtleQ0NCiAgICAgICAgICAg ICAgICAgICAgZykga2V5IHN0YXR1cyAtIHN0YXRlIGFuZCB1c2FnZSBvZiBr ZXksIHdpdGggdmFsdWVzOg0NCiAgICAgICAgICAgICAgICAgICAgICAgIDAg LSBBIHZhbHVlIG9mIHplcm8sIHdpdGggdGhlICdFbmNyeXB0aW9uIFBvbGlj eScNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgZmllbGQgc2V0IHRv IGFueSB2YWx1ZSBvdGhlciB0aGFuICdDbGVhciBUZXh0Jw0NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICBtZWFucyB0aGF0IHRoZSBXTEFOIHVzZXMg cGVyLXN0YXRpb24gZW5jcnlwdGlvbg0NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICBrZXlzLCBhbmQgdGhlcmVmb3JlIHRoZSBrZXkgaW4gdGhlICdL ZXknIGZpZWxkDQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzIG9u bHkgdXNlZCBmb3IgbXVsdGljYXN0IHRyYWZmaWMuDQ0KICAgICAgICAgICAg ICAgICAgICAgICAgMSAtIFdoZW4gc2V0IHRvIG9uZSwgdGhlIFdMQU4gZW1w bG95cyBhIHNoYXJlZA0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBX RVAga2V5LCBhbHNvIGtub3duIGFzIGEgc3RhdGljIFdFUCBrZXksIGFuZA0N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICB1c2VzIHRoZSBlbmNyeXB0 aW9uIGtleSBmb3IgYm90aCB1bmljYXN0IGFuZA0NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICBtdWx0aWNhc3QgdHJhZmZpYyBmb3IgYWxsIHN0YXRp b25zLg0NCiAgICAgICAgICAgICAgICAgICAgICAgIDIgLSBUaGUgdmFsdWUg b2YgMiBpbmRpY2F0ZXMgdGhhdCB0aGUgQUMgd2lsbCBiZWdpbg0NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICByZWtleWluZyB0aGUgR1RLIHdpdGgg dGhlIFNUQSdzIGluIHRoZSBCU1MuDQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEl0IGlzIG9ubHkgdmFsaWQgd2hlbiBJRUVFIDgwMi4xMWkgaXMN DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgZW5hYmxlZCBhcyB0aGUg c2VjdXJpdHkgcG9saWN5IGZvciB0aGUgQlNTLg0NCiAgICAgICAgICAgICAg ICAgICAgICAgIDMgLSBUaGUgdmFsdWUgb2YgMyBpbmRpY2F0ZXMgdGhhdCB0 aGUgQUMgaGFzDQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbXBs ZXRlZCByZWtleWluZyB0aGUgR1RLIGFuZCBicm9hZGNhc3QNDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgcGFja2V0cyBubyBsb25nZXIgbmVlZCB0 byBiZSBkdXBsaWNhdGVkIGFuZA0NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICB0cmFuc21pdHRlZCB3aXRoIGJvdGggR1RLJ3MuDQ0KICAgICAgICAg ICAgICAgICAgICBoKSBRb1MgLSB0aGUgUW9TIHBvbGljeSwgd2l0aCB2YWx1 ZXM6DQ0KICAgICAgICAgICAgICAgICAgICAgICAgMCAtIEJlc3QgRWZmb3J0 DQ0KICAgICAgICAgICAgICAgICAgICAgICAgMSAtIFZpZGVvDQ0KICAgICAg ICAgICAgICAgICAgICAgICAgMiAtIFZvaWNlDQ0KICAgICAgICAgICAgICAg ICAgICAgICAgMyAtIEJhY2tncm91bmQNDQogICAgICAgICAgICAgICAgICAg IGkpIEF1dGggVHlwZSAtIGF1dGhlbnRpY2F0aW9uIHR5cGUsIHdpdGggdmFs dWVzOg0NCiAgICAgICAgICAgICAgICAgICAgICAgIDAgLSBPcGVuIFN5c3Rl bQ0NCiAgICAgICAgICAgICAgICAgICAgICAgIDEgLSBXRVAgU2hhcmVkIEtl eQ0NCiAgICAgICAgICAgICAgICAgICAgICAgIDIgLSBXUEEvV1BBMiA4MDIu MVgNDQogICAgICAgICAgICAgICAgICAgICAgICAzIC0gV1BBL1dQQTIgUFNL DQ0KICAgICAgICAgICAgICAgICAgICBqKSBNQUMgbW9kZSAtIG1vZGUgZm9y IHRoZSBXTEFOLCB3aXRoIHZhbHVlczoNDQogICAgICAgICAgICAgICAgICAg ICAgICAwIC0gTG9jYWwtTUFDOiAgU2VydmljZSBmb3IgdGhlIFdMQU4gaXMg dG8gYmUNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgcHJvdmlkZWQg aW4gTG9jYWwgTUFDIG1vZGUuDQ0KICAgICAgICAgICAgICAgICAgICAgICAg MSAtIFNwbGl0LU1BQzogIFNlcnZpY2UgZm9yIHRoZSBXTEFOIGlzIHRvIGJl DQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByb3ZpZGVkIGluIFNw bGl0IE1BQyBtb2RlLg0NCiAgICAgICAgICAgICAgICAgICAgaykgdHVubmVs IE1vZGUgLSB0dW5uZWxsaW5nIHR5cGUgZm9yIGFsbCBzdGF0aW9ucw0NCiAg ICAgICAgICAgICAgICAgICAgICAgIGZvciB0aGUgV0xBTiwgd2l0aCB2YWx1 ZXM6DQ0KICAgICAgICAgICAgICAgICAgICAgICAgMCAtIExvY2FsIEJyaWRn aW5nOiAgQWxsIHVzZXIgdHJhZmZpYyBpcyB0byBiZQ0NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBsb2NhbGx5IGJyaWRnZWQuDQ0KICAgICAgICAg ICAgICAgICAgICAgICAgMSAtIDgwMi4zIFR1bm5lbDogIEFsbCB1c2VyIHRy YWZmaWMgaXMgdG8gYmUNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg dHVubmVsZWQgdG8gdGhlIEFDIGluIDgwMi4zIGZvcm1hdA0NCiAgICAgICAg ICAgICAgICAgICAgICAgIDIgLSA4MDIuMTEgQnJpZGdpbmc6ICBBbGwgdXNl ciB0cmFmZmljIGlzIHRvIGJlDQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHR1bm5lbGVkIHRvIHRoZSBBQyBpbiA4MDIuMTEgZm9ybWF0Lg0NCiAg ICAgICAgICAgICAgICAgICAgbCkgU3VwcHJlc3MgU1NJRCAtIGlmIHplcm8s IFNTSUQgc3VwcHJlc3NlZCBpbg0NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICA4MDIuMTEgQmVhY29uLiBPdGhlcndpc2UsIFNTSUQgaW4gYmVhY29u Lg0NCiAgICAgICAgICAgICAgICAgICAgbSkgU1NJRCAtIHRoZSBTU0lEIHZh bHVlIChESVNDVVNTOiBuZWVkIHNpemUgaW5mbykNDQogICAgMikgKDExLjEw LjUpSUVFRSA4MDIuMTEgRGVsZXRlIFdMQU4gLSBkZWxldGUgYSBzcGVjaWZp ZWQgV0xBTi4gVGhlDQ0KICAgICAgICAgICAgICAgICAgICB2YWx1ZSBoYXMg c3ViZmllbGRzOg0NCiAgICAgICAgICAgICAgICAgICAgYSkgcmFkaW8gSUQN DQogICAgICAgICAgICAgICAgICAgIGIpIFdMQU4gSUQNDQogICAgMykgKDEx LjEwLjIxKUlFRUUgODAyLjExIFVwZGF0ZSBXTEFOIC0gdXBkYXRlcyBhbiBl eGlzdGluZyBXTEFOLg0NCiAgICAgICAgICAgICAgICAgICAgVGhlIHZhbHVl IGhhcyBzdWJmaWVsZHM6DQ0KICAgICAgICAgICAgICAgICAgICAoRElTQ1VT Uzogd2h5IGlzIHRoaXMgZGlmZmVyZW50IGZyb20gKDExLjEwLjEpPw0NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIElzIGl0IGp1c3QgZm9yIGFk ZGluZyBrZXlzPykNDQogICAgICAgICAgICAgICAgICAgIGEpIHJhZGlvIElE DQ0KICAgICAgICAgICAgICAgICAgICBiKSBXTEFOIElEDQ0KICAgICAgICAg ICAgICAgICAgICBjKSBlbmNyeXB0aW9uIHBvbGljeSAtIHNhbWUgYXMgaW4g MTEuMTAuMQ0NCiAgICAgICAgICAgICAgICAgICAgZCkga2V5IC0gc2FtZSBh cyBpbiAxMS4xMC4xDQ0KICAgICAgICAgICAgICAgICAgICBlKSBrZXkgaW5k ZXggLSBzYW1lIGFzIGluIDExLjEwLjENDQogICAgICAgICAgICAgICAgICAg IGYpIHNoYXJlZCBrZXkgKERJU0NVUzogdGhpcyBpcyBhIHR5cG8sIGFuZCBz aG91bGQNDQogICAgICAgICAgICAgICAgICAgICAgICBiZSAia2V5IHN0YXR1 cyIpIC0gc2FtZSBhcyAxMS4xMC4xDQ0KICAgIDQpICgxMS4xMC43KUlFRUUg ODAyLjExIEluZm8gRWxlbWVudCAtIHVzZWQgdG8gc3BlY2lmeSBhbg0NCiAg ICAgICAgICAgICAgICAgICAgSUVFRSA4MDIuMTEgaW5mb3JtYXRpb24gZWxl bWVudCAoSUUpLCB3aGljaA0NCiAgICAgICAgICAgICAgICAgICAgYXJlIHVz ZWQgaW4gSUVFRSA4MDIuMTEgbWFuYWdlbWVudCBmcmFtZXMuDQ0KICAgICAg ICAgICAgICAgICAgICBUaGUgdmFsdWUgaGFzIHN1YmZpZWxkczoNDQogICAg ICAgICAgICAgICAgICAgIGEpIEIgLSBpZiBzZXQsIGluY2x1ZGVkIGluIGJl YWNvbnMNDQogICAgICAgICAgICAgICAgICAgIGIpIFAgLSBpZiBzZXQsIGlu Y2x1ZGVkIGluIHByb2JlIHJlc3BvbnNlcw0NCiAgICAgICAgICAgICAgICAg ICAgYykgRmxhZ3MgLSAoNiBiaXRzKSBtdXN0IGJlIHplcm8NDQogICAgICAg ICAgICAgICAgICAgIGQpIFJhdyBJRSB2YWx1ZSAtIHRoZSBJRUVFIDgwMi4x MSBJRSBpbmNsdWRpbmcNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg dHlwZSwgbGVuZ3RoLCBhbmQgdmFsdWUNDQoNDQooMTEuNy4yKUlFRUUgODAy LjExIFdMQU4gQ29uZmlnIFJlc3BvbnNlKDMzOTg5MTMoMTMyNzc6MSkpIChy dW4gc3RhdGUpIChXVFAtPkFDKQ0NCiAgRGVzY3I6IFRoaXMgaXMgc2VudCBp biByZXNwb25zZSB0byBhIElFRUUgODAyLjExIFdMQU4gQ29uZmlnIHJlcXVl c3QuDQ0KICAgICAgICAgKERJU0NVU1M6IENBUFdBUCBpbmNvcnJlY3RseSBz YXlzIHRoYXQgdGhpcyBpcyBmcm9tIHRoZQ0NCiAgICAgICAgIEFDIHRvIHRo ZSBXVFAuKQ0NCiAgICAgICAgIChESVNDVVNTOiBBbnkgY29uZmlnIHJlcXVl c3QgY2FuIGZhaWwuIFRoaXMgcmVzcG9uc2UgZG9lcw0NCiAgICAgICAgIG5v dCBoYXZlIGEgZmFpbHVyZSBwYXJhbWV0ZXIuIEl0IG11c3QuKQ0NCiAgTWVz c2FnZSBlbGVtZW50czoNDQogICAgMSkgKDExLjEwLjMpSUVFRSA4MDIuMTEg QXNzaWduZWQgV1RQIEJTU0lEIChESVNDVVNTOiBUaGUgbWFwcGluZyBvZg0N CiAgICAgICAgV0xBTiBJRHMgdG8gQlNTSURzIHNlZW1zIGxpa2UgaXQgbmVl ZHMgYSBsaXR0bGUgbW9yZSB3b3JrKSAtIHVzZWQNDQogICAgICAgICAgICAg ICAgdG8gcmV0dXJuIHRoZSBCU1NJRCB0aGF0IHRoZSBXVFAgYXNzaWduZWQg dG8gdGhlDQ0KICAgICAgICAgICAgICAgIFdMQU4gSUQuIFRoZSB2YWx1ZSBp cyB0aGUgQlNTSUQuDQ0KDQ0KDQ0KDQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0NCg0NClN1bW1hcnkNDQotLS0tLS0tDQ0KKDUuMSlEaXNj b3ZlcnkgUmVxdWVzdCgxKSAoRGlzY292ZXJ5IHN0YXRlKSAoV1RQLT5BQykN DQooNS4yKURpc2NvdmVyeSBSZXNwb25zZSgyKSAobm8gc3RhdGUpIChBQy0+ V1RQKQ0NCig1LjMpUHJpbWFyeSBEaXNjb3ZlcnkgUmVxdWVzdCgxOSkgLSBE SVNDVVNTOnJlbW92ZSB0aGlzDQ0KKDUuNClQcmltYXJ5IERpc2NvdmVyeSBS ZXNwb25zZSgyMCkgLSBESVNDVVNTOnJlbW92ZSB0aGlzDQ0KKDYuMSlKb2lu IFJlcXVlc3QoMykgKEpvaW4gc3RhdGUpIChXVFAtPkFDKQ0NCig2LjIpSm9p biBSZXNwb25zZSg0KSAoSm9pbiBzdGF0ZSkgKEFDLT5XVFApDQ0KKDcuMSlF Y2hvIFJlcXVlc3QoMTMpIChhbnkgbm9ybWFsIHN0YXRlKSAoQUMtPldUUCBh bmQgV1RQLT5BQykNDQooNy4yKUVjaG8gUmVzcG9uc2UoMTQpIChhbnkgbm9y bWFsIHN0YXRlKSAoV1RQLT5BQyBhbmQgQUMtPldUUCkNDQooOC4yKUNvbmZp Z3VyYXRpb24gU3RhdHVzIFJlcG9ydCg1KSAoY29uZmlndXJlIHN0YXRlKSAo V1RQLT5BQykNDQooOC4zKUNvbmZpZ3VyZSBTdGF0dXMgQWNrKDYpIChjb25m aWd1cmUgc3RhdGUpIChBQy0+V1RQKQ0NCig4LjQpQ29uZmlndXJhdGlvbiBV cGRhdGUgUmVxdWVzdCg3KSAoY29uZmlndXJlIGFuZCBydW4gc3RhdGVzKSAo QUMtPldUUCkNDQooOC41KUNvbmZpZ3VyYXRpb24gVXBkYXRlIFJlc3BvbnNl KDgpIChjb25maWd1cmUgYW5kIHJ1biBzdGF0ZXMpIChXVFAtPkFDKQ0NCig4 LjYpQ2hhbmdlIFN0YXRlIEV2ZW50IFJlcG9ydCgxMSkgKGNvbmZpZ3VyZSBh bmQgcnVuIHN0YXRlcykgKFdUUC0+QUMpDQ0KKDguNylDaGFuZ2UgU3RhdGUg RXZlbnQgQWNrKDEyKSAoY29uZmlndXJlIGFuZCBydW4gc3RhdGVzKSAoQUMt PldUUCkNDQooOC44KUNsZWFyIENvbmZpZyBSZXF1ZXN0KDIzKSAoY29uZmln IGFuZCBydW4gc3RhdGUpIChBQy0+V1RQKQ0NCig5LjFhKUltYWdlIERhdGEg UmVxdWVzdCgxNSkgKGpvaW4vY29uZmlndXJlIGFuZCBydW4gc3RhdGVzKSAo V1RQLT5BQykNDQooOS4yYSlJbWFnZSBEYXRhIFJlc3BvbnNlKDE2KSAoam9p bi9jb25maWd1cmUgYW5kIHJ1biBzdGF0ZXMpIChBQy0+V1RQKQ0NCig5LjFi KUltYWdlIERhdGEgUmVxdWVzdCgxNSkgKGltYWdlIGRhdGEgc3RhdGUpIChB Qy0+V1RQKQ0NCig5LjJiKUltYWdlIERhdGEgUmVzcG9uc2UoMTYpIChpbWFn ZSBkYXRhIHN0YXRlKSAoV1RQLT5BQykNDQooOS4xYylJbWFnZSBEYXRhIFJl cXVlc3QoMTUpIChydW4gc3RhdGUpIChBQy0+V1RQKQ0NCig5LjJjKUltYWdl IERhdGEgUmVzcG9uc2UoMTYpIChydW4gc3RhdGUpIChXVFAtPkFDKQ0NCig5 LjMpUmVzZXQgUmVxdWVzdCgxNykgKHJ1biBzdGF0ZSkgKEFDLT5XVFApDQ0K KDkuNClSZXNldCBSZXNwb25zZSgxOCkgKHJ1biBzdGF0ZSkgKFdUUC0+QUMp DQ0KKDkuNSlXVFAgRXZlbnQgUmVwb3J0KDkpIChydW4gc3RhdGUpIChXVFAt PkFDKQ0NCig5LjYpV1RQIEV2ZW50IEFjaygxMCkgKHJ1biBzdGF0ZSkgKEFD LT5XVFApDQ0KKDkuNylEYXRhIFRyYW5zZmVyIFJlcXVlc3QoMjEpIChydW4g c3RhdGUpIChXVFAtPkFDKQ0NCig5LjgpRGF0YSBUcmFuc2ZlciBSZXNwb25z ZSgyMikgKHJ1biBzdGF0ZSkgKEFDLT5XVFApDQ0KKDEwLjEpTW9iaWxlIENv bmZpZyBSZXF1ZXN0KDI0KSAocnVuIHN0YXRlKSAoQUMtPldUUCkNDQooMTAu MilNb2JpbGUgQ29uZmlnIFJlc3BvbnNlKDI1KSAocnVuIHN0YXRlKSAoV1RQ LT5BQykNDQooMTEuNy4xKUlFRUUgODAyLjExIFdMQU4gQ29uZmlnIFJlcXVl c3QoMzM5ODkxMigxMzI3NzowKSkgKHJ1biBzdGF0ZSkgKEFDLT5XVFApDQ0K KDExLjcuMilJRUVFIDgwMi4xMSBXTEFOIENvbmZpZyBSZXNwb25zZSgzMzk4 OTEzKDEzMjc3OjEpKSAocnVuIHN0YXRlKSAoV1RQLT5BQykNDQoNDQpTb3J0 ZWQgYnkgTWVzc2FnZS9FbGVtZW50DQ0KTWVzc2FnZSAgICAgRWxlbWVudA0N CjA1LjAxLjAwCTA0LjA0LjE5DQ0KMDUuMDEuMDAJMDQuMDQuMzQNDQowNS4w MS4wMAkwNC4wNC4zNg0NCjA1LjAxLjAwCTA0LjA0LjM4DQ0KMDUuMDEuMDAJ MDQuMDQuMzkNDQowNS4wMi4wMAkwNC4wNC4wMQ0NCjA1LjAyLjAwCTA0LjA0 LjA0DQ0KMDUuMDIuMDAJMDQuMDQuNDANDQowNS4wMi4wMAkwNC4wNC40MQ0N CjA2LjAxLjAwCTA0LjA0LjI2DQ0KMDYuMDEuMDAJMDQuMDQuMzANDQowNi4w MS4wMAkwNC4wNC4zNA0NCjA2LjAxLjAwCTA0LjA0LjM3DQ0KMDYuMDEuMDAJ MDQuMDQuMzkNDQowNi4wMS4wMAkwNC4wNC40Mg0NCjA2LjAyLjAwCTA0LjA0 LjAyDQ0KMDYuMDIuMDAJMDQuMDQuMDMNDQowNi4wMi4wMAkwNC4wNC4yOQ0N CjA2LjAyLjAwCTA0LjA0LjMwDQ0KMDcuMDEuMDAJMDAuMDAuMDANDQowNy4w Mi4wMAkwMC4wMC4wMA0NCjA4LjAyLjAwCTA0LjA0LjA0DQ0KMDguMDIuMDAJ MDQuMDQuMDUNDQowOC4wMi4wMAkwNC4wNC4yOA0NCjA4LjAyLjAwCTA0LjA0 LjMxDQ0KMDguMDIuMDAJMDQuMDQuMzMNDQowOC4wMi4wMAkwNC4wNC40Mw0N CjA4LjAyLjAwCTA0LjA0LjQ0DQ0KMDguMDIuMDAJMTEuMTAuMDINDQowOC4w Mi4wMAkxMS4xMC4wNg0NCjA4LjAyLjAwCTExLjEwLjA4DQ0KMDguMDIuMDAJ MTEuMTAuMTMNDQowOC4wMi4wMAkxMS4xMC4xNA0NCjA4LjAyLjAwCTExLjEw LjE3DQ0KMDguMDIuMDAJMTEuMTAuMTgNDQowOC4wMi4wMAkxMS4xMC4xOQ0N CjA4LjAyLjAwCTExLjEwLjI0DQ0KMDguMDMuMDAJMDQuMDQuMDINDQowOC4w My4wMAkwNC4wNC4wMw0NCjA4LjAzLjAwCTA0LjA0LjEwDQ0KMDguMDMuMDAJ MDQuMDQuMTENDQowOC4wMy4wMAkwNC4wNC4xNQ0NCjA4LjAzLjAwCTA0LjA0 LjIyDQ0KMDguMDMuMDAJMDQuMDQuMzUNDQowOC4wMy4wMAkxMS4xMC4wMg0N CjA4LjAzLjAwCTExLjEwLjA0DQ0KMDguMDMuMDAJMTEuMTAuMDYNDQowOC4w My4wMAkxMS4xMC4wOA0NCjA4LjAzLjAwCTExLjEwLjEzDQ0KMDguMDMuMDAJ MTEuMTAuMTQNDQowOC4wMy4wMAkxMS4xMC4xNQ0NCjA4LjAzLjAwCTExLjEw LjE3DQ0KMDguMDMuMDAJMTEuMTAuMTgNDQowOC4wMy4wMAkxMS4xMC4yMg0N CjA4LjAzLjAwCTExLjEwLjI0DQ0KMDguMDQuMDAJMDQuMDQuMDINDQowOC4w NC4wMAkwNC4wNC4wMw0NCjA4LjA0LjAwCTA0LjA0LjA1DQ0KMDguMDQuMDAJ MDQuMDQuMDYNDQowOC4wNC4wMAkwNC4wNC4wNw0NCjA4LjA0LjAwCTA0LjA0 LjA5DQ0KMDguMDQuMDAJMDQuMDQuMTANDQowOC4wNC4wMAkwNC4wNC4xMQ0N CjA4LjA0LjAwCTA0LjA0LjE1DQ0KMDguMDQuMDAJMDQuMDQuMTYNDQowOC4w NC4wMAkwNC4wNC4xOA0NCjA4LjA0LjAwCTA0LjA0LjIyDQ0KMDguMDQuMDAJ MDQuMDQuMjYNDQowOC4wNC4wMAkwNC4wNC4yOA0NCjA4LjA0LjAwCTA0LjA0 LjMxDQ0KMDguMDQuMDAJMDQuMDQuMzUNDQowOC4wNC4wMAkwNC4wNC40Mg0N CjA4LjA0LjAwCTExLjEwLjAyDQ0KMDguMDQuMDAJMTEuMTAuMDQNDQowOC4w NC4wMAkxMS4xMC4wNg0NCjA4LjA0LjAwCTExLjEwLjA4DQ0KMDguMDQuMDAJ MTEuMTAuMTANDQowOC4wNC4wMAkxMS4xMC4xMw0NCjA4LjA0LjAwCTExLjEw LjE0DQ0KMDguMDQuMDAJMTEuMTAuMTUNDQowOC4wNC4wMAkxMS4xMC4xOA0N CjA4LjA0LjAwCTExLjEwLjIyDQ0KMDguMDQuMDAJMTEuMTAuMjQNDQowOC4w NS4wMAkwNC4wNC4wMg0NCjA4LjA1LjAwCTA0LjA0LjAzDQ0KMDguMDUuMDAJ MDQuMDQuMjkNDQowOC4wNi4wMAkwNC4wNC4xMQ0NCjA4LjA3LjAwCTAwLjAw LjAwDQ0KMDguMDguMDAJMDAuMDAuMDANDQowOS4wMS4wMAkwNC4wNC4yMw0N CjA5LjAxLjAwCTA0LjA0LjI0DQ0KMDkuMDEuMDAJMDQuMDQuMjUNDQowOS4w Mi4wMAkwMC4wMC4wMA0NCjA5LjAzLjAwCTAwLjAwLjAwDQ0KMDkuMDQuMDAJ MDAuMDAuMDANDQowOS4wNS4wMAkwNC4wNC4xNA0NCjA5LjA1LjAwCTA0LjA0 LjIwDQ0KMDkuMDUuMDAJMDQuMDQuMjENDQowOS4wNS4wMAkxMS4xMC4wOQ0N CjA5LjA1LjAwCTExLjEwLjE2DQ0KMDkuMDUuMDAJMTEuMTAuMjMNDQowOS4w Ni4wMAkwMC4wMC4wMA0NCjA5LjA3LjAwCTA0LjA0LjEyDQ0KMDkuMDcuMDAJ MDQuMDQuMTMNDQowOS4wOC4wMAkwMC4wMC4wMA0NCjEwLjAxLjAwCTA0LjA0 LjA4DQ0KMTAuMDEuMDAJMDQuMDQuMTcNDQoxMC4wMS4wMAkxMS4xMC4xMQ0N CjEwLjAxLjAwCTExLjEwLjEyDQ0KMTAuMDEuMDAJMTEuMTAuMjANDQoxMC4w MS4wMAkxMS4xMC4yNQ0NCjEwLjAyLjAwCTA0LjA0LjI5DQ0KMTEuMDcuMDEJ MTEuMTAuMDENDQoxMS4wNy4wMQkxMS4xMC4wNQ0NCjExLjA3LjAxCTExLjEw LjA3DQ0KMTEuMDcuMDEJMTEuMTAuMjENDQoxMS4wNy4wMgkxMS4xMC4wMw0N Cg0NClNvcnRlZCBieSBFbGVtZW50L01lc3NhZ2UNDQpNZXNzYWdlICAgICBF bGVtZW50DQ0KMDcuMDEuMDAJMDAuMDAuMDANDQowNy4wMi4wMAkwMC4wMC4w MA0NCjA4LjA3LjAwCTAwLjAwLjAwDQ0KMDguMDguMDAJMDAuMDAuMDANDQow OS4wMi4wMAkwMC4wMC4wMA0NCjA5LjAzLjAwCTAwLjAwLjAwDQ0KMDkuMDQu MDAJMDAuMDAuMDANDQowOS4wNi4wMAkwMC4wMC4wMA0NCjA5LjA4LjAwCTAw LjAwLjAwDQ0KMDUuMDIuMDAJMDQuMDQuMDENDQowNi4wMi4wMAkwNC4wNC4w Mg0NCjA4LjAzLjAwCTA0LjA0LjAyDQ0KMDguMDQuMDAJMDQuMDQuMDINDQow OC4wNS4wMAkwNC4wNC4wMg0NCjA2LjAyLjAwCTA0LjA0LjAzDQ0KMDguMDMu MDAJMDQuMDQuMDMNDQowOC4wNC4wMAkwNC4wNC4wMw0NCjA4LjA1LjAwCTA0 LjA0LjAzDQ0KMDUuMDIuMDAJMDQuMDQuMDQNDQowOC4wMi4wMAkwNC4wNC4w NA0NCjA4LjAyLjAwCTA0LjA0LjA1DQ0KMDguMDQuMDAJMDQuMDQuMDUNDQow OC4wNC4wMAkwNC4wNC4wNg0NCjA4LjA0LjAwCTA0LjA0LjA3DQ0KMTAuMDEu MDAJMDQuMDQuMDgNDQowOC4wNC4wMAkwNC4wNC4wOQ0NCjA4LjAzLjAwCTA0 LjA0LjEwDQ0KMDguMDQuMDAJMDQuMDQuMTANDQowOC4wMy4wMAkwNC4wNC4x MQ0NCjA4LjA0LjAwCTA0LjA0LjExDQ0KMDguMDYuMDAJMDQuMDQuMTENDQow OS4wNy4wMAkwNC4wNC4xMg0NCjA5LjA3LjAwCTA0LjA0LjEzDQ0KMDkuMDUu MDAJMDQuMDQuMTQNDQowOC4wMy4wMAkwNC4wNC4xNQ0NCjA4LjA0LjAwCTA0 LjA0LjE1DQ0KMDguMDQuMDAJMDQuMDQuMTYNDQoxMC4wMS4wMAkwNC4wNC4x Nw0NCjA4LjA0LjAwCTA0LjA0LjE4DQ0KMDUuMDEuMDAJMDQuMDQuMTkNDQow OS4wNS4wMAkwNC4wNC4yMA0NCjA5LjA1LjAwCTA0LjA0LjIxDQ0KMDguMDMu MDAJMDQuMDQuMjINDQowOC4wNC4wMAkwNC4wNC4yMg0NCjA5LjAxLjAwCTA0 LjA0LjIzDQ0KMDkuMDEuMDAJMDQuMDQuMjQNDQowOS4wMS4wMAkwNC4wNC4y NQ0NCjA2LjAxLjAwCTA0LjA0LjI2DQ0KMDguMDQuMDAJMDQuMDQuMjYNDQow OC4wMi4wMAkwNC4wNC4yOA0NCjA4LjA0LjAwCTA0LjA0LjI4DQ0KMDYuMDIu MDAJMDQuMDQuMjkNDQowOC4wNS4wMAkwNC4wNC4yOQ0NCjEwLjAyLjAwCTA0 LjA0LjI5DQ0KMDYuMDEuMDAJMDQuMDQuMzANDQowNi4wMi4wMAkwNC4wNC4z MA0NCjA4LjAyLjAwCTA0LjA0LjMxDQ0KMDguMDQuMDAJMDQuMDQuMzENDQow OC4wMi4wMAkwNC4wNC4zMw0NCjA1LjAxLjAwCTA0LjA0LjM0DQ0KMDYuMDEu MDAJMDQuMDQuMzQNDQowOC4wMy4wMAkwNC4wNC4zNQ0NCjA4LjA0LjAwCTA0 LjA0LjM1DQ0KMDUuMDEuMDAJMDQuMDQuMzYNDQowNi4wMS4wMAkwNC4wNC4z Nw0NCjA1LjAxLjAwCTA0LjA0LjM4DQ0KMDUuMDEuMDAJMDQuMDQuMzkNDQow Ni4wMS4wMAkwNC4wNC4zOQ0NCjA1LjAyLjAwCTA0LjA0LjQwDQ0KMDUuMDIu MDAJMDQuMDQuNDENDQowNi4wMS4wMAkwNC4wNC40Mg0NCjA4LjA0LjAwCTA0 LjA0LjQyDQ0KMDguMDIuMDAJMDQuMDQuNDMNDQowOC4wMi4wMAkwNC4wNC40 NA0NCjExLjA3LjAxCTExLjEwLjAxDQ0KMDguMDIuMDAJMTEuMTAuMDINDQow OC4wMy4wMAkxMS4xMC4wMg0NCjA4LjA0LjAwCTExLjEwLjAyDQ0KMTEuMDcu MDIJMTEuMTAuMDMNDQowOC4wMy4wMAkxMS4xMC4wNA0NCjA4LjA0LjAwCTEx LjEwLjA0DQ0KMTEuMDcuMDEJMTEuMTAuMDUNDQowOC4wMi4wMAkxMS4xMC4w Ng0NCjA4LjAzLjAwCTExLjEwLjA2DQ0KMDguMDQuMDAJMTEuMTAuMDYNDQox MS4wNy4wMQkxMS4xMC4wNw0NCjA4LjAyLjAwCTExLjEwLjA4DQ0KMDguMDMu MDAJMTEuMTAuMDgNDQowOC4wNC4wMAkxMS4xMC4wOA0NCjA5LjA1LjAwCTEx LjEwLjA5DQ0KMDguMDQuMDAJMTEuMTAuMTANDQoxMC4wMS4wMAkxMS4xMC4x MQ0NCjEwLjAxLjAwCTExLjEwLjEyDQ0KMDguMDIuMDAJMTEuMTAuMTMNDQow OC4wMy4wMAkxMS4xMC4xMw0NCjA4LjA0LjAwCTExLjEwLjEzDQ0KMDguMDIu MDAJMTEuMTAuMTQNDQowOC4wMy4wMAkxMS4xMC4xNA0NCjA4LjA0LjAwCTEx LjEwLjE0DQ0KMDguMDMuMDAJMTEuMTAuMTUNDQowOC4wNC4wMAkxMS4xMC4x NQ0NCjA5LjA1LjAwCTExLjEwLjE2DQ0KMDguMDIuMDAJMTEuMTAuMTcNDQow OC4wMy4wMAkxMS4xMC4xNw0NCjA4LjAyLjAwCTExLjEwLjE4DQ0KMDguMDMu MDAJMTEuMTAuMTgNDQowOC4wNC4wMAkxMS4xMC4xOA0NCjA4LjAyLjAwCTEx LjEwLjE5DQ0KMTAuMDEuMDAJMTEuMTAuMjANDQoxMS4wNy4wMQkxMS4xMC4y MQ0NCjA4LjAzLjAwCTExLjEwLjIyDQ0KMDguMDQuMDAJMTEuMTAuMjINDQow OS4wNS4wMAkxMS4xMC4yMw0NCjA4LjAyLjAwCTExLjEwLjI0DQ0KMDguMDMu MDAJMTEuMTAuMjQNDQowOC4wNC4wMAkxMS4xMC4yNA0NCjEwLjAxLjAwCTEx LjEwLjI1DQ0KDQ0K ---2133786286-2085581730-1151019083=:29535 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap ---2133786286-2085581730-1151019083=:29535-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jun 22 23:37:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtcTy-0006St-Sa for capwap-archive@lists.ietf.org; Thu, 22 Jun 2006 23:37:22 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtcTx-0002Xh-Fg for capwap-archive@lists.ietf.org; Thu, 22 Jun 2006 23:37:22 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 663504300FA for ; Thu, 22 Jun 2006 20:37:20 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 9D8A9430081 for ; Thu, 22 Jun 2006 20:36:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7ED83398023 for ; Thu, 22 Jun 2006 20:36:45 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D172C39803D for ; Thu, 22 Jun 2006 20:36:41 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5N3af1J009070; Thu, 22 Jun 2006 20:36:41 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5N3aeT2009067; Thu, 22 Jun 2006 20:36:41 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 22 Jun 2006 20:36:40 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Michael Montemurro In-Reply-To: <26140d940606220827m1e88b826xbdf4bb03a36fe501@mail.gmail.com> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap , Dorothy.Gellert@nokia.com Subject: Re: [Capwap] draft-ietf-capwap-protocol-specifciation-02.txt submission X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb HI, I noticed that unfortunately, there were some renumbering of sections for messsage types and message element types. This is making verification of the issues below harder, and also, the nice short 22 page summary that I sent out which includes section numbers now doesn't match the I-Ds section numbers. Can you quickly put out a -03 version that keeps the section numbers the same for the message types and message element types. Thanks, /david t. perkins On Thu, 22 Jun 2006, Michael Montemurro wrote: > All, > > draft-ietf-capwap-protocol-specifciation-02.txt has been submitted to > internet-drafts and should be available shortly. We would like to take this > time to thank everyone who contributed to resolving the issues that have > been addressed in this draft. We encourage everyone to review the updated > draft and point out any other issues in the submission. > > The issues that have been addressed in this draft include: 129, 128, 125, > 43, 80, 100, 136, 133, 126, 103, 104, 64, 37, 141, 77, 120, 119, 118, 83, > 66, 117, 107, 18, 123, 116, 130, 134, 132, 124, 106, 98, 97, 78, 45, 84, 81, > 74, 2, 63, 85, 86, and 105. > > Thanks, > > Dorothy, Pat and Mike > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 23 02:43:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtfO4-0004fY-0F for capwap-archive@lists.ietf.org; Fri, 23 Jun 2006 02:43:28 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtfFg-0008FC-Qs for capwap-archive@lists.ietf.org; Fri, 23 Jun 2006 02:34:50 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 807994300C5 for ; Thu, 22 Jun 2006 23:34:47 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id EA1D7430063 for ; Thu, 22 Jun 2006 23:34:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 80316144801A for ; Thu, 22 Jun 2006 23:34:06 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8B12E1448003 for ; Thu, 22 Jun 2006 23:34:03 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5N6Y2t6006260; Thu, 22 Jun 2006 23:34:02 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5N6Y2aZ006254; Thu, 22 Jun 2006 23:34:02 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 22 Jun 2006 23:34:02 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Dorothy Stanley In-Reply-To: <5bfe7a820606212328x5aca8a45oc73d051627cbe646@mail.gmail.com> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Proposed text for issue resolution X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 746e7c8096e71e3815c27253c4c3edc6 HI, Below is an update my earlier proposal to resolve this problem. I believe it also cleans up fragmentation in CAPWAP-01/02, and provides more efficient use of CAPWAP packets. --------------- Proposal for CAPWAP Packet Format -------------------------------- Updates from 8-jun-2006: 1) Made to look closer to CAPWAP-02 2) Added CAPWAP Fragmentation Header so that both control and data supported fragmentation 3) Updated descriptions of fields of packets 4) Changed how fragmentation is indicated. 5) Modified so that the Data (or Control) header is on in the first fragment of a CAPWAP PDU 6) Cleaned up Data Header, now that fragmentation is in a separate header and made the remaining fields match those in CAPWAP-02 7) Updated the Control Header so that it closely resembles CAPWAP-02, except for 'F' field. Updates from 7-jun-2006: 1) changed diagrams to make DTLS experts happier 2) renamed "CAPWAP MUX Hdr" to "CAPWAP Pkt Hdr", and made it 2 octets long instead of 1 octet 3) made the packet types start at 1 instead of zero 4) fixed a few typos 5) changed the formulas for the message type value and message element type value to multiply the IANA enterprise number by 4096 (shift left by 12) instead of 256 (shift left by 8). This means the the enterprise value must be encoded in 20 bits, and the specific type value in 12 bits. I checked the assignment of Enterprise numbers, and there are now approximately 16K, and also checked the OUI assignments and there are approximately 51K. Thus, 20 bits (1M) should be enough! --------------------------------- CAPWAP Packet formats: CAPWAP Unprotected Data Packet: +------------------------------[--------]----------+ | IP | UDP | CAPWAP | CAPWAP | CAPWAP | Wireless | | Hdr | Hdr | Pkt | Frag | Data | Payload | | | | Hdr | Ctrl | Hdr | | +------------------------------[--------]----------+ only in first fragment CAPWAP DTLS Protected Data Packet: +-------------------------------------[---------]--------------------+ | IP | UDP | CAPWAP | DTLS | CAPWAP | CAPWAP | Wireless | DTLS | | Hdr | Hdr | Pkt | Hdr | Frag | Data | Payload | Trailer | | | | Hdr | | Ctrl | Hdr | | | +-------------------------------------[---------]--------------------+ only in first fragment \--integrity checked-----------------/ \--encrypted----------------------------/ CAPWAP Unprotected Control Packet: +------------------------------[---------]----------+ | IP | UDP | CAPWAP | CAPWAP | CAPWAP | Message | | Hdr | Hdr | Pkt | Frag | Control | Elements | | | | Hdr | Ctrl | Hdr | | +------------------------------[---------]----------+ only in first fragment CAPWAP DTLS Protected Control Packet: +------------------------------------[---------]--------------------+ | IP | UDP | CAPWAP | DTLS | CAPWAP | CAPWAP | Message | DTLS | | Hdr | Hdr | Pkt | Hdr | Frag | Control | Elements | Trailer | | | | Hdr | | Ctrl | Hdr | | | +------------------------------------[---------]--------------------+ only in first fragment \--integrity checked----------------/ \--encrypted----------------------------/ UDP: All CAPWAP packets are encapsulated within UDP. CAPWAP Pkt Header: All CAPWAP protocol packets use a short header that specifies the version of CAPWAP and the type of the CAPWAP packet. CAPWAP Fragmentation Control: Used for fragmentation of CAPWAP PDUs. A CAPWAP PDU that will not fit in one UDP packet will be fragmented into multiple CAPWAP packets. CAPWAP Data Header: This header is used for CAPWAP data PDUs that encapsulate user data. If a CAPWAP data PDU is fragmented, then the CAPWAP Data Header is in only the first fragment in the group of fragments constructing the CAPWAP data PDU. Wireless Payload: The actual payload from or to for wireless devices. The format may be 802.3 Ethernet II, or native wireless transport specific encoding. DTLS Header: Protected CAPWAP packets use the DTLS protocol to provide message integrity and encryption services. DTLS Trailer: A field used to provide protection service for security of CAPWAP messages. CAPWAP Control Header: The CAPWAP protocol includes a signalling component, known as the CAPWAP control protocol. All CAPWAP control PDUs include a Control Header. If a CAPWAP control PDU is fragmented, then the CAPWAP Control Header is in only the first fragment in the group of fragments constructing the CAPWAP control PDU. Message Elements: A CAPWAP Control PDU includes zero, one, or more message elements, which are found immediately following the control header. These message elements are in a type, length, value format. CAPWAP Pkt Header: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version - the version of the CAPWAP protocol (the first is 1) DISCUSS: should this be split into major and minor, and if so, what are the implications of an increment of the major or minor part? Type - packet type, values are: 1 - CAPWAP Unprotected Data Packet 2 - CAPWAP DTLS Protected Data Packet 3 - CAPWAP Unprotected Control Packet 4 - CAPWAP DTLS Protected Control Packet 0,5-15 - reserved CAPWAP Fragmentation Header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|Res| CAPWAP PDU ID | Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M: The More 'M' bit indicates whether there are more fragment packets needed to be combined to reassemble a complete CAPWAP PDU. When this bit is 1, there are more fragment packets. When this bit is 0, there are no more fragments and this packet completes the CAPWAP PDU. Res: The bits are reserved, and must be zero. CAPWAP PDU ID: A 16-bit field whose value is assigned to each CAPWAP PDU. The CAPWAP PDU ID space is managed independently for every WTP/AC pair, for each end (an AC or WTP), and for each CAPWAP stream (data or control). For example, if AC #1 communicates with WTP #1 and WTP #2, there will be the following independent CAPWAP PDU IDs: WTP #1: ID1 for control going to AC #1 ID2 for data going to AC #1 WTP #2: ID3 for control going to AC #1 ID4 for data going to AC #1 AC #1: ID5 for control going to WTP #1 ID6 for data going to WTP #1 ID7 for control going to WTP #2 ID8 for data going to WTP #2 The value for each CAPWAP PDU ID is incremented with each new CAPWAP PDU sent whether or not the PDU is fragmented. The value wraps to zero after the maximum value has been used to identify a CAPWAP PDU. Fragment Offset: A 13 bit field that indicates where in the CAPWAP PDU will this fragment belong during re-assembly. This field should always have a valid value. For the first or only packet of a CAPWAP PDU, the value must be zero. The fragment offset is measured in units of 8 octets (64 bits). This provides a maximum size of a CAPWAP PDU to be 16 bits (which is 65536 octets). Note the CAPWAP protocol does not allow for overlapping fragments. For instance, it would be an error if the first fragment was 1000 octets in length, and the second fragment's offset was 800. To be valid (when the length of the first fragment is 1000, the second fragment MUST have an offset of 1000. CAPWAP Data Header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RID | HLEN | WBID |T|W|M| Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Radio MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Wireless Specific Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RID: A 5 bit field which contains the Radio ID for this CAPWAP data PDU. WTPs with multiple radios but a single MAC Address range (for BSSIDs) use this field to indicate which radio is associated with the packet. HLEN: A 5 bit field specifying the length of the CAPWAP data header header in 4 octet words (Similar to IP header length). This length includes the optional headers. T: The Type 'T' bit indicates the format of the frame being transported in the payload. When this bit is set to one (1), the payload has the native frame format indicated by the WBID field. When this bit is zero (0) the payload is an IEEE 802.3 frame. W: The 'W' bit is used to specify whether the optional "Wireless Specific Information" field is present in the header. A value of one (1) is used to represent the fact that the field is present. M: The 'M' bit is used to specify whether the optional "Radio MAC Address" field is present in the header. A value of one (1) is used to represent the fact that the field is present. Res: The bits are reserved and must be zero. Radio MAC Address: This optional field contains the BSSID of the radio receiving the packet. This is used in packets sent from the WTP to the AC, when the native wireless frame format is converted to 802.3 by the WTP. This field is only present if the 'M' bit is set. Given the HLEN field requires the header size to be a multiple of 4 octets, this field MUST be padded with zeroes (0x00) if it is not 4 octet aligned. The field has the format: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Length | MAC Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Length: The number of octets in the MAC Address field. The length field is present since new IEEE technologies (e.g., 802.16) are now using 64 bits (8 octet) MAC addresses. MAC Address: The BSSID of the receiving radio. Wireless Specific Information: This optional field contains technology specific information that may be used to carry per packet wireless information. This field is only present if the 'W' bit is set. Given the HLEN field assumes 4 octet alignment, this field MUST be padded with zeroes (0x00) if it is not 4 octet aligned. The field has the format: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Wireless ID | Length | Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Wireless ID: The wireless binding identifier. The following values are defined: 1 - : IEEE 802.11 Length: The length of the data field Data: Wireless specific information, whose details are defined in the technology specific bindings sections. For 802.11, when sent from WTP to AC, the data has the following format: IEEE 802.11 Frame Info: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSSI | SNR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RSSI: RSSI is a signed, 8-bit value. It is the received signal strength indication, in dBm. SNR: SNR is a signed, 8-bit value. It is the signal to noise ratio of the received IEEE 802.11 frame, in dB. Data Rate: The data rate field is a 16-bit unsigned integer value. The contents of the field is set to 1/10th of the data rate of the packet received by the WTP. For instance, a packet received at 5.5Mbps would be set to 55, while 11Mbps would be set to 110. For data sent from the AC to the WTP, the data has the following format: Destination WLANs: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WLAN: This bit vector indicates the WLAN ID(s) which the WTP will transmit the associated frame on. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be set to '1'. Note this field is to be set to zero for unicast packets and is unused if the WTP is not providing encryption services. Wireless Payload: The format of the wireless payload depends on the encapsulation mode. There are two formats defined, which are: 802.3 Frame - this is the standard IEEE 802.3 Ethernet II frame (DISCUSS: this needs to be confirmed) 802.11 native frame - DISCUSS: finish this CAPWAP Control Header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg ID | Length of Msg Elements |F| Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type: This field identifies the function of the CAPWAP control message. The Message Type field is comprised of an IANA Enterprise Number and an enterprise specific message type number. The first 20 bits is the enterprise number in network byte order, with zero being used for CAPWAP generic message types and the IEEE 802.11 IANA assigned enterprise number 13277 being used for IEEE 802.11 technology specific message types. The last 12 bits is the enterprise specific message type number, which has a range from 0 to 4095. The value of the message type field can be expressed as: Message type value = IANA Enterprise Number * 4096 + enterprise specific message type number Message ID: This field is used by the CAPWAP control application to match responses (or acknowledgements) with requests (or reports). The value must be monotonically incremented for each unique request (or report). After the maximum value is reached, the value wraps back to zero. The paired response (or acknowledgement) returns the value from the request (or report). Note the size is 8-bits, and thus a maximum of 255 CAPWAP operations can be currently outstanding. F: The 'F' bit field indicates if the message is the first message in a message pair. A value of "1" means first, and "0" means second in the pair. There are two types of message pairs, which are: 1) a request and response 2) a report and acknowledgement. Thus, the first is a request or report message (with the 'F' field set to "1"), and the second is a response or acknowledgement (with the 'F' field set to "0"). Note, both a request and response (or report and acknowledgement) of a operation type use the same value for message type. The 'F' bit is used to indicate which is which. This allows new message types to be added that can be processed without knowing the meaning of the message type. That is, when an unknown request message type is received, the response is the same message type with a message element indicating that the message type is not supported. Res: The bits are reserved and must be zero. Length of Message Elements: This field indicates in octets the length of the message elements field, which contains zero, one, or more message elements. The field is 16 bits wide, and thus the maximum size that can be specified 64K. However, the maximum size of a CAPWAP control PDU is 64K, and thus the max length is 64K minus the size of the CAPWAP control header, or 64K - 8, or 65528. Message Elements: The "message elements" field contains, zero, one, or more message element field, which has the following format: Message Element: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Element Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Value .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Message Element Type: This field identifies a message element of a CAPWAP control message. The Message Element Type field is comprised of an IANA Enterprise Number and an enterprise specific message element type number. The first 20 bits is the enterprise number in network byte order, with zero being used for CAPWAP generic message types and the IEEE 802.11 IANA assigned enterprise number 13277 being used for IEEE 802.11 technology specific message element types. The 12 bits is the enterprise specific message element type number, which has a range from 0 to 4095. The value of the message element type field can be expressed as: Message element type value = IANA Enterprise Number * 4096 + enterprise specific message element type number --------------- Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 23 10:30:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftmg8-0008G6-FI for capwap-archive@lists.ietf.org; Fri, 23 Jun 2006 10:30:36 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftmg5-0001H9-Ut for capwap-archive@lists.ietf.org; Fri, 23 Jun 2006 10:30:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DFCDF430111 for ; Fri, 23 Jun 2006 07:30:32 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 81D5743006C for ; Fri, 23 Jun 2006 07:30:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 631684315BE for ; Fri, 23 Jun 2006 07:30:01 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.198]) by hermes.tigertech.net (Postfix) with ESMTP id 5DCDA4315CD for ; Fri, 23 Jun 2006 07:29:58 -0700 (PDT) Received: by nz-out-0102.google.com with SMTP id q3so815087nzb for ; Fri, 23 Jun 2006 07:29:57 -0700 (PDT) Received: by 10.37.18.44 with SMTP id v44mr3849340nzi; Fri, 23 Jun 2006 07:29:57 -0700 (PDT) Received: by 10.36.20.6 with HTTP; Fri, 23 Jun 2006 07:29:57 -0700 (PDT) Message-ID: <5bfe7a820606230729yf482e2bqe932dbe6cb5debf6@mail.gmail.com> Date: Fri, 23 Jun 2006 07:29:57 -0700 From: "Dorothy Stanley" To: "David T. Perkins" In-Reply-To: MIME-Version: 1.0 References: <26140d940606220827m1e88b826xbdf4bb03a36fe501@mail.gmail.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.0 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Cc: capwap , Dorothy.Gellert@nokia.com Subject: Re: [Capwap] draft-ietf-capwap-protocol-specifciation-02.txt submission X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1775294627==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.0 (+) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a --===============1775294627== Content-Type: multipart/alternative; boundary="----=_Part_4262_12067939.1151072997751" ------=_Part_4262_12067939.1151072997751 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline David, I suggest that folks simply use your document with the -01 capwap specification, as indicated, and map as needed to the -02 draft. We plan to issue an -03 in late August, incorporating additional issue resolution. Thanks, Dorothy Stanley On 6/22/06, David T. Perkins wrote: > > HI, > > I noticed that unfortunately, there were some renumbering > of sections for messsage types and message element types. > > This is making verification of the issues below harder, > and also, the nice short 22 page summary that I sent > out which includes section numbers now doesn't match > the I-Ds section numbers. > > Can you quickly put out a -03 version that keeps the section > numbers the same for the message types and message element > types. > > Thanks, > /david t. perkins > > On Thu, 22 Jun 2006, Michael Montemurro wrote: > > All, > > > > draft-ietf-capwap-protocol-specifciation-02.txt has been submitted to > > internet-drafts and should be available shortly. We would like to take > this > > time to thank everyone who contributed to resolving the issues that have > > been addressed in this draft. We encourage everyone to review the > updated > > draft and point out any other issues in the submission. > > > > The issues that have been addressed in this draft include: 129, 128, > 125, > > 43, 80, 100, 136, 133, 126, 103, 104, 64, 37, 141, 77, 120, 119, 118, > 83, > > 66, 117, 107, 18, 123, 116, 130, 134, 132, 124, 106, 98, 97, 78, 45, 84, > 81, > > 74, 2, 63, 85, 86, and 105. > > > > Thanks, > > > > Dorothy, Pat and Mike > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_4262_12067939.1151072997751 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline David,

I suggest that folks simply use your document with the
-01 capwap specification, as indicated, and map as needed to the
-02 draft.

We plan to issue an -03  in late August, incorporating
additional issue resolution.

Thanks,

Dorothy Stanley

On 6/22/06, David T. Perkins <dperkins@dsperkins.com> wrote:
HI,

I noticed that unfortunately, there were some renumbering
of sections for messsage types and message element types.

This is making verification of the issues below harder,
and also, the nice short 22 page summary that I sent
out which includes section numbers now doesn't match
the I-Ds section numbers.

Can you quickly put out a -03 version that keeps the section
numbers the same for the message types and message element
types.

Thanks,
/david t. perkins

On Thu, 22 Jun 2006, Michael Montemurro wrote:
> All,
>
> draft-ietf-capwap-protocol-specifciation-02.txt has been submitted to
> internet-drafts and should be available shortly. We would like to take this
> time to thank everyone who contributed to resolving the issues that have
> been addressed in this draft. We encourage everyone to review the updated
> draft and point out any other issues in the submission.
>
> The issues that have been addressed in this draft include: 129, 128, 125,
> 43, 80, 100, 136, 133, 126, 103, 104, 64, 37, 141, 77, 120, 119, 118, 83,
> 66, 117, 107, 18, 123, 116, 130, 134, 132, 124, 106, 98, 97, 78, 45, 84, 81,
> 74, 2, 63, 85, 86, and 105.
>
> Thanks,
>
> Dorothy, Pat and Mike
>

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_4262_12067939.1151072997751-- --===============1775294627== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1775294627==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 23 14:17:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtqDW-0007Pk-4V for capwap-archive@lists.ietf.org; Fri, 23 Jun 2006 14:17:18 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtqDU-0001X4-Rk for capwap-archive@lists.ietf.org; Fri, 23 Jun 2006 14:17:18 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E1FB043011F for ; Fri, 23 Jun 2006 11:17:15 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id C688443005A for ; Fri, 23 Jun 2006 11:16:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id ACD31398048 for ; Fri, 23 Jun 2006 11:16:51 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A264539805F for ; Fri, 23 Jun 2006 11:16:47 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5NIGl3q009922 for ; Fri, 23 Jun 2006 11:16:47 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5NIGkDK009917 for ; Fri, 23 Jun 2006 11:16:47 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 23 Jun 2006 11:16:46 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [Capwap] Packet flows for new STA session X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c HI, There is a lot of detail missing in CAPWAP describing how a STA session is created for both splitMAC and localMAC. It would be quite useful if someone would take figures 5 and 7 and add the detail. Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 23 15:59:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftroh-0006j5-KT for capwap-archive@lists.ietf.org; Fri, 23 Jun 2006 15:59:47 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftrog-0007XW-54 for capwap-archive@lists.ietf.org; Fri, 23 Jun 2006 15:59:47 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 19A294300CD for ; Fri, 23 Jun 2006 12:59:45 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id DFCB9430058 for ; Fri, 23 Jun 2006 12:59:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C4F3E431BFB for ; Fri, 23 Jun 2006 12:59:14 -0700 (PDT) Received: from web60315.mail.yahoo.com (web60315.mail.yahoo.com [209.73.178.138]) by hermes.tigertech.net (Postfix) with SMTP id 68F99431BF1 for ; Fri, 23 Jun 2006 12:59:11 -0700 (PDT) Received: (qmail 13398 invoked by uid 60001); 23 Jun 2006 19:59:10 -0000 Message-ID: <20060623195910.13396.qmail@web60315.mail.yahoo.com> Received: from [12.129.211.52] by web60315.mail.yahoo.com via HTTP; Fri, 23 Jun 2006 12:59:10 PDT Date: Fri, 23 Jun 2006 12:59:10 -0700 (PDT) From: Behcet Sarikaya To: "David T. Perkins" , capwap@frascone.com In-Reply-To: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.0 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_WHOIS, HTML_40_50, HTML_MESSAGE X-Spam-Level: Subject: Re: [Capwap] Packet flows for new STA session X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Behcet Sarikaya List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0441015566==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 --===============0441015566== Content-Type: multipart/alternative; boundary="0-1135028901-1151092750=:11096" --0-1135028901-1151092750=:11096 Content-Type: text/plain; charset=us-ascii Hi David, Roaming with key caching and other new developments is a work item for possible rechartering. I think the present text is OK. Regards, --behcet ----- Original Message ---- From: David T. Perkins To: capwap@frascone.com Sent: Friday, June 23, 2006 1:16:46 PM Subject: [Capwap] Packet flows for new STA session HI, There is a lot of detail missing in CAPWAP describing how a STA session is created for both splitMAC and localMAC. It would be quite useful if someone would take figures 5 and 7 and add the detail. Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --0-1135028901-1151092750=:11096 Content-Type: text/html; charset=us-ascii
Hi David,
  Roaming with key caching and other new developments is a work item for possible rechartering. I think the present text is OK.

Regards,

--behcet

----- Original Message ----
From: David T. Perkins <dperkins@dsperkins.com>
To: capwap@frascone.com
Sent: Friday, June 23, 2006 1:16:46 PM
Subject: [Capwap] Packet flows for new STA session

HI,

There is a lot of detail missing in CAPWAP describing
how a STA session is created for both splitMAC and
localMAC. It would be quite useful if someone would
take figures 5 and 7 and add the detail.

Regards,
/david t. perkins

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

--0-1135028901-1151092750=:11096-- --===============0441015566== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0441015566==-- From marcello@gfsignet.com Sat Jun 24 01:49:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu11F-0005MZ-6a for capwap-archive@ietf.org; Sat, 24 Jun 2006 01:49:21 -0400 Received: from 60-240-217-2.tpgi.com.au ([60.240.217.2] helo=gfsignet.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fu11D-0003Pi-Dn for capwap-archive@ietf.org; Sat, 24 Jun 2006 01:49:21 -0400 Message-ID: <000001c69751$b1d2df90$f362a8c0@kve92> Reply-To: "Marcello Mcdavid" From: "Marcello Mcdavid" To: capwap-archive@ietf.org Subject: Re: my jaiua Date: Fri, 23 Jun 2006 22:47:35 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C69717.05740790" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C69717.05740790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 V l & G R A from 3,35 and many more at http://dupalerikason.com =20 _____ =20 =20 Goblin, and also because of the burning of the chief wolfs nose and the death from the wizards fire of many of his chief servants. So much they told him when he forced them, but he guessed there was more wickedness than this afoot, and that a great raid of the whole goblin army with their wolf-allies into the lands shadowed by the mountains might soon be made to find the dwarves, or to take vengeance on the men and creatures ------=_NextPart_000_0001_01C69717.05740790 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
V l & G R A from 3,35 and many more at http://dupalerikason.com
 
 
Goblin, and also because of the burning of the chief wolfs nose and = the
death from the wizards fire of many of his chief servants. So much = they
told him when he forced them, but he guessed there was more = wickedness
than this afoot, and that a great raid of the whole goblin army with
their wolf-allies into the lands shadowed by the mountains might soon = be
made to find the dwarves, or to take vengeance on the men and = creatures
------=_NextPart_000_0001_01C69717.05740790-- From gonsoulo@apollodesign.com Sat Jun 24 15:28:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuDne-00024R-1t for capwap-archive@ietf.org; Sat, 24 Jun 2006 15:28:10 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuDne-0005gr-0T for capwap-archive@ietf.org; Sat, 24 Jun 2006 15:28:10 -0400 Received: from atoulon-151-1-127-104.w86-206.abo.wanadoo.fr ([86.206.202.104] helo=apollodesign.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FuDhz-0000QD-7T for capwap-archive@ietf.org; Sat, 24 Jun 2006 15:22:24 -0400 Message-ID: <000001c697c3$01e3efd0$cc8ea8c0@yta32> Reply-To: "Ananth Gonsoulin" From: "Ananth Gonsoulin" To: capwap-archive@ietf.org Subject: Re: my teqio Date: Sat, 24 Jun 2006 12:18:43 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C69788.558788D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Antivirus: avast! (VPS 0625-7, 23/06/2006), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 4.5 (++++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C69788.558788D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 V l & G R A from 3,35 and many more at http://malinoviray.com =20 _____ =20 =20 house was perfect, whether you liked food, or sleep, or work, or story-telling, or singing, or just sitting and thinking best, or a pleasant mixture of them all. Evil things did not come into that valley. I wish I had time to tell you even a few of the tales or one or two of the songs that they heard in that house. All of them, the ponies as well, grew refreshed and strong in a few days there. Their clothes were ------=_NextPart_000_0001_01C69788.558788D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
V l & G R A from 3,35 and many more at http://malinoviray.com
 
 
house was perfect, whether you liked food, or sleep, or work, = or
story-telling, or singing, or just sitting and thinking best, or a
pleasant mixture of them all. Evil things did not come into that = valley.
I wish I had time to tell you even a few of the tales or one or = two
of the songs that they heard in that house. All of them, the ponies = as
well, grew refreshed and strong in a few days there. Their clothes = were
------=_NextPart_000_0001_01C69788.558788D0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jun 24 20:59:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuIy1-0007pU-Am for capwap-archive@lists.ietf.org; Sat, 24 Jun 2006 20:59:13 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuIxy-0007f4-BB for capwap-archive@lists.ietf.org; Sat, 24 Jun 2006 20:59:13 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6A26A430106 for ; Sat, 24 Jun 2006 17:59:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 97065430064 for ; Sat, 24 Jun 2006 17:58:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6A79B1448008 for ; Sat, 24 Jun 2006 17:58:25 -0700 (PDT) X-Greylist-Status: Sender first seen 23 days 09:42:44 ago Received: from co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by hermes.tigertech.net (Postfix) with ESMTP id 4C36E1448004 for ; Sat, 24 Jun 2006 17:58:23 -0700 (PDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5P0tHHk014743 for ; Sat, 24 Jun 2006 20:55:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 24 Jun 2006 18:58:21 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The MUX header Flux Thread-Index: AcaX8nLBTVv43WMSSSOPmSqBoxhm7Q== X-Priority: 1 Priority: Urgent Importance: high From: "Mani, Mahalingam (Mani)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_60_70, HTML_MESSAGE, X_PRIORITY_HIGH X-Spam-Level: Subject: [Capwap] The MUX header Flux X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0984495680==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 0e831a3b581a967a651997b2cbc2bae7 This is a multi-part message in MIME format. --===============0984495680== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C697F2.744F2C06" This is a multi-part message in MIME format. ------_=_NextPart_001_01C697F2.744F2C06 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All =20 http://home.comcast.net/~mmani/muxflux.pdf presents a summary of discussions that have been in progress so far on the proposal to use a mux-header for multiplexing control and data flows. Apologies for late summary. The attached also includes a proposed set of questions for consulting other SME (subject-matter-experts) as suggested by ADs. Some of them could be framed better; some more could be framed. =20 In the final analysis, we are positioned best to determine the best way to go based on inputs that may need clarifying not only from SMEs but also the current practices in the industry (enterprises, provider environments of various hues). We may not be able to get them all; if we do get a large subset that is goodness. Else, it is inevitable that additional field deployment experiences of the CAPWAP standard alone can help us refine it (a -bis, perhaps). =20 Preamble: More than a year ago, around when the WG was being rechartered to work on the protocol; it was suggested to treat the data-path independent of control path and leave it out of the CAPWAP protocol definition itself. However, architectural taxonomy indicated trends that found usefulness of split-MAC with tunneled forwarding of data to a centralized AC already having found some acceptance in many deployments also merited inclusion. Hence we are ending up classifying three modes - two in split-MAC and one in local-MAC. The Split-MAC treatment of data-traffic has led to questions about its protection, encapsulation and multiplexing with control stream. =20 Since then there has been a lot that happened including succeeding in getting a -00 version of the WG CAPWAP draft protocol out for review and a -01 following it. A member of the WG, Scott Kelly, has proposed use of mux header citing several reasons. =20 It also appears that - given the nature and intensity of discussions; as well as the stated/claimed deployment practices in enterprise and provider environments to enforce local policies - it becomes imperative to validate them over a broader network equipment vendor and customer space. =20 It also becomes apparent that a best-practices (applicability) document may be useful to guide operators (enterprise and provider) with best choices for given topologies. =20 While the presented approach of tables may not be the best way to summarize - this is captured in chronological order showing the progression of topics; it is interesting what has caused what looks to be a simple issue to resolve technically to take this magnitude of debate. =20 We would like not to linger long on debating the questions; simply send in your additions/changes and we (chairs) will recompile them once (hopefully to general agreement) and send it on to the ADs. =20 Regards, -mani PS: The technical merits of the reasons have been debated. Also in question is the concern about compatibility with existing implementations and behaviors on intermediate switches and routers processing along the way leading to performance inefficiencies. The discussions are not citing any correctness issues, however, mux-header or not. We will try to summarize them all and see why we gauge consensus in favor of mux-header. For those more used to other SDOs: That does not mean the perceived consensus cannot be opposed (as it happens ever so many times in other SDOs based on respective process mechanisms and influences of varied hues) or argued against/for - on technical merits and pitfalls. =20 It is customary, both thinly contended to closely contended issues (technical and otherwise) there is a need to call for consensus by stating a conclusion and calling the question. This may happen at many layers - not always requiring the chairs to intervene - as happens with many cases in the issue-tracker. However, in the event of strong dissent the chairs are required to/called upon to assess, gauge, state and validate "rough" consensus. This is what is happening. =20 =20 ------_=_NextPart_001_01C697F2.744F2C06 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All

 

http://home.comcast.n= et/~mmani/muxflux.pdf presents a summary of discussions that  have been in progress so = far on the proposal to use a mux-header for multiplexing control and data = flows. Apologies for late summary. The attached also includes a proposed set of questions = for consulting other SME (subject-matter-experts) as suggested by = ADs.

Some of them could be framed better; some more could = be framed.

 

In the final analysis, we are positioned best to = determine the best way to go based on inputs that may need clarifying not only = from SMEs but also the current practices in the industry (enterprises, provider environments of various hues). We may not be able to get them all; if we = do get a large subset that is goodness.

Else, it is inevitable that additional field = deployment experiences of the CAPWAP standard alone can help us refine it (a = –bis, perhaps).

 

Preamble:

More than a year ago, = around when the WG was being rechartered to work on the protocol; it was suggested = to treat the data-path independent of control path and leave it out of the CAPWAP protocol definition itself. However, architectural taxonomy indicated = trends that found usefulness of split-MAC with tunneled forwarding of data to a centralized AC already having found some acceptance in many deployments = also merited inclusion. Hence we are ending up classifying three modes = – two in split-MAC and one in local-MAC. The Split-MAC treatment of = data-traffic has led to questions about its protection, encapsulation and multiplexing = with control stream.

 

Since then there has been a lot that happened = including succeeding in getting a -00 version of the WG CAPWAP draft protocol out for review = and a -01 following it.

A member of the WG, Scott Kelly, has proposed use of = mux header citing several reasons.

 

It also appears that – given the nature and = intensity of discussions; as well as the stated/claimed deployment practices in enterprise and provider environments to enforce local policies – = it becomes imperative to validate them over a broader network equipment = vendor and customer space.

 

It also becomes apparent that a best-practices (applicability) document may be useful to guide operators (enterprise = and provider) with best choices for given = topologies.

 

While the presented approach of tables may not be the = best way to summarize – this is captured in chronological order showing = the progression of topics; it is interesting what has caused what looks to = be a simple issue to resolve technically to take this magnitude of = debate.

 

We would like not to linger long on debating the = questions; simply send in your additions/changes and we (chairs) will recompile = them once (hopefully to general agreement) and send it on to the = ADs.

 

Regards,

-mani

PS:

The technical merits of the reasons have been = debated. Also in question is the concern about compatibility with existing = implementations and behaviors on intermediate switches and routers processing along the = way leading to performance inefficiencies. The discussions are not citing = any correctness issues, however, mux-header or not. We will try to summarize = them all and see why we gauge consensus in favor of mux-header. For those = more used to other SDOs: That does not mean the perceived consensus cannot be = opposed (as it happens ever so many times in other SDOs based on respective process mechanisms and influences of varied hues) or argued against/for – = on technical merits and pitfalls.

 

It is customary, both thinly contended to closely = contended issues (technical and otherwise) there is a need to call for consensus = by stating a conclusion and calling the question. This may happen at many = layers – not always requiring the chairs to intervene – as happens = with many cases in the issue-tracker. However, in the event of strong dissent = the chairs are required to/called upon to assess, gauge, state and validate “rough” consensus. This is what is = happening.

 

 

------_=_NextPart_001_01C697F2.744F2C06-- --===============0984495680== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0984495680==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Jun 25 01:57:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuNcy-0008Px-Jc for capwap-archive@lists.ietf.org; Sun, 25 Jun 2006 01:57:48 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuNct-0007Zv-Ru for capwap-archive@lists.ietf.org; Sun, 25 Jun 2006 01:57:48 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 365504300DD for ; Sat, 24 Jun 2006 22:57:43 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 319C8430064 for ; Sat, 24 Jun 2006 17:42:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0FD4F144800B for ; Sat, 24 Jun 2006 17:42:54 -0700 (PDT) X-Greylist-Status: Sender first seen 4 mons 30 days 08:55:09 ago Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by hermes.tigertech.net (Postfix) with ESMTP id 8AA7C1448008 for ; Sat, 24 Jun 2006 17:42:52 -0700 (PDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5P0cj4F009876 for ; Sat, 24 Jun 2006 20:38:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C697F0.491F9D31" Date: Sat, 24 Jun 2006 18:42:50 -0600 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: The Mux header flux Thread-Index: AcaX8EUvTsiVAHJzSjeCfHzf8Tz4Gw== X-Priority: 1 Priority: Urgent Importance: high From: "Mani, Mahalingam (Mani)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Mailman-Approved-At: Sat, 24 Jun 2006 22:56:13 -0700 Subject: [Capwap] The Mux header flux X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 866eb9a7bb35c119d0ff01da04cba60a This is a multi-part message in MIME format. ------_=_NextPart_001_01C697F0.491F9D31 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C697F0.491F9D31" ------_=_NextPart_002_01C697F0.491F9D31 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 Attached is a summary of the discussions that have been in progress so far on the proposal to use a mux-header for multiplexing control and data flows. Apologies for late summary. The attached also includes a proposed set of questions for consulting other SME (subject-matter-experts) as suggested by ADs. Some of them could be framed better; some more could be framed. =20 In the final analysis, we are positioned best to determine the best way to go based on inputs that may need clarifying not only from SMEs but also the current practices in the industry (enterprises, provider environments of various hues). We may not be able to get them all; if we do get a large subset that is goodness. Else, it is inevitable that additional field deployment experiences of the CAPWAP standard alone can help us refine it (a -bis, perhaps). =20 Preamble: More than a year ago, around when the WG was being rechartered to work on the protocol; it was suggested to treat the data-path independent of control path and leave it out of the CAPWAP protocol definition itself. However, architectural taxonomy indicated trends that found usefulness of split-MAC with tunneled forwarding of data to a centralized AC already having found some acceptance in many deployments also merited inclusion. Hence we are ending up classifying three modes - two in split-MAC and one in local-MAC. The Split-MAC treatment of data-traffic has led to questions about its protection, encapsulation and multiplexing with control stream. =20 Since then there has been a lot that happened including succeeding in getting a -00 version of the WG CAPWAP draft protocol out for review and a -01 following it. A member of the WG, Scott Kelly, has proposed use of mux header citing several reasons. =20 It also appears that - given the nature and intensity of discussions; as well as the stated/claimed deployment practices in enterprise and provider environments to enforce local policies - it becomes imperative to validate them over a broader network equipment vendor and customer space. =20 It also becomes apparent that a best-practices (applicability) document may be useful to guide operators (enterprise and provider) with best choices for given topologies. =20 While the presented approach of tables may not be the best way to summarize - this is captured in chronological order showing the progression of topics; it is interesting what has caused what looks to be a simple issue to resolve technically to take this magnitude of debate. =20 We would like not to linger long on debating the questions; simply send in your additions/changes and we (chairs) will recompile them once (hopefully to general agreement) and send it on to the ADs. =20 Regards, -mani PS: The technical merits of the reasons have been debated. Also in question is the concern about compatibility with existing implementations and behaviors on intermediate switches and routers processing along the way leading to performance inefficiencies. The discussions are not citing any correctness issues, however, mux-header or not. We will try to summarize them all and see why we gauge consensus in favor of mux-header. For those more used to other SDOs: That does not mean the perceived consensus cannot be opposed (as it happens ever so many times in other SDOs based on respective process mechanisms and influences of varied hues) or argued against/for - on technical merits and pitfalls. =20 It is customary, both thinly contended to closely contended issues (technical and otherwise) there is a need to call for consensus by stating a conclusion and calling the question. This may happen at many layers - not always requiring the chairs to intervene - as happens with many cases in the issue-tracker. However, in the event of strong dissent the chairs are required to/called upon to assess, gauge, state and validate "rough" consensus. This is what is happening. Now that =20 ------_=_NextPart_002_01C697F0.491F9D31 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

Attached is a summary of the discussions that have = been in progress so far on the proposal to use a mux-header for multiplexing = control and data flows.

Apologies for late summary. The attached also = includes a proposed set of questions for consulting other SME = (subject-matter-experts) as suggested by ADs.

Some of them could be framed better; some more could = be framed.

 

In the final analysis, we are positioned best to = determine the best way to go based on inputs that may need clarifying not only = from SMEs but also the current practices in the industry (enterprises, provider = environments of various hues). We may not be able to get them all; if we do get a = large subset that is goodness.

Else, it is inevitable that additional field = deployment experiences of the CAPWAP standard alone can help us refine it (a –bis, = perhaps).

 

Preamble:

More than a year ago, = around when the WG was being rechartered to work on the protocol; it was suggested = to treat the data-path independent of control path and leave it out of the CAPWAP protocol definition itself. However, architectural taxonomy indicated = trends that found usefulness of split-MAC with tunneled forwarding of data to a centralized AC already having found some acceptance in many deployments = also merited inclusion. Hence we are ending up classifying three modes = – two in split-MAC and one in local-MAC. The Split-MAC treatment of = data-traffic has led to questions about its protection, encapsulation and multiplexing = with control stream.

 

Since then there has been a lot that happened = including succeeding in getting a -00 version of the WG CAPWAP draft protocol out = for review and a -01 following it.

A member of the WG, Scott Kelly, has proposed use of = mux header citing several reasons.

 

It also appears that – given the nature and = intensity of discussions; as well as the stated/claimed deployment practices in = enterprise and provider environments to enforce local policies – it becomes imperative to validate them over a broader network equipment vendor and customer space.

 

It also becomes apparent that a best-practices (applicability) document may be useful to guide operators (enterprise = and provider) with best choices for given = topologies.

 

While the presented approach of tables may not be the = best way to summarize – this is captured in chronological order showing = the progression of topics; it is interesting what has caused what looks to be a simple = issue to resolve technically to take this magnitude of = debate.

 

We would like not to linger long on debating the = questions; simply send in your additions/changes and we (chairs) will recompile = them once (hopefully to general agreement) and send it on to the = ADs.

 

Regards,

-mani

PS:

The technical merits of the reasons have been = debated. Also in question is the concern about compatibility with existing = implementations and behaviors on intermediate switches and routers processing along the = way leading to performance inefficiencies. The discussions are not citing = any correctness issues, however, mux-header or not. We will try to summarize = them all and see why we gauge consensus in favor of mux-header. For those = more used to other SDOs: That does not mean the perceived consensus cannot be = opposed (as it happens ever so many times in other SDOs based on respective process mechanisms and influences of varied hues) or argued against/for – = on technical merits and pitfalls.

 

It is customary, both thinly contended to closely = contended issues (technical and otherwise) there is a need to call for consensus = by stating a conclusion and calling the question. This may happen at many = layers – not always requiring the chairs to intervene – as happens = with many cases in the issue-tracker. However, in the event of strong dissent = the chairs are required to/called upon to assess, gauge, state and validate “rough” consensus. This is what is happening. Now = that

 

------_=_NextPart_002_01C697F0.491F9D31-- ------_=_NextPart_001_01C697F0.491F9D31 Content-Type: application/octet-stream; name="muxflux.pdf" Content-Transfer-Encoding: base64 Content-Description: muxflux.pdf Content-Disposition: attachment; filename="muxflux.pdf" JVBERi0xLjQNJeLjz9MNCjM2IDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyAzOCANL0ggWyAx MTYwIDM1MCBdIA0vTCAxNDc3NTQgDS9FIDY5OTMyIA0vTiA4IA0vVCAxNDY5MTYgDT4+IA1lbmRv YmoNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTM2IDM2IA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDEwNjcgMDAwMDAgbg0KMDAw MDAwMTUxMCAwMDAwMCBuDQowMDAwMDAxNzE3IDAwMDAwIG4NCjAwMDAwMDE4NzYgMDAwMDAgbg0K MDAwMDAwMTkxNSAwMDAwMCBuDQowMDAwMDAyNTE0IDAwMDAwIG4NCjAwMDAwMDI3MzYgMDAwMDAg bg0KMDAwMDAwMjc1NyAwMDAwMCBuDQowMDAwMDAzNjkwIDAwMDAwIG4NCjAwMDAwMDM3MTEgMDAw MDAgbg0KMDAwMDAwNDY0NSAwMDAwMCBuDQowMDAwMDA0Nzk5IDAwMDAwIG4NCjAwMDAwMDUwOTYg MDAwMDAgbg0KMDAwMDAwNTExNyAwMDAwMCBuDQowMDAwMDA2MDYyIDAwMDAwIG4NCjAwMDAwMDYw ODMgMDAwMDAgbg0KMDAwMDAwNzA0OCAwMDAwMCBuDQowMDAwMDA3MDY5IDAwMDAwIG4NCjAwMDAw MDc5OTMgMDAwMDAgbg0KMDAwMDAwODIyMSAwMDAwMCBuDQowMDAwMDA4NzA3IDAwMDAwIG4NCjAw MDAwMDg3MjggMDAwMDAgbg0KMDAwMDAwOTYwOCAwMDAwMCBuDQowMDAwMDA5NjI5IDAwMDAwIG4N CjAwMDAwMTA0NzggMDAwMDAgbg0KMDAwMDAxMDQ5OSAwMDAwMCBuDQowMDAwMDExMzI4IDAwMDAw IG4NCjAwMDAwMTQwMDUgMDAwMDAgbg0KMDAwMDAxNjk1OSAwMDAwMCBuDQowMDAwMDE3MDM3IDAw MDAwIG4NCjAwMDAwNDcyNjggMDAwMDAgbg0KMDAwMDA0NzQ3MiAwMDAwMCBuDQowMDAwMDY5NTY0 IDAwMDAwIG4NCjAwMDAwMDExNjAgMDAwMDAgbg0KMDAwMDAwMTQ4OSAwMDAwMCBuDQp0cmFpbGVy DTw8DS9TaXplIDcyDS9JbmZvIDMzIDAgUiANL1Jvb3QgMzcgMCBSIA0vUHJldiAxNDY5MDYgDS9J RFs8Yjk1YzRhNTU4ZThlNWMxZTVhMDExZTRhZjBiNjFmZTM+PDNhOTU1ZWRjMzU2ODg4MWU4NGEy YzgzNWFlNmM1ZTk2Pl0NPj4Nc3RhcnR4cmVmDTANJSVFT0YNICAgIA0zNyAwIG9iag08PCANL1R5 cGUgL0NhdGFsb2cgDS9QYWdlcyAzNSAwIFIgDS9NZXRhZGF0YSAzNCAwIFIgDS9QYWdlTGFiZWxz IDMyIDAgUiANPj4gDWVuZG9iag03MCAwIG9iag08PCAvUyAxNzIgL0wgMjc5IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlIC9MZW5ndGggNzEgMCBSID4+IA1zdHJlYW0NCkiJYmBgYGZgYOlgYGVgYN3EIMiA AIIMLAxsQMzxAsRrqmtpaTzU8NXBX0ArQFSBgeFZ2p9pCMWMzJzHbgoYzMmdCGJwGCo3qiROPT5z lttFHpemeepyqbuYBVSCUo/dA6mZwMCkGtHR0cHAAUNMKq5AgQagpSDSBSyFYSMQiDEwtk4F0iCe JlhElIGfsYRJg2GCioKkAgPjCQYGdiUmEY4FDAzFDQyMN4BcPmYbvg4GhuwEBsZ5DAxsAZoN0SuY 5x1w0H0t3XCEWYLNhTOChzWLwWAVQ8Px4DdwH8kzMJlpAWkmIPYGCDAAaOxBIA1lbmRzdHJlYW0N ZW5kb2JqDTcxIDAgb2JqDTIzNyANZW5kb2JqDTM4IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1Bh cmVudCAzNSAwIFIgDS9SZXNvdXJjZXMgMzkgMCBSIA0vQ29udGVudHMgWyA0NCAwIFIgNDYgMCBS IDUwIDAgUiA1MiAwIFIgNTQgMCBSIDU4IDAgUiA2MCAwIFIgNjIgMCBSIF0gDS9NZWRpYUJveCBb IDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiAN ZW5kb2JqDTM5IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RU MiA0MSAwIFIgL1RUMyA0NyAwIFIgL1RUNSA1NiAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA2 NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgNDAgMCBSID4+IA0+PiANZW5kb2JqDTQwIDAg b2JqDVsgDS9JQ0NCYXNlZCA2MyAwIFIgDV0NZW5kb2JqDTQxIDAgb2JqDTw8IA0vVHlwZSAvRm9u dCANL1N1YnR5cGUgL1RydWVUeXBlIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIgMTUwIA0vV2lk dGhzIFsgMjc4IDI3OCAwIDAgMCAwIDY2NyAxOTEgMzMzIDMzMyAwIDU4NCAyNzggMzMzIDI3OCAy NzggNTU2IDU1NiA1NTYgDTU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiAyNzggMjc4IDU4NCA1 ODQgNTg0IDU1NiAxMDE1IDY2NyA2NjcgDTcyMiA3MjIgNjY3IDYxMSA3NzggNzIyIDI3OCA1MDAg NjY3IDU1NiA4MzMgNzIyIDc3OCA2NjcgNzc4IDcyMiANNjY3IDYxMSA3MjIgNjY3IDk0NCA2Njcg NjY3IDAgMjc4IDAgMjc4IDAgMCAwIDU1NiA1NTYgNTAwIDU1NiA1NTYgDTI3OCA1NTYgNTU2IDIy MiAyMjIgNTAwIDIyMiA4MzMgNTU2IDU1NiA1NTYgNTU2IDMzMyA1MDAgMjc4IDU1NiANNTAwIDcy MiA1MDAgNTAwIDUwMCAwIDAgMCA1ODQgMCAwIDAgMCAwIDAgMTAwMCAwIDAgMCAwIDAgMCAwIDAg MCANMCAwIDIyMiAyMjIgMzMzIDMzMyAwIDU1NiBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGlu ZyANL0Jhc2VGb250IC9BTU9PTkMrQXJpYWwgDS9Gb250RGVzY3JpcHRvciA0MiAwIFIgDT4+IA1l bmRvYmoNNDIgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA5MDUgDS9D YXBIZWlnaHQgNzE4IA0vRGVzY2VudCAtMjExIA0vRmxhZ3MgMzIgDS9Gb250QkJveCBbIC02NjUg LTMyNSAyMDAwIDEwMDYgXSANL0ZvbnROYW1lIC9BTU9PTkMrQXJpYWwgDS9JdGFsaWNBbmdsZSAw IA0vU3RlbVYgOTQgDS9YSGVpZ2h0IDUxNSANL0ZvbnRGaWxlMiA2NiAwIFIgDT4+IA1lbmRvYmoN NDMgMCBvYmoNODU1IA1lbmRvYmoNNDQgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xl bmd0aCA0MyAwIFIgPj4gDXN0cmVhbQ0KSImEVttq3DAQffdXzKNdase3tb19axsoFAKFOFAIeVDW ymbbRDbZumm+o/ngjjQz8iUJZR9sSaMztzPH+6kNTto2hwzamyBLk7SBFH/0tk2hxremgfY+OPl8 rGB3dMcpHHcmOPlynsH+GMRonKYFtLsghfYxuAw/3kV1UoV3UZxVSR6+j+IGHxBdtV/RJM6SrMy3 0J5a+12AB+2PoH1HQM3GASVpVpWMRtePUbZJihAeo7zApY7SEHb2aBM+2EcT9lGMRw1aul258MuF UYa3GooY98L7KC5yjK83/giUMYffbr9w0AzJGIqXT4QMfeQc3fD1uYu/1sMZmV98t9erMKblrVYc YacZEAgIPW+qJBN3ieB2oyIDLGVe4g4jDT3fF8fP1it0+lrJjv4gIK7sWN7Ud2hV8dJXvKCKt+5q ZdPBmDnYmtPe2rTLFKOFM9q/iBBnE7pk69CWGA+pNgVHXoQj3f3japxL4gc+dYljrCO/6I5rWmBX nS+yp9ZtQuU2f1r/pe2XtZALGLVR5E3MNS2B0cVSvO9om+FAK7aTc8nhiaNUpgPTC9qgd3TxIIU5 8AbMm4e8UkYQzX5VADPPUnBUVNbCDq7DA1V31gqXiW/ybIYuPQ1tf6rwBRknFg4yQcM0Q0R8HAXh Hhz4RQZL1hi7J6I2HfZunkZuI3dxL+ZkGB+Ey4ynBbeXi2hfW2u8v/bNk2+h7wmHH6MRUzbhCRLX ctqbZDEgpEvZNvO6NBuVhWi9IVM0NPWr0a7XCvht9LRuPLur/8rNMiMsZrdywKmPvOTHlPqyyVNb vHrArVoqk6YlXGttZo2nTXp4Eu35Ra+E+Dj1DKTFynOjNwt6TIwUKnoeipkDkhw1FnU5BCUNgWjA SoBi0q6Fvi2nj0dsebhCk9G2RN34YR6Wh3rp+YUGsFrI56gQlzTxd05uOiWHCuZsmMSpdx/GmZSa zrW5Dn1+ClbCZvY+Rrg4/UYCjp8wZy5SfKTwVld780xmyVqC3vzO8MhkWVbRyJzTl93TiWmrZ0Qw L8gu5EKKCrEcKRUIQfqZHr3O7WHQBmVqLmDsWzDGjvUZu+Rn1VtJoNoPHprN0WCvxd1aeNBSAYtw moKV+Go2Zuu/HtPQvpSBq38CDACmTi3GDWVuZHN0cmVhbQ1lbmRvYmoNNDUgMCBvYmoNODU2IA1l bmRvYmoNNDYgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA0NSAwIFIgPj4g DXN0cmVhbQ0KSIm8Vttu00AQfc9XzBNao9qs7ylCSBWVkLhUSLgCqeXBibdJSrCtNqHNb/DFzO7M bGJHgJAQT+vdnes5szOu3kyqpxMd6UwnUD1MrtQmCOMiytTSQJCk0VR9CsJM4/o6KPEYXp0FcR4V 6gMtcutPw2mUKGju7MdU1WTjho2Kcej5vpOTbm4PctWRwjoIk8wKdtsN+fWG0F2CYlrdoUsFbMjQ /fcgTJMoVSvWNw/2HAOq2wZqCK2KjuEJhxmSMuY+Nk9RSBgdmxGz7QLkk8KLJDHGge19c+EUEp1s Z4ajhm6ID6v9gYMTRuRL5di7Uh8pHYFwM0b7Ld2bIbay7mzIKVpl6WV9Tyd7lnoUtardPbkwDWz5 iGUNb6ETDOE9KV8GocacPxMwjPjS1I0HwdcAkgq+DvQeLvz2yBsv0YqeRIlivm4s300tEjW75WBH iqYWTzC6qVvW6Ds+8RbRmXxLbF3rOcGUtZ5mUM3t44qLlB7XtuWsSwQKU7k8dw8mJlhKcVOyaaTA FV6qloFGKXKUEtFYHs6GixAr3UnwjaiLAkbmKu2UKy2VTFNXY1npX3LpaiwfFnBOpXNqtza6mSTB vuGe3G77owQi8TdApiwID5s9YV2oFflCaO3DxgLa2XPUvHVJJGob2LJyLnO2jy/yRj5Yak5atX2X hT/tWtZ7zuIUz7OqSiGG6mYSR+U0LyGMozhLTqE6ZwpLR6GN9oXWM6O1Tl9Wt1YxGSjqvcoR6+8M 4yNwMUudo0wg7t1uzYwx4I8kKTxuHDc7OmSK5K51+vh622btzxbuIQz8MUG8sB9xWzsRcnNgRF4S CmDvxCTKfRItSbO9bpAFfCUhY/p6vaLmnIhP8G40LvtKOwhSADvszvEwD7g4o4AqF6HtMLiN/XZM dPgPmc490xkxfS6tgNvGcKhh/nmBoUnj48Z7NCu0qPNSL8yw2QJvR1PpoLHbjgszg+x3+2Ey7rc7 iq7nuXAwjKiBXytS2LZH49rMh52UTTSjOTr8C/AZXgccyWEFZ7aCx2BsafvIY/0HZYbj5xedHC2M nP1X/nkQryhMCaEfzl3j/l0IAC4QfLStWcPMI9GMkFkgmZIrs25MC81f1dvJ8C/jt3PU9Q0mdT9G EcyfAgwAYpJA/A1lbmRzdHJlYW0NZW5kb2JqDTQ3IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1 YnR5cGUgL1R5cGUwIA0vQmFzZUZvbnQgL0FNT09QQytXaW5nZGluZ3MgDS9FbmNvZGluZyAvSWRl bnRpdHktSCANL0Rlc2NlbmRhbnRGb250cyBbIDY5IDAgUiBdIA0vVG9Vbmljb2RlIDQ4IDAgUiAN Pj4gDWVuZG9iag00OCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDIyMyA+ PiANc3RyZWFtDQpIiVSQsY7CMAyG9zyFRxBDQmGsKqGydICia7k9JG4v0jWJ3HTo219SFTgGx7J/ //IX87I6V9YE4DdyqsEAnbGacHQTKYQH9sbCPgNtVFir5VWD9MCjuZnHgENlOwd5zvhXFMdAM2xO l7q+lbu2PezEFnhNGsnYHjbtMbt/x04zef+LA9oAAooCNHaMlxfpr3JA4P/9b62dPUK21PuVxGkc vVRI0vYIuRDiUDwTWv2pP12PTv1IYu/pTBQsTq/95Es/fOGoiSiSLmdYQBKCsfi6lHc+bUvB/gQY ADPWbjgKZW5kc3RyZWFtDWVuZG9iag00OSAwIG9iag04NjcgDWVuZG9iag01MCAwIG9iag08PCAv RmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDQ5IDAgUiA+PiANc3RyZWFtDQpIiaxVXW/TMBR9 76/wo42WLG6SOhUICW0MMYEEWiaQNh7cxl0LJa7WlWo/gP+N7Xuv88H2gnhKbN+Pc889vq4vJ6d1 nTPJ6tUkkamqSsXcV8o5q88nSZZmWaVYvZxkrD5OXmXZwmRZlr+uv3vHKTiiX+ZdnIcs597DO+ey 8n43/ErIWTrlGzHN04r/FEnlVjtR+M/WiGmRFvxeyDKdcbYSFRniFhocRaHcSsNqu2Ui6VsdhuH2 Ip+nijPxrb6cJHlaKlmE2oppKC6LZTkbV0/9Austw4GrY1YA+DcAt7UPInFlFHxt7v1Wxdnep84d wIwv/VbJyWbjwHkYtmV2JZIicxEYFPAlLCv+TihnwCIn+RRq7S8XlAozsbUGg18iKWepDKmZRqO7 g2kiph3t6gfMb1ijCZ9mum0YgrYtbaOLdVG3WAG7Pv8EDLCdxXMyT4ZLD8Z3AzpcRRJal1YNSYEq iBlLjtAu14sb3rHNsANnwnXIKWQJFVK0Yez2DmJ0wu7pGnv/D8J+RhvvEeRbQFg7KJJfhE2nvR3S ZZBn05iWfhnVZ4EK6tuh09La95bMjt7MMYWU/9WKU/ximFFDjSZFRVBRzpZUAECo76S4Ww72F6E2 qBAFcYIR2BVcQWIjHvvG/IbotwLvzKg7yX9sTwHtKeUsh/Z8CNdpDrfFy9NhD+Urru9AMblXjF6A HW1tN0BOzh+9tavQgsEKt1ljdls0tmjj7h4wGAOHfBSJsjumJN5vr4hhYt2H+OhtC3/ncaM50p9h raHAQRm5v0Od6w+EbQgkEhHztuS9xyTQZkUB7CHixh00PCEGQh+zwUhNs1k+B+b3AACxUXkUcwmn a4NBQRyK1E7FsF0Y8WrYORgaktsRlzSeVEyTwHKhMY3rEJWJ+AwiOaDnGCi2Nhb9eYAvyF516DEY cU5p8UOxSUO0Ri+NalGuFDqy7UvK3DXSm2FIghl5WxsSbH/ASgy+oSCj04F02FkYt/6Sh+rguVLu GQxL3I2D+pnBiOOqm9E4zP1I+wiT4BrG+VeYHTjX1kY3XnFhVo1H0HNBSayu7MX4MBm8n91YlGX/ ybCRkHBM7xK9pQ9PPdWO0xgvTuzeAAiB8QBf7Z2O+LZPP1+Gao4xPGNressbpIDWpjdW/wgwADgi KKQNZW5kc3RyZWFtDWVuZG9iag01MSAwIG9iag04ODcgDWVuZG9iag01MiAwIG9iag08PCAvRmls dGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDUxIDAgUiA+PiANc3RyZWFtDQpIiZRVyW7bMBC96yvm SAUVw01bUfTQNgWaSzcBPTg5yLYMu7Al105S5Df6xR2SQ1mS0wS92BzO9uYNZ1RdR5dVpUFCtYoS yfMizQH/pVElVB+iRHAhihyqRSSg+h29EWLeCCH02+qn9VTekxyFdRHWmEGMBonmaS7NMKBXVBcU OXWRuciMjT5jVZzIjOds3cAmTpThhrWx0rxgQbyLc/wNUu2VWxJhf4iTAi+6fXeMZco1q3tdvd83 NelJCXcun2FdLBis64c4STMuWQNkcI/3BzyyVZwYwRWrFzZAypplMOm6Fuqg9uga5+USwSfKcGVl hQXmGP8jlZmlcMNs+F2caMUzFvBRlrWFpVR8W11HGKRAhgW4g1EZVwZ0ieUjdzvPp8j6TrF2aZmW eO3d/MlozQ36FZildztrw01sQXGCDjNX1ak3BLJBxjz/PW9ehHnTtOBQJ9pwEd6AHLwpQyllpn1O 3wrNmtYRi2k7z6rEk41b9iaEIMfHNHgbmpEj/WHvHKQEbfJwCeRZO+XEEZvqrItwEfSt6wcawAlC 61uHUXzzUla3j94sJGlcEorVOWH74IwV5nqFrKahhJFRCOj9gXQh9WZLqLawnBRAMO/HRDRL7KcD dEshOP37HonhgIrTCxqP6lnD/HvI7KzuqeBNT4VvGF0HWrq2IUivRwAwxzQt7pbU7xbx8tP5buNL bLgHtNvVh0d8M15a+SbBEulWtqMu8XERrI/HcNc5izbce2xXVSRB4LAInsFx0UalAK1wODOQ9nFm CE/yVMGhiVbRu2q4FSezZz1laccPB084hQ04GEEqRbGwl+pwwKf5xavChpuPVx+NXlgkPfhfCH8D UWF4rgLwXRBFapFvI6VTfi56Yyu6Os9kmXNhUHZ1Dc7B7scFtBPyRjBkKuwqsxOHvo6/rxN7hRSX fWoplJUmhE9pDj7/pNr0b23GvjXj8aR58rujnzi67doprZaprDjxGuTApDblkFgSA0Ha4JA8IQcy +0om8jMEjwFJqW3i5xjW6aglGY5A8RLDwecJhodj+Znomw/XoN9pBz+U7rthH7ndhCeWL8nxPe39 nV8j/VpsvYNdwE5Ba29dhxC0dyjlH+j678WTI93X43j+Pw5Ebls24mDGuvMv1Xayqu/6DTiY29SP cdmL82ZcSljkWMhfAQYAASgVlw1lbmRzdHJlYW0NZW5kb2JqDTUzIDAgb2JqDTg0NiANZW5kb2Jq DTU0IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNTMgMCBSID4+IA1zdHJl YW0NCkiJlFXLbtswELzrK3gkC4jhU6KPaRIULdC30rQIevBDiV04dmLHSPv33V1Ssh1Lbhojpsnh Ljkzu1L1LruosodMsxnLrBvIIjCrvPSGeakcMxa/V3XmjdkCJmyBq1dsAeFKBvgv2Hq8aPOYIH3B dFnCet4G3GSfs+CkcbBhgGtKusBy+iZ4D3TO4pk7sDclXuAfwXR0BHdONhYu34vivfvR9txuGAWI MqAEA0VqAaidkhr4a408aOvrKjupKg/bq5tMK6lAOvjEXxBpBgWGVHeZIgATAqYCBIwzIKuAYvWU XfNPIkjHV0IX0vLle1HKwC9hxr8TwEYnwjh+y2YLAVctORN45cDfpJAah6IZFgJya9j0s9otC5C0 NHAp25rfcjGWyLUY8m0wKox9VWKmRhgfNdwR5nOSxnRLY0DKAZ7m5cBEeUAPhVLApatfeGdNx6U6 9HvnFeTfi41I0V1moAXal3Q6mGGLxo1ce/IjL6XnSxJ7wHNYLvhkk6ZDRA2f07QAFE27T2ATk1I8 Eog2xs3kZNzBIjZN01nasY7Z2Tha2uSbP0v83OPUsp1GYut3up9aXx80fhI8Nv6ev6k944PksLe3 cNvaO+Gpe3vQ1L09aNO9PfBB9yLhY93bU6IYGWxbnrsFo5RNBaOCiQVzegYeFpyd0/BW5AGs+3om rIYq+hin3y6+EPpDUOeykcDVP9iqFmx0iF2J3BoYKwzxUIdxaxxmWH4QssYpOD+kBG0BHDIPxLWb eRff0kinlO5gHFxirAsbGd+v8IolX46w/h0+gu7iClsLap5ZWl+Mcd3xOtF4JBqWT2v24RQhjXSp yPOYYSTaTqAEk/bX7RG2pfoPqgVEhm6qHqle8ye8hEmXcHy+HRU6vVhGHq5x5y5ZN9xl6fg4Ojll zcJUKHhMR19JKcs3o3XcVT9s6sU2by9VH7DsX84WGsp2PPmSrdd8uI4WJeeWAt8eybZG+2HjW7Ow XMi0wi5TYM2W0bobkbv4Bmq0QV83EfxNShlwu5egK/D9sEPQhKMELTxB3REzp/VwUlPFgupPdK6D p0IJr39WnVNh+0HzToacVOKz+ZytaK+WFv7i3p5+qCebts6hrEGOsi1rcPKvAAMASwEBPw1lbmRz dHJlYW0NZW5kb2JqDTU1IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQg OTA1IA0vQ2FwSGVpZ2h0IDcxOCANL0Rlc2NlbnQgLTIxMSANL0ZsYWdzIDMyIA0vRm9udEJCb3gg WyAtNjI4IC0zNzYgMjAwMCAxMDEwIF0gDS9Gb250TmFtZSAvQU1PUEFEK0FyaWFsLEJvbGQgDS9J dGFsaWNBbmdsZSAwIA0vU3RlbVYgMTQ0IA0vWEhlaWdodCA1MTUgDS9Gb250RmlsZTIgNjggMCBS IA0+PiANZW5kb2JqDTU2IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1RydWVUeXBl IA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIgMTIxIA0vV2lkdGhzIFsgMjc4IDAgMCAwIDAgMCA3 MjIgMCAzMzMgMzMzIDAgMCAyNzggMzMzIDI3OCAyNzggMCA1NTYgNTU2IDU1NiA1NTYgDTU1NiA1 NTYgMCAwIDAgMzMzIDMzMyAwIDAgMCAwIDAgNzIyIDAgNzIyIDcyMiAwIDAgNzc4IDcyMiAyNzgg NTU2IA0wIDYxMSA4MzMgNzIyIDc3OCA2NjcgNzc4IDcyMiA2NjcgNjExIDcyMiAwIDk0NCA2Njcg MCAwIDMzMyAwIDMzMyANMCAwIDAgNTU2IDYxMSA1NTYgNjExIDU1NiAzMzMgNjExIDYxMSAyNzgg MCA1NTYgMjc4IDg4OSA2MTEgNjExIA02MTEgMCAzODkgNTU2IDMzMyA2MTEgNTU2IDc3OCA1NTYg NTU2IF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL0FNT1BBRCtBcmlh bCxCb2xkIA0vRm9udERlc2NyaXB0b3IgNTUgMCBSIA0+PiANZW5kb2JqDTU3IDAgb2JqDTgwMiAN ZW5kb2JqDTU4IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNTcgMCBSID4+ IA1zdHJlYW0NCkiJlFZLj9MwEL7nV/joIGL5Fce5IpAQ4gAiiMPCIdu4u0XdZNkHy/4NDvxexo9x m7S7q6pq6/FM7Pm+eaX7ULzrCs4sEcT/3q7GouVEqpoZ2NOcCUMqIVgtyY0r1sWbrhCccUs4fOLK 20vDakO6q4IHhT+mAiW3NelWxRkdNmUlNdP0thQ1U3RVVpbVdCqlYpb+LqvaMEHdjd+29DFqyeCu 3Ti4MVnjGa7keA4rK2Fgi5Q/ugDlVyHIhhRWs0aCW9r7XzNpiYGDrccgVQCVdVzvdN9ekXHBRjqp Vd5Q1JxpS6r8wLr4fIwSCcS1cIdVrJWRFqABfh4KcLX76T0V4RITLlH17BbTeI9foB2f2bvjCPWw Ekb7i89oF8hq6CXwt4gHWcrjdFc2ntieXKeoTOfbHIAQtqu4Ty4mfHq8IP2DV0raYxCTjCZ3KWLe iRy1Y1zYgP40LhrJNOfiCBtN4gB8VpIZeh8h/Amion/nTgIOWHmDf2TneOAj7S/5wnN9bia+EktI GvKRWIMDAHE6FU+76JEeNxyk9jGSGn4iQwby2i4Z2k+S97nc3Gv0YD9mS+DlUTp2WYMaPDTaY1ZM O7ryJeQac2cvHKhNHeNZUmrri/Q0XnTL1KKBndF+3p6mOdaB9MMwzw6UprHfLpgZo7guK+gNEkH3 iTCEl7bvE1u4fb+fVS/UjTa+9eyhl/ZF9KphVh/mRN3mtnVGN4AgFr+2AGBd2vDdgD+rUrXQV/zS lYg2Bh3QtXSTdm+j3bJZKyAfpk3qfldZjh16W9QyYDmQo72X5UKI42ubOVnKaBz6/YzEmSuiaWB/ 3u1hHkgdDCCrtA5/VZgKwWCnhucPhoV3RD6p9Zc/rZ2jPlA/MZiFToMZFqb1QV7BCHpuBkGamlOr J9+ynEE6zyAVs+iTz2JfSjCEY7fAqsEiUFmeRhJKrvVVEzQETS4duXT9EF8YIKO+07g4d2gRGoyi zo3k69t067N1I6TPrtNwcx+Lo/MGX3x2XkLT6sdh10sdGXAgf/ziDSQlezWe35By5Q+h8mczpYet R2ys2RBg/hdgAGgJFxINZW5kc3RyZWFtDWVuZG9iag01OSAwIG9iag03NzEgDWVuZG9iag02MCAw IG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDU5IDAgUiA+PiANc3RyZWFtDQpI iZRVTW/bMAy9+1fwKA+zIMmyLB+7YZcdhg3w0EPbg1srTbbVzpoVXf/9qA86H427BD5YEimJj098 bD9nn9pMggTBDWzuhqysNK8VKIELGqSpubJQSMkrBY8uW2Qf0F9wYUHgF0dpj2y8l5DQPmQimP2B V2zput495oXlll3n8Q93/l+x7mmTy4qXzOWFKtGQptD1/QqXNNfsT15Ig3+aj0P3Kw0hD5to2uWC vcSDHQ7TnZDftHM4pW24VGfitOIQ4jpdNSZYbhP/CQ1FPtzDrVvkhRZcsTHtcZC8Rgw57f+5BUHo T4QanKb70PIm+rrGhfPAG8u13cdfoIOwGtq7OKwraJ8xKw95USpP8vDiEXoMkeQVWdY+3iaB8o8g TMnqhgi+RLTBQNNV8h+HTTyYJwO0YWDYMhdcTn7JCw7nb6XGGI/6vNxUhjfmsABidiqfHRHz8jR0 iWd6Lmtiubslgt0U3W+MbwVZqRtuMCK8qzJQcaHBhMeLUVVKbQ0Y72S4fAfDPrx4isJ8+sPCAygm 90X2LbOaK40OmksDWpceOGJA0oMDmcP+sLy7XZV4/6zVXz5vrVTI9ZxZcBtw2ICjEQGwpwirCSP9 D0XeX+sj9KBVotIFYi48HYp9zBGvYTA41096BM9dqjcgsnzBQpc8XhcxVWFH/ltKX2PRypN3Opay 5FrPluHVVCpLlzThMshOzdocs8y++hAlQzlaxtKi0hh6+HIRjdETrplHJqciHbu+mMdRSv8wT8eh JG/UbMFcsdtJ67vhIK/D/XvSxn7SPU/cIi3Tf0cgSVJwTyLs2W9V7LDZpLuWuwr6Gq1sPL7T0eJI i+MCkXhzQ78eJzKIxdg2awbfk3Q5IJF8ivz9DVPFiui47bk1NQU6awzS+Aaoc2qqwaQe7QaJvn7c 7W7guv02T1knjlOF8ann7UugDTLbGC8NQecqL18YnipDvGTBF0iWIID7GG0S66geVRQa8vcKeASq woQ05kBCSNExzvbHXB9J15zVR7a3/BNgAL5TChQNZW5kc3RyZWFtDWVuZG9iag02MSAwIG9iag03 NTEgDWVuZG9iag02MiAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDYxIDAg UiA+PiANc3RyZWFtDQpIiZRVS2/bMAy++1fwKA21YFGyrRzXbdgDG9ChGXpod0jjtOiQ2F7b9fHv R+rhJK6DrShQiy+J/PiRyQrgv7tlm+WFKgpnYb7M6KQrA/PH7Fz8uJO6VFasoLuSuS2UFnAsc0ff U7bU9PHSZ5nrShnxHiQa5cSNzNGS3Eof4wpU0UNr6BfP4dp19OoWDSz5IisWLcif8y/Zh3mmQUOh Kp+fKa2qEbRFVVagq1qhg1xrVSLcrrKr7Jj8KXPnKwqnFGOMslTZJhuXW3K556LpwJdJechCwL1P 1IquU/E0ZPSbcrqBzNiZqhxoup+e2SR5Rr4O1lmJPruRGL1ZxpFgtCosCUPCIzk5n72Bdh+VvUR0 XZM+L/m/x+R75qxC6+2EmrWG4aLaKS/vsDUzcKzeiUZTKjxk5JcPGvcrHlt3C5gVBBN1lUhS/aud 5Osq5dx+J8/FNyaOI+I886EUsOj7deCfFcugW9zLmqSk7Vrob0NYN7Q7unaBwOvoGpkBf+JhNUlP zs1ynf9dSk2XVeNSMA9J9V3MLiVHIxM1iyYVcR0S3cjcoKqo7LaB61UoFC4TGGPuOk+pGhXhXnKX 6BIiG2WKxqeeTKQcTC+IF27h1pWhvYMrs26iYiRcyH2ngbxpeMnQdM1/cYKFcv4Ftzvws1cO+wRD wqybYbVhWG0XghGqxIo2FIonj6IWC4k2QmpFz0IgAkY/zwKClddeXHooTljpxFEU4ZOKJ4PmiPpB zQm98js0NhVFfyE5EIUaArtHdqR9yy8/yLws1Sy+fBvSTffFrk6CFqn4Gtwm6LizIz1uNuC2CTxM LGyaNCmryzg6T5F6QXrwYNLgtE1idZqpYfR47b5lG4qvdP6YWP+Or0ARTSfSzEh75n+I3FbrPwd2 9BSbeedODYBn+QjQtNnTct3jeVifYc8fWq4UOkxIakOwhBR4gOizExf27lQcW4aatB4/GHbyVOAe GLGSbdzwe/UyMJpCYLBu4/4KMABIarbsDWVuZHN0cmVhbQ1lbmRvYmoNNjMgMCBvYmoNPDwgL04g MyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0xlbmd0aCAyNTc1IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJnJZ5VFN3Fsd/b8mekJWww2MNW4CwBpA1bGGRHQRRCEkIARJCSNgFQUQF FEVEhKqVMtZtdEZPRZ0urmOtDtZ96tID9TDq6Di0FteOnRc4R51OZ6bT7x/v9zn3d+/v3d+9953z AKAnpaq11TALAI3WoM9KjMUWFRRipAkAAwogAhEAMnmtLi07IQfgksZLsFrcCfyLnl4HkGm9IkzK wDDw/4kt1+kNAEAZOAcolLVynDtxrqo36Ez2GZx5pZUmhlET6/EEcbY0sWqeved85jnaxAqNVoGz KWedQqMw8WmcV9cZlTgjqTh31amV9ThfxdmlyqhR4/zcFKtRymoBQOkmu0EpL8fZD2e6PidLgvMC AMh01Ttc+g4blA0G06Uk1bpGvVpVbsDc5R6YKDRUjCUp66uUBoMwQyavlOkVmKRao5NpGwGYv/Oc OKbaYniRg0WhwcFCfx/RO4X6r5u/UKbeztOTzLmeQfwLb20/51c9CoB4Fq/N+re20i0AjK8EwPLm W5vL+wAw8b4dvvjOffimeSk3GHRhvr719fU+aqXcx1TQN/qfDr9A77zPx3Tcm/JgccoymbHKgJnq Jq+uqjbqsVqdTK7EhD8d4l8d+PN5eGcpy5R6pRaPyMOnTK1V4e3WKtQGdbUWU2v/UxN/ZdhPND/X uLhjrwGv2AewLvIA8rcLAOXSAFK0Dd+B3vQtlZIHMvA13+He/NzPCfr3U+E+06NWrZqLk2TlYHKj vm5+z/RZAgKgAibgAStgD5yBOxACfxACwkE0iAfJIB3kgAKwFMhBOdAAPagHLaAddIEesB5sAsNg OxgDu8F+cBCMg4/BCfBHcB58Ca6BW2ASTIOHYAY8Ba8gCCJBDIgLWUEOkCvkBflDYigSiodSoSyo ACqBVJAWMkIt0AqoB+qHhqEd0G7o99BR6AR0DroEfQVNQQ+g76CXMALTYR5sB7vBvrAYjoFT4Bx4 CayCa+AmuBNeBw/Bo/A++DB8Aj4PX4Mn4YfwLAIQGsJHHBEhIkYkSDpSiJQheqQV6UYGkVFkP3IM OYtcQSaRR8gLlIhyUQwVouFoEpqLytEatBXtRYfRXehh9DR6BZ1CZ9DXBAbBluBFCCNICYsIKkI9 oYswSNhJ+IhwhnCNME14SiQS+UQBMYSYRCwgVhCbib3ErcQDxOPES8S7xFkSiWRF8iJFkNJJMpKB 1EXaQtpH+ox0mTRNek6mkR3I/uQEciFZS+4gD5L3kD8lXybfI7+isCiulDBKOkVBaaT0UcYoxygX KdOUV1Q2VUCNoOZQK6jt1CHqfuoZ6m3qExqN5kQLpWXS1LTltCHa72if06ZoL+gcuiddQi+iG+nr 6B/Sj9O/oj9hMBhujGhGIcPAWMfYzTjF+Jrx3Ixr5mMmNVOYtZmNmB02u2z2mElhujJjmEuZTcxB 5iHmReYjFoXlxpKwZKxW1gjrKOsGa5bNZYvY6WwNu5e9h32OfZ9D4rhx4jkKTifnA84pzl0uwnXm Srhy7gruGPcMd5pH5Al4Ul4Fr4f3W94Eb8acYx5onmfeYD5i/on5JB/hu/Gl/Cp+H/8g/zr/pYWd RYyF0mKNxX6LyxbPLG0soy2Vlt2WByyvWb60wqzirSqtNliNW92xRq09rTOt6623WZ+xfmTDswm3 kdt02xy0uWkL23raZtk2235ge8F21s7eLtFOZ7fF7pTdI3u+fbR9hf2A/af2Dxy4DpEOaocBh88c /oqZYzFYFTaEncZmHG0dkxyNjjscJxxfOQmccp06nA443XGmOoudy5wHnE86z7g4uKS5tLjsdbnp SnEVu5a7bnY96/rMTeCW77bKbdztvsBSIBU0CfYKbrsz3KPca9xH3a96ED3EHpUeWz2+9IQ9gzzL PUc8L3rBXsFeaq+tXpe8Cd6h3lrvUe8bQrowRlgn3Cuc8uH7pPp0+Iz7PPZ18S303eB71ve1X5Bf ld+Y3y0RR5Qs6hAdE33n7+kv9x/xvxrACEgIaAs4EvBtoFegMnBb4J+DuEFpQauCTgb9IzgkWB+8 P/hBiEtISch7ITfEPHGGuFf8eSghNDa0LfTj0BdhwWGGsINhfw8XhleG7wm/v0CwQLlgbMHdCKcI WcSOiMlILLIk8v3IySjHKFnUaNQ30c7Riuid0fdiPGIqYvbFPI71i9XHfhT7TBImWSY5HofEJcZ1 x03Ec+Jz44fjv05wSlAl7E2YSQxKbE48nkRISknakHRDaieVS3dLZ5JDkpcln06hp2SnDKd8k+qZ qk89lganJadtTLu90HWhduF4OkiXpm9Mv5MhyKjJ+EMmMTMjcyTzL1mirJass9nc7OLsPdlPc2Jz +nJu5brnGnNP5jHzivJ25z3Lj8vvz59c5Lto2aLzBdYF6oIjhaTCvMKdhbOL4xdvWjxdFFTUVXR9 iWBJw5JzS62XVi39pJhZLCs+VEIoyS/ZU/KDLF02KpstlZa+Vzojl8g3yx8qohUDigfKCGW/8l5Z RFl/2X1VhGqj6kF5VPlg+SO1RD2s/rYiqWJ7xbPK9MoPK3+syq86oCFrSjRHtRxtpfZ0tX11Q/Ul nZeuSzdZE1azqWZGn6LfWQvVLqk9YuDhP1MXjO7Glcapusi6kbrn9Xn1hxrYDdqGC42ejWsa7zUl NP2mGW2WN59scWxpb5laFrNsRyvUWtp6ss25rbNtenni8l3t1PbK9j91+HX0d3y/In/FsU67zuWd d1cmrtzbZdal77qxKnzV9tXoavXqiTUBa7ased2t6P6ix69nsOeHXnnvF2tFa4fW/riubN1EX3Df tvXE9dr11zdEbdjVz+5v6r+7MW3j4QFsoHvg+03Fm84NBg5u30zdbNw8OZT6TwCkAVv+mLiZJJmQ mfyaaJrVm0Kbr5wcnImc951kndKeQJ6unx2fi5/6oGmg2KFHobaiJqKWowajdqPmpFakx6U4pamm GqaLpv2nbqfgqFKoxKk3qamqHKqPqwKrdavprFys0K1ErbiuLa6hrxavi7AAsHWw6rFgsdayS7LC szizrrQltJy1E7WKtgG2ebbwt2i34LhZuNG5SrnCuju6tbsuu6e8IbybvRW9j74KvoS+/796v/XA cMDswWfB48JfwtvDWMPUxFHEzsVLxcjGRsbDx0HHv8g9yLzJOsm5yjjKt8s2y7bMNcy1zTXNtc42 zrbPN8+40DnQutE80b7SP9LB00TTxtRJ1MvVTtXR1lXW2Ndc1+DYZNjo2WzZ8dp22vvbgNwF3Ird EN2W3hzeot8p36/gNuC94UThzOJT4tvjY+Pr5HPk/OWE5g3mlucf56noMui86Ubp0Opb6uXrcOv7 7IbtEe2c7ijutO9A78zwWPDl8XLx//KM8xnzp/Q09ML1UPXe9m32+/eK+Bn4qPk4+cf6V/rn+3f8 B/yY/Sn9uv5L/tz/bf//AgwA94Tz+wplbmRzdHJlYW0NZW5kb2JqDTY0IDAgb2JqDTw8IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMjg2NSAvTGVuZ3RoMSA1MTgwID4+IA1zdHJlYW0NCkiJ zFZ9UFTXFT/33vexu0BYPrVi9a0vECOLxK+IaHCV3eVr0oBi3dVYdhcwoBgJOtSvOhhN0QfpTCYk nViNmFaDyCZvRS1mnMaaYmltx/pHUlOs6QcdM2noTKZa2+m09Nx3gQGmSftH/yiH3/7OPee8c885 976ZBwQA7NACDJzVzTu1t3LPnEHLMQA5f3PjM9t+dG+5ifotAKnqmYbdm7cVZeYBJCFgqK42XPOT 1s2VAKkSrh+vQ0NyiuNbAA7uf7hu285dJauNI7h+GoAdbtheHU6vSp8FkDwTgFzbFt7VyNaTnwKk DGG81thU2/jUjx+pAkjANcO8/2d/Nz/XswClmgToAboBte9ABH+PImoQr0EHdNBeEQOLECZqpXBX HoCF0GTZF8E+/PXCX0kXfNOyrIAI+iMY3Y9cgL5qZGLl6CDtFn8DDmHuz2gvvUqvWt6VmLeURwih vfIA2nm+g/AW3CFXMGYvvIy+S3CTP4WZOyAKD8hclDbyBzJMy9FK+P6YZytGd2C9P4AP4c8klRQQ g1zGmGR6wKpF7NaCMf0oN60sXJ4kDWQ7aSJHMOcQZXQJZt1OD9NOatKrLCgVyANKsrJUbcAsBCje viTskGf7CqzFnSPw3HhWIb8glFSQSlJHXiWdWEM/GUa5R3PoSpw6l1dYSIqXPpa3ym+gDCjr1OM2 BXPLoMAM0CATFmNXPtyjAmuugS2wx5K9KPtwls/DCeiEk3AGYvAO/JDvCYNwBx7gdBJReF9LyTKy HiWI0kT2k0M4j7YJ8iI5RnrJO1jfdfI+nY1dC2nA7kWVB+lRep5epz+jH9Eh+gn9jAGzsyoWYTvY KdbNbrAbUrHUKZ2Ubku3ZSKb1qSSlVRlk9KG0q7a1a3qIfUl9bh60TEfpmFfbuyrFNZjV7uxk31w GAzr1GIo5+ECygB8wvtAGRnthMsy4iV+sg4lSDaQENlGdpBd4x19j5wmXeQ89vI+yi0ySH5L/kj+ ZMkDqtB0mj3eXzldS9fTrfRV+ho9Rs/ijeyll+ktegd7HKL3scc4lszS2CzmY36USraR7WIHWZRd ZYNsGM8tXnpCKpDWSZuw92vSkPQxniSVmZwpL5HzUerkZ+X9cpv8Ot7oYXlYibemkqykKMuVVuWE 0qt8qPxDTVPT1Tko89UF6lq1QW1Wu9Uh9a6tx77KXm9vcrihGx6D7095ey/g7X6PblJyYQYZxNvw HEvEKI2/ezRebbDX015enbqWzMWT+jU8YHYok67BerYRGuQIi1M/hS6yQzpAzjI/9MAptZlcZiE2 zE7JmcpyMU96lHWru9WQehcrvcdeluvU+WSV3Ea66Ep8o5tIBfyF3Iev4c476Ty4BkfgMGkGG3TY ekgCvmv9dDZpk99g56RO5pP3k0fxBDPkAfYCLIE0iIe5MAfvugypCPAszVu6eNHCBY/lzs9xZ897 dO4jWZkP63Nc2uxZX56ZMeNL06elp6WmJCc5Ex9KiI9z2G2qIkuMEnD7dH9IM7NCppSlFxfn8LUe RkN4giFkamjyT44xtZAVpk2O9GDk5imRHhHpGY8kTm0FrMhxaz5dM3/u1bU+sqEigPqLXj2omcOW /qSlS1nWIgEXLhc+ofmm13k1k4Q0n+lvrjN8IS/mi8U5CvXCWkeOG2KOOFTjUDP9emOM+AuIpVC/ Lz9GwZaAVZmlutdnluheXoLJMn3hGrO8IuDzZrhcwRy3SQqr9YgJ+mozMdsKgUJrG1MpNFVrG62e twNtWsx9xWjvc0IklB1fo9eEnw6YLBzkeyRlm0W61yzaMzQ9x91HTlcGTHthH4HKwCUoHWmJlbR4 vUG+W3JhoNUKn4bh0/YMZTDDN71e40vDaNXMzorARK+L/waDmDTHXbYm4MKqdV+7xttYE7A6wKRk ei4WyW28TdFwre7jltAWzbTrq/U6Y0sID2uGYcKa3a5zM0o9l0Z+A6U+zagM6C5zZYYeDHtnxlLB WLO7t8SjlUz25LhjziQx6dhDiaNKfMJEpXbcZ2lWONew6rFRE16RXoJXxNSqNawkoJs0M4//1OaB UZ2HYfgXJDjRepxfyHDm84OQM526ZtwHvAj68KeTLeFRi5LpvA9c5ddl/Mqhf0w3s7PNefP4TVEL 8WixsgJrvSTH3WyW6Y1OzSzDkUF5AB8K5ufiyF0ufsptfR6I4MJsqQiItQaRjHPgyc0OmjTEPVfG PGnruKdlzDP+eEjH63we+AdZmmnLGv9PdKan+OryTZL+Be5a4cfXx6fFJDnTKA9khY22jKyQ0R7E o/Hjq2gYfl3zGyEj3DfSEtE1p27EysqMRl9orKW+kSttGaanPVhHcKjmIjENM6UwwDJoUGg0gwVz gNehLvhnOUBcO8DIDcdHVmUT/36HH4UtXFEQNo4CKLXPhQ5HPeIKlKpZ0GG/DFHWDf22HoiqcyBq TxxFlUBcK6IdorZ+iDrehaj8bQEeK21H3EQffsGor0CprRNzHkLdJfwWuF6EdoTUC1ElgM/XCqhH BKQaAR6vvAtfHYPt9xhXjLbruMdF9Gcg4tC2GG0HkNOgQymBjrG95L+NYgCBNSsb0Z42Wsc8UYvd g7mwbhXz2S4hY3/q1xEv4XoR8rOiV9sL+PwTyJuh15ENhyWcHcfYXjjP0inIm4S9GLN3yiz+x8Bv wCg7I3q29pmKEwL/KU7icUMTY4hz1HcT9cR/m9sCiUyxtX5+7H8HW2QK8NveJu7vgi+CQ8H7qYgz t859ct5fjusfjGJ0rSyZDJshMO7/+2SM2/dBPwc/Y0tfhTwBbBCqWRpU24qgxhMPfj/2kJxk8xRr ffTxc8ULkQ5aRHoEnRV0RlCXoDcFfVfQSUEnBJUIKhZUJGi1II+gAkErBC0TpAiSBDFBxPMU8m3E IOJXiA8Q7yEuIi4g3kZEET2ILsSbiBOI1xHHEe2Ig4hqRJWV822ROiqoW9BpQf9iv2pCooqi8Dn3 /dzrOOqMDfZoLH1ZEQw6/ixU7Geckoq3mVDCkcHsHyEoWgQukmlhBmFdch9FCW7MpwaNVuDCSqil LVoFQa2yXS0EZzr3vamQolXQpnv47nffdx73vvPe5Z1zJ3x64NMdnw761OnTXp/afOI+GT4xnyCR IH5LeENYJrwkvCA8JzwmPCLMER4S7hJuE4YIpw83R0oiJa0yh5cTR7i8x+U4l2NcXuDyPJdnuTzD ZYbLPi7TXPbyHWK7qBXbRLXYIixRJSKiUoREuQiKgBDCFLpggvaou0lzmNOdRMddPAXOyVr3a3dd DgNH+1yjLolupQNOT9Jy22Iuu+5VHjkszCDeHImqomMeEAsjY9Eip9NQFfu1WRuunNTQU6jBVuDU t8zxmiWu1G5SpadKpUpPtXA2Bc3OiRsDW+E3E/9s+Efvhju7BlW4qd4ZAcn0gYzPc6w0QPEMRO10 sip0cZ8XXIdtDUcXdMBJKKXcG6RiroygXPWd9Z3KRRlLucpVnVd0WcMddnQBJ4uuEMlhepV0rqTc pmXpX69RkHWJCr6C+greB9ALYBS0efwAEM+vhlZh/2fqmxpbwnZ4px22sxqsZxnkwVhea8vqy0Bz TQEY095cJhybNUwzx64lypgWYabONFOn4lwpFrIIItNR00lXa91immHqMI9XAeMfN7fTatTHmxpH jYaYuBJaGhUNVsyggV3CbBuN6bW8wfI960H2BPvV6Wy9mvUXCj+e4BA8MzMAi5BQqXvXf/tHdg4u /SXzajV4j0GIwxiU024L0aid5E/03dEz2oNZ2N31evB4xZ4vIiq8Am5iajyveOYVXwHIpwLveBNd Br9Xet8EGAB4o6oCCmVuZHN0cmVhbQ1lbmRvYmoNNjUgMCBvYmoNPDwgDS9UeXBlIC9FeHRHU3Rh dGUgDS9TQSBmYWxzZSANL1NNIDAuMDIgDS9UUjIgL0RlZmF1bHQgDT4+IA1lbmRvYmoNNjYgMCBv YmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAzMDE0MCAvTGVuZ3RoMSA1MjAwNCA+ PiANc3RyZWFtDQpIiVxUCXRU5RX+7v+/NxOyERBIMkF5wyMRsggEkbVhIJmAhUAWkAkFyWQhCRIy rCYYWWQJHRaBgylERCkiQQq+pIEGCi0qKghJKFoVa9nUAh4iac9BrMi83hkohb573nt33/77XxCA MCyFROaEnL7J+R7XeuDjbcwdX1Dm9oSkn90IfFQH0JGChfO1mvizC1n2FWDpN8NTXHa6MrcWsIYy Pbt4VuWMQ7d2TQaSTwCLGkqK3IUtW+I2sb/rbPNUCTM6D+hscsAqpnuVlM2vCH/S5WD6DcDWe1Z5 gVuq0dnAPpbbEsvcFZ6QMcSxP/bra7PdZUXb23p1A06uYPpHT/m8+Zw3PycL/XLP3CJPtu/4NeBx jh9sqocRza9N3Y1oJQ5RgHmF36v+v6/UvOqX+//iO7ZuuvcCddhHpdiHP+M9amerd3AIjTiBSKRh G6qwGdWwYApzfo1sBpX5mynabERf7OB8dqCZdSdjMQ6jG0WZ17AEK+UnbLWSO90TI5GJcqyjceYC TMUFZTkGYRxmw0NLTZe53txkvoldOCRPmHcQAhsKGJrN79UvzK+QxBavYCsu0KYOB+DgKEtZ8zXM Ra2cppBZbP7EGdjxPOegIAPNdEwksPciXKEoqpKp7GWnaZjHWas7pqEEtThMA2m0sKtTzQyzGd04 RgV73YoGHGRowlF8SaFqu/mm2Y5oJOJprqcRLXRM+u4s843gjqncpT4YwpJy/Akf4Qzp9K4oV0PV ZNWhLjI/RRf0xyTOdjdb/oNuicUMS+SHSro5CuHcl43+buMDXCIb9aUJ9IzoI8rFdjkXQRyxP0Mh SrnfW9j7eUqggyJUtMqdyl7ltuVR30UznE8kDq/iNbxLYVypRvPoJfqMvhapYrp4VVyWm5U9ylmr m6t+FmVYh724RZ1pMGXRr6iEqqiaNtJWaqYzdFWMFBPFc+KGLJFz5FFlFEOOMk9Zrq5S11iu+ly+ 476/+G6ZyeYqZPE8LOPsX8F2ruwQWnGO4QIuk0ohFM6gkZ0m0QsMi2kd/ZbqaA81cpQzdJmu0b/o Jt0WYLCIGGEXPRl0MVc8LzaLbaKV4Yy4Lv4tI2VPmSAHyuEyV5ZzVtVyA8MBeUmxKa2KyX1OVmvU 19U6da/6ntpuCbW+FISg0z/vvBN/57wPvtW+Gl+Dr9G8hK58hjbuQg8M5+zdDDP5vGt44t7BJxTK vbNRPKXQOO7MdJpJc6iCO7mCamlXIPf9dIS79Dnd4JzDRPdAzk+IgWKUmMDwrCgSc8QGsUk0is/E T9IqQ2RH2VXGy9FymiyS82WlrJGGPC3/Li/LH+TPDKYSrPRQeipxSoIyWpmuLFC2K1eUK+pU9ZT6 rSXYUmZZZWmy/NP6lDXFmmnNsk6zvmw9aP00KI+n830cwB/wwEMX5TLplAewXgxQokWLaOF5no5C mSF4UkUdrRYvUqPopVZYholhNB7tShz3+kPxuvhBDJMZNJZyMFP0v+vN0kV5m3/DlffRphzh2lrY c4UllBaLG5ZQNBDEEI75geynJMhT+FJeIKuyA39TgimS2sRumclTcFRJUV2wy23YL+fQizggnLyd bget5TkeT2/zXphIyfSjNCHFeJ6iQfJrLMdz4gu08T1ejd9QoVKM9RhAVbiCt/hW9FFnW+ItXemk KFW84hFqhFD2cHVDqBdJtQtW0DRZa7khzmEBWpVgnJe/4+xbxX6ZobSr2VTCN+BFrMIccxkqVZdy looh6RnEKhd5u1XJZMXO/yW8VabyTjvIt/sw74GRMoM5UTw543guJvGGqGXYwntC4Qkq5Ts+mbdY CxotE0UTitVw4q0DKKd82ZhivoWtZjFmm5uQxPug2qxij3X4Fi+jjlb6XoAHj/HNOU/j1HTRqqab ScIrzokcUfPw+XK3YykK3zHsZyJF/SO8yufIwQhzrflXnu7evGG3Ih+/xDdc5fccYYw8hgG+8aLe TJcervcCsszdZg8KRok5CxNwBLusKtzWBEfqpIkjHSNSfjF82NAhgwcNfHJAcv9+fZ9ISkyI79P7 8bjYXnpPu9bjsUe7x9iioyK7de3ySOdOER3Dw0JDgjsEWS2qIgUh0amn52lGXJ6hxOljxiT5ad3N DPcDjDxDY1b6wzqGlhdQ0x7WdLDmjP/TdNzVdNzXpAhtOIYnJWpOXTOa03StiaZkuRhfl6bnakZb AM8I4BsCeBjjdjsbaM6okjTNoDzNaaQvLPE689LYXX1IcKqeWhSclIj64BBGQxgzInVPPUWmUAAR kc6h9QJBYZyUYdPTnEa0nubPwJCxTnehkZnlcqbF2O25SYkGpRbo+Qb0UUbHhIAKUgNhDEuqYQ2E 0Ur91WCNVp94zLu2KQL5eQmhhXqhe6rLkO5cf4xOCRw3zYhc9E3U/0h23jnVVf2gNEZ6nVGlmp/0 eqs1440s14NSu/+bm8s+2FbEpud50zn0Wm7i2ByNo4mVuS6DVnJIzV+Jv6q79RXpTj8nb6ZmdNBH 6SXemXl8NDavgexKe4PN5jhkXoTNqXknunS7MSJGz3Wnda/vAm925e+jHVr0w5KkxPqITncbWx/e 8R4SGvYgUnRfFsAC6n5sbPb9zpI/I/1pHghDK9A4E5fONQ32f4oGw1swmNX4ySW2Mgr5REqNDql5 3oihfr7f3lBjI3TNexM8AXrb9Yc57nscS2zETfhR/5zcHzWW/xc3EhKM+Hj/iFhT+Uw5x5QAPTAp cWGT0HVPhMY/bh8yubfu3KF9uf12u/+A1zQ5kM+EsTTLdZfWkB/TAMd/uK/6oKiuK37ee/e9XY3W VVwbZYwQ/IyiqIMf1MhGBBGqCfK1EFvxo6kNsbGxSdOOicsQAVfotGl1iBoK1FQKdlwMaYBJG3Qm oaaTOM0U0zb2Ix/MNKHTJhmTTjTy+jv3vbfuPpxg0/afMvvjd8+5X+eee8699y2aXxZRK7imz6nx F3NNyKmJdq9IQSR3ET9l/RHv7Ohvgm9KQvbOjIgy5VOqv2LV5xem5BeUB5OywxW2b/OL4iSrfkW0 zi5FErKCWqJql9RETdYiKDdHG7MQHBcRs/AzZFDv6PZ4EZVSoyTlRHwVudb/srHJyTfYqdt8j3tJ utbNNjOSMT9e/kKcHGfeuLAGg3EN5heVh8Nj4+oQataE621CxFNRMDkpK0LFyMxZ+HWbfSsYZYmR AFyWxQ0Qf5bKFuMaJtrlMvxxdKYuyMFBFw7npCTlhCvCW7vN0LaUJF9KuEc9q54N786ucAKn2+w9 mBjJqS+Dr3YqGUgKldZ0pih1BZ0Bpa6wPNjjw3dAXVHwtKqoWRVryjpnoi7Yk0QUkFqVtaxkIYkF ylewyNOqV7ZP7MHXSEjWCqmQ8vZuhaTO6+gU2t6tWjqfo1OhE5YuIHX8x2dMVlEwNnpkSpal8lWG L6fVwxspy0eXTw3P9klN7J8RNmwVvzNsRNTX6MtiD/mB9Z7p9C29hIJKLZWr7bSXoU2ngDhJD6Bt O+Q7wL3cF+2LgT8Dq4ASYJqt2wBsBQpZRtse7osxdvM4kvdQuXcG3a+XmFcx32G9n+4BmlBuFW9R m7GSdkE+jn7PC6Ll3AZ9Dhvt1Aj9MdRvh64JHITcgvJm9Euzy2M8DfhWAwMG9PMwzkF7vXO0M7RM 7DHfwFrKMGYeUIM57gLnAPlokwBeA9Qq/VSn9JutqAdTNeavZT2w1uZcjLMf9ZnoNxNyNcrTYIcB ngAkA3PVk7RSnUzPgRdh/aXWuoF+2slrjq4J9ts2jYRlY34sMOcvgBR1pTkIHhNjmxvVLqzXllII XAkkAgXqy7RLfJEU+OsJfZA0hpeI/fQn4HaxgzZCVmBnod5FR1gGNkjsMa+KY9SsXaIVqPuOcRjr 2AF/4+WrfkSL1L9RqjGL9iG+1mL8KqAJY/5VxsMOKsL8C8FLxaCMoRqgHnP9w/ET+wZyFfZ1E+b6 xMsx3E6FwDrsSwi4j+3B/IvY57zvSsnwSrR9G202M6D/vATWzjHJfbg/xpplx2HrNaZWtGmAX/8C FoCfbXAg48wG6l7EOFMBA5gOLAQGgVagEsgAngXmYm7CvJqMV8QMx6aMD8SG3g8fwjYZs9YamuR+ WjnTYo/F8yQbJ6nSRjKPyfnCMQtbOp2xOac4ZhyW8V3Jca+8z+vkmIoyck8M0Tq2QeYgYsthzjvY zPlwWC2mOvARxHE1xyzb5zD7hWNN+gQ5YfOqmLWmyRwBa0QpdqxXO+z4Iso76TjGrDC24Uxpplzx Tby9v0/bxHu0VptHC/U06LAetI2oQ7TJi3c59vJOyE+4uJHhGVDu1fuwzg74c4CehE+/IQbUW8WA ousd5js6Kef0DvVRWR7Bbih9Vh0zI7bu39V/FqgX9A6cmR3mu/qAaWI9j3NOeIaUNCDJYehPAyHg Nu98pdFbqXR7islnEF0C7hcBytADtFz0YX/8OOeRC9AX62/Q81oDHRAD5u+VEIXUAarx+Gkrvp8m 8FzqBapm8Pjg3TFxFBdz7lhy2IlXN/OZb8fUDLCB/HvFxts2PgI+RBz9WLHmWM7ns7wfcEYDNVa8 mpej8XmOngIfdOLTFaeVrvgc545LN8u7Bee7k6ew44Czfj4f+YzjM5LPOT5nnPZujukfVtsRx3wO v0zldl7faiMPNr5p5z7OYex3qWkaOeYJo8ts0yaZbcYSlH8H6OYJrPvh6J0aNIft+3Sec5daerrJ uUf1pbTLPs+Oy/PmA/qhvEdLpH1jjFO0T7+CfccZKO1ttnMQ/oTdlaICPj9C9VjHVK0W+Qg9sJl9 IveC6Ga+F/hO1A7Bz3wXNVC19jreC9x3KU2U90UmlcL2c1KHO5WZdXoptRpDtEQU46ztox28V7wO tof33vsgjff6cU4M0GLxU7Tx01i0a5Y+CNAJGRfct5KIfeHZTh7E7Ea04fFaZJ8ATbL9cVz6QvbH W4Tji32BMQ0/bZLviSH6kV5MpcihFk+IWoxi5Jyf2jDGU+hXzLag3zR5Xx+iu5FfdTib6nDmkIz/ cvOK1oH1PIxzHdBC8FEH3ayH4MNKufa1wjpjazl/tHaazTFiHMI5zO+JQxQW8ynbqKQG6Bp0nJOY 9yB0jyF/05C7B9B/hn1uE+Y+AD33zeS3DL8ROF88AUowQvIdQNIGfqdgfu0datHyqA5xfIf3EPyw n1JxXyiIvVuAxRak/KiNegtS57NYSdZ89IjUL6VX1XbtJsQt36E9ooq+JkpoibaYpoqJlCp+g1z9 mI5qE2iLeImOim6qZ1kk0FwNr3StC29L1p+nu1ivvgq5kcrFKvSvo6+LLbRH60Ts/ZbGinuw1+in fxdxMhP9P8C4NpS3qFwrQW7VoPyxeZLbyTm6zFKGyKVU2S8G0lYHLpvVfPgtD3sKe7kcZy9sjdrp 2Hgd++Q6eVz04zbiKK0iMi8CsyweLlAbqANoVv9AWdoG+rbSZvYqxyhHGQSO2fgZ5UruBApwx6cr e4GFIp2eBapQXgD+JXDKkvF2S6fXgf0Y+wz4af4uYKhraBkzdE1AI/Brpy4WPNf19LHQE83eOPkZ 3DWAcglruBRfJ+eswrs8Hbjd7GUgFvMYxj6a7HmIJmtzoL8F/Vyynoh8eoZmjmbPaFDOU5r0oYVA 7Bqd/QBPuQFcjOEkZvtu+I/s+yzA/u4DviT9+3fyWzFEn1MumBfBJcoF8mkPIgYByKmQExx/OvsE /Q+k3rV/iBXSyPynW++W3fs6mqw+TVti4cRBNB4ep9UMkYn2gFv2nqPVDOMF1L0wUhYnRkE53aYd YZsQg3NGysadNIehzoSt07gPcg6IyudxRgDcVvYfT+sYMncBtQvfa0C0Pp2yGTF+XcZ+1Y5Y9c7+ OPvi3h/YFxCv0HrwbPBKcCE4z+FofNvnRVzMF1jxHpX5LBl0tbmWE9dy4zzfNdcf8/8JyJ2XgH7g xf/1XAohVgEfYFzEOyQT78gBvE/upmqiqzhLPlkE/ATnUBH4Nehwew/PA8ajPBG6r4KfJLryIcoP QD9gwVRFIjXb78qp0P3c7uu1xyu0+l/5FdHlS8Apq/+VduBelN8HHkH5j+Az4Ea0fxf9HgOfteqv boH8EPAc5CHI9wFBlL8H9oMXAAnAJPQ/zOD3yIjv0P86X//740YZb5btsHMGuBe81/0NccPs7Oco 7P7WcPZ/NNbtb4mRbPkB30xv4t0Xif32+bRvHIexn8P/Yr36Y5s67vjdPcc/EoJ/FJKMOH52fpgS U0JNmEOSxs/BXqAWS4DA7Cwl4UckBkwwOYA0qfCYVm2ogyA2sY5JDWPTNK1CPNtr5iSVkilbt4YC 1cqYRlugHerWP2hKVcrQAO9zZztAAGV08/Pn++O+n3d37969u+/dC92a9G3klDN4Hs1zWZ4/i/wx q8X5TeSxaJeQWTmN/ph4/spzZ56/QvP6v6fPE/1Zg351i35l941711b6GXkZsAClWb0VnJtsbvoM 9iYz1tTryDV/wSH2Nr6vAZj3Z0X8fHqEc6BPwy+Dvp7b03Jr6wNr7DR72v/bf9w98gvsqd4suqbg UeU51GWxnGPqXvy4mG7v/sJ7+SP26Hv36f/Vz+3zOUyXlz6QB0zjT1ff4/pT847H9qfkJTl/Kh6I T517uXxmDpkziSnf3eOCny10r97N/XN9mPodT35vuTPCXhK6F1gHnszuocexXiwEygDsUenDKNtj vEW8xhPEC/9VAPvmnavQm3gMup8eIIR9nr4N/zvwLbrTghvJYtN083nqvOX5ucgPMWZiHTzE+09q gAbABsSBb+beNT9Dou2/Mey6/Jyr60hf150BpuSA0+rF5FvACfhm+OZ4uzlQLhWTCSANSESGrAFa gS6gD+gH9MScLdkO7AVGgE9ERJGKE4cXKSmoF4VKbtnmFe76jNv5nHCTX4tm9IqVGR1cnqHVZ2hP 12aKFzRn9Nz5GW2r8qpc5xd6RwNFUhF5C2BkByRlv8fKT4lMjkmziQYwSZ8tUSRbstLt7R+RdIRK TKJkE5HToxJNFFq9gXyWZhPEhj3/Y3Y1E2FXkzOt3v7As+wDchIYAST2Aa732fs4YF1G7maB9AP9 wAhwFpgA9Owyrku4LrKLxMzeIzWAH+gC+oERYAIwsPcgLexdft4Uktt+gLF3IS3sHTzWO5BmdgHW BXYBXXs74VviHRSGpyZryFVZo7g0a9iKvCn258TNeXKK/T3p9MjHAgvZOaIBDI2dQ+XniBNoA7qB HYAe1nlY54kKHAKOARqgxz04OQJONg68CZwnCwEFaAOM7K0Emkmxswl3sxwoYmfYH0kxBvU0+5PQ b7LXhT7F/iD0G9AO6HH2esIhk0AB4gT3WKAt0DWI57HfJSttcjpgZSMYHhmyBvADrUAX0Afo2Qgr T2ySbahkmIwjyZVZgnwk9C/JcSNRtsiKeynmmJMLd/0zsCD6nf1upriP/AQuF+6Dh2Fx4f7uD2Bx 4f72PlhcuLftgsWFe9MWWFy4O7pgceFubYcFkWIv/7Zyruxr3UqdATPbjVHajVHajVHaTXRsN7/I TR3v208T1dUYsaOKZ161rA5R9TWqrqLqcar2UHUPVfdRtZGq66jqoaqdqg6qKlQdpnUYCpUqv7nP XaKUUHWcqieoGqOqm6pVVK2kqpP6lBRzJZYvEiokVDLAvyvoZ5q8ZvTRhRF1YVq78NmPQJ4F0sJT QHKWZ8hfcnBdnqz2Z/wF9d7tgWVsDDeO4TWMkUuADi9oDNNoDJWMoQIzpB/oAkaBCSAN6MEuR8f7 hDRD1gB+oAvYC0wAetGdCYCR7dkunhQdq8l2upV7bAxXOS4XcyllFrvFY1km9dmp2UFbHWkH85Gi IkKIzWq0pmjhwI3Cf90oJKaAiR1kfaQML+JQVvclbpbJKfpSwj0sB2bTHxOHDrOOLiFuWgVdR2LC X0zsRq5riZ29Au1N2NfiNnPCPV8eojP5XQPyTfsV+SN7isH8p31Y/qszpaMJ+S8oeWVAPmffL79R kzKi5DV3ikINOQV10F4nnxgX1H0IHE3Ie7gakJ+3t8hb7SLQkwmsi8FTzPIqd4e8DPUF7RtkJYY6 B2S/fZ3cmGEt5vcMyAvRBU/GrEZn59lFoxUOUeEaX4puVuYbjhgihlbDlw1ew3yDyyAbygylhllG m9FinGmcYcw3Go16o87IjMQ4K5W+rHgIXt0svYUrfvigRCdsC+MSQqxr1MjIs0R7Qgqz8OpmGtZG N5LwBqf2+eqKFM1f2aHlVTRTzRYm4fZmrc4TThnSqzSfJ6wZ2r4eiVN6MIpSjX0/RUl7JEXTvOiF Us22NDJIKLW+cKCU6ydfOBCNkpKiXf4Sv63JuuQrwYeI7qz03P2V3GeXaUfCqyPar8uimpcb6bJo WPvhamdnZJB+Sj8JBQfpNa6ikUGpiX4aWsXLpaZgNBpO0bWCR5z0GniYMdcEz+ggTs4jTqMjwzua 4VXhfvAquQLPZCJVgldlMgmejnJePFYZCsYrKwWn2ElighMrdt7LGa8Cp6pKcIpUMi4440Uq52hN gmK3g+KwCwqdQ+yCYqdzBGXtXUpNlrJ/krJftCTRuxx7hlN4OccpvAyO57/99TR7PDTZEN3YGeqp CHVXhHqAbu3FXZtLNHWD0xnfGOUBpya5uzds3Mz1+h4tWtET1DZWBJ3xhs6HhDt5uKEiGCedofZI vFPpCSYalIZQxfpgNNnSVuu7r639k23Vtj2ksjZeWS1vq8X3kLCPh1t4Wz7elo+31aK0iLaImONt kbiRNEeXdmZ0khXkY752l7qizUWWHU1i8ja4SvaUDiEh+RUp8ES1GRXNWiHAQ08FngrwEL4pHpqJ YnM2VLKnwVWKbD0bsqDYWtFMPL07YztJSegbwcw/hh+KenfyAc9IT+xRP8RCmrI+GOslJKxVrw5r /pUdkbjBgNJu/khafa6soCCUSo9mChegsJ4XStIkkZc18jKTKUt88P3vzOql/CtQ2XCSKg7aS2JR SXOE2xmWgvYOPGtnR2QI6RLfHmJRPGCMemgsV4foNsnYhD9vDr07s1Z2HHqzOnMXbonlhmPyx0eJ r1NYr/JwYXMxEOKyuqxVEFjTyC2nNHpLySP/Jk7dKJhEw8rWlzcEsok8H9ezpe2RBCN5KXZSKTA2 6vNN9bpGfT2lNVduXyH+2x/6S+N2EXUjyog+v+CUZKrPq9M1kjrwpEbGnJTSU/n5BftcP3sJa9JX LZ8917jCctVyBVVcsXxM/P4VltsfYk1K5mHKUEujpTEafXrhE5J1kVWSFi+a/Q/fpdqfn6XbJBMN 3Rm+dePOj06f5s8SSV/Mm5v3NrLg/7BdPUBRXGf8vbe3u9ze3t3u/dn7y7JIPKQXPBA4wJxhtTWp SanRSBTigdaYUUhUQO2IJIZgQEkbbNr4pxNH0thGrOioqCfQ6CSOVjvUJmQyU9Ma00HjpDnidIhj ajn6vQXtpO3t7Xvv3u593/e+3+/77dsH4Q1jlv77JneD0uBpmt4UaVN+E/krStuZ/rZCtkdao6Q1 uDWT9Cp4mWd5JlHculKLmIPqFYU0BhvTyQZ/Q4BsQJsV0uFpDZBu92GFtKodGukQWoPkD9r5bDKo vBcgff7zLrI62qeQ1Z6VBWRlBD9VsDRKHimoyiDlypwAyfOXZpBQ4AGNoNxcNXe6IKCAoqS7NUXR tD4h1yUIuaEcCRfmqDMZS6AtPat6mXOds8vJRJy6kzj/kt7pxd4EqdKDvofVBi0dp5eU5FR3WbG1 K79a4zFfW1wPWZRux5Oj8SSkcng0GYcOxoDHcLIs2W6bHra9IJ3jbbF2G+2kmDHIz8Px//2gyX4q x2VNyQ4VFUaLQ7QtmKG4XSyOFns4XvHwIRyNFhWGsqZwbpfiwZijfcGMKDNY+WHTZ1vrjhxeMefy 3p1nUn/HfK6vP2/hypc2PZ9SN8yteXTe8qwsXJ46+fqzr728oKdnxYrdzXu2ffJkw2tztr6faPng F6mjS9ZPO9vc9nTnI8wrc1eVPV5T/b0pj39nrAjvWfzGvMqzK6FKqpjjONtgZUh3I5bB7AhBTIuG d2CCa7n6dyYygsqSWHaUllLyAG+YbdMH8+Cfjq+/To2AlebUArIM+CKhWbqQbYenuYNPk6QELjiO 9tnSoNdlfp+tGjESozEMc0je+xPD8NjtpHQbrMfKYjSLOETkwuJocQHHw+GWMP70jT+WVw20bMqe lRXG4dSCAXwH20aujN39U2XHzv7fpTJS2rf8r9TFaWSaRMyChJHDTCMQ9jEY+l54Ea22JcZv9UoS qYDBnV673RgM91qtxuBL3S4IpMJuy7AR2yHHZIy03P8rTmcWkguzQ3AUKB7FLZGxFhwOT5mV3dQy UFV+ObUAX8OfDZze2VH14d2xKyOpf6TSIMoGlDTNNJ1EFlSiZ6A1ZvJNGrOG5TnzGsEkfMPiNWVk PiHEJy6u8hrFXD4aS8ak4VgMRUZjY7HR/LypcmZRJlRvpjtTJjhVjzsP4s5UfRK/foD2B1JrwM/B 1FXcigaRgH54QgBh+i2XwE/oIUMysIBjSIC3WSaGuBJ+5nxUg9aiLagLGNBloTICfkeHJfAbA9Ch BT0ZM8DPzysA6F0cnx2NFp8cfGLxjFJg6WD9q6Fy3/Knwe9snCC15HnQjwd13zqyjiHluBxcZiHi Z9fBDT7Tup/SlQ3HpRsoUp7Mz0P1kMyiTPdskoMTJ07QzV8fNO0QPYOm6l5Cg41NhHgEmbrgepfp rYkyNVg5EVTfINUtEOPxz0kp8IBBT55GzPjVY65Skhi/qmuu0l0MJsw+5ghDmI0Iu+BuEG8GCcxN RG4CP7rBuel4E1iOSaNJaQLrdnZ6OP7CRIWHw25cgHH3jtQSH/vlP11U0yvGPzfJ7FngXTquOEqo puuCXzWxLtVq9ZgT4zcNjtGB7qMkM8tIpDNIEUVoRTqHIkCwQWgGYT10RYGJp8O3LY2CJY5augFs NQYjus9i4ahJic4gSRRpS+fum/yPzV5O80lBoP8xolneHb+GFDgdcNphU/4jE9dOtlm22S/aWDNv 8ZK5zh+4H/N9N7DIudS91LcwUMfXWVY4n3PX+ZYFNpEfcxstTfZ2bje/U7rovUI+5j62fGL33w+3 0axnZhXmmTEyS2Zi3pEhNyJ4sOs2mNWQDonboV54daK4oK7i9eHkZJg4Xo/iqIR+MJyVlU7JQRVT cUCRGTrqlKg6yhIoJs9V1A11bTy2fk7t0FsfbfrZ6e7m5u7uF5sfi5MhbMKzDtUcT41fSaVS7/fs PoX3pnZ9dQuvwrUjq9soVz4FAO8CdgI6omuMbpUL60xbSCfZk2Y6ZMJmxLGEMbNYJPiSYEQv0DUh TPUGXmQMFYHBF7psABo0ALUZgEKWdR+F6x4mBj5+kdWt9kL2XibyWKyxOktYn6UPx/AraKI06sOQ l8ldBvyIlY9BIZZ5SrFcSvOD4uHMLJnj+CKowgJyt3f20KJdf4usN21+uDnj8KOXaujaYsBlHtam 4guTXDLLktXrdHIVVkolWTYGI7pZkmCkuliVUtRDb1BVelUN2uCKKtLI1QTp10UieDxahiTDtiMD 1CDy0SBtB1EkSSMto+25GZS85L5D0eEghkPdbJfJPT/XdIvDSSpUF52jto+BaVoqFgup8FAVNrL4 /7xRPlN/1JvhTI8+xD7E9bNnuH7+QtrFID9PrBQX2erEZ2xNjibndseA47r/euCWXzxjOeUkASko pUuqxL07fgvxQP406M2All8VpDSOuxT0u4JBf1rQD2qR5g8yVlVKkP3H58tYTmDvCboCZKTDjoko NHqGINuU67iftCANSbhEF+UTZaSGrCVbiIn0kQdQBu48OkF20JXbYSovIC5jsbLkWHxYdlBkobm3 uZhQWnSvAkpQHMcbKiunujNDxYD4vc0CFWFjJwFMgK+J/1cx8Ux9+5dfHdiz+eU38WnnnQ+Gbn// nfd+tVTt6ZkdW3H2xXPXn637+Zsdzst//qJnycGB/duW5wNTnhq/YVKAKWFcOQmcxefVaf69QYQp VcMi/MA5WYLVLtpVQchxq0GTmhNkc6xZVtHrg8esJlHya3yIokhvD0Wo+gxG6IEcpWVl8BBJAn7J 89J5R6l0LjyDnhS/aaxVsc61tllNc+XF8sYAs1B5Tqp1PaNssG5ytVk7XNsDv7YKrMYYvLGIVpuJ x+AXU1h0WEA/9qIcZMVFvaLoNnn7yH7kI6v0bIiShTCtjsYaba1GNC9lsvYS3xgytCmEUUgKEYh4 9BS9EtqR603gkn/TXS1AUV1n+Dzu7t3H3b1338sKy8IKgihQBXHpNt7MOO1YRZgxajGl1GjVilYR ba2RgogYFRWbmhpjrNgaUYOmCIiPjNoQTUyZPnScmNSmTR2b2pJJWkpnGlj7/4ddxDZluNzDfZ3/ nP//vv/7OpJu0gt0OjSSK7r1EVtN6qE//HmCsEQWkbMGcipGeGv4HhYn9EnM50g6AaqQQEArrS53 FXmRs0Ti5KLRYSKHmEQZ/5JweuaCztT9VXVnjtZOneN2Wmt6mlZ+u9ndmfbg9MYbVcuWNrTEPrp9 9SHd6n9x+2sNm1vdh9nG2iUNjY2hruvLO5ZWHsoNvr7nSuyf9yHoAHCABsrOApuTqU9zfk1ZoRxU TihvK4Y5fI7tRxJ3Qo0Txchlg8XKZaIA2G9wyc25xG2EKTZJ5hfZRWICm3NEtxBJgkfIDYvUw5ad MxgsekpqgSXBhJaRxiQGH4sOZemhRbpN1tPDBXJ9WqHcojIsJ6vNXUCYxkKMM3wZ34HBvW58h3XZ e2iz2Om/AfsJIhxAeolq9zXBg9pAdDDqiESEGt2emyMBZFRVhe0WztAGPd8ZAcq5pVunRnj65AiX UlKi+IlySAY8o7sV3RpR6ssiip4ZUdKT4Tw5Iti2HKxbIZ3qmOoJO7iDsheGG9nLz1+71hkrpJXH ePfQV4/FWgHU+4eroPCw96cZXgGOXTCCnPOEwvpsuCCabLcEPZ5kJ1KFVZWkYLLNTonsh34hFIEY CJQhpyFKsI6giIZ7ARkIjGyn4F5V/J0d+H7KzpQXXMddbyi3lffHmcwuv31igJvzDfnWC8BjHNCh uSwep8t1w6667S63XbUBRHQXBqLbj4Cgtau6h8aDOqdK9CbCB1hND2F4jkptjVan7dUkDUDiFyDx U+LX/MyfAIm/JeS8RAuJSvdDUU3vsHd9HlhSHwfLI7hUoKIEjIiFVjjgQK+63ZSbY4AsEkF8gvNo Naitx2ADWHGB5uWAF+Jxy6AEMue/7nlxVUNne/PC5qwTe9id4XOljfuuUNP63QNvDdN6beeu3qMH O0pneNmnr8a++/XY4G+u7+v4A6q2EsicBzgvhUykpXHWS1VpKq2knI7LCurgCW3QqsYZ0oNumyVI SYaGTUwoOC3o0zCDPsF5PqHgfHG51XerT3szkUnwjb0VmMnJVUl0pqx7ZibNDC1yPhWq4kvlpaaV zqWh9aYNydtMTcm3Tbe8DjmEWzxhBBPG+WFBeDhKEzdkvDEhFA6l4Q0HRllmYxDnOHqzEhMJpGdO xAx6drruJF0ZNZpIJHghDVAKq/jkHCoSrWWSBTMXpBHdO8NX6Vvjq/NJPi/e83lxOl8PG382Z0Sk ARL7R5MYZzzBdLDGeMYQPsh25VQGV4TSzCgjuTmxQYXTiUMrQqqj7jEp5Z+d9U+aVbXgyfnPsCcv Le8c/t6vG/8Yu/fyjo/a7w4Xle6Zu+5nR5/ddFKaZ1+ZX5L/xMe/W/LN2L9+u7P/B3Q23UxPXG37 xdDdipPlPYcPnDkDG7AY+M5rOE5sZK1u77VRCX6ZSTIDlyEK8xmVzIqthnOGW1IqWjRnAdVUY/4r KYXcVzI+A05raB2IxyR7vIrRh1VHSwb652qDqMbQGWD3jjgiI60aihUdjJFwoxye5nQWLeZdzbH+ 2dPU87zhHzukf7c37485Y5/1vN9OH9Drhwi6E6jAJKhAHwmTfEZGarBTIeOCuciRoMPY/NxcZ1rQ aMgKOm1Bs4LFhi6gW7iIHBV9LJahmhBOOBA3VT9PmFyeeIqPli8f71HwcY/4okeUr+eRW3jciqDi 6o9ERh3JORGIMRGIcSSQe8KZqAkOj8+P12AwpKfjRZwW3/QIOvOIlT5aX2IymIvmxQNIHIigokIv zfbO8s7KvK/8Jd9gzqe1pJZultabqq3rlA22Tb5dZCdtlppMW6yNSpNtt++XjmsuZzogpSM5FMBT KJSHp8mhTIRPMDukkKCfKBDGkVw6ZqdrLpupuYct17WcGlUPAXZUSlRNZWoP3dc9xV/zGqcc7neM r/GMWhqP7mGeli+MWpoBwP7ACOX1x9dWIRaHTSuOGMFzFeuqSXV5Oc3MLCyIy7mEEiBwxeUeg5ax 0KEr1666f/nKg6rV23fHBu/ciQ3ue6apasW2HcuWP1c8q2Xelrb2hrrjfFz2gZVH3vvgyLIfZ0/q fe7SQ0Lplb1X6VMrGrdWLtneOPSwpKX0lfqGk20JL4s1GQRWPB3PtzUVWkCGAxrAoEgodgLBTn60 OFmYUb9DpNQhnI7D75iUY80KqvZUe6md2+1uUkapkJE2DVwFxU6TjiIad6U3p2KKIJEpYmMg21h+ GrLo3TdHncSYIB71Tn2iaJ4OUcX/Z9bH5/qvqfLGTqQXFAfmePXw096F4WV8lXd1YHl4U6A22BzY FTzoPRG4FHjgvR8aDLm+5D3sbffy4uylRjYB+24YismfFjKGsoKl9kpsssk4Jb1ZNkLJnRhE6gUa IVZgZMfjbbVlEvJ0J9K0Y7SWHLqDOVpyro9Vm1hK/WN7Z4J2SUU1rSiPd8onWGHBBGRbOBMoJqdD Y9goqSgZj6ilte3ezYvn1ZZNo9Muru4eovK1vf3Pbvr06KvvsXeOrd/YcWJzbSudp236zpy6d9cq /gVV1PTuB1Q7GPtT7O+xP8fOnr7MC17q7j3UDJQLNXMe7E+TlAmMJpPpoCMMxCibmTEq8Sg1ShYW BV1DWAj2otXUegBWBKhA/gQ3IPIg4OAqnOrhcJzv6+vj5X19Q8f7+uDbJ2O/p1vFt+1km55XY91q fd76U+snVgPsZaalyPJlywLLtyxdlg8tstVil3FOOWo0GuyS9RSIzzI9bIhKIowthBiMclSyTLcW G/KkGRILSVRqVRMhRQfugbrUooLbteHhfk38MxIk0d5GkifrqhOBuoVyL+qGeMsWTolM44moq3dl liQtfho2hawlH0pflN4gRrJIV/byegPjBiM3McNFtggucraog+nGC7QMxHWZ7iGn6KmQxAImKUpx uzbICxeJAohi3yFJeYGSfvjxB+JRocEg0Heoh1LPWv7OUIwztqWNHjwb641dPYu5WUdbpWLJKHLz FX2CwUgl2UwyOM3gTM6QJGMGtMSfsF8xxi4bSMBMk0w451ztnnaf5JX0Q6ZwD6Jiwgi0O2SutELU yGlS8dB0/hYe/Bttwy+1/c+K69ne/5BercFNXFf43rtPSStpJcuyLFnrXeuFrQRjKzb4Qa2MwTzN GGJsbJBroJhXSMDQZEJpAsHUoZDBlIEU6BgCgUCpGygOYxs6DZRpJ3UoaTMuFArpw9DAjCckkOIm eN1zVyZJ0/zITHe0u3dXu9I5937fd77DglPG0FsQmjFGLGTMxTHNmEtmzB9TGaaUR15R5TA3kvHN BORbWjlAU/6ajDEuoB+25EEBgx8MM71kgz7/JC7DpSf1Jpp1PbgAiXsPVCwLtcRzgcE+ss67zkcW eBf5yHJpvo3US9U2UmibYCO+dFFgkRxxOJA124UVYOwb8YCWpZVmmjNLs7LUUk1TUIPylLkhbVlQ blAd2LEsMLIywEtKTpijUnkIyFkKcRvs7HcY7V8CNpRIYJD2sYVjKTm/6PlYiiEbESia8GWsuPOC p8e99uzqPZ7u9Pu9lzCq3zin0Eu6LuClQeeyyuKS6KEFxUv3te12X7hy+3DjgTUzpjY+qb9i8ORp fabQx/WhSagW3Y/XspqsujUtVGCN2SbapngmaBXBiimTaqpta7Nt7lA2Dpty/OHsAm9hUXmoxlPn n6vVZNdMqatZ5FkUasp+xrvW3xzc5GnxbvVv0VrD6Ta5yoaYJ6iFMtsjYyxVFmIR3KfJZFSOppHT neXFjDmTdhTFWI2ujJJoD65EEXL6VO7koF3AQhfZGLfLVd9CQed+e3CMvBJsaA8+inykvbNsXE4Q njehAGmPm9QCXJA+p3Zr0nNVDgzR5iExcG8IyAl1NHdgIAFK3g9wKEv0w0SP+C8ARSJEZY8WUSet omljY0xS78YWOgseI8FAFktSXU42pgbHxnieDWQFgxG6Lk6k5YPtTZWNjiISxq4RHYWlshF28+Ov zqw7svTgx8217UVZJ9uUbH9BTfOmY3rHhdv69/v68I5PMI8XzHkzNqj/9KPr+mZ9sLz6O2vxWRwf xFua579z6vLE2S6r7n6xety6VZNb58dXLYsfnDZ3yeUN+3DZ/rmJvUPzt9p9kfFV2LrtdZz186v6 4tuf6O1Hjz+/9MoLzTd2/vLqvWvYjtXetzt69et/+11OJB1P3/zj8pbeppd2Pd72e0D88BCIWx3X Ayy34cWnsM0Oxo90DX/cOTIYNAo2oQ6wzjBvhhHjjGOuPEZeLC4xNcovMW3y29xv+LfkO7JF5Opw DamSl1iOy3elu9a7NhMrsVbWxljMJo5lJatN5AVBgrHISwJGCP4mbqe1GKmC5IKvCMPQe6n0HqOy kgveMikcJyo8w3eRlXETEqVbcYIJ6cEWMCaWuFNS0SKBmVXFXmTfZ5k2kOgujOOWKukt4X2JaZOw RK9lu3BRIC8I6wUi7LD/6VJSwtNhh48H0OFNl6FaespKvYAWg54DrdzoaBR6zNbRHuNsFB9QtFb5 /Hnb+fOtXPIMrJ123PLEtOPKzPo5naydEYWe4TvQ3w7SYluHm2lfSrcAjuEAozEpGhOO8AJDYn8g c64dG9r76p/xR7srsjJiXM+nFfiMPoHU413dz768hbr+XaBNt2ClHEbnmdKNWFiTSRYLP5tlKwI1 gabAalOLiV/q/S630gT1jtto4SNuE+OJ5Chuv8mU4lRycrKzUYZfgXnLVBQHEj1hXqJWn+8avhmP UXvEO6k14nk687xIf5031pp3URzw1aGwlEHfkMz0OYniIpU+JXkf8SuqUX1U+j1Kmr6RAX0WBp92 GoucHPB0cCdupr+LEtGSeclmkW4J6JBmGBeVA/eSt6JQXOEu3UEkQTNLi3IdRbAQ2JnUS/iJmEPL d3/ugm0kgDXgMDW94QAUnvykjMJ4Fwkf6V3dtHjTttr1Z7fqO/D4DeOmTqt4sV2/ilc0hMvri6t3 btU7uJ667kUNh2ORM+sXn2jMY2Y53E2VU57O/my/II1bXjHruTxauZqG/8k9AzXDj957cyFZ5ic4 2VQZ+X0Q/zYdqSjfuhBq3Br/etTib0N7uGPMIWs302n9rfVd1O+/63fYnH6H38/k8KMcORlq5iRr jas2tSZ9Cbfc/z3nFuceZrdtT8YR/Bo54uizpSAX8sou2csCM6//YlSRYZIfHVUk2xFmfSmKxPgU 1iSH7VNRWAU3681MC6siFiUajZiuLJxn6GQUhBImGo73kq1GsvjACiRWwYRGcTNOMwQPJs4ZhMqT JoRpHaJ6SA0h23luvP7rGwP6pb1v4PJzf8GPlPwqdm7H0X/MW3HzBwf/Tkjeh5+dxU/98QaefeKv vY/u/9EB/cPtp/VbPzxDq207aE89INoOc3cjnqtm4nIxiU6HrNiRCCGbcGbc6FkNUJnMFFEmj3HH gJ4hSd5Mv/yNoXf/IfQGH0JP+Sr0RsaJLyCXN6b8uXgh4xNEXuREVmT5dI/XQ3iLGXhghnLhdrlT 3AzvY9I07LTBwSNmaNhtdmgIZjEazYFtA05QhKa509zOVBcBfIa0/MIkQCOAynb872P1z9etWT1j 7fYLm/QTuGj7obyJla88OaNDf4frSfVPX6BfPP+6rh+dn99RmDfx1uGb93MUyPoAKMMHMI8WtDOe ynOKKAoCYlg6kWaTYkGiQNHhl52PCdXMVNWsWonZa2VN/wddpZK5SQCNTFqlQdhE5b3+6Fd5mjcG sk7VRvYDbPBBOxN90Me0cD0detnPdGsHZRGYQHYT5GBCL8ejRg7boPw/TANS+IlKVAshXss3iDtu MQKXRkio/0/45pJ5Xwr/S/H3g4VPhp74auxHmGsPbpDjQ1U07uKOoSaIYQVwvxu4H8Ipca/P5Usl jRHcIKZgJxMMIs2ZRkJIIQY5VRoDxnyaYmM0hTdhHI6EguBhIa9II2GAyP1GJkb1pZnA4IqxAkb1 9dH3SfP6CI74w6oZm2V6w5weXjj3cypXyol/jeQDwYM45hqkhnO01Limegk7NT4A6AlswJfhzUjP YHgpLIdSw5lhMcSGAyGP1a8htz1Fg4ddKaoAV1lcSMMZFkC2ywEHxaRpKMjAAdE/BITTpif6cKNY B2dVEHL8l3q404TRBOSDF3jDUAH6Hcx0smKb/u7+y/q+zpO46uq+/1Be9cFRXVX83vve3Xf3vX27 bz+yn8lmNyGvIQtDCJuPhUXeiEVjoERGQgJdoTJYbWVKQPEDW9JaAZXBgpYBrZRx0Ka2ykdCmgaV NNOxSK1lHL46RcofBUfGMBnMIAPsxnPv24U4/EM3++49923mvXvPOb/f+R2Md5kHk18eeOoHI99K tmzFZOczY58i817H+UvrN7yJv3T+LN7Q//jgz+rX9Sz6wvOLt738duFmz2PN2AvxOACMUiWQcP5N pIPXo/6ytCzFnep+9ZRKVEqIxgDBCUWBkndN+BuM65Ymqp4hqt7gxCUrLCofFpUv16NjnWh21vFQ qvDQB0g/Vky/SYwTLKInoeOE3q6v0tfp8pyucCrXXeKfIgPZcUzxHAQ8zctmcjMEDWEocpCScFXD eGCE3BoZyTvoUP43ZPmtBaQvvwj2eBwA9Sx4QUJ/PcqxQyjsuq9lblrMs9L2PL3enmun2nN1jT1X xO05HBWzVacb6QR9gR6kkKsg1n6C9qNDSJ6BLNSOPkJjiPoScPMFJIl/F55E4aJ3/l3yzrWSd25Y hq30hHd+JZ/tmkS+8x/tPNIDci7X1b0+m8+VXAI+mMehOMt7fIRLIzhj88Q/pceEGnrVMtaQxx3f IN90bNO3eR1Ogbd+jcNtEEctTY57nE5TVZmpDU5c7ec7EwbfkGazgzDsos3vWEEeMS2X8OOE3/K3 +1f5ZT82eT0vUeLVUlAvFDmlzTdQOsmokeu2T8TVI0BwNDWPdxr+5iAvmk2NcJCA6DnmHFTWrW59 onak663n3noP7w/3fm/+hmek63cigyefuMh5EVQfXcIzGhesuFTVnGHO2Q+pjY4m9bPqMmmLdE5S NqofSB9AEeIsIUpjLd0u/4j+Vr7KqCrjRvmsTJw8qZ2+ZFpK8AFEQ58r4+N3+2DNirPM5woxD/f5 gvz+RWtuBN5ZUzOXOSORuQBdp+pkKpVkOUHVAKWwAjg5QLU7VBVRImOiaAwxVSIaRvIgmW156ine Tw/RYXqJyvTzjN/T6hWcABV+SJGgydtiubTEJy1G1+8Vo14u44s5NJrPdUPn1z3KGSnL4ZPN8gtY kAt5NxfyFJS8DIbCjCzLgmwPg2yPgWznqvp8S9dhB5n/RbEY63N5ub/GrBAYDsPtTTPDbaSd3FIN wAay39sldJP4QBZbXmcV+G1aJCPzqyqWAXBcHAiCGcw4uFs1X4ZVBTKyFchwNx+tAbMsk7r36eIP xt3rcynEGwee/TiJ4at4d4+Q81jJ7yXPTaD8jTGA/1RyLv/7O3vIlasF2c4auQ6yhqK1lgsTYECK WIK3ROQVy6MQ6YFL/4375JLjPrl0JWfXfBuiyTLY3t8Bpv/5HbxiD0IOD+zEIB8fJrZTGXCAYEjm 1r2iugE5gAEeumbVcsvl4z9Tj0tyIkyYU3Mj5iSq5hDYNYrAvTUggGvA5q70F09ys3SSO/ZJZsAe 3xMDUMjwsHHq1LAXGoZUyo4WitmRtioVwUcOMUpilMVIxch4tlVziwhRAQWTV2O3kJ+iP1LFqPAd cDcx7rBKbpkUuxKqL+0RA3VJCLtBkjHQZvzg/GnCEA85RjqQD3zVYelF9eIouV88FmF+lvEZkOui LGTtw+Tu5V7KTseYtRkRDwuQGJM3ura4ToArXa2uVo80Va7Rp7k7pRXyRv3b7q060whlGb3JvZi0 SZ9RLLZI/7Rb3UP2SruV3axXekVx+IjH7a6nBNBOmEvX6ykDk7mWeJZgCxPCmFPVgPfdboPHaZWv x0d8Q6QX6XjmEZpgg3impbqcasJybdawNgSHdGMNfiGDWLOcHkhEzzoDG4Ok440EXUV7KJQS0tvn 5aUxYoznxnPZMOTZaDRiALKz0buLj3MoDIIta0z6ixqjoxzoW59+eyvAHCbg3rZDGiA8Dgj/I3JN 3IYcPIvIxNmWlpYuQL8LfqsV6Ncnbh52q/wugJgvTw8kM+5pyYw+CGZzxt3QLMyj0+Hu9CJcu9Z3 5wCjULW6IP1xMNTUjJNQoHE19u7BU/CK+mCkEa/E9Fih42Chkw7dvr7zc+2/kO7cWiC/e7tRvnSb g/ElYPpKroDx04d9WklnsLArSJZKvJNMcosRqMIKA7plRJEk5pQJcSpMlhIOBy3VW3pX0lAbSSBC rKhI51xCwwmtXVulrdN6NKoxUNNC1OjwsgeT1fL9uuaurJ5UzFO5lFAy3eP/p2R8GZCgmcxWWUSo RLTSxKU3gF9ZAgYkyJSLSohBP7MWZOD4wwMLMsxqsM2GjALsSjijRsBssE1+t1qYlladUdwBuPx8 PT7gB7PCNivALOPmzcN36RZPgg6EcBbm+gp7X3pHIkPv3ClAwJ6VN0Owem738L51Naj+f9DTyI1i 6KTVHvXggBEIxEKxmCwbckALaTH51dCA+89uKRQKx0iiwvIu9i8OWdFO2ulcZiz1rvQvD60Md0SX xX4c2kuMSFySfHHNWWYmoOnhKoMHQSmpJjDGBB8rXHdw74MxLghB4WFJCuqJ9lTgCo/JY+iYRB2R 8tWlXgc6hEdKypIvRHMA1JHrRrlcrttvoGSDzFtTodmbDTSrAXnTxKyuQqvxNtz0Ll7wWn9h4Pj7 haHeE7ji3Ic49p1/7fxb4Rw5idfiX44Ufn3ho8L+oyfw8j8V/lt4H6dxrA9rPy1cBp/tg4qUh+zW URgdsaat8T4ZIG1GW2CFsSIga644MAwKhe1ez2cylZ+bGUXuLXY/LJqIYvhGw/onbQHv72Ajk8uY qGOPGN3COdwxpf5VaG5oZQDXDaE4Ad8kk16wmxrT5kNmdXIfmbpr0dd3dV0r/KWwDW/6w77cwpnP F35Ih9y+NQNrjxXy+dclvH3zo98v03nmdE7soNcgc8pQLf6q9eJK82WTRMLNZUQrlyt5NxaoDFQ7 6uj0UMqcQ7Oh2eZCujDUaubo0upO8ym6Sfou3S5tpy+in0sH0GvSGXQmeBldDl0OR8tpCtXROVTO 0V3h3eYZU64J1pnpYMZsDbeWP1z5cHWb2cE6vUvLlpcvr+ioXJZYVvU1+pWyJ81N5o7yHeaH4Qtm RAvjMmC3I7EMuOq01RLLyOFAuI7OpjKRgrWSUmuGgxQ5kpI/SglfIDolHvdIhE2JK/9jvGpgmzjP 8H3f3dn35/uzfT7bibFj+xwnMwk4JDGg5boFGLSBIGD8xSobpJTyU/5/xZRqA5oALdpWaCXohKJN 7SY2IAUiOmmUsUK2tpPaCUo3Vg0hftoxscKqDYjZ+519gDZNmq37vtd3Z/u7733e530ePmL5TZIJ v4tcv6uY/QTCJBd+F7kksNMkK/4pOBKv66nDdQkL2El0vJfooFcMZ/8TvR0Vneegt+2mFipUPG2o QGl5dUgdKnfDYpFaTTh51eo02E4r43nMhxKMw9nmCrg1gvQWK8P8Y8fqwusH+n9ztvTLXxxGE4YI 4FcMX31j+c8A5xdLl1H0T892ze8+UKzfUdgy/xTq+uQiWnTyndKPPzlW+nR3Q3E/KhxFwg9KF0pw c+mDzLgw5Pwg8PohQL5J1aD7dkIXZaQ3V80b8Qy3fATDq45acEavM6aIeSFb5iM7RQLJDUQ30Acf XB7QI00w3xqoyTRp5HN1pkmtzEplhusfD1Rb5etwv1qZyXV7MgRpeUrVlPgMsatqedVqfqO8Sdkm vKjs872pDCrX5WuKCgonrikBTVM0ReL1KE5EDMGja6pPYk2eN0KRcCxE2keYJC0UohI1Tg2bgAOZ i1nyfg+BAAGFxy1PD/EiNeQ5PB7yxJ5iPLUy1ZOiUzXm/1vXnv/Zg5LEDEx13QAUdgdpQk6dh6+Y gBpHJFTqux6ujS80AHYQAGmHPLKeBVdASr7+8RdV8aa2wNlKQVHHavpY0irQKkclyNBxIuGCBj1J h0O2qwoqSHu1ZgQcD5sM0QajDSMY8HiNkBHyJ+mRGCgk6dAJ4ZNk4iDuO/Pe5t9+1FE766kHd07P WjE7l3jyL+jgtr1T9/WXGtmT085t2n++Op2auq60Co363q5W0Tu8js63bJr07HbiFrseXGM+Zz+i GnHQziykFzJr6LUMk86MoQtVX6cne5+qnjCiPTUxM4Oe6+2qnl3b65eToBWcdpNyg7QbWG6QcYOk k4ryzeUg7QaWG8DNX9oTSVTrs1I4RWfSzUpTsj09oWFe/JvJWell4nO+pfIzgW5zk7jZt1nZqq5L rUlvp/vEXl+fslvdlvpu+vu+vcreYKyiznMJS49aEd7KIouishGdGT3KorqhuHy5TdHeKI6mDV8u lkmjNGuwhFgcNc7GcnwsZtBOn6sHjijCUZmKiEjnhpvld9TOpVOyT2QTVdWxKOf1MDT2oHSqBs55 2Fg0F7EJ7F6G3nPToHKIIN5RViqKo060AK1Ee5AHDaLDtj9H/pL8Nax4Cm9RWZQlbVuW8awsWZqP fC8bGQ3PhCydSDZySXdBrhMsK06VzyS1EB61cL4D6GLHFUJ7KrDglw4b3ik3cHW4WH+FDHfIEwGM NSKxIAQRRRVXPUIxcKG/JYbzZbRlrFTGssY0NTfnAZXAkMCEnmAgZDAhB6SEL62uE76nz219/qcz OrvGlZZNX7L4O1/8sP9f29mTyqE3Dx8stKKLc3o2b7934Gzp9mvogrpi9+yvrWmfsDgZ+lZ9S3/3 8+8sWvLeC/LOl16YPy2fX1o77tj6db9fs/YGQWoj6IGTwIpeqtf2sTgGG07BvrMMP4jXDDhWFaET njjCDTSiIT6GHGogQlh06IGrcMMXrlW97JLEfZcUSmXTRH6RO/7a464VthMU6ZXiVUIG5XY/qjGh JcYkggkN+0vVTF8pyvoOHbp7m6z2ICi+GlhtgLpoC5Yyh5nDDXGMQWBggG5uYsZxE5kp3HrlJ+x1 xStRWBvEb7/l4QMWdjU5fqjJsUoWjAkLVjmWshg3UNzoNPACY6XRY9CGz4oLSHAtgODQoeDSoeAi RXhIhwJTsZFlOhQe0qFQDBJJ/ogO64s3O1TQes5GlBWgo3DqqSLKaxXlNwbkb8AwACgas+D0otK9 P3xQurvy9KRDW88fZ0/eP3KpdL//JeS7QU+7f/RXx759GgXIHvHQ5ybCHgnoq0ewU7Y6iyjOUXQC xfIcizDbcOl99dL7Wj4Pe94GQB3VGLVTDSyqo2rptNAgNUoLpF6ul98jnZJuSWJc6pQwg0UOl5ng BI8kkeLgJ9vaSNMvwLcFno9zbIDjWAoggtkAxiwPf3UjLoAb7eZQN+bIVoq1hU4O9XB7OPiMkO3D dm3haYxexj/CGJMzWpztZHEjONA97Cn2FsuCC31xQFzwRtmFrroC1UQOU4UqhEYSCd8028YTrwlN g3hNmFDZaQbATR6lFMjE34/yOiITF4CU/63VeRHTWQu3NTumk3pwqnXuXEeIg9Scm0D5sofMI/zE 8LkP0daRI2pyaNe7w6fBiVzoWblxI5O9O5HseZiivOuJtkB/tK0sZWlZ3TILVLNW0JvNydQkbbI+ yZxDzdbm6LNN9VXuVaWykXZeRZFwfbCJbZLa2XbpyeBMdqY0P7iIXSQtDa5l10pbggoblGgK6RyU Gnby2NbmZC3ksCfZ/BjNsCz2eGHzBUAi75MVRQr4dT1ohEwTpOT4AZYy42SWdI3M9rwgWE6KxRh8 ZwAhymQ5LhY0A8GgqUs8HwvqEOqapChxVQuoqqbzEmcGWUVToa5gSSxtqorC8xyHYU2mrmsaxUVC oYj6BI+mU3FKgjEIh02xaPrxeBwhFA4Pop1HysKgGAl3DEfM4eFIeNicOqG7/epDTaBW3kQPwPNp 7gF2tcOxqyTJ/zVBJe2Q1TNnYBh/xo0eHyDZCiRbI5jQBRPqt4yANJyse4QAqgwdGc4MSDZrt5ZB sboIgPCXAeHXYfLnURKBoPUi9Hppy9lPU5FWAYU++3Basip39delFW+XfpfxhgKlIajVtn2vfJ6i /zwcKf319s636J+DiS3uindPutdfqdjJgB4/PmZnoRuFkSHirJ71t6IWupVr5Vt9Y+Uxeotf0P1x PdGkk0EG3hqA2VeZ+crMET5bBgFD7qLJsAFtELHFZL21Yp1s6c3MWG6sSH7xG9xMpsh1ifPkmfpi 1M08xy0Vl8jd+jpmM0c0wQZ9g3870+ftE15hBrkT+rvMEHeB+Zi7KJ/XrzHXuevyVf0rICM/szVJ gyZskFHkyAil9s8BElRwLkpUMKCaguYhuvO6LZNI9VDYB6yEAdKQdpLjf7NdrbFRXFd47p3ZmZ3n zuxrdtdjrx/r5wIGbMcsLPEUwivm4UIdCukGkybBNglgE2gjRYK05ZGiFFcV/REUhVY0VSnF0Bjj prRYqRWpjZBRk6AaBYKIXVIVFxQ5aknZdc+5aweQKu/OnL268n2c7zvn+6A95iGdATTLMoFOxPPQ aAI+Q9eJaeqWPxBQ4c6orvJaQFGJaNKArAQCxZwM9U/mqa4Xa3xQ03ioSDxPaUCHVs95a0MkBOgs 1lyNagNk07lipUcZVHhlgAyc3TRVfAZcRexzzRZz2ORNmOQqxVw0GHq3BItPcvUEYjYTGYuOZ8Yz EDDYZh7C7QHPQxDl8DSplM+HqEx7hx585VE5tIEJ27y/JdP9gQlaFQStGk0RFLORghRIkmtgCQP5 lwDX2F+Q8pYWpCD3g791UjqW17iTCoDw5eGrG2E7HfCH7YVecAhpXoAIvMs1dxZYtVJ/StUKSxYS rrAkrSoYUYy0gA1jARvGMKIQPaTBk+SBGJQ3FMs6cr9STlNCpo057SZR1pXNWUwqP8hmafJO7nC8 ZE4o10Pv0T/mDu5qallP9mVX3btL1ZkNLUU5gpVUnOpeGuns98rzeWEBHO7m234bgX3TNSAQovDg 8SGjr4owzP/NXQCBUAUPP0DdW6PUGkI7aRfb1WuigCASvZIsirLIy4oGfVwuVtSgoqgiL8o8SuUw jvLFlEDjIqKmigSkEFEHaNSVFQVwBf3TGKARV9bkta6yV6GAnLOurqpaMcevXUMPMwSddWWopsFp 5+SqTB5pU5LoxpRIopF+3ZhCFdMAqIRAQuZff0cllIY4beVL4IFZyaQXupoHUcWiAwYUNRMezadt KFYOFKs+ryZrwjuTExw/OUFYe0PlSZhjkmUAkRe+AJtrZ6JohjZ8lcYS634CLbog+/4tUtKyZNFT xLmRPUdf4Ffllr788s4e0nvv7exPMEuHch00wlTjUjcp8ElCTY+Y5CQ/3JIknhI85ZBJdlLgMG1F wXjS+0Y7Kj9wdCDyJtJM70GUl3wBqyRUZtWFDpHXRkZyHdLXj9wdOYIrVeY6SB9bqcm1BU9SEk2e JqEbih7QMacEvlyCa73lKmy1k/LRjbDIxP9bgpQ01FllDSWkL7dzZIS8lus4IlbCGpR7fPIzwREe 5aq4RjrTnSHrck1Uj9VU6zU1Kf2RUGPB/JoVNRk9U9Opd9S0zf6hvr/69fDR2K/0UBVwsA81XyXW tChGb0VPVPVHf181FB2u+mvoapX3sTApQr9hoST0+5khYraoASt1K0ZxOx5JzqipTwmpGSuE5TOe 8G5IPuftSO7WDmh/1u7qd5NWY71BBLM2UW/PLQlGNlVvr6bVTq3RZBw23jQmDc+bRq9x2+ANDeFm oNFBBBq4cMg0xVZDQx1qiD4fPA2Htwfoif7IkaDj4P1NuDEm1ZdUKnMdXq3ebG7mRAbZ8pIEKucp Y3orr5wTAt42/B6Fw7Nggt0CBB+jK4CILZSY9gCJAfqka1S6XIVZUVwxu6K3wpOCYsUcFxjWy/0s mINjrl5UVj87NZiix1IkZePevob/0S6PlNYmLojDIo2LTSIVDTypyIglRnA/wFk1/4QeY+BxRRMX F+fMmzYcyUwX2LWkCeIRvdv4V3I8nU2OjaEKH002jWdHoWjXTs/vypvVFDOqSChWBLvgxXWVoz1j 5q2R/TXUV6J9kyofpczNhUOhYNguq+BFyaAQgpSHSXz6md919p5ftnN5w9YrW0jdkoN7Xio8Hdl2 6dWDJ1pM2S4979hPD23/1twXOtp/XlH4/dalv963+pXVQUOPJcqVbTMXbuiKdB1qdjc/Puu7d/67 b+E8crXKMatW1S5ve3LNwu8AovcDouPAGpMrJHvdo8Sj+RKeBs8Sj6cpfjpO4/FSp85Z5OyI98TF +YF0OB1bGV4Zy3gz+jd9mfBTsU7v83q7b1t4W2wwPqJdsa9EbwRu2beinxZej0/Go8WeWl9tcLan yed6VvpaPM95rhR+IXxpambIEETKFTjQAZSQY6iRxCWVmKqrtql7VSHuYrZUhlE1wmI0UZg8CO4w DKkIJgQPBNcZeHDErcV8qi8Sq45j4OMEZinr+HJKBwnpIcfIaXKHCHHSRNYQnqDpRNBCcM8tRHgR BhXCTB/xI1QIgwoqlT5EGJsaxqVJBNclQVyCRIuWNT5k3RAV3elVZhZGRs3s/UFm4+BjpZijwtLb 1c11lUBhsx6pm1tEQyZXVlrJB20EQkM9QoXM/GVf95mne7vc3Od/OL+V1rf+ePfJX+zafdLzTvaL w2sO/2Vn7nbu8hvkpxdaD118/9J7F6Emtkx+xo9DvYqRjVMOr97Y4yM+lbhcC7eD4znB76hSxBFU YoQkL55eYqeXNDy9ZOLpJYbwix++h7seN4cyc/GLRnCZrJG4sziw2F4XWGe3Bdrso/Qo/7p+3Dwe 07x6VOmkHXynZ5e2Q9+rv6WdlfuVs5oW1vZrn1LeKN3k2+7b4+N9BEqM+9JsDjfVBtvq4Y5x17k7 IHd9PpW7v0cHtp4wvKw+lRbA+RJqMg49FPyCyxLksuwsZzmJsZyscEKJYYnEpSaJSgZOkhScJLHy Ks0pqB/CXpPPSp78me7mdWXNTOUTVPnj3RPJ8W52diC7lao1M6PwwbShptlAbOQ2Z9X7IXVhW6rA bOUpzKfPFN4+dSX37+5/vPqbj+O90T0bD544/oPOH5F99rlhUkiUk4S+0vuzgq3P/+mDy+9+D3vM UsjZJ8BICxjZ6h5XqKCX6/X6Y7qnIdjgrKffUNYG1zlb6DOeZ+VvB9ucwfiHno8CV6NjgbHgbfuf 0THGvHA8nowhXZtjyF1pFk3os8LzaYPeTJfoS4MrnPXKE/oWfUy8Gf6STBgmCfGGavqAkapkcUBJ Xo3UEa7c8pWb5iWLmJZrtVl7LaAmYiJPUMuPzLFY00KqWiIiyGKEhdHPYSrcuGXgjcPvfzGWQvAf dxFmx3rRn7ggDUufSJOSgClaI/FSEYMcq9NSUR6KLG2sLUms+0jRovqWB5iW6Vo1nn2QdGkTFdIo 5iyN3/s868oAzRqwFkMxzicMOEeC93nGz3t2aM9Huzr/x3X1AEVx3eH3dt/+ebt37N6xt8vB4d2B C+hdE/VOEMuEtQacRAEx0UoqKdY/Y+O0EUeN0ZDimKhtTYdxJm1s04K1dUzaNIhMqtSp14ljZzp2 0DZ2WpOomdCMpiVx+ocqCvT33oKlGYZ9b/dud+/9vvd9v+97Z2/bdx88OZb4+fYdPz2+e+eRfT86 ePdoNxa/1bxIyButF8IXfveb81cunGOYLQUVnQE8iwBmj3lOHMUi4BBbpVa6Ut8gbpaepht0NcK6 IF82TLwVbFYcY8fy8F+kUWukkMwNL4zOjS0KNxQuijWH10RXxNaGv1a4NrZT3hkZEUYKTGRjI+g4 y+02e4st2jGjy+wxBdMkRTFNQQPC62zHTqlZDtgAdTeBHS/nA3scD2z/e/2spEGGBXt1kPV/VlKe CGj57GxvEAcL43B20i3LstFbxNpsHMftjDlT8WbOzk4hlZiGVIwj5RMsxjGyOV6A1HRNbE01jA01 mu3gZdvZeQNTwjHokEOcXK01Y+01PNYxuFjM4R106xTFTJSZh0KWkrQZXjhZxpuo+ORA+pPTN8c/ xdZ7l3EevndD63tx3cGxK0JzYMGqbz73Gl7lHO3HcRD7AK4Yvzp+x0y8ObAJv7xv8aZjoCL5AGGn 9Efk4KA3w6LYiD4YnRP1oluiPwi8GnwtqBYGK4K90VyURFk9Kgrj2WI1KAaMmIYjQsrKJ6KMtG4L WxP5HnFcgkThEMgSK+LcBVk2eqlYPNuFcNRjNIl6QaDJpPWv4La/hBEHpSfNPxCHty6L1RP5Ho1P PuINDyajv+Q27GhB9AweQEk0gjU0lRCmaMCzAljbYXN4uNUPCmBxh6tDUNvFz3qWGZKpIqvgkEwa LkIh2SjCENpm79mDU8CTrcwEZ+ZnqyqBJiBrTNUiGTDffd3d+YV7dyxbU7Rg3oqHBwfF7x9s35yt /2L4h1p921cO3tsIjPjCeLP4MTBiBpqNn/badF2y0rprLdPrLJkWR4vTepmVLq3WK61H9XprlbJa 36SPav+O5D1Qmi5/qPSh8mXlXemetFKZrJxVm67X65N1sx5PPj7rq8q65LpZbenO9JXyG8lPSj8t Dzm2HDklnOiviOUrvJOYCTSH95FOlEMXIRCcEjq8eVIsZmh1JbGAZkcybkZzCwouOth0PKfN6XRI GkourExzWXO4rDn3Zc3hsubY/DNAw5c19i2Znfuy5jBT8Cjb9M42A7uoJD7zrDFoXDMmDBI3ao0m aHScMUYhw9YoYU8zYuxJBtc2g2ubEU2ltyWZvKUap8nbv4bNzyjc2NAIhJbhIcafITay5NLaDk3J cWzHN5DlwBrB1zkHMo3FTWj+NLHb+KY+b/G2jgMFeXhH77u3vn7ppTO7jm14t+fXHx8+1vHc8Td2 7Ty+urDZnbf+iareb+Oa91/B+OArnfeeuj2482fi7Eu5sxfePv82S1/7ERJvQNey8NrTyIaNH3Gy Iost3F67ZL5YJw4ECb+00IlmHTUUCFmihJERkxRL1wIu9TKV2QmKcxTbvMfYHoOBVvCjxSCgLFiE WOEo93a0kH0Pro74kFCLQUJZg9HZe6nG6MI+f4vVljbajItOtjLba9+yhS12j91rT9jEFiyX89Uz 4TfcgvWgBOyc64gwqnFBZRPP4Sz1baXKXo3IJENHfT+IBE5LgVvOxsiS5ZPmYhI1ljZZpJjmEPll UMEa3w5W47DPzjw5T3Hz5EARDqrASwTETO1BQGqcyvgu0bYjodIQh1GOhPb3P5/b8Yul/ds3L3+p BizhPw61/uTVsS8LR/bvfuw7HWO/Ak4eAKDgI3B9Cvq99yStZCtool20h/bSHL1Gb1EF0TjdQjtp 9+Sl63SCanEKHkshgkhl8XmMZEkmmqy4EiLdpIf0khy5TuQcuUUERBLkIpwR4ntlYSW5XzfC60Y0 9lbClY1MKRthJpzVjDASaayGpFH9bPW2QvWYjNUO8xbB/tmW39qeyp+fiYhQlQP9/f3kb4ODdyOk 7O4VkPWJH48344V8zWF02asjkit9nmSkfZLkqJKkECIQKR/hoC6IVoCEJF1hK9RlJRYyukDRHQdY GXQ1rUvHcb1Wb9JFna2oiq1IN3ky4UFB55lSn8GTSYAtSld5JuHc1qP51hvJJdNZzVkM2aCm0azb 8PBH7ai2gWUCWFW4+v76QpnMflOt8XeEahplqqkVYZqnFCF/R+BWtnZcxSkNFbAUoPi+/vFNJZXx qsr+zKLvPUJuXrp0Z/fhvEcOkTV3e841rGd8hb0g3oa66MJar0j2vZW8Sn6Cikbwn9KILNIAQ09m GYstT5ua0KkJUPmGZ7IbV4rPaEJYTuQnsyqEs5Ph8ixlIQ3GsMQvJPkF7wW4IhMiEbmKLgEo5M9p q7VnxO3aFfFDWTkm41K5THHVankBrQ02BVtIi7xaaaEd5FnpMD0v/4H8SR6Sbyr/ke+okbCmSaJI BFlWKFXhhKqqq8iWosgiIa6kWZKkabBhiYphW0qyogJjkUZOYcOjEmHYSCUqO0smeDowuW0p7AID pLtIcCErIlyLmoA5sD29uZz7HHHEEUd8J6MwVwAeJxCPJigaCH6QXLJxOtYcaujDYH1GUq0g55zy JvzBdq4JOdX7pQdSpMM8B2NBKg8mCsCu1oj8eELm2S24lOI4fUEUaEEwlAUtaG+B/b94zWpPo+ni aqoWF9cAYFf7iqtheKcvwYcTyWr+E1rA+YL/RakU3HEayRO5vmQ1gJjrs9lwtc+slv2BnwX4cEL3 b061wGZjN3rh9wlWLRveZlk1/AB3jfQVsJv/fqLI/zpubeHWjc3auV7hDMalWAGG4tdvjj+Fz14d P/INaeDeGdw7vmNsvRDfNf4lti/3wqGK8/XDtyQuUBKzUVULsnzMzvfHOXP9scTlo+dCuzGkuNQt XZNIExxuSWJc2iJ1ShMSATXXBNEXePYkLvQRcDbdCOcgZgrT1f72/9S+eJra+1j7fkydNGO+ZMFk ghsAdF+7UCP5f+1i4pVK+fLFu/RW/zKrzN5+aWC0frKHymXgmUrxb0+jINCMPV49NTkBBv3Za9CD WZcMkSH6gfPXhHRZGkkIjpoopQVFCSqKpTNicoRZCgXLpYVRU7vo4i63579sVw1sE9cdv3d3/ro7 2+989vku5y/8GewQwHHICB8+aCgfKaElLSuJXSIK6xLIipPAgoAq6UqzrhOldCjttA8+IthoJ2jI EJ2GijagKh8iE7QbqlCYylhblA5NCG0UJ3vvOQZDFznn/53vPZ/f7/1+/98vQkeQjtkiO0UgsiSx KSSt4W7Kk8TmxD9SxIx24x8q0iS3ERlDttBOMsvd++ltIsWArC4okZ0a0Mh02v3pNDIdOv9aF/F0 GumSGoen0zCXSHPWBDwxOr9HJtbwfDJFV4UiYJhC3NtD0X4K848h/PN+i39EcSl5ogPfK3rk27qT tOICFLYCJcOR46D76KMKTJoKSiSw5MpoSXPO5huINndQ2Dyj1kNIjOgKiEwXZFlwSlGnIGrAYXUV G/VEdEH4umaQkIkPhXZNfHRp496bPNC2qd//0tlfHToayszd8LOhZ9c80VvLRnc3rFr97B8OH8vH 6F+uX1W7eyDfTw92dz/58zfzV4qe6wbaLzLYpksGxijRv4HH4efMP6VbzB3JyGLJnY02zGYI3obD yjVlXGEDZqfNKTuQ5wJG2cpZbYItrBCfpRDPxRO3xRO3xd93WzwhAR8kd+AVJm6LJ24Lnf+3AChP 3BaP3RiRQ54YOh6gF9+gYNKVYeel3FLoDcoe5YhyUmEVhq5yyYSbd4ZEscC8/2+4uEcMl1hiuNgJ Jp7UHY8auAY3vJPNPcAUsfA2MWEPXUV/o0iNsQ9DPfi+C5ONooUzcyaOMcKoaLRpwM45JkCO92K7 jbYQQRn7MfdDEPft23i1Ze+TkBuKr1vUeZCN9h9esGFpclu+k371B+3zdp3P/xE5FKpu/As2hlC0 UipYd8yl4F8iISYSktkxJTtxpZIPHCZOFRYaF5lXGFeaXzC2ms0pWOuolauVBbDeUS8vUDKGjGU5 zDqy8nKl3dBuWQPbHe3yGuWHwGUxGqzNzNOGp7lmYT2z1rCWWy9wbg9rEpFkOMMayT4a2QYmnHJI 9jEp+KoJTly9NYTXnxTEM+AC40AK0kAxCFI4kppmApQJmgImxjR9BGkEvr7YF0pNQ7UtTAk2HHsd hM4CwddD8LURfAusJfpDyQRhHU2J5YCmppelarC4Zh8gB3OJ7J1stgRLlIzSo0hqUY7N4bZlaTQ0 WlYbVltY3JvwLRKsQaBRLhKKqNJQVDfw2unPgLzl5usjY6MfDPa9Onh0e98gLYHYjk1jf89fuPky 8AHr+XPn/3L63Fn0QH1jrewkhKCD8oHV+g4BToFzYD1k04EjAdofmCyEvElX0jvfuyGwM2Cudddq S9xLtJXmZiHjzmht5nVCK2x3r9NOBi45rypXyy75rjuv+64FxgNyiE3AhKuarYWPs0tgE/wHf9M7 BnnRxsgeD1Z52WPjKZsaHuYA5HSuhevh2ACBMEDgRL7ths5jIDll4vxu0dB9TbAkzg5DyOG9FsKL zXUBqYquckQo6iRyQWAPOAJuAdYP0mAZYADuc0SNAVFjQNQYkB0CBDwlwGTG2JFbSTACAp4YSSTC Faj+hTUKSDTAR4QY5m9ffxBzszmEYpp4YqK1VBY3TionFUVVdjlpHGhjIlOCXt9A7a7v/3i4bePI lqY3KsUDm7rfPdjV+f5Yq+HET5566qfjb+8f++b1J2rz3zADF06d++Tc2b9iFi4aa2WuIQwh5QEz 9B08naDjyiy6nt4sGNOutFqv7vTt8RlSUkpL++qkOq1RatSel57XWnw9vsvGTxw3jF8KXylwMh0U Eq6ZdLWwmH5caKJb6SvCZ8rn8pfqDe0ebQes1Vnm4U02o9PDIuDctioqAuGwHUC7bm+x99hZn86j 5fQR9OwOrIR2rLiEjHYjXna7TD4jjRQvvV3Ga42lgjCQ3J4m6tElhj80XTSNmMZNrB+Z3GWIjGHC 5DI80BQk3JYLxpfwWfX6uialSrpkNrd0NJ8owWk2Qmn2t4GhckAkTBJTGBx3NfJ8JagwFfH+Z06M /evFSy+dzu3LT3qvu/PA4U0b94+10uZZDaASmPaM/ejAjruPMb+7cOHPH13+9CPc4bYjaM4gVETq Y33WVAlAFoTYFPsY28h+j+1ijRbRbDFbrJJosVKMGfCEEhRnKd9pBuZgQAISHRQLxk+HjzaGEq/3 H10saTRGIkQPOQqyhyljiclvcCw89XA8RZ3lOsze7riOFgcvzUz0IkGOgh/32badwgvVAbJFT+A2 4XUxoUaxfd/c1nTzc3Pnz5/1nNPHRvfmFtUejC1Mt3TkL+NVSI9/wbyPVmEa49a3sEFnsNayxFIX XhFcG9xq2WF5JXxAerfiT4zV4i5T3NPqKz51GzT6GZqGScApGXPGkuEyfEbIWNvMbZY2ro1vE9qs Q9GhmD0WDcfCk2eEm7iV/JromvKuUFe4J/wW9wthV3l/xe5pA9xvhf2xgfKj0dNRubzoRIPFIlQs wsWivJAOJ+7BRahYhIuFF+UK3eGb2WSORQSOLQtEXSxf6S07Th/Sg2oFXny/mlaXqavUw+pF1WhX /eqL6ojK+tU3VFo9gbBxoX1xiAIIVSe+HQId0BAMo6AHIKAB9vlOOQUI7DYxBUBlxrveS3s9LhOL HwMPQsUNAjAudAkDzHoqeX8ZKAuruqSkknj4VEw7VSkcMVtUGe8RNYBHqgE8SiXBUZVJlz5ONw+a wnE09PeemcNxEMffgkfEMT3xNPEiT1Hx1TE8KF5GvmpSLJ5qSZ5M0ulkT5JOQgBAmFIKfpdsuUBh lZG04wI/AC50FT9EIGwnAmwnj2cPTCjEXT1AdMNGhEEgohAcKcZadTrupEiGEcknpHgU/UP01tFA LBK+lEssLfHEo8gL45vSoznHzKmFZINEm7yhzY5eaM+7C+5Jj03xhQzOiqgIHVCCjDFoDWiUpdyk AcMUdPA50ekkW0ijgiGrYJ7MaaA8ZuGMCVaj/NCLfVYCIldWOOAEmognent7qRI5AtmOXFaqkQtS E4vGKunq1IyaQoNAHCNezOlG3sztowvNPpoetL+2ZWt3deStM+8sm/ed+JuN2040iUeEztatbbI8 VXvlw/4VrWe2XbwC5njWdaytmxNSIsnFvQ0LN5f7E4u2vKAszyyvCXm8Eheumrc10/Tr776HeRoe /zcdN7xDuam/fUBxaA+GoikLRnYeKnpUQAHBygGGkqElYedQ62b+R3a1wEZ1XNGZed+Z95236931 roG1Ye2FRZjKa8wSt34Kjfi4xCFQyibZiv4c0RKgH4WACCEqjQkltGmlxPSjpIlUQKoajG1sTFpZ KkX51C2tgLRukVyVJBTFVVo5VCn1undm127SevfNzJv1+8ydc8+5x/L8BtSAnSBj4xnDvIvetc3Y bRw0vm2oCCqn543TxqhxydANIdaCq4yKWMvBPwYEZxkVP1YdSFavVNCVmkxoP4z0amlWqSqNEfJF lMAr+rr/x6SC/E5CfexfFww/2QFDwfC8pcV/VdjWXC4TF/FrbOULgd/bgMkW8qgIPfGTn2j/7I6l hw71Dw5Gctn5P3rO/9gXXiCfO4qNHeWnjk5/d8PSpIjR14HLJtRGeHrXOZSE2NCaeJ6kI7G8J962 JYjmcxG8yIzEbByJWUDmHMKEWmKZRFzYiaT0KnHpUuKBCEBc2k4Rgbik7/icP4lLfxIX9C79SVwa zrjwJ46Ix0wcj8Zx/O6k2KMaYU2S7ybJ7uTzydPJmaSatDN0TjgoRjRNL9EJqtJZ4aBzwkHlkykT T6Xi/lIvqPQmlIhn07trhfecizYk1+T/mxBQEBH3jvaKcsgkSqq+63gO0Q1TNzUTjIhqp5Bj8hQS NmTJksdBf+Ha+la5NU2wOS0cAC8SYoUYKx37r3z6xS7fGrD4zo0bj90x8IOBtQ91tX6VfGe6/6mP rNm46VuHSeH2OOwObJFyA3aH4Zt9hKzevDWMayZipo51hjRqaphoiwT8tObctTH/2hhAQ6ideNXU UKuGUQMvMMHvDi9QsJl5UzQEmK4felzt4T9+H9L59XmUhUbWnbQhk0cxaOBsPDyQXZZHaWg8ezHK 0kZWQK1sLVrDtuAtpGhupd24m2w3t9NH0B68h+w1H6F7WA/uIU8oTxqHzSP0h6iXPs1+gl5gP0ND Rh97Ff2SjaMr7B30F3YbTbGlsByWQDGWRY2sjXWhkFEtDGJ5DaCS79Pl2imsRywdiRI59MQ2MiQ5 VMRCzMlyVkRFzhJNsy3YtuZrOYgNHGO5sRxq7uiQW5kK25hhmhnKopQypBAChUkUY3gRBiWLaRKC dYNRBWGt2cZ2gxmGIT1ICR3GqcFQO6gRDUYhTZMQN1g3fyfQNJmsnS5Nl5KJyeslUWqIaqOjXdBl B6Ruj7Ys1/PohZ5lCdEVoQDJ5cARfdD0olKxHrdEYvEVbZEWjH9a3vHz65kFidw758o71cbpQw/u 2vwwOQzgAHToCGlDgI5AnVdBxzkUiMpUso8uhUqveozLA7YjJfYGlKgw4mm78sPogOvLH0BaxYiH 8pxxBSMbqiGsexANx9ZFQtkcE5WpnIkTPkt0HFRnbMy/OuZfzo0J9IkAC8WpyoJIhhRkYBQvURcz sp7fz49xhafl/g3PTEgKVGcHXNAOXVCf9+vmNQm6fjccWrAor+o2jegpWhtoKlJ1i1quGfgookSN OjNlzQMHmzGWmDk3j1qNVeYd7seVNXpobDA7rdXeGr4+uN+7N/iS8XnzwWCvvs/4mnlOH/HOBu/p t2nW4lmUdZrcrNcUNEdXorZgj/mE2as8a5/AJ8lJ68f2IDqrj7ivqFf1P9Ab6g3v7WBK/xets3Tx xrZsfdm6svVkG1Rhm2KupwaIm4aZMbyMK2ycaygOtjPO8MzVsE2wlAPoWyK9moOjEZ1ZvJHl+Gb1 XvYA38H38yOccaYCFsV2VDbmv6EuybK2OTcFX3HuXxefivrDNxVGFU0DwjI0ypgJHoX5nAO/d/Zr KICaZV3YzTw3/QtumGmDB0FOM6KaZriwzxnHjTqOa4LdyTEzCpcjbS5TEMFGoJoet11Hvl4APG6a hiFSJ/A810Usest38DZnt3PQUZxhfCJk6S6Gd7HHGGHD5JMh7eJ4F3+MEy7OLF/D27TdkFwKJNeJ QXwrcqtblkS1G6ZKpQTUNfAVSVZKvDWXWX71A0vH1azjsu3Z8MGE+3AHqOxx/QuG67eLQ4zF0Xl6 waatA07aTpOXZyagpp1A7sylAbTcSweAUbyy+lfsPJ3fBBlnzlzqM5ZjOVG/qfN0y8b75OxEn5Gu zAYwO1/Owo3OQikI9wa2unTGWC7ueAatJCOVJ83dfO66uLyOz0z0s7SaRuIHoA28+gF5t8tngwJa CgckeF+kACsqVsXsK4JKRK0IVlASiuSTSFyQykKlScGd5fMjpzrUllPnnmv96NmXygPnTy1+Awjm +9f5a2TndO/rY6T79jjZP/jv3wDTeKBDfwem8fGfqjpU42FLVwnVie4AIj1ZkXvNOQlKHpf64wXY a6gt6EJ/7qkt3Oc9oz5jHne/541qo/qo8bpHvTBWSCoRWuMk/Va8ynocH7PM5uBTatEoWlvdZ3Ev 67WGyLD9ivWa+yt/XLlCf+v80X+TBbPJZdko4F7CgcJCF+zmipGnI+IgxgjkiCBeQALQkOhSYbeu K4ZJKdZ1qqkKlHwe6LmDPc/xLSgqiGMpts90j3jMv4guUuJnEI0iRBXiXHSwk7GVqG0rjFJFITo4 AdtGrCvAwTrngN3AvM/o9EDIQBmGQv0e/aCu6MNkdeimlQOkoQtiuY7vl0a1NFURC9AK/01/avKt 0ofwLLSiVEVr6VH/AhKv73k9pkRppYVOQLfdbK+CYsBNzCtYIt7WvILdEC8ocIjzM/UFX3A8qyng hvoCDesKs4pTLH0Z5UCDACggOC1xIT1tMAKYYA8fKh//84vL6pZm+t8oP42/eW18VfmvJIvL769Z fmfL7bI9/Wu8vlguwbrqyxuVvwFGkvifVYzMY1FPsZS6Wi/QLT0SBl7aCu10FSu1zbnktWRiLFnr i04AZ1LKRqrfq8OeWMRDdYVsdIv3ElNCJ4QNSWeX533RGDYNYk4iaLKa7CZnhb3CaXWPcysbZCNr Y8WgGCnWbA+2R7bX7NUfdvbyfdF9Nd9wjvCjwdHIk9FedtJ62T/PR6I32dvR95xp//3oTN38WUTF Iv9hv1pjo7iu8Ll31nvv7s7ODjvjfdgG1jb4wUJs8IuFCR6HYB6NH2DAYHCISYHGceosYBIechIS UjVBJRBE00QpLWrUVFQxAQNu04pH+RFoCLRxW6oqBBWnIq0sUOOgErJ2zx2vjaFEtFJ/zr36Zs7O 3J255zvfnHuuJyPd4XvQ94JP8oWHp2/ND2PQmNRRmc8nq5grsXII65o23u/W8YdPxmQ43uPWPR63 5vfLsscpHgAZagYtyDiWQTO6aPlhH3Jh6l10oekp95t+usJ/zE/9XeSBIz6SBbPS3eKWxZYZkQvl GlmqlQdkKuOIQwU+5IaWd6ZHtmBiRPIScdwuoojQ7A2pfT1htacx3psWUnstC0Ji4zCkKI5KwnMo qiQl9R1LP5j1FMw2Icw274E8cAU8A1fIyFyjD1w8UhZzZ5XFFPzKDqfGRmWlxpLqwUyDNQzKR8sV NW6Z6LdKGFyqsA5+Rp8+0ZgTHJWT4ul/4uTH0ayx0cud/S0V4wq3LC7uX/MzNW9c+uO+0Y68xA/a ntuygT5+8/2OB5bWiSonD3NPN+pKIR2m199FT3PqJ1P8wWLMoR+aLjTIDKxa8ddJcx4a+TTPVaDG SMw9l1TSSj7XVaMuJwvpQt7gqlVbyKP0Ud7s2kzW882ul8k2/l3XDdJH08M8h+TzqCvG3+J/Ikx8 LUfV1GKK6RWLkG4z2x8jdJrLTbnbPZ5QXP4owXXRSZtSouiiu8kLXlGCuqzVPKq4aRfxdeJimOJ8 jy4DAIY3A+Imy/L+SCGgmMojyrPKNSVFEf8bJ24p68HdTkgHkBpohQGQICQuQ9inrs8UaSNa3YfZ 3ahSe9WEMHqiap8IbgK3KVFD/RS3iJ+OEmt+stRUlVNRjKG1EljlGEbzcD7J4ZQMsccFl/jr5FHB oqDSGkjiS0mjFXuO6cMnSEierhxNj7l4IP1+UZwdDMasbZc7EKM6Ii1wK7EUlRBndmZJZiphpUWZ qXn0J+uW9NdI30ycaN3YTP6xS+LOXU8lHt7sekPEuZ5OciyW2iAAi0z8fByBdI8ecHgjUXk6Sp9E cJG7ZCoeLPDUiKtbhm49InXRJaYse+W0EIFwML7dqhQM9boBBVV9iR7MqqrY1vViLdqolZQWTQkM 7sPKUp3W5iw7y1nf/HPjhU2zZmVXvFxqPr/AeKK3xozTSWefzi4e7a+e3m2UZjSXoQThKobQD2fR YuABw/Q7UyhxuA1R7zgckttt4MYgfJAZWLiEj0oG/Fb+8xci0SdET+Z2tTc4ZXJhUUlRamYSV8+S i2fJxx+etRpWAV+RM45WVIwEY0wfKQGalhJBesKOQ5uEez2N6t/QO3RJQmYdjnXkzM6dWIlBnfQ5 bUj5COcWhAvm8r3hjjC9yq5q9BP2iUbPsXMaPcaOabSDdWh0L9ur0R1sh0bbWbtGb/KbOm3hLTpt 4A06lbmsU13jLCj7PCD5bijSDap4KZENLxhe0kVqzQKtlT3DdjCJEW2qbihe2cCCzwymFStthE3l BiVgSNIOSmg4FP+pFZlGFG4CxdqjXkexWhaUNxoJoxf1bLGj9pLBmhXU0+ppDNvaeDxO4slGGklq dkkx5peg08kyR9hEPxGZsGxiWbFEdg9ZjlO/e+tFoza/Mris/paFTM2WPqPVKactpv5iVltMXePX dEo40ekldkmj59l5jR5nxzV6gB3Q6D62T6O72C6NbmVbNfoke1Kjq/gqndbxuiRTPtkjgb5fE9zI XqRMQbII38/EhUKCBFIwCFF8hox85XqDM1C4gi5vG6WoFqQsFyKEkGaLLawPjL4ewZGgCpUsbPzI BUeJ3qHz7WQN8xSPI28EFV+UqjMnyy0tLSsaYdefGBtdNrG0RLowZDj+hQRNn58/O7Ci7pYlvspn pc/JfEtV7WbpZr6dUy8nCUYusquM/pqdY/QN9g6jDayFUc5QLOgnwc+D8Kmt5Bmyg0iWWlIZPsty ETUREZqQ39x4SxPonXCukfSAcNkQMhBeDfkk3BkZ7Yq7xRjf0CJ9Ru63IrvezPmIXWb0XfYbRv/J yav8x5yu41s5XcRXcUo54RivZHjGkOFpw3AsrGDcNs1kDAYnmGQfhkQqVDqS8C134xaG24Q78Mf/ BD2OaceJeBHAMTGJ3QApMmIB4nuIfsxKvwTgewDcOF5+HcD7JYCvE2DUSwD+UgD9DEAAxwUbAEIh BI4JuxGvAKRtBchAjMFnjz2FPuO4rEqAbLyfjc8bXwuQsxggdxpAXhZOdQnirwD34RwKjgAU/h1g 8jWAoh6AUhw7Fd8dextg2geAKRJgRjtABc5jZmESryfRfzsqzwPMeQdg3kqAhwIAVd0ANbjyz8f5 LvgVQN0BgIXvA9Q/ArBkOUDDdoDlyMHDWJivuADQ9G2AlesBVmcArMH3fusiQPNXAK2rAeL4/nU4 57Yzt2NDs43/Cr+/O55yD+LpYoCNGJdNCuKgDRs2bNiwYcOGDRs2bNiwYcOGDRs2bNiwYeNeAAoE RNNBEhZJQzjhnk1yiKPL7ZFB8amj/JqeGgiGwmnpGaPHjI1kZmWPG5+Tm5c/ITpx0n0FhZOnFBWX lJZNjU2bbsAMMPGvD86qnD1n7rxvPFRVXVM7f0HdwkWL65csbVi2vBFvNg2+ZP+IFx4+cqgT3r33 xP5fzQFv43EcRNByQCbkw1JYBo2wCdphG+yC3bAnokVCkXAkIzI6kjMwgKMjkANRa1STNWonvHrn qIHLIzuOF29Iv/TDS29i/z72bcl43LtJ9xzBYXXyaRLIeCRJz2Tsg7YTrZCIvMOFV0I4m0GbggJG 0pbw+ryk7UB7ZdJ2or2poqqmpnpmtGLtY00tX2dDBVRBDfZqmIn8VMBaeAwZaoEFsArWQBtaTXjt 60b9r9fRM+dLeCiHDcDQExUKYDG67cUYSfgbnSCvQApwEViwwjt4htXUjyQNtzvpLMeG2o3AHi4e 8wGXpdeSrGIsngu+tnaFz/iCp3Nr9L7LuRPE+Rd/6Lz+ZUdizb8nwMABigNQOINNBgCFB7S0CmVu ZHN0cmVhbQ1lbmRvYmoNNjcgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2Vu dCA4OTggDS9DYXBIZWlnaHQgMCANL0Rlc2NlbnQgLTIxMCANL0ZsYWdzIDQgDS9Gb250QkJveCBb IDAgLTIxMSAxMzU5IDg5OSBdIA0vRm9udE5hbWUgL0FNT09QQytXaW5nZGluZ3MgDS9JdGFsaWNB bmdsZSAwIA0vU3RlbVYgMCANL0ZvbnRGaWxlMiA2NCAwIFIgDT4+IA1lbmRvYmoNNjggMCBvYmoN PDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAyMjAwMSAvTGVuZ3RoMSAzOTcxNiA+PiAN c3RyZWFtDQpIiXxVC1RU1xXd5777ZhABEVEYQPOGUUJl0ECjgqIiDChVEcUY8JPOyGBARUhEq9RI RaztSBqJxsRPrJoYjZ/0oTQajYrpMiuxfsLSGGNMwjIaP5FVqrVaI/N6ZrRWu1Zz73pw7rnnnrPP d0AAgvEbKMgbk983eeq5gipgzTrm5haVuSrqlufMAV6fB1Bj0dxK7W9PrDzGd+cB88BpFc+XBVzZ Fw8ERALqF8/PnD9tUX3gV0DKDsCxvqTY5T5xwbqV9V3nN/1LmBG2MMxgg2187llSVjlvgyl5LRAS DkTFzywvclFDbAHw0ig+28tc8yqCa2kFv1/A8tosV1mxu3lNKrCa76lvRfnsSsbNa7Xdd1/xYnHF MKubOfFpQGi5ug8x/m8LYmQcYgDj4n8+b6lx0Xfn+y+usbbu978Haxd24AuKJw276S4icIcslIQc SNxmi39CO15DOMZjFYWhJ7rhGeSQZJkE1NFaY65xFYPxKjYZe6jG2Mb3r+Bj3GEE30jCAOSy/DMo xlXlEgqNNQjAUnTEIIyjbnDhDO9bjGEFVuIgLTDusNVw1LC+NAzDMOOwcQ+9USeXq2c7/Bn12E8m o8goRQ/EwiMSjDPGt4hDId7CDsaUQE1yBKyYgSV4gyzKx0y9hrfhpSAxRclUD7GlHEzALPwKHmzD UQqjPPWs2mb82rgME7ognjGV4ir1o9FiswwyhhjnMAkf4BP217eb5CS5RZ3kHWq8aXyErthDgfQh HVaT1T+0LzI2Gu8hiPEkcURy2c5ULMZhfIq/44aoNqoxAvls+Qh1J43iOOJnhEUsFAuVU+jD3k5h tHPwR+ickX3YjwMcm6/QgksUTtH0C5pK9XRDBAm3OKmsVRqV05LkuxxvG3pxjCqxGe/jGI7jJKms /ynKo+lUTq/Tm9QidHFd3JYBcrH8Ubarcd4W749GrnELkYjCKFShmmP7FnajESfwOW7gJv5JoZRC JbSRdGqh66KDiBVjRIVYJTaLnUquUq8clv1khpwhj8tz6m/VZWaX2XvvHe8K705vs7HHaObaCWH9 ccjmiC7iqtiMQzjF2r/E17jgqx/WP4gm0nNsZTb9jlbSTjpCzXSNvYR/x4pBwsFWy8WLHKcasUKs ZOsneX8mzomvxQ/ilqIqsUp/5QVlo6Ire5XPlO9lqIyTfWSSHCMnSoMzk6wOV/PVrep29SO1zZRm cpsqTFfMNebagGPtvdu/8cJb4tW9u7l2A7iSqjgS67GJ676Rc3CUI3qCEbfgH5yFKLLSk4w7lbJp JI2mZ2kyFVMNLaVX6Q1aS5voPfaAfRBmxp4ghol84RLFolYsFS+LRt77xKfijDgrWhl5hGJTEpQk JUeZqExSZrEPlcpCpZYjW69sU04qp5TLyhWllbMWIXvIObJKrpZbZKNsVkepZbw3qYfUJrVZvafe MwlTlCnG1Nc03bTVdMFsMvc355l/bz5tvhlQQTHUm5FreGQJC/dgD7FNhMtqamVGd5LoxJ4ncB7y uStuYqji5byE+O4ZW1dhkV18L03pUuf3lbQf/egIqk1C4akqW7CLzosW+RcxGJ+TkyxyizJLPSqs 2M7TaLn4UOynDDSKNDFBrFNAl2grLnG9z8NKmkGzsZ1aaSC9RAOoGqdFNyWfapFmbBKSOlAOtYER YJF04zn85KJUntZXvetlsFzA82kvVnFGd+Bbehd3STWu83RTeBq5eMrUcb0vgW/qTeE+q+Z+tPAE mWk6iUYy8cQfYBoiq9CGf+Gquo8rKoMn6WVvqVwvvzMGGIncYdxl2Mp9V4Lh3DGXuEoO8Nl3msyd HsizJJm7Og8T4cZLPPXqDd1YZyw25hvl+Cu/vUt2uksbuCP28os0fML7FXxJy7gPh/+0n/9ved1o wjWKpF6UzP3Qqs5Vl6vb1Eb1oHrclMTRrsVarugLXM2B7EERmnENtymAc2OBHU8z3hTGXoCZolA5 gEyKQgX3bDzP8YwHnsxmLTUcvXXczwe4N9p4TkzGQZwlQRHsURHbD2A9IznOv2TpdziDi2k3c9w8 tXvjB/Y7hFJEJdtLZ02reGo1Mabz+J6jbfhx2XkuOGgC67qNZ+FmC/2RRw2cgfeRypPVoRzjePek UGRQLL3N75zcoSHojlT1OxKwe3ONFFGqHODfGIP5G/jXKxqD6QVG0Yn9aEdXGoN+3nGM4RSQPmx8 +tAhg9MGDUxNGdDv6Z8nJz3Vt0+iPaH3z+KfjOvV0xZr1Z7o0T0mOsoSGdGta3iXsM6hnUKCgzoG dggwm1SpCII9y5bt1PQ4py7jbCNGJPrONhczXI8wnLrGrOzHZXTN6RfTHpdMZ8lp/yOZfl8y/aEk hWppSEu0a1k2TT/usGl7aeLYAqZfdtgKNb3VT4/208v9dDDTVis/0LIiSxyaTk4tS8+eW+LJcjpY XUPHwExbZnFgoh0NgR2Z7MiUHmGraKCIIeQnRETWwAaBgGAGpUfZHFm6xebwIdCVXlkut543tiDL EW21Fibadcossk3VYcvQOyX4RZDpN6ObMnWz34xW6vMGy7QGe5Onbm8opjoTgtw2t2tyga64Cn02 OiewXYceUXUx8r9HVh6WWbD00dtoxZMVWar5jh7PUk1vGlvw6K3V97ewkHXwW9Er2+nJZtN1HMSR +RpbE0sKC3RawiY1nyc+r+77V2zL8nGc0zW9gy3DVuKZ7uTURHl0jJtv3RUVlf6B0YKoLM0zvsBm 1YdG2wpdjpiGcHjGzd9tSdcsj98k2htCO98PbENIpwdEUPCjRPHDOz/lF/dRI8c9jCz5ENlyuCB0 rUhjJAX/5r7qg6K6rvh579333kpssqmFKkzikg1EBIqa+IVWVxmpDRMCCLigkyB+NGpbaZg4sTMh NNNWskjrR1QUtDZpYgKmXYx/rGDbtenUaEqTmYQ0YzMZizVV0U4z0SaFyOvv3Pfeuqxam2b6T3f4 ce495557zz33dz+eH3Oawf9WzqDQ8hlohl+VAq/wCqzI6vCogpqQN5/17B/WM7x+X+gygQH+ixdG apY5GiPDe5m4yDyJUQ12txzOzg5PnMgUMQuwpohxjqxPzc1ZH1Gn+eu8Pgikj0qQ22VV+XlIf3o6 L3BzJEC1qIQbS4N23Ue1aQcpkJddFVZr2BJ1LckVbGl0LTH3Gj+YfIj4UZ8c9mTG/m7zpoxZ8Eh+ WEn5N+aVtr1okb+otDroWxCqcXJbVD6iZttnxGxOKTymIKilqU5JTdOkFaRcGmvMleDosMjAnyFJ vSKsgZRSofgKw96ahfb/qqT09Bv6RExPnFPE+jt7SXHVzYkynJ89sj5rRH1EdKNDGuIVmWpReXUo lDTCVogDKBQq9PsKQzWhZRGrsdbv8/pDh9X96v5Q3YIad0EjVndzWrhwUxUm8YiSD7KqNL/LrzSV dgWUpkXVwcNefKk0lQcPqopaUDO/qutu2IKH8RQJSK0a03LNxzUqUkD0g6pHmtIOB4gapVVIhawv jygkdR5Xp9DyiGrrvFKHXy7x2ptzhoupwEuDg8OZXqmJ/xkhw1GpMx10UER7nepEPX0RKDTvoCr9 GFUrf6WlsK0FCrQ78I11gCrQ/jHU6yG3qTOtK2hfCTwL3As8AGQCS4DFDhYB8+BzHOhAHw9zP1Ke pjVmL30VYxGwA1gGPKNX0nbYdhozqZb1GGsT+vCjvAv6PUYHbUG5FfYqbisl+1fS/bDnoLxNr7Qs s4VM6AjlK9CnYPytHDNkJsavF/XWRZQnou+vw74RsgKy3Il3rCyfZh85V57j01xGfhqg3wKUAc3A EuSH/SfBbzzqLSjfgrhGQY4GbhVEd6HNbLwVw5C5GL/AmTfJeWMesTkhfhnT9cE5nRcPxMTzOgf0 Am/GxZaIlhGox6viXrl+POcvALPUXpqPvAzzvPQz1scMD9G7mFcPoOM9OtlDVgfinKsfolbUpwCz JepJEe20TruENThE3zV20E+hJ3Uy8A/KUC9QqpFB05G/IPpfDKxEn69KPqzgGKwLkOPFGUpFXzXA Gox93M0T5wb1hVjXINp+ijIetfR9YDVy0Ao8yvFh/DzOOdb9Y6Vy+CW0PYVxihgYc7wE5m6vKz0G /++gL0WOY6+DLQHY1yCnPwd+DRzlGFxInjmQfXWQpnZYH0GOAVKBXmAL8w2oAfZxG4yfhPZJkq/g DHOT+cHc0I9Jri7i2O05yL3Q7OyZb8F/CTAOmGAcoKUOJqAt56eWOcv7xe2bucW8dqXk9FrmvXKe 58mcipPP6FEq5RjkuOCWK3nfod8NLPFdwjHt1vpoM3OW+eZKzgtzjfcj7wlHlsTNNcfZIznwv1Ny HVx0pZuLmHyDdqPPSmMLeDpAxeIkFeMlXKxvgNyK+R2GDvMR+KLQsulBT5SysJYPwndXgmxlmH3K Goz1Y9GJXPTRHpnXPvUu0afoeqd1TifluN6pNsjyNTIRStS2sWTE2z6r/r+B+o7eSatQPq/3WRbm s5X3hDmgTAJ8roT+INAITPRkK62etUrErCAvPvkuAetEgPL1AE0XUZorkimAPGVAX2F8TZ67m9H/ MWWAWrBePzSTya+dw9mIsdR3cD8A3D/kA3E8GsG5RC650uVromTO8LkLqUOOw77rBnqAkw7+DPSD j9+W+xd3A5/P8n7AGQ202Hy1Lsb4eZzaIX/k8jOBpxMT+Gkm8jJR8t3C57u8W7BPEUeLO38+H/mM 4zOSzzm++9z2iTLOfzvOjj/Kc7iXqp19nQVMAvLQxxHnHOnRItYl7NGzxltWjznX6tFOWD3GLusF c631mnHIase8s2J3atQ+y3g/uXcp54nvRfce1TNplXOe7ZZtMb68RyvlOUDGBuy/NVSLfn/P9yrv Q60d+w75RH9PiRfpm6KfNiP227Rf2HqxiIr5TBTrUYYeZzrbb9E2S3uZ+IjWiyyUX4Rso9sNk9Yb v2Efq1fqTts21unVtBO8yxNP08/0LgryWvE81KnWCV577PlUTyPtMQkc7qfdYhBzjmKOx6Rsk3xi 31esQZ6fOYu+rGuYH7cB2EffQz4nHztkLqIyR9slh5EL7tN4W743SH8X7X9CT3iSaLfnHpxPlynV xFkix+qixZ6AzLuQ9/WH2B8D4FgFNelfsv4p+X/AsrRB7KEB7C8GnnZ6Mo3TB6gNe6lJ5seWzbx/ tAFKZo5gfuXyPTEAjj9PjxqdtMmIgnd9uAv6sG4DmMtamoHyFtFpDaHtAvRBPDb0pfJ9wvdUwHqT 94sZpbFmAOOjDccg338YVzuDeLdRE86SeZ4Bes7w8btGUcC9O4HJNmT9SaAB2GRD6ry2VNLRxxNS v5JeUzs0Ffxm+3HxEvZeG83T9lOSWIX3w3l6Ss2jjVoxeHcRd4YGP9RFDk3QLlKR9om8fzbqSTRd tkvBPX6WSkQV/KO0QhykFZqF8lhgO/gIPz1C1fpyvLMeQj8O1GnwGUUlRjPKedYBbifH+MRKYYgN NEX6xUHG6oJjfjYu5u3I7ffAB44X5fh4OdZYnE6M14tPzpP7hZ9s8yeaR2S9B2TYcrhUbaFOYJ96 Eu/wKDUoO6xupZ0KlTNAu4OXaaGUXUApFYoGpQkoAYRooL2QuZDngT6gHTgC/E1MpR+g76OQr/B3 AUP9Fc4uSNifB34JvO/a4sFjXU8fD/GB1R1f16fQTIaagzM9Z6RNtt9L94nHcQ5PsroZ2npKYhi3 UpbpoSy1H/pK+CXU9Qm0U6xDu5vEczMob9AkmUMbgfg5uusBmfIf4L046WOJ/ZXL9/PnjfGzAuv7 JPANmf999BXJobN4k5vWq8oRekg5ZQ3iPDcYdp1SZT730u3uOkHfJPUJ6weuTNPKSEvUozyb4dYT 1/VmdfS7Oh4uD1yYUyjAEO+jPZBYx30QYBjMsZxr67Fxb4Ryug95KhTliKX/2rrhpTyGWod6K+wf 0D2MWL2cshjcloHc+hnIdTdD7ad0hlYGW5lsP4cRl9cg51WLsq/0l+vj8jxxfeBL4rc4j/6CN3M5 pSbKGL+d82IE50ttvsfqfJacSWhzdU9c3RvYKzfq8/8J2DsngGPA7/6n44DnCoGrgJfwpnsL740w 3qrP4RvzdWohutJENHSU6NOHcQ5NhnwZugqUMyE/BMZCtxoSt9HQKZTrYHsb6AX2iTR63HlXjkN9 ge175QWnvwzbn/0G8doZmmb7D20E2lD+AwCWDf2L9vKNbfK44/j9MX6epElsQjAuIdzTBMfEIY3n hhmGlDwOlGrNpriQomQM1aPtpG1asUZSNmhJyhSJhJJ66yat69R4kxYhMZonj0vqLGFxxyqhVgyv UzWYNM0v2ItpVPCibJpE533vbCNkRtN0m6zv8717nvvc3XP3+O535+E/gN9EeQvcAPwo7h2DdyAf hXYi/zvkOyGG9Oegv0Lo5y2EMbfawb8GPSvjkf9wDv3f+j3OH5/U0cevQ/tUzIn+lp8hPrGX5nMJ Lz9rlOZ/KS+dJe7y4jgg5ntH6o6zz8eecUqO+fxnUR9C1x1j+Y8QU2oqjkYsq2JuGT8WXcXb76t4 kqqYsugYT9mPKhk7y/gV/hN1zruE/hwkX0C/9qh+lfaRO9ZWtok8DXmKwrpHtqPMe+jPDXqKuOip /E3ElgkpubepfQzCvvsu3IU1d5Eu5G/CLyLfgL2sorSnldbWu9bYu/e0/2t+uXvkp9hTe4v6WplK 979aVPnz9qIapcr34uVqqb37U+/l99ij79yn/9t8aZ8vaam4tDwOWCq/VH3LzZfHHXfkZ6Q+5rnK l8clpXy57np+97dXiGfW4v9WUtn/brnC/7TbcSB/pfR/LfWh/H98+/9WOiMMkx3QwyXH+rER60gL 9GLx3NWENPbA/GG5v+m3SEg/Q0LIn4Vm5ZoDHyjsffkX6RuIpf+BwJ78axR5zXFRle0vamCp77n8 u5XxuYoPMWaq7wnMxYekHdoG1UIz0DdvzzXOkGj7AsfOK8+5/Gr+Juq6ea9Y8F6Oc9635HkPeRfy rl+RPv5jLJ2UiHyG/yjlrguZaf5KyrUqZEbc/IckCjFi8S+SDMTIAf49MgwxFO+x2z4TmpOJVGVN yI3yJ4gBjUCcJHGlKm9CsvyJ1CqPrP67tmul4o7YwY5CIuX2hqKROv5tQvnT/BnSRAQ/Cl8PfxLe AN/PnyLVqp9myuUOjaC9LhTv4qtJCx5HuAdzIvgOfHf1qtiQXVNoZ8jeGAhFKvl27lVFXLyadMB1 rtkhYcxzEz01+fFUxX2yf8dt9+rQOT7KNVKHUiMotUa4zvFK0g7JN+lLVVSHEpEq3ofX7MOwCPSR kkl1NfkzNipCew/zdcSDZ9/gDWQ1fCdfb68WmXn+sir2fVkL2uu09YekpaprQplIBe/EU4tPYMQn VGuJVPOWEIk0840kCDEM6jBSw0i5+ThS45imcUzNOKZmHL0YR6xJ+BiejKFMOz9M4vwQSUCTSDtQ 5WobIzinEhs2hub4/dyLkXDPY+wo7q5NVdTInnnt2lWqmDdVVRPqOscPkl6IofODqTXe0IF5HlCv sinlrZdA3K6owtCtKcwFQI+cg3N8HV+vRqJBjYAVEchT4uKCUPYOy8rRYb9n78v5ZZeQl/5u0S8W /bcFz2dYNoVWzDR7T3ouso79BZU9wf5EJpFibJ6dJ0EAf2Rp2Qt2hc2RLvhl5J+Cz8Efgv/SfuCC SLN0Coa+v2pXe+TLsvN2a3sxIXzFxJr6YqLWE4r42K/ZW2QdqvgDfAP8LZYhjfBFuBeeYYPkAvws 20y2wd8o+m/Ygvym2ZtslmyBp+wa2QXL1qRN205pr9ukkIu2iwX2OjtN1qLoGbt5Le6eSjVvEK55 1EfZz9mg3SBqI5Xsp7Qfy4VgSXJZOqllP7PDspKEvWCIOZZgCdMbNn1mmznFg75gW3CKGz6jzQgb U0bEzSbICgwe/rDsBK5hYjB8PZAJJdiY7QhbkY/wTvK9GBnBNalSMVzjKkVwdd9+ekOlutgoQo5R pBLsKDQMjUAvEAeuh6Ej0HPQ8+rOIDQEHcLyEQcRBxEHEVdEHEQcRBxEXBFx1foQJIkYiBiIGIiY ImIgYiBiIGKKkP2NgYgpIgoiCiIKIqqIKIgoiCiIqCKiIKIgooowQZggTBCmIkwQJggThKkIE4QJ wlREEEQQRBBEUBFBEEEQQRBBRQRBBEEEFWGAMEAYIAxFGCAMEAYIQxEGCAOEoQg3CDcINwi3Itwg 3CDcINyKcKv5GYIkkQORA5EDkVNEDkQORA5EThE5EDkQOXZohmcjbwPJAskCySokCyQLJAskq5As kCyQbPHVB9VgMHw2R6FhaASSbAZsBmwGbEaxGfV5DUGStUBYICwQliIsEBYIC4SlCAuEBcJSRBJE EkQSRFIRSRBJEEkQSUUk1Yc7BEli+R/lsqeGvUD7dWyubIS2KB8m15QfJZeVP09mlD9HppQfIceU HyZh5YdIs3LUp3yQCJ3aIuyKeLAE9EJPQAegSWgaWoQ0lboE/RnKs81mo8Ol9WqT2rS2qK2Y1nIa czl7nZPOaeeic8W0M+dkRqSeVat1FEsLeUldh3G9DmETwbVLpbpYB9rtwDq7Gb8O1mGu/MC4HqCX AnQxQKcD9KUAjVSwR6hDrXQGCTN0nPabVc2d4jIUbvZ3YmWamL22RtjNnxVpulCwFrMVfg2agaag Y1AYCkFtkA8S6l4A5fvNxmKVC5AfegAyZBPE40GsVrtSN+dYNZ1KvV1NKmQ7/o3g5m1/EJa2/b2w N23/fhGpoLPEL8MgehYzdxo+bYureHymYL+wxTzslC06YPts/4Owvbb/oohU08eJcEi0r+i78d7S d9liD4o9ZosWWKvtb5alA2jIh6cttJ9chfuK1IZCS0222AZrtMVWWVonfjnx1EnaVPdWQNJ5Ch26 Pkf7HdS8T3wgXhbXgP8NA4vP44qRdsAu+dJ0j1kpFtpeQ+GIsCOVsjz2h5miW9LPiinfmHgVdVHf rHhFPCgm2tI6bp9Ev8dUE7Y4ZqTZaXOVGBFBMdh2VRwUj4qviF1inw/3bfFlsSC7SQZoPzs9K6Ko 8PN4C58tHvGlVRd3iu8IU/jFVmNBji/ZUqg33LYgR4CECq1vwvgGfGn5jT8eTtOVZkC7oSW0vVq3 tk1r0hq19VqDVqfX6m69Rq/SK3Vdd+oOnelEr0vnc2YrwWdbh+MczOmQV4dKu5m84oIrYVRn5FFi reI9rGd3N+2xMk+Snv2G9ffdTWla+diXrBVN3dSq7SE9fd3WltaetJbfZYVbeywturd/htKJAdy1 2PE0JX39aZqXt0brrdrteEhGT9bPEUrvHz05MEC8nme7vF21nSu37tzxb9KrPriJ44rv7p0+LVkn S5Z1kg6dOFkGhJHkL0mgRGdLKqTGCa6BSDRKDNThw50Wags6oZB2htYBwtQdSDKN6YzpFBuYTEe2 ArFpoW7oF5n+AcM0hXQ6pTMeSJuYzhQPwxQs9+3JBjL1fz3d7jvt++2+3719+/Z2gapzrvY/uexP Pwr5t1s70vmzQiZfRx9mhUxr/nsd4kvpcWIixlRynJRTkUmPs7uIKfUV2s7uSmYANqnAIJrLAYZq qACYtgWJFAb5pIXCYI5KOB90B5yHCsDpjcin4Hx6o4JjMcWN3BBTyRFRVDBwjLqhYG5Uo6cwEDHQ Nzni8ykoScRpisJpSVSILVUGcrsBUutWIBi+65SB3Fgxlg88gVTPQRofQxoVWwx+gnGXMNYl8xjr EsD4/8+rq8WPC6HcgcupLinVKaW6oHTmj+zZbs9/d4sojhzIUYWYZ3ydW7Zup3JzVz4ndSXzB6Sk OBK6vID6MlWHpOQIupxanx65LHclR0NyKCVtTmYK8Vi6+Qu2Dj22lY4tMFiMDpamtuLNC6ibqTpO bTVTW83UVlyOK7ZSO2jcr0uPaFFLJvFSSRZImR5iuNPpybTYuF3P0oAeX+WxH3BeYBE+jcr8mbxB askboVBVbXNtM1XBOqOqcmg2zansB1Z5nBfw6TkVB81mqQXNuxZRUGu+sb017+nYlKahkpc3Lzxn PfRS1HaU2pGEG/73KgV+TyNRz4JX70JXLpfroVXO34NQa35ZR2u+qR2YaDRgqjOZgbYV820Mo7SN 6HSpsdkJUPqBBO6l5uiTH/vBg7IeTl0aMqge1BB6VOgtOIS6b16EHfx1KHCOI3tHAyHlFLG3sLia nl96C4HGkoTzKZWjDk8dWCiEoSuV1SUpm2vhob+6v7Y/PFg9WDsYVkPr+SFodA/RrXQ0MMSgXn/P vCPgsTcDzgZa1N7JUZegGB6kD35/xt+DFX/9r7PxvNMfO7ZnbtQeZfje+QkptfegErik9OfmO+Xm uijKnNJFMQipF1KwCn7wNaVBLe8TXFRrxkhctiAVW2SQXsMWMeK1alWRML/EPqTDeWxHdj93PzYT e56bjrXNxFAcnrlHUIWCHrPHXA0VJHr0SGQmHskq9BCJ7AS1sGn2E9WQ6joczVbAfkPkb5eZ9QGH mQ+E3eHgT7xD5Wf4U+IZ79AKg45VSzxbJVUzywSfJxI8Lk0xtx1lLpdDEIw8b5ckMRAIRiJGY11A 4pnlEZeDYX2igBk41zLqSEASBZeDN+oal2624MbV6jJchhwrfQOcLWAjtjF8UDbqlw+YODfXzw1y LDeGF8mmugGT3q0P6hk9H237jt0P75dtm5nJTnFQnuduo3i8bSo+Za6KVkSj2FwBsiqq/OvjtDEN FCpH1CSxPl2YlLAEW2BBV97gAPkBSIaDik5RNhMKoizOVmt8NWq1JNb4Ghuawj5a19fZKq1qjaUp XKVWa2w2HG5qbPBJi9WV1ipGDbWtvq4prBo6u78n84fDxbuHu08Pt679028vfbzz5B+9jqIvIgbe mvGtXd+eSqyVl27u3Pu1ltfWFG4+071u7bt7B47+vSNzcs33xz98MzPYVbwnb1vZt3/Z8h2MYWWz 3LQ2sbzhy8XXQ4fXfLWnIUb35u5iO9kOM8ahL8nlS0zDDNHqMNJxqEJ7ES9GOthYF0MUHZf1unuG AZENsoQdI28XzKe6aYxkp2amp7gp8BsX4yA6cBZLPtLIwdvVE1Jpraiyka5f/3hw68aDE4e2PdMo Fdvv4H//A3swuXWxeK344t2fFU8PvEqZJICJrDB5TrbXkBr9NrJN/w4ZJqfLNToth+Cu4CgnBDGq cHpfe081YKBsKnYmKJupmckvkrE8yzQ2EKbeVlFp1RAm1ZFc6Xr10K/eGW5pfa/YPnrpwd9yd/EZ HPhzcdGDa/8qThcfUia54jg+hXlUhuLndNoytV5Dg8epPoEjZXr9t7BP4zXBF5SIgrAGeMO2PXOB NDkDttumpmewOYrM0WgoaPHAVKs1NU1NYelNzC/LbQpvWEPewPyV147uEntdWzZQe824j+wgg7B+ 6mRPEMuY4DCsJo4RmSDDMkkVp9hiEM+e+jq1NZlt425nUWAqCyZgPTaTJbgP88U7dLRjUL0H7Bnk lStJBOmJ7ym27GO2M5RrKFgP/Y9hfq737MzsHbIKZoFBEVmAyX+OMFZCGEgjkCvwZ8ShYj6DUY4p PKbbYNHcb4O3jsVjfaoV/v3cb0JBDa7HDO6+XvwRr/r8P1bK6afwOj7VBITTRlnXTfaRIzAkCyeQ wisqrBojL3+g1akwMujQL+BbhiBMsrJRhVg3K7J5lmV5/QU8jAdRiXqsjeYmxeh0dipKV5rHY1Zr Gpu84XrGV7zz7rVvYBKcZKX+1Kz3yg8og3qEWAMwEHBcfuWc/bxj3PkR+3v7VftV/qpDm3AmXAlh Iz/AvmU/yw65tGqHiJaow441bMKe4BMOrdfu5b0OxuZjN7Jv2E84T7hOCGddZwVtBRI4QRRCwh7h oNAvfCxoBbqD2KyVDQLhDCaBTh6h3pfBhXSTqbA1oDFyskCwwUTPC5LbEDAQgwzthiGLSncDcsIL QNnhNt3g9hJ+0fUPS86ept7eHYu10Rif8e+ehLTsz+6OmSsgV9X7s3T3QcLsxKg5SjmMmhQhl3NR VstFVVozSHO0tGFkSklMLtM5eSdxWjBrQQgGgpvmLpxtbU9fRM7ZW8gFRZi9FYlEMnh3NpvFZk9T RbhpPmtpqpu8cylNzao1rOFRDTf4+SX/yq5Meru2+CmPtb+7+WB1W33x/mobVhUfHse6v4zEX9zw ctfOfa5PP/rnz7cWtjRPr/PRWWqbvcM6YZaWoptyXV/llUqyz3XERYaYM6ph63nmguq89RP7X3mt zYqP2o5WEQ98NbO4ymLzuI2cQT+GvbLhBSOWjT80EqMRwzZAZJPbErAQC3WvZcipwuDyc/+lumyA ojjPOP6+737d7u3u7e0dd9wdsnt8niCBCAhMrrJpTIKhiAbHDxj8it+xqdCq1RikEwmxtsWZJlpn MoWOrabYKaYqImr9qNGajNVRpyWmaa2jMclIwrSGNJFb+rx7wNS5uX3vjrtd9v/+nv/zfzTgCvgD cabCx+z+XOWQfAb2QA5oA9uMDqPT6DFOG5xxSxiozcJZ4fzAQHATHkChvPG9GExuBqyNg96Kwsax DaEH+rZpEFMxK8YkpaqCqCAfavRlB6jDO+oJZYEJGaeT4qlB0BFaQoofZWZk1WBNaZ4zf1Pz89Oq jeYfLphZtdJtJyLf/dPmK6+sut6yx/742kX7G9wWXf3S9vVrt6bcZdbMf27B8iVT2jobtq97/ez3 IyfbztpDd6GeQFx2BugqIQX906qQTaVClENyvlwnvyjflvlBBfNsgM1mY0qV0qAcUI4pFxQRw5Qn 84rASW5FQLKsKH349xb0YT8DtkRkVmEUwkpIsJQzylV4cwLHkAsix5FexLLwA9SHFxzhOiQs0Y3Q NaFTOC0wQthTSbYRQkJqP/4OrnKq+k4TNJMaqG1a2JUQOxKNcSoh9GHkLNReWPAXj8czjm6B/C25 Rr4sfyRzKAktyJsP2aQUF3uLUzK92ItJS+JtsvV+b689ZPfg3GFm38iir+wPSDr+0nYDcQ1AXCm3 H3xBsya7VFMu05/WZ4b2Kr9U9+g3VVH3+vSoN1Nv08GOsCKBCrrX20e6rICq+FVV0SW/ialpM7Px LnDuR/A65tAVUaBJ1VuKIRVKRKIgSvv9FD63P1Bi+ov8lp/x9+GDlt/rNbRCjRRqlVqtxmj0qxq9 ls/jUVmPBjheDWIriINhQ+3DUUtXNuGTVxG2UCfqoQ0i/fpx/OyYTVI47wCkzgtql5rjFvBB/gSr jU3epLQqSIsneHVYfQTUXB/oKkB4QUAoD3Q24FR5Y82CLZuXbl5yZxe5l/h8yqJlJzC7psN+fxTh zZMWf69jV3v7i1Hy0P7660J76IOjPzt3E1icD4rnAYtBlIlOWU+sdW9wtbv2hA5wB1y/Vbt9x9Ve 7ynfGe8Vn5LCTfPO0LYEjpJr2lW/cAJdgZ+zWEjVtYgJpkUlTAeJIvs9ihEtjJIoFSy6v1LElnhV HBUZsQ/XHu7BGFOxMgy2ELbFcvYkhYNy3pQ+UCtjOZydOqCHsiZKe6ywkyb7oBEEHMxvqoQnBRKN 1TKghrkcp3RBFd0pWeTVEHgh9k/oxrMee0ia+9TCl7U1bx16aP/3yj/s2zjv8wMfJn7VMmfW6vVz 56xn69Lnzu5KbLUf3PiXPYQX4h3453j5iZFPd7y5ZWdH2za46UtgjrfZHCfDP2ZFmHLM8+WsJPYw hPA52OSKOML1uC4fdDIZDevxYVQJSTaZD8CyvZdoh8chRqHryH+S/Z6gbsg6N50ze1C1JSmypLrp 6d008qRJb3HlHsnbw6jNDJeD3FnJANij0SslMw9cbFAbdnIPXM9RyEk+9LL/l37OJi8/noCS/4Yt j+Wg5XX0f6GTymmuH+5Rwk8eR8LogCWWVZTwMTgIdLPFWGkJb8EB3g1Ys6O58Dc4TEZ5QFRMKpTL URlXKa9Fa8kKZiW32rVK+oTxPMdjGmoZSRRZQcTYRAKEEoEXWdbkeD/H8S7JCk+aLjklGZ5UImUT huFZgOekpfIC4VgWI5ccDIahby+13AacA0q+FVJOH8myREPERWKrSMR+koVY+IZoQqoJuRe9MB61 QsAQFGRqYtbTK2bAlBGHDaqM1wyCWoXQw/Od8NT+yvn2x1LpImjxePv580mfOyKWiAoMFdTgqg+5 66oPpc+ph0bPjNp/cLFS/6gNSo28w7Pl5WM9Otnho1EGHjjqYxjutP3H1kTvZvsCeQJX5L13AdfY h7n+kR8TM3GL9t2lo/e4RZD6wuiv1qzXxB3+HYFO9Av+oniDueH+khGzxZgcUyb7Jwc2cBvE1ziX 4BOCQV8wOJnkMdmcEOP2cnvES8y7bq4S14ILPq8hfAsNwabSxONNLXFWCe6jD9dbwdQC1qVaql6i Vi/24FoP9lgpqSWQhmJWhl4gMZ4v1HnoC+ScKlyUhtNScrsE7BEMoQj6Rx/5yeFIS92Ey83SoEbH CvYBWNydfLrSF43JKQxCC8ezmSatz6gZDASThevVaJ2yldj4tn35vv13+3W8BZdg5e3lU+0Pw7/Z uO/9P3dt7CaRhqFPcQeuxy/hNzsXHXqmeftn9jf2Z/d3U2bfAGaXArMaROxtVnEMMHw2uIJdIXN5 wYpgVWBhYHWAqwhOi7RH9nK73ZzhzcaI+PRsj+YK5fYImIJ9WHSX0LuyfK1RbEaLwMm8uolMrUgj 4P87D5uP141H3wTEv8am4fwmJ3Yn4vRJ77IJpp0oBAhn1OHpIzMKqXBq2XQCTpSTm5P5Bpl0bMmP +pYUlK2seXXZrxPXceyjrWVVi+PxdXXTj3L9aTnn7Ht/Ofpq1wvVeQZ7bqRU1ee9293du1JXKSPL gJFTwIiJBqxnytOr0+cJG10b5TbXdrktuD0i8kE+ogf1SMwbS42FY+muKncDO1esd69lX2a3pP4g 3Kv2aheVC9rftHuayqTxJmXCMsIVBpw9m2AcSCvgRZ1ioVfX+rCPMuGjTOQFCjwMDCNmaDF8nKvP I4ZpMiRsZhRlkIxQbpeEPZIhFUmMRNmItnQ+wgYVTXsw2ORUW5IRQITGtniiKT/u9DsHE1wKYwQL zQ0kg4hbbLJjpKRoOpBSVspUkpZGu/Pox3b3784c/+k1CBjFU+ybxsHWc3c/Odl44ikS+SrRV7/j LF51/S5evnjm3ffK1r0y/G/7of1wZkk/3CdAw+UBL260z8oWWU5iiChls3oPgxkG8RxHMBFcLjdy cS6Tv0L5IDutDEuZrSxRmPVKq0JMpUjpgsTFKsRtYjpZnKGTBWAiP77hUUyah52X44YDB5AgOScw MCBMqmDonBB2lnd8dDRYCDgxnEa/Gk8Oh+OP3ThGZuCYPZA4yfUnTpP/kV0usFFcVxiee+dx587s zs6uZ3fttRfPemyva4Mxy/IwBnlSqMMjPBJDwUkcWUTgRwt4EcE2EcaQYuwKtSRqgFAoVpo0CqQY cHjYhRTSCCmt2lCFQGhEZRIaUFK3qEUpATzuuWObR7vS3Ls7Gs3ec85/zvnOY3cq8ObBTWDTdpDH u2ATz63p5USQcyKZFJmsrTx3t8uNcJITbXGR2Cb2i2K2WCM2ijdFoU2E/MY8J2P+MuK4w1w/x59h VYMZdR5+CdxqYcJoMNeOmFI+nbXf1Fo4LTvfdlQg9t2pgHNYQ9f5P8I5AtzTdm69/JYXL6Yrab23 Xq/3b9A7daLMVjf7xkEPgMQNmAgz1wYaDVRiIEP9ZzZwakba4IgL5w/M11Opb0b/c/DWtWGRoJgf 8gsIKD+eFwq7jR7/CsXNos97L3+FUFg0S5Y//xQU15rjy9t+/u+vzdbkwtRRON0+YPA3xUOcyM2w I4sIs1yA2snJghghmB+OJHbjKE3ofRDHBbrDTjB/cMRwNybBfRCNfvHQ3Tn/Ybn5MsdJGWC5B6fb qsrny/kqEDqCsLbZNGtaUjGnlSXpyaH+npHdfiOrGO7CIlFZ+YL+XREEqihpOEvQabZi4bGCSccr tbhOWEEblCbcLLxBDyjHaJ/yDb2jhPYLO+h+5Rz9ULmEPxUu0svKdXxD+Bv9SvE20WblJbxdeIlu V3ZgskxdgRuEWlqnrMctApmF5wmz6DxlqbyULlNIujJeS+JpQpKWKeUaYUOFRKkSxBEhTMkI6GeD oxQqeghJSJonwXG8zmN5kexNqmxxrdRUb1K2tXhSZQvc2mvr7Isq8wiYERMFJhPIgHJI93DpcIes RuMH9AsD7AawZJk9Dv7FFGRKE8MjDlYVJcFj+IrhNbxHwNijAEUQOVtDwN/eHiKJQh+e6or+meph sYcrFyfFBLHJJhnJpzdBFE6rpuoBsU21A6ByGx7kbHiIS2QDfLLXeFne6rcAM4v06f/Qp0cy9MHU YGp6JB2QvQhuwHjE+N1NYjjto7QwQgZplZDV8lD/EdVkGFDtftwsKeKKUkw2CMVcKkP+l9FvkIII OuUMOFecL5y/gl7T+Rt3KoQtd1vZBZraDZXKAk1R9Cdbo7wkZ/BhWQhAroJ3uZ6AWs6qBjOb7XYh WMQniGwQIvMyxoSn4C/wFS8wiwVmsZCQPgIyYmmXYauL1BqVb1TbVNylnlGxqZao4Gc68lK221pl ZZImHqlxykM1DsAJqtxomYNfbnVgDFrKwbWtmBkPHhrWEat5/TYFVcjmsEbOnKBMNS5esdo3oWSm +1TbcXWS3KZOcg2bESlOypWwiHyIT/A2L1TwW+Udcpd8VL7GSx/wH8l/kXmTHy8n+TJ5ofwKv1/u 4rvlw/xvZXUYWydOSmJ7oout/bZ3fCKJTbYQYxLc2WXTWHESL4bFfbpijAm/YJExIemYD5OxOE7K 8ESyANvkWfx9Qg2cSebj75E95CD5A76Mb+Dr5FusxnEBmUuaSQd5B0usQq4tGv1wo1Ko4lwlsBqC /LuRiZehNOfS4BEQwDj+4zsV/Kl7sxjXVEG3vw7d3sdlcq/bS3aJu+Tdnt2aICOiyT6SHk9vpk0B 0uRvDrYLnXKnp13bGug0OoId4Y709oiHBEAJkWAgYkTSgxGSNs5LM8YRPhTvVhCn6Io53KttsyRq R2uijdG2aFdUMqM3oziqx7s45AOgKnFjvr0nq/V39xu6Sz/VLv248w0IPcVVpyWnwJQBHXsY8Thk BO6PYFUzE7+u7exBs9BWp9U57fQ6rWjCl0eOfHHlxIl+fKF/d+PRomnOamePs89ZA6BX960zNDR0 7/Zd5odXoWrfhixgfmiy8ySx1+hN5x8XUa14UcQBf55X07hMHfAF+zg59H9EF8qOlozYJ0Z138NV PutRqLvPdIzo3LlglOsgYACtIXeYkiwrA4NpzDZgulfRZ0h7qvXA8l0LGj48+3r3+pnPzZ7UJfaF Yle6t52s9wcHLwnvOzXFyx9bVOdV3LiuksZAXINcAUD3xvbottgebo+xN7Q3LDXrG8NNZrvSrnXo HUZnpixFaV4k04gasYy8H4Q3cPI6DlWROpBYS6RlTIv5Y9Lp74y0m6+RPepO/9vkeOhc6GLIPyVz mb+e1CsbuBYi8egJ7lnuh5yQG8qJx3NDhOMlnJ8FQBc/iZ84lr8wZxzFzGM+fxKfRJW2j79AaX5+ dkYcz+suRIERbwaG1VJoF9YUNha2FXYVSmbhzUJcmB3v8iCfJ9tT4uE9TC3f+V+1gF+vDQLtceW3 Bor0QWd4Tg2XcqxQgI9TQH5wVUM/J+DUuDQ6KXCs1edNHtFRkI0LU/LjU0LihFVtq2ba2okd3c4h ZzNMgnNQBWqdVOD0lZb2Hzt29eo7dunT1ZWv9C0o/rNhkRfL0U9QHapFP3VSzmvv7Vhtz3zvRefu vUEQWrAs9naCKY2RIZAVRCbG3ba3lPrm+JaSBrXBc4C+pXVZx7VPqSLJkhKWQ8pkrUKr8BFZp35D M3yGPlmb7Hvc94LWon+sqM20OWN9tIN2ZLRHJRoyqMenVWovaD/Sfqb9UhM10+sxvF6PzxP0hkN5 abqBaowuAxsGZ8aYkEHSQU6GBnfKjnNe3Yu9FzLjXdJh6Yx0XhKkbY0WMq0SC1ux4MN6zpnw/AM9 u1k6cKt6YJQ9XU1Xp2B36zPU5mpto/4B8rthcNkKYgBST7hKJ6FQOC3GF2PL8vsf6N3aidd8/Unb +2drNjb0OL+4uHbxcyunf/ZJw/SFs3PfvS72Lfz9ljcvZU1tP+h8jsoPVsUG9/ILcpd9d+4zHpFx 0tyhL4V/gfrHovP2jF7/yejxgnNjBRhmgzDMBtOLVogrCtZJzd51BZc9Fy1PlbJEW5JTZdV5VgZq Y/UFtWObou3RnTFPwGIsNSY7yXZ7RUYk+WTOk9bZnLOWkMpJWZtzNltXc65aUpFS6M3NybVKvUlr njLP+1+6yzU2iuuK4/fO3JnZedmzu97H7Hhhd722MWvsxR6/sBNPxdMxBqMEw0I3cUVsQqsIG/Uh qvBIyyMhpOHhQoqJTBpCgqgQmFBswAqiKoR8ASEECcRFaQkOSA5RRHkUdtwzM5uGfOjuzD1zZ9e+ s+ece87/Ny02teDnckfBSvm3sdflTbF9wgfyhzEvL/AyG2MLVEGV/TEuViDIBAfagoYa0ZcH8fJg X5AKHqc6kAb9QQJg0rA2KY9Gs7DVMJpCET2JDdyK2/EWvAcfwqewC39DjFCdQjCZNJEP3hkL4IDh DeiBZq64KFQGe0Y5BGzZjO+4nQCqky5mq1HzswsPI6M21WJFb45yD2xiBYQRUOluOnHDsSsSN2AD OU3FxokY+EMLPw3+uJC1/+r31sXAPWBgdq7fY80uGLmeOjniqRPsM9e697WRI8E9uU4IWqe3LvHk K5UVgb4pwhS5KlYFfmySp8ZmFOwT9scElE5li6S30O93Sn6x/a7Sq38AOI715QX8xM4sArv7GRwJ 9W18a+tTs/XBb9o3rrmzH+fhAGd+5l216tWm8tJafOj8rzaPoY/N2+ZlPJy/9bWV8/QmzVNW37by YNffOr/7VO5eUhWr0wvLO18eemP1F7/A2MqvUugWg7CHObTCKCjnkyTJtPJd/Fp+C8+xmKEKCU1x yMUHAiGyxlJCeJIhsFwEJ9EaaxfB1E3ntFJd1FpqC0Uo1ZX5SzYq8xYepiAqDS2wvzINMEzvmHYj 2y0abDCAll4V9YHAu262kDfNOeT0gwePnoan2g69PA5PpaJNRi3n4nhOgSLCz3TN5LkFfJuyQ9np ftvX6/9AOea/4vuKvceKsiQBJHGFXl4SI/J5S+7aGKq1au0a3aWt1aiIltT2aKc0omHgtYiaVE+p tGoVgtD/xdBRuxjY+OYFjgrYIauuAjWi5FCAVFbctuMJovetV1avDeEJyVc/O3jx89V5YZAnN4dq F728dMdBOvHYNB9c3ZH6We/81fcsr3MIcW9Y9IPHDE+CTrARsVIkiMWiEZqis4AHR8DST9h+tQr0 5YjBh8K6oMIgfT9D1oyxdnXKH9ZJBAYOgISVQsjHl6BCnrsljEj3+YfCfYk5y5wTzkpX0SXgn8vS bfQVzx8g7zEHhPelE+QIc0I4Kn1C+DISY8qFiNRLtjO9wh8ll5PRH7lwjsxa3S0n6khoHi4AX6LW I+8+4pDNbsNncc6L1kxkaYQ5gBneZhnw5Q8sYxdV7aPTImEiA2PJIyygzMBYhfFTGkkRRFNUBKM8 SFKBZZgKUcgTRYFnOS7i4vNcLp6IkpSFHliElhCFiUQzgsjxLtbFcQxDQMxjB3+gNUD+lgPdDOCk IUTYIXHIKLdoE6ZSBJIZ2FaVn892g5DakkmHgplMSM2kg3MgbW/+j2WU7Nt+ejjc9ojcFuK0PMk4 PzaOVrcRpzurb62hOx3FUS/wjRcsxrjD/DMuH8YS1EX8JZ5o7jbPmF+Yw5BLbvrOY0QQ8M6sRwOQ QfBinoUMEnG98a6baMI8skggB5h93AF+r3gNX+LY9eLbuIfexezkdvE94od4L82HsI+bgIu4FG7j 1tObmE08r+N6jlKFCCkXppHZwmJhHdksbCV9wh5yifxDkGtIrbCd9ApnyTnhAuEEimdFjnaxIqFd DILIMogH1IxQoPFhwopiBDF58HQQNggisKmIoGqcPMYaXp/ONvNwfcQVkunj+CSixk4dhbtUs2i1 bjFb2CUrEKoViaBVykfh8p5zhcqd1gzDj4kyF15Okh6FOl2sE6vbOfbTY7xbF6ph+B6Z7Orb3d2N VkzGltudA//bnIIX4SIcwQvMWpj1mifM41SGGjJL8JVMbSYHPzLtnrzNXEKts2tmq1HBJhmDoZga RDeSuYQiNVhBHppiKY4wCkjru0wvQlaGXcA0bnctfSWYUKC4KKOjaSuP4ECNjRm4AefkpNcd9RW4 K33b8HcjI+YSbsHwf5YMW2sWwZpBe81pxsRGZq69ZJIY9ooepHAsS42HjL6LGdKLrsPPaeff+7Wz Vsb+585KsOpoGjIRKm+lu6CKCpo5I6BCHuwfZvqugfObxr4mZeRpVIAqcLfxEhdy5TNhf+gZbVZ+ U+E15bqbr1ZnqAuKOtWlRRuKtqnbQ/tCg9rZ0CeaxLKyz8+q/mK2xJdSf0NtoPaxR9kzrPSx/rlC heMVk92lctxIlOlxIzYBBjWsL48/jlPxGWGrmCRzcvWnwhiFlfCh8MMwCYdLcSUy4K5FVhSaHzXy 3Y1RQ1NgCIb06AD1y6OEk2Sh1KpJ8Jlt4WPbwjdK4RuGkSeOm1zkKuEnyKnxUp9EjYeqK2HJyPHr UmiujvV28O8fkuCyypLoCwF8PYDnBl4ILA/QAbVy2U+yynwFJGD3aHqOkr6XcGY37P4AKQWFLQPG 0hq2Ykw4mdhfHsbdqVFnMojiY6eOaWH9ufiLcSqdSKXhL6CG0DmK0wy701ZaFoMEsOQknecPRG1l z0KTsZRBTXWNI+qxxVS+PEvZw80q3DGWuHj+5EAzrRWat0WFo2ftTe8dauvd9vfZrcubn8PPV9+O 1yycNnt6pSJS/yzb1ZN6/Zg5sHn97Pwa1TVjRv9ri95szi+M5M+bXm9e9FQEixvq2yqKauId4PKN kA09Nkvmo3cGkWfsgTFZrKvRZmqUp41tE9r8bcFU/n2OrSL1cr23SptOmuVm73Sth/sTL0g5UFZR CILQz3B5Viy8opiLhEDUFeoah8cpJRRdlDuASwwJd6G11tYPNzr+7m5oGc003JwDjOkQ5qjViW3y wempCw2xk+0UOv2dwWX5TDqF0gmQ4W5wnQcoCBxW7PNCq3bEFbhsI1Z/13/aNDODiw8bHr1pZfr3 65Z2bGCOZ77tMUfMh+a35tXFqd3UxPfndvUd+Ou771g7bj789kbYCSr60pi3MDflSflfyl3mWeZf FVyp7qR2SmeUM8EryuXgLfaW65b3lu+/ZFd9bBPnGb/3vu/su7PPvvOdkzhxk/jiuJkJdoCAwRdI UwoDwqAMA2lCtwJZN0ioWlg3ICotH2rHh7pWQNMRunbQjgkWlpDAGAh1KtI0lbVaNVViVBsdqmgE 2tKMldjZ8945MGl/XN77eJ33fZ/n9/ye3+8uG5gRmKEtUBfoLUbO2+nlZqrT9ekGtYXZouxmdil7 zRPqcX1YHdQF2UFoSRqPA2owLack/MaMpKWis5TOIZoQIWaq30PYMJWwYR6ROgA4PQdtkYZPFSEO 4bcoSiQlfCNFl4DwCZdw0aAZXumGchGWxG2LRhJgJUETj7bdAMTmRxMJGF0uhJg6mtNF1bTpDAYd 9pMARbq+cEv+zpLObTuebl2noWBi9I9fFG4hfeTy5+SXU5ctP/jehd7Vm5K/uwzESSMOVR/HznA5 xG5tETcH7Do1x+bEnOqi5RBA464gdEV6IuRMKu2dqaXNBVSzd4HWbB4WhKADFw9GjS17OFmBVIih uCzFEEaKohDh/Rg7Ud4sW5m5f8LuMRcxjsrAaCn6M8CK1Ml2ip2qixa2LReNNhQPqKamhvxR9L9Q odcW7jX9etXZwr3C5f4XkJlXk83Pr93z4vrv7u5dnUMW+BQZmT8lfeNd731z4ztvnz12FM7bBOe1 ACtBohT9fJjwQZ20eBoPC0ek130nmOPieeG8NBTm+SCaTz7KtohLIiekQXYw/IF4xfuJ+BfvXe7f klSqlGo2MIRmy/60ol3UPtQozUFDJOuMcghG8ie2V5HVVrlDJmVDxX5q0CxJo5RK4DllFWlnfCju jok6dzRKndFWgE77sH7wwbbbVRXCfIb2qAYOd5WHI6IoqbkgSkbaI5siRyN0RInytqSkIeBFNkzg iLdhUI1CcY6AnbKDhl0TzBp2RIE/QMEG5mqn32bzjt1SYRMwQ8WbgUlqkarx2D85dbQojpwfEPBB bcSb7g/h4fQZQZzjPDZFs458yt3ADNrmLC/bECUZLyrj5WUbguX2+2QGyBlMH0i2lKPjgS0QhngF SHeMcYKKOqo+4PquEPk1MqZ9capw66VOFPx4BKls3qZeWDt3lUVtXbEmk0HoW8kjxwYOXgMsJAof FC5se3k++v7zO+bNewbzhgEF8A/mY0Inhuyp02hUS1f4Kvw5usdgePqiQWq6nwyqul8OKIRPDiDC RwYFXvGgds+Eh/TgRIgs8is6mtCRjh8jPvi/d+Bfs4GgKKSy/BK+laf4Gl/S3+4n/UOItiU5ECOD 7USffkkndYwJwZvWzdDWYbKTcHMGlDoOUmC8DayYeYMwoEzaujN5uEB+dDdOxRKq2IcCKceLTg1x DitoKdAkUX+l0dt4+Nmtz8TmzZnd8NFHhZu9dKx114vLqt73NS5deG38LPWYU/uFpXSHoyCSaLH9 5Jay3WWk6pW66ndJPfV0BaokK6kpKEWmKBvNI+dRq5VcMFe9Ir4CUvW0ctd/N6DOklL6rJrUwwul Zn1hTfPDd7z5kLgPerbHK3lqvZIl6yGtTvKGdNqowhUw4FSAA3TZ74DkjMfrjjW1bgFUVrtjfdot BEErcRp/O4MJp1yx8CCLdTjgHo0zTLY27omFDUw6gmmGw/vrUT1Q0JAtEqmqqGpOuc8+o0X+8Y34 8jcmm1V+dLMr9Cf7P+Fszlm8H5LjwBdhO0RgK4EvjvdNtrhuh7eUzmBn9fr4ukRnksVdLsToocm+ 3wAUVgRwqAGcKbjRChAKgeADLvshauLLalZsnF4dkLZf+mTbkwhd/H0P4uZ0nd9f+Offxnd2rN+3 Z8NTO1usGVokqtdXPvHGyYH9f0YeFP7Va+OP/vbc9zLD+2Ry57tvHvvZO31vYuVLEHQOeF0n+u2E gspRI06kby6a6/8r+g8SOEZnqsiV/g1+BiEyEPSrASpIIgUHtYziBFEMaqJOEB4xxgt2RVX6lIAm BCRAmCEl+kNV6QNGn0F2GXcM8raBDCIY0zWHtmBun4buaEgzQ1k38N2bE5lF+QwwEdyNFZ9clwke YQRiGnLkFY/lFaAaYYEQITWActppdyy+Rb/cc2Ft75Kyws2KpbNbNqYKoIbznx+d37Vnf/4gWX98 VUPz3l35L+HQgO1XoRBPwi0FOnzLMCHAzrJ+MWsLrQLZI5wWLglXhdsCUy50CDuEPnjBUCxHMDQF XcwmrhKfwS/bQBOxDMvRIslBz3SwGK1K0yZfPNeDc2Sd8qQYxya4InFzIoA3DderyCzcRCY9iOjC +L0FdOzep5ChvZChduwLiX8NE9TEtTOSP0vhNbaZdWmO8lEB1hLWsafEi+IV4Q/ip6K4jOqgSIkz hBb22/xzLDMoXKdH6HH6K5ZZzC3m17Hb6FfoN+he5gh7hDvCi+W0yiboBFPL1nK1fFJaSC9kRNCk gijwIiMKFEt7GJqFUxIeD8+JlCh66CHyB3aYSfKN5WCJnpJITwz1EKgcNmx6sz8qSmx8btM31m1A Rfkcu+K6vWwGqmQ3v833Pp+ZrCZq4kq/EAVLl8PJbQNW3wyKGqtA185x/r3IRI+hVYXX0EuFPxW+ 2smcGx9DzxV+nH8CXdtbOAlLP8jmsmGCgRjFcS6ZVobsYU4zl5irzG2GKWc6mB1MH7xg4EgUSDIq hojJrBEm/X9ZK+Yp5eaIOfd1C6y1nSDYQ8CKFpo1TMTh122wFnQhr8bq3jSV5tNGurKZfIR/xGiu 9FZQyfgyoSPeEz8af5s9zv3CO8AOeE/Hr8Y/i8tEPBlvhQ8X49fjbNwOl6az8NzjfGS4KM2Fy3Db 6Be5qNM9aM7n91slpaUxSwToKb6Y6rdXNXT40SYA0hDZYivhklhZKbzbVIo6SlEpvPtNdSxmYcXV TxCWI0KELB7tabBvC6ZadhNcGbiqrLRlz5ydTlofWtctSrHKrR6LIqwKa4o1YdGWWfP3zKSJcikx 4XJlZgz6PbSkse42PEyWrs8p3+wIkKPDjRDPzQncllAiENWwPwo5LimkO6Vs3S/lB1W9HVEvX1r3 +pSWt9Y8+1YN1HaZtXTWhm8Ubkay05o21BVu0rGD7y5//PHl7WuaD+X/y3fZwEZxXHF8ZnZ27/br fLe3d3sfxvbt2eezz8YmvrM5Q/EmMcbgEJsPE0x1tUX4LC3BbSluWjUksTCBNDRRjQ0lwaoq4dKo cTBt7H5IbhKVpmnVqASp0KpFlVMICoqRqAkSPvfNnk0hUXo6z+xo91Z+b9783//XQTpfWbi0+fDR LCFNP9xU0dR7bOYO7NmLTO1gz/zopBVweA3vJucOJx2jGHbL3ehszPvQzQu2tHkcLlVQZBmsKsEx P7KlDeFZeMnnSZskxxQXy6+qKncVTsFT0OXuVzg7U58RudzBmHe5kfskzU4SCB3tyF4pXpNe+Y0E CAV/+HzmeGshKXh16+K23jPZQho7cfbhHb3fZrq2FvzrcYhUBdoZsJqv4ivOW95bPnqOXOWJFuSD Iulwb/Bu8HcEBsigMOgcUMbEC+Rv/N/FC8oV/opwVXWfcr5L/ii85fydwu91Pif0OjmPXYWywVKk U4eedoS6wnvCJOyKoPvwJAd5OdM+3/3Ene5t4Nl3BihmrQ9nvEkNwkI+HQCvOFZyT59be2jmxA2c zL7z0UvZW4dw0dHdu/v7d+8+SsznsXAoe+7jG9m3emeHXxkeHjoxPMziPZz9Ch2AeN3AJ8ethYu9 zV6iJbm0mvYmw43cSnWltzF8Oywyxp3nlmnH7bATzs+9POuXZXeea55nPWUuV17M7bZBRf400a6+ vhQ20j35Gaa1exPr94xp7+EU8GGwkyzmOahlqPK/qA9joeZnXx7HJHtnfOORVthi/wvbNj9z4PHt B2Fr27Zk/5GdyU5nLza1z3zIjY/+9OXRUz86CQXZhxBXZ8c+bMUHeCy68Dp+G7+X56q0ja4drj0a lcQ8pVAhR5RZhTQorQpRxsg+q8zhgPrmiCDFkegWq8U9IhVDT2knNdKpPaW9pr2nUc2NYpiz4ydk Px7CBAc9DeM4P2dCu+8p5+lMcHXOhkImoLrTD+RS0Y1aRox1LSOpNZs2vi49sBjyELFr+q4hFTx4 iFX0w7sauzoeW/GFJWuraGxgV2PqPwsfPJ29ATFWQz27IcZy8qY1IXiEqLPU8BjRQW1QHyjtLxcd epNOtF+p465zkQ+in6jTplCmtqtb1X55QDtljiuOB6NWcWNsu7kl1qf16QfMZ4vFuthyoUlepbbm NUUeMh1mcWmsTklFUmYqmip2CBLvESMBtVQxTTPqKDatiq8rPfq3fN8s21t+0NdbftzXX37WPBtV 9+MjxvOBY+U/KR+pEIyI34pEk34rvzBZ6Mf/BMtf44y0lRwpISVWYEGyJFTB1MEA1W2rwNUVuKoC VxREqt3YXYMjaE6Z7RkeyfUlUYW+lOgZYym/A2oLDrX7+pyCJLrZCnT4Osq1UislYCxgP46ZtZGm yHrcYWzBO41pLGGD0FDEJHGvqpB4qJNi2hSX20I41OR1ADPAl9nX+b9Md3gcmbPvMscdGcvN5tjs 5dGCYra+PFpYnFsHQ/baCsPFLhXXmk3moPoD823zfVOImIpKaQjNeXpUw9z9qFHZgOcA0F6bJUk2 Wwug9yFcjS3chmkX3o+nMIewG1ZdmNpPev3wJMbWakRxJ52ihIXgt+DV/hrDgvcaFrzUsFJ1ScNK LIShpAwGeG+eUWh0Gk8Y1GgPWaDeeSHcFpoNkbnguxM3M7leNplgy5uJue7GmJQlI3ezI0dU3fDJ ZGysLZ59xxJlrSEvDgPk4aNfqGlFV9Ls8oyShgxde11O2+iK4fegh94Sv236U9DqSqHogM1Y9+Nz uOrTgYKgFerAA7FqHNJ2P/7VuhLdtzL76he/e+mDS+/Hs7c8nRufqC7Kj+Hfdmy8+fHFGVyVWNse z68q8umelmUbjh369QuHFy17qNAfLfDlb1vVcuClv4zAKSqcvUpe5F+GnvAnq6wIAbpJZXn1rlWu jjxH0IcCnN+HDM2rY0MjOg5wokNyKAGW7jxkDBkjBtcF04TBGYCoZ3yYSeYo8gkOJp0uRRarpCoE lNgJKsEgNh7gYobW7mvQT+qv6VyXvl//vv6ePqXzSHfrRXq1TvVgqGdo3ky0jNSBTiwBnRhH+uzE 4o4c4d7MLHXftAkX5BUUFx6dBBvhqZkj3AwGnNXtnBosaTFIqSeaqkmVeMiTE3JpfumqwObvPPJk WhaffhqHaOxydv0zifzwpfKaNcsX9eM/Xz7/4+xzkJ/vgcqsozHwBycs4zHPds9RnhOFoLCULPW0 kBbPFeKwycdDZT+SfLouiYJXj/l8iAmky2+7BD+ehTP/f1yC6LxrD5x4yomdnw9AuRbzKXeQiaQE O8wUWAM77Npadsk9Wv+bnbtOP4KDhWsbmr9WjoMn2zd/6fRRMpQNXN66pHXvJJ4ApIA4ZfBBmyBO GYctHx8PVSUdbBDY4GQDAMZfR2G2YaYoVJ88TrHAyU6npMhAbETjQmJIMlGlfE5W4GxPWf4FRUkJ 8bKOgnIJKpeTqF7uQ2JOks5KWFXsd8mikaQYiVhAEmpoWArbmGC2MB22NBlJVJZEkRAswLWYVtkv AvnxpKwWqtWqpVLVMEJuqUFqBQgZI9WWTElapg20lXL0l6QaDNp+K09JIVwEEsLhoPI21FaQFVci sPp6BjpVJvjo8q2N/7bXtj9l5lRLY/gX7KOdgIbFzil8IjjiNWrrauu8ACBvZNfj0t/XG4LL/Qcc yUL2Zv718+X+ykpSkMupCDywGHKqkFJrEWRWQgKRHLwYRn5SQD18yKGLBZJHUbQElxCicppLC81c szDIDQqii0XaU7ECUihTylNRlqgSRiHq53UxKPkUJYritJSvFONSqbII1fHLxCa0gqzgmx0rxX2o h+7je8QeaZ/Shw7SPv6geFDqUy6ii/QCf0G8KF1QrqFrdJKfFK9Jk8ptdJtO8584psXb0rRSyY/N nrfEcH2SxmAQx2Yv2SuJrZT5e4itBKbAwXpWHhNvwCxbMMxtsRODY2b3AeJsPvXBhWyxlSyAiDug gkS26YwJmKIyPbR3/uybMv0v++UWG1URxvH/nDPnvnv21i27lcvalrawhZZ26Y1CtxehlN5AsVQs AgJKKEFqSCSB8KIimBhMjGl8UMILiZgIpVggxgclXqIvJpIQ0odGiDEmJg1B0iC76zfnLCDG2Bdj fDiz+5v5Zs7s2ZnvNucoiYu5nvOqaVDbna6R4UvQr2QfJMZ9smJamqGruqYpCufCP3wmOQrMKrvF lmxyCr3VYDYSpPO9sIg0ZGaPJ1jcf+USK3KfVYriPZmiWCZTFM/EXCeAa/6W/DtKsNlZEH1DTo2Q s0ryC7jJ28nhdBJAZP5xK+1vpB3PjPkbacMzlPattE+MTFPal92GelNjluhN3T8EnFNEPBcJ/4qI L3tcltlg9iwLfTXBAue+ZdHsmeytiXHysU7pouD369KZzEbyMh9F7lYnckfTb1ZoX3NpVLvEJtlV bdqv6FoRj6kVaj0a9E42yA6xA5pZxpJaHWvSVrMubdSaUWc0YyEv0xabKd5ktvNe8wuud5tP8UFz B99rvsIOm+/wd7XL5lU+ad4z/TLXNMMs5Am+2KzlLeZqbkR53Gwye8095mk+wb8x73BDo92eD8dE vrh2PjpHtFPpqC+UYtzUuDAiNToMXRaa+GTRklROZkJMBwpLU3KZZBRIkqGolpW/PG0xIabn0GWr DEoBoKiKQs+qumFYUC5Ke8fUWoOatKXv7PN/4J/yy35ZDEu1lhgOT5O66Jk4gWpw7HyYCfZT5N/+ Nd4THLrjSKhysytVR5WlyeT+5NHDV44ujeUlJnwVonId/YKZIJ8WGxyjFg/cY2j//hEmqlrm2JUJ q/rYkezbbODTL1lXdpQdy56+dl0qkeTsJCvNGpnv2drshMgddnY930BWjbDUeLhCYRGx9ZgvkNIL /YGUJipVVEohjUkiuBZQTlZUlfstWw1KiKg8InHyInqdiWylR8mL7GNKqAF/lV2BRLQ6ujUqT1Pi dp61ylKiTYfnzk9FKXR4o5yOxVNHhEFYedqQnJ7EJNELs0ak59alhBbp3afgSv6sTvZk4lSLvJpx Yom0NdITvH2T3vqGqtyAopwaEppzA0qzg81CU24YDa07G6SjvomO+jEexOUcWSs3fU4OsgYqg86D lZL7OW37Qy2RYCROVTjWogg3o45ox6jv3mvQDSLNlkuKy8vFcVhvs2R2hpVkj7UvbB840r++N962 fPuWOAWULd26J10a2r6yODTpf3kQD8rw7Ejz89Arp1zzJ04R0xSZS4lXXRSVzoOPAJ0DBv3GPAFY Vx7FR+O+D/8eu9QlsIWcuPMhobeA8HbiFyDyRp6bQGEDEKsD4quAIht4jNY4j7LFAlp3QiJ+dCmh e5aefMjCgjyHHqX8OFDxOrDoc2DxGFD5GbCEqHoPqCaWNbvUvEj8AKRoHctHgDpaW/0Wl4Y2YAWN N9NaVtL+V9E6W7uA9gTQ8b6Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh8f/A0hgEKUAspBYEaFi1iI7 tQHLBwSCoTAKooVzYnEamzffuVSKsnJgcbJyCaqql9XUppbX1TegaQWwCmm63vHE6jWda7vWdaO3 r3/9hiex8emBTYPPbH529v/+TwrHSaqLkSBJoroMi1CFOqxAKzrQhY3YhM0Ywm68hIO5HM0VcypQ iWVoojntWINuDDhztmEPRnK53I1//uQtMVuRZ52hY1f+XjJCVLP8jkL0cWWVpGJhcW7QSDFq87IE m3bmyjKNP5+XOcmv5WWV5NOtPX39rR3J1pHd24Yr2/YN75h9gJTSgz70OwpMUj1CytuGYVJZG/ZR uwMbsBMv4ADJ2+jq7PP/jRlCI+px3EIzDaikgSDZeSON9ZJVZerT5tkJKNA5SaJ3v8UuKUw/f1D+ aoYWKuTrCRzUxW2+06NcyltD+umF5Vay67lA8296XHdmn7rRPE+0l65eiNy9ey8ThB6FCDHm2uyP AQCSt+RpCmVuZHN0cmVhbQ1lbmRvYmoNNjkgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlw ZSAvQ0lERm9udFR5cGUyIA0vQmFzZUZvbnQgL0FNT09QQytXaW5nZGluZ3MgDS9Gb250RGVzY3Jp cHRvciA2NyAwIFIgDS9DSURTeXN0ZW1JbmZvIDw8IC9SZWdpc3RyeSAoQWRvYmUpL09yZGVyaW5n IChJZGVudGl0eSkvU3VwcGxlbWVudCAwID4+IA0vRFcgMTAwMCANL1cgWyAxOTAgWyA3OTQgXSBd IA0+PiANZW5kb2JqDTEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDM1IDAgUiANL1Jl c291cmNlcyAyIDAgUiANL0NvbnRlbnRzIDMgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBd IA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0yIDAgb2Jq DTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiA0MSAwIFIgPj4gDS9F eHRHU3RhdGUgPDwgL0dTMSA2NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgNDAgMCBSID4+ IA0+PiANZW5kb2JqDTMgMCBvYmoNPDwgL0xlbmd0aCA1NzI1IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJlFfbbuPIEX3XV3ReBuRiRZPNe/KyE3sTYDFezGQ0mAG8eaAt2nJWJhVf 5rKfkQTzvanuqmo1m2xJhAFTzb6wq+rUqVNn50+FuHkSCfzFUSGebrrF2d/fJ+LuaVFlUSlFmdRR LkWSx1FWiWWSqNFju7hdxFGld1V6V5oPlhdlJIfL/7panK1WMCVWt4skjuJKxPCHv8xu+IpYPSxi PafOhekkr8XqZrGEn7B09WVxFdw/hWkdlYG4D2UaVcGWH3GwDJM8KoImlFmUBeswqyIZfA6XZVSb bS1P6kcUVoEI/7n6ZfHzavHvRSLuxSLN6qioRAkfzKM4E8aQXEp6C/aZtx9/EJ3rEDqBHFKW4F7b H++Ug2UmSgmmat/q/3puP5NlqdphzeVSu/bANvziKF4yhTt7Z9V1/bP8Uc+0DZ86Bv+U2uYsjpLC BYEbelhf1JUbdgx2quKuEFBIjPtluKwguG0YQ1AfcXCnB/fhEoIpg+5OnItXCgMQ1AuBuLgNl1kc 9BBu3nSjHmnQPqmVeSCa7jlcJoV10JIR4RhX1MUMy6oiqqop03JjWoam6YtVQbvb6gtkQfNNvYG7 6TumAQ27G3xuaEPf3dOGP3CigSR4Dkt4wRN958Kbchvj9EDDokiiLBNbQoozpMVqqI13xwUcArDY ah9Zv806nSO2MweXYILJCuU6ypAJp0pwPUTAgozyo3Ih5PDqX8rGaWKiz0wSk4eOvLjMTPBSDN4/ EEhZgChKMZolRSBFuO1nabHg8aYVDe2glRsF3Nrs54Wtc9ALYD/hj7W4x5za60kT+km3aDTP8skE oq9MOpksojRrdG5uOaf+oGX6LeQpZucreAu5GgFmi0Cse5OUXc/HiU3/RS3OghaoPM/BzJY+8SNu O2wl4nGeoSUkXeFN3SskFbgbuBnMTfKAErOlAFAQK5OGlMc2J5ntOpUFc0BDS/uO9/S8XNBXejzl AXc8MBcc8UMpo9kBL+A7/iy4Ci5W2twiePNe3QIQ951M3MObEfofRn7Xd21E057aS/yjy69hBVV+ zQTYYCYOVGDKfKzAA36hggkvxnWW58p9xbP2DjhxNEvF1DPLxdQz7dabQhPe6SUnTzzxItxeIlY+ hPC2CD6hXFriy+sGsKpCR7hr14KWt3uY3rXibzp0pQ1eRr9Buad8gmsgeKebAwtT6fLNLWUYp9bj /pKaJ6SuglxJt2gqp9eLNaV28I05bSm1xHUrTJKlEmXH3gfr6ZpK4TI1NU7BdlNShyNcuq+g7jgF zSqpotq/eZ2nojJiqKLmpeKx4xXVws1pJZW/M4tNDqNT/yxJEa0IZFAdZ8dbP48FnOOq9rLYIvyr 2OOvZrfj5gJP4DtYCJh2DyF9lnsm0G6LxOvWlA12gWhZETY7wutPIQAoCz7qpZXx41tMddC6a9EM ixBDv+VaJtatdepBMxGZlpmyOmqmhKsfKCk/wXVKqCSvsaCcK2kAd/otwDLSdIK0zlcdQRV9PcSA 5sEOh1tST5zHrKa4CL3Qj5bLa0KQKflAo7u0lFoedoSEIjg33omuAQ678b3vFW/lWNxLHj1rX7Ap 0O58BwTgbdmI3laFpBgBrWujKdU5t2Ta7cBELtQdfoZv8g0PGUiXBImy5j0DPXdceILnk7l6PJ7S Y2Vt+ArEyG+h+rr0igrNwFpTGF7UmoLew13Me7+kYOZDSTEgWJQNJFF8qoL2j/h5UBdGs6gqfLOk KnzTbhkGe5X7Ty3DeX1aI/RrC0BzGpBmyzDCF5qxgX7br4gqJy15twXxzRm9462eFscxMq+TaIZy yiupvOYkI19jzc0N3IxzhtNi11CW/U7JNmQPl28sy073gc/GSl//dCNLjQ/HSCZapIY3fOFrNpCJ csdtauPeEFoP8058uHjrcIB76wJKy5zQ5LqWunUxjqWV+4AyuKXibnXDb61+PEKXUSp2mlRrOWRI 7LYSJL/MnN1/+CQXpVM+UvOHJJdJKrDhiNSi8+ewpSdlc5OypCkkaf8dSwoWAyyT3rTNetgWWFI5 ht5019LO5tnRaX3XbA/XAcrRWYZN5Gls4eCmDyssm3CHBMQAaIKU0FFDburh13saPyt81JDK8aGa Ac5/4DEBY8uU645p/dYUFjOgZN0a452xWXyg9BASvN0sVjJv5cHtnn7WN0uVxzM7NPtYP5vnxbzU z8pR6iOSpUFygoHXtKOCKe4RiAkCVnduCgLA22mt5m09aBaJRvwXNe8lPj4oOkyDT6EGyv+owX3E 51/oC+IaZJA6hU/bOqf6KDDTzHK6HyBCtTwpo9f9l26YotQkbVp+u+GUFZz1out5kpe3dk641081 wE6/vuKDMYEPxNuXEKKj2jF9iw4fz+oSD/pmUvm4CtY4sQ5167JVr1p8dR2SyXrmq8l4orM0UYUA ugjIHVCpWibSW/r02aOee8YHzYGkVCPx3ONBXpfIOf5IZFRN9kDjcDKbEvu6JNvdvTgrNspn1ybY HM62E9TU9R3PUfQVSrjB1Q2iz8ZE5/fpZsaJkqAuV2uzTLVoIgbeZJHO6kpXSxLnhVWjzRTq+eJA iWbeyY00Lk6o0Bb5HC3S/IVZtczLbiMYXGKkONTrNcerve6RzwDwurapvCUk/MiepTFBgQ/hCBAs Nq27jeHxwiuZN1gJHC7uxHGzPOLludR4RKJH9B3g1v0LukIG3HtIxDUQf8MvoD19pdYD012IhraK c6V8g7c48VH3tQWoYT1UGjaIMPf1Mistps0lTpxl7pgXr4Jz0uP6XiXdqwyGb1mUG/OhRxGbBluP z+EyL7gP4XK470R6aqQ6cYl6/gMq/0909LQQIoAbIUTZZ4SPO6b1pH0GAyktFTQY8DK/BOI8Qwlk JzJqHNJjPglE210aQAXkmUQB5JkcWuvOOgSqfDSHQLOqHhGohyB+VqGUwajEt41h9nXLBWDdkgi6 1eCSugI8Qvj34n7DS4h5NEYKxAhgy1sjsqpQMDjdRAhkNcqBDXQdRqSYsuUpgTx+ASMMU+1ZUDTr tbvUalHQSuMkn1llrqjaMktWB80qIOOkaxYRMHpbG/c72iaGgUC7D/ifujbbTcfLKCDvgYdFqnh2 S8B3h7h4axfawbjI1GOrHWP/5nWeKszwpyqcZipljpbhfRKA1weiMRBckjG5iYJ8uU+fH318YPRo FrPfN2uR39Q00ldsUAR+BhRlgIwjEJKgEGEh0KKLIk/+52cU/4x/xIVSuxobJkMIKx3k744JYk0C 4mEoMbrGyEROjm+UUO+s7uL9AJCUqq2lMIFU+EiaBUlNAJ9EKvrIIDVPEJrsaXeMy7GyDAe53CPT /s2LCKX7CA0ukGVShdFmMK4xlC5enOEBCAZr+/DGo2mXccDQWYwD9x0zjqTA7LjT48D8meniNQZw i/zCoVahJbZiGjUkektbmbNMqekQSKaTxOEQLbpKeVkWjT29eECLFk8K6JFc3PUsE+/peYMqkIdQ MdhYUwY1H6v7Xrei2e22Zu1a2KaaZef0+pUSjOKC5KPPWAkaNZthbFKrFVMlJSUruDbqJhDEojCZ Da1BDgVSK0LsFOC630ExPqIEHBqUaoNgf6NTljJXhVAfwOftcLjlj7MmpW97zE7KKJEzzIbHsIM0 RUCFWqYVBvhLmIJAVI4AKzYhIXCprbqBQNRgPlGSigr+b/FVh49nQKh41+PgfaiR+kxDemzV8U8h 4K6Eihv7OCyGlMKeFZogkDdW00pTSqPylK9cEgNQuTTLj5RLiwf2hfJQ68rf2XcuB5iG90ywjacy /dobTQkOM+XlTjhyrt8x0+waqhSkjlpL2PGantmHj2lsrBd6z+GGjclmTsM2RTjALUSAxtCeJete ezc8R/cESrFcweuHYtQSg+2R7pPJZJYxE4SCMcwMcq6C9f0tcQJ6PCG+L3WVL+HW3IB+Uxkogz/R Mk8fSWjb95E6Ifb13Bniaq7o9gB5xPSOozEv9veSDHzsJQf5RZUcxYa30OP+UXqSoPTMkqD0zA7t Hk1Pc2Raa31sJaD+WVIGvsaq6y/xzJOM456zSNxaxZv7EoPbjvD6OVzmBUS84RpSDlosBEIMqIyS TAJzXwxgpqgiZQ4/UMz4bYflxUy2JGVLLk+mhnHV2kKl2xc2vQbvtPrB9tkVIJoTkZXy/ymvlt3G jSz6K1xSQKzmU6RmEzTceRgIgs50Blmks6BMWhJaJhVbStrfESDfO/dZrCqyZGtjq1jvW/fcc06z 7Ub/6bvH/qywNAsVvJB7Vt27o5Ye9qg4ajZ7hdAen6g0E174AtG/cujt/i/hbl6ql+9WLPQ4GNbS sGQiJHnLL/R+Qarl46JI4t/kUvY3EQP7Z0R0BTJgwVXsibVix03pPXPrcFpAbgyLAlPtYWH8K5wY ybdx5tDYmSdw0vb1PHOfAzLNTFmYS/xG5aiOf4JPAoSfGQhCHEsjVxkEP5oskGimxXJdgY4sl1Va 5Ji+bnDzVKILK6RpQovcoUQQT5WhUKIQSVjd+Om+jTPoMHDz70VRkaxJ8LXxy1YeA6FZIlq5LW8T YegPMLrjl/iKn9fxfsPNvZ5BQ1izq4Mk2sv6cmlUAWUVAC2/UynSWjN6CjxJ62jvS0bp6FxBqb4R 2JypRXE09KItNVjsbCuQ9c+8l/TrhM1ISgyhWbw3gvLt2eJiFRZ2ydN6KImopIxZZrraTrWJPujJ yyyjg8aaAit4MkgHy1ZG5tjAVmllraLHOLoSouPmVx6ot9S9XlRMeXsZQeMCbSJrvv28kAAp1wsx EokHaRN6gamZ21Zr/G3TZqBXaDPQa6mHuW7Pg+SwU3mFB8kzuP6bbOadGMIeirqYxcNeXSLlYh7P e0dbvqJKxI/0DCuQwWxKRRfnrItzsay6jlrXjW7jutGAHcuzKyxoDqWwrn35+yE6KtqavlOgeqYw aiL55bCgAfhZx7XKioSDSjXBRq3oFxvQM/dJM3z8t18pgdVXbzIyJ0sLRRaW2+5oNNWLMEcrKr/7 05SWo2dQ+hHxcx5ScvRRmlm9ZjnLKPGaMvigLnPSTsgbHihC9m8dF7CgChS1oCuM2qsW1ILLxIHa e4hS102u8S4BRGZ5Ja+Ww63p1f7B8CPlE1l29D/D7KL/T9QLzwdUvEKAUs5F3QJxB3qjqMh/2oNf omcd9wxPCDy/MiMeaUYdf4Oip0bBhDN01NM38iN6/nuBHMy7ave9rLqTxWZT3Nz/SrM3B91AnnvV nyVnbsijhfS36JIH/WJh4xOLnqjrXVphQk1Lpa0uBAjlUYOxkYmH83Z3MS4C/6tCEywBouY9bRHU MuRLSGOmoLRJyf+kZc2zNgcjjTYiBgqxOY1ZFeebxfsteI3RxNBWl+LAIL8qDtkaJGuRpDORqARM wjGdzU6oylFAoqpVOVSQK0DZAY0UyuENj73F6IDHoLxnZb6K5Rvhcylk5tdEZP9VrWWvXCYgI7QY lVk2dqAI0I5JUZNVtOBUoKy9osYKJc/D6kUmTwqiU4gnvaxeQr2iXkLd88yVVWvzXAEk34GILiwJ 6eDt7EjDG8bXrmvaTlVvczSloBHM7v6jpDUSYO+Ja0ENP28V/0BKXjbvu65VSHjZLJ+PncBBofIg w1TJq1jP41bsw0E/jOqDTpSQe0nX6eheUhMijtAD1eCaziAeCmZ/+MT1+/Yj/7/hre8Z2mS4MoZm PDxZxQHr4e3oewEWFbs8uP8H+0yOoyoNS0LtVSUBSmrp6AN1ofmySCA/YDaAGpBJNjSOlF85SQUO oRzO6hqrgyQa4K6wczjUyzkc6pUcDnV7Mi0rIAWvUJ5ZjjeZrU3TtP+OCahvj4MhKo9b3hEyOEXr +FdopVCCaNo7Gfmem7f4nAAel+FgkVVQg2ZA5+kV9iKDAuZpaj1us91aXDv0HRMJCpgkFrEZNX0b PEoKFe+Kk6T0cN5hzAlgTz1Yp2Ru6Fskrw5uvMHRyO9aYI60gE6Ql+mi+buHLpjUePY33zBdY376 iQTAM6ZW97zn82gT76DCpOmHsfxptZx5GCmaTR86fbpeLcsr3ietK8R10Ily/otLHPoHYdODelHp OUG+r4JcK4aDEar+I61ydRRYI7ymDDZ+w2+nNVE2eQ77txkX8B9aJsR/rNaIq1f9h1MssC7kHJcI LpwmSRL/LpTyPxZZQhrnRtWW/lfK+RzjiBT4lOd9h80KygY2V/H3EM7MJSaLkqL/svT7XkbfZlVR fl6wy410nENckAdZXVYBqvCc6MEkKOHPuMqub4XU4VfUDrZldZVAo1j+wvk6Ufdwf1oIC80QoHtl 812nWrchXtcYsgpJhe2fOKDRZjj3bfPEwdChY/C+8JeAYtBzJIYHBQCnJ0rwZkH37RdS+aEsV/i2 tfacuoWImd1CChUppUdFhoy756m86uAsJ/90ZMv/dIE9bib7v+NY3hF/ILN8pL83M9G0k7Yd1G+I MzDBkagsJSiRZmfP0TlKVBvRUyfSYTpbPoqCivYaWic1zJ76MpvO69fXpJ10MfdGXs7uoBqOv/XX kvj4D9Oylc+oakDOAP6DqoaLxaRUOCVq0iuqJtCrqibQDeKBalZtCjrUxeQKXQPPvFxP2J8LS4VY aoVeGo67anmNmyA8SVW1JBkPjGQe0pbQ0GCerrbA31niYXqdFV3g7dcpwfsF6cmxkqixWWHXIrky w0jp0fjIRqwmpHrG9UkpOaP6dEN32pLd1O+m/GZYfsOXK5MrboZCsfZ1A14oyfRuEC2+22c4CjqF RzreOj4uCCxQeog39vK/W9RUQTLMdL7I/cBDH3XqQGN6/hrp14a+Pn2RW9NqPX3b0l+stlCXSpn+ hC9fxRdCkdeY2m+PRrZe5qu5h57Ur9v37Jo+MmeqK3S/Kh0u3Sp0RyVLDaA6RKn+/064c6QgLUhR c+HO2QrFgnXnrL545xSsYHHBgnB6iwdR+DWiGZE2bwrkD/mgCFayPaAWWcXK5pHD8ZIdo+yMBMVn DtRXQksef0uD5+ScFCYj5zBixSjnvCYPHuWb30b7U4ucs3/rOJJzbsSdY6igKyEgr+u5sUhalpeo 3ve9IktDDCG7+3s7l/Y7mR8CnUIPgd5pyqXFdSmXlDMpN8odqKKYTLUIiltusK5496sIlU9QO0hn 1kaseHInku8nyB4RMKDh8vUooV4AiEDsJ1kyklHaDGMsyTE53lxX1gXaoRDAqKwIvn6x4IFMgtcg mT4KjeG83VmiV03ZVPu+iK3bXCCLdUaJ/9aL1JQQHq233b0rsNuujc7Prs8EUtvp7+3oLvnUWh0s k9mReJdBc8ivE5QuJaZaDtWSji041i44qukKQ1eSV6BrJryCXSeFR9wKbN2N8tLZaUXgegUmOmcW KlckT+NGWP/jEPIzmRbuSDXYoLYpanpNrqM8hSnUgyu+THmXxfD1nnmElwfqs4JBEmiNQbqQkTJn Bl6/G3Mn+zdGGEalqEu9y/lovCYQNl58JCkWneayiRNAjlK7f5Dh+t/K3a4/kQW4fGlB4TV3nkHi xC8+kCmUaiaVT2ricoZRkRIg9HPoKbN5wM2gSlbRZK+QNlxUCWkxNwc5jecbUDqdfBSELAyxpirr z07FTnO9NPW3FUKcn+uERu40TlW6nJ8rvTyXO8ep/x8A5Fu2twplbmRzdHJlYW0NZW5kb2JqDTQg MCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDM1IDAgUiANL1Jlc291cmNlcyA1IDAgUiAN L0NvbnRlbnRzIDYgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAg MCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag01IDAgb2JqDTw8IA0vUHJvY1NldCBb IC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiA0MSAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dT MSA2NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgNDAgMCBSID4+IA0+PiANZW5kb2JqDTYg MCBvYmoNPDwgL0xlbmd0aCA0NzAzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ lFfbjttGEn3XV/TTgjRWNC/NW/KwcDyLTQIna8MyEsDZB47JkSbWkMrMKM78Rh78vVvdVdVkN9ka CQasaVbfquvUqVMvXz8U4tODiKNKJPr/h0/96uV/3idi+7CqY1EmdZSnIpFxlBRinSRqdN+tblbf bVYvNxswic3NKomjuBIx/MO/9Mo4kmJzt4r1d7XvGmxxlYvNJ/i4+bL6GHwK11WUB0P/ECZ5lAW3 4TqVkQza7l5ZqqB5DNdJAV/YYqb+FuIMEf5v8+Pq35vVH6tE3IpVJaMyFSVcIo9S8IpvnGbaBTTE cjT88kL0K/sBaA/yPQdHKsv3d878TNZRUZkFZRnZbzU+AeycSlGmMNab6v/1nNEiZaZWTmx5Wipf TizDk2cXTTN4BK9VXdtv5UM9Zoj/QtSLuqKoR3FSSIzyRsewDHYc1e5vCqJoBP1FSNgNw54iLYab cA24SyHEaQarGAq74bjd8UCYrwCVUn3QeIjhrlEi01psruAGv+idKrhJGSXBW3VkwdsysvhK/TDf uxNdu+1E2+GSP8N1liJcY9iI7t6FMZ2+eQFn/hags9ML0r6HYc+n8lrzIH0r+JXwsDt9WBE0sD1Z PuMiNxO+Tk5vaE4jrodj3za08gm/gpNtJ/iG5gR7e9g3ganD/TTR9OaLW3Lc2LMe7vuZvOKTzvUM j474vfTJiYzqskiFjPIykSqugMY4LmvDJ4EQ4eZ3xQWUFYDJeTKxrRxhnauEnSbMspHyZdnI6bJs TTRbFJoDVJrATlJ6aHUprWBilvrZdJJsP9Cjqef30SsNGY9dTxPZrpDMgLzueNqXrusN27oOZWVU W3UirU46lEK0l/yRyp+PwetX6kaUqiXlbxnYXwVdXAbNQV9XBkdEYcaFIwu61nvntIiKS4KQ6ND6 gqD/LCkKi9C2YtBvBfyl0kCl/IRpzlo6TTLeZ7KHz2PYJvFV8yWP48J2dwq0Q0OZz4k/NK1wybQR BoPMdORTv1y4iziD++rSLfMI4DCWbjZB8TYmXbynXtIulF9Uus10VboXXE3hQerCyrKRU4hSnIqf W+cUOvefeVCz5uxcNoUTojx72cOhYwrmb4wA+nzsqMRxIR1GSImf8PcDlrBfqSQqLPZDv+bYLHtN yT56fSLZec084T8Gi3fgWpGu8ffABYi9M/WOENWMbKWIy64aI75IpFHI7sxYo2rP/O0OcbYap84A 2WNvHsUd8+QFfWlfhfSiBVIsUmoCPLSvhtH6GcaxiPmsWMV8VtvvmdklFHitSwglr6WLge9UEFMd RIonaYBdczRSsF2Uas12y4Jiu9AoOOCnqYOtPXxUmdcJDM53rErVUzm+vUffOI1f4dDWeHFAOF/0 xkvleaWPPv+CpaY4l81JPin+SbMKWecY6qMP+PMQZgnc/fEepHMB99UfG/y507dMTQVa6zniBucO oX53M+ndgKveh/oVfI4VEPxLXj7XSD2HTh3ZA2E4DKaQGnH+dVbERglkwqKJVKljG2OIYi7WitQm qlgNzdkw0WzmVSg5CMj4AoWSS03MDgqvWaG3x4av4+NWH3liWc2BCeAGujqztqXibExwXzb5ijOR Ru6K5FO1mZjDEokAuySJ45gSrFDK57ohSfgZfwyLZBwrzHxVNmBYY/siVZAFqcvXygDTb1lCkraE oIN1j7FOeDssV2XAk1l96aqYl3YfektXoR1ZtHbCMRjIZaS69VGsgtndt3hfsv6DRsYLeCvqpGAY 0XYmsFRCdLnzFhiM1HKT5DFSeVk2TorsgtVFv8wvQz9cy0X/hAkmcoo1aCca81e3N82PVSC6PrTU NZNCO0zk+DsyKoFFpL/25XSm3/p8r9QZJzqle4QfgnPEthqR6TNiiiHWb/8J9Jy7QHnzt8FeYwCv aL0MWr2bGLzdn9JD5zuUpFFVLfQVKbL0hyuF60Bsux7jVNDVUxQIUPf3e/rwpC6aE7ihpkAywgeu uDlHugg6K/k1/47LvW4lGqHnexYnUVacVYqAbYaxX3NkvAWttusOPEHsuqY1A8+tZV0pwjz71rKq lbzzI8wAR8OAsHHoiGeZp3jW0KM+LyeUI5UcYPba6W2YdvsBaZi3EbS/2damczFNxkzlm0Jm6ks2 WZVaYY9vcaJTUfPL6mRvhsGbVc1/Qdr7K2asug0cylJT1J4o1BnS5P20pk7HsizUz157NvnbzPMU XCZSKrhFrcj3+Ypr6BSejYViIES4+X2sH1T2fQWETp6da/k7s2IJ8VmphvjMLgLgiS9CQFGcRMAk h/O1jYLjwZQQ5tBMiTtqa9jIlgejE/XnG6d/mTS3j8DXC42NK1N9OVBI5fr5fJDrh/XzwR9HznVO Qyw+glKVMvoOWYB+nFszm4jvX6r+IjPsoJsjnyc5FOQLBAGh0ltpHpD+ubpwbTiEqQz2tzdUVNjc 6ZJBa8StPdvMSaXZp6OeAtqCR90Q8U5DbwrWImlImSg4a5mdSQXHUWcbG4TI2Dx5z9invDfTT+f9 NAOY8wLO+ukhWW6dUui0fCbDeI03y6TJsgyDdDWMwkX8hGD6gJLlVxWL0u7BEtI+t3tHUTslw64j uIZqDKG5aRHHf+pwQhB7M3sL1RuNN66sXnogSsDxgU7Altd4k5C0rBEPjWlcsROptAg1GkG7ySKX M1eaLzCV6aNpWyArZqlhOxIR2h8nGlf03Re1dXraccrXixxfyllEwtB3dFdUGNUsfVThKKrlHFEa dTGxZsnDuxCuS9Wf2MmDxY2qt6/20fpZ7o2lf8mKtc9npdrnM3toMEvoST0p9sY0m6YH2DUA+7zA ZqiGnmAw/S0y9ERN54vpYycYij63y9Xh27yAKzRcPHYm3T9Z210/8Rrr5KHtCPfleBZfmuuRSVxq iJAC9uZ4K7Fm4k7M6izTDddrAE7wl76Qqvff6motRnUvWpOjDUkGdUiSj0csF3SWEFoC8EzzZFY+ Qj/Rd1vTUvBOjd27Qn63R3Jv0mL8iOf8l2b9QL8/U4Z/nRxqFE7TTjYYr6KPE1Ny0o8xf9TrzvZ5 sgu82DQyaVZNtPdDA7PUbQEB0FbUqkk1nAA7JartAMCX9FSJjOqyUDlfJhLwfuVLAgH7JHEcB6/U TZPgCmsMQfUb5vkPfcNoclDVmIaoRFGhlnPx4JrCyL81/c6SKqKdaOOOV3VW3uhCm5fAq1Ei03p0 jYBMAlLBA7OlUFpFHWaCiMO/cCJHgsPwRCgcpuUV4HC45zJjYWvg83h3Q85Eh8i9XraEzQtvp+Cz Elt6rMyWHrOjLrMy0V3SueoyKxLqj8ZKBXJlzPWD+XNnsVahRf0TPpdo7JhQzuuk3pFNUzHAotNt pv3qlPwexZzltfLifJ+UVPTKMv1nmWO+dL2N0iccHUxPAEVire/a2BORfQnKjGiQ/6CSCk6+n8Xe ZASVFYN93PSr12WI8vn+ZoDk6qxu7zzma4CGwXMrPO0iu7tU3W+Pi/N2XkezIrrIV8iGrDjR17WG 2Qx01fFa6GWB2/PtiNFEe8simH+R7Ji9eiRE8eHqLQbX6xDsX1/QqGbwPpVfIyNaKXrzAkQ4GktV Lzg9u1FAg9I3M+BrZ+exHWeGu9e/JNOCcvTvRKOk5sdy1iRNEUkAGQFkICrajb5YGbx5r/xIjZbg C0/0f2N8Ul8iS2i4nSlx5B0PY02Be2Jpd4iT99y6zsZxqn72+m2mf/M8T1vLRJ3PGP0dvE+l51d6 PnW0vADOqJ8FFq9ZYHcrW67wiQt6YoB1O5gC3XD3yb9IepRKTsM6TNPFvPuyJ8TnF3ky53SForw2 SVIhnu4QKsdQqp/9YwgyCujoQGPAvi7ruh+sAyVgwfsnHNGkx1DrAj3vIcxqrcornks7NDiXjqNp z/itiO4ip88n9sEpspQanDGNnfK6BjtZ1PQ0d4FlTnpFDH6RY14Wz4xj6YQfciWQwYMChnC1jL8i a6TQHFH/VARI0EasF+RFqqQ1rEmJG9LnvCIav8irBSr/GHxvNAazsK+RdMe9aVehW6Vu8PSliZvH S5/gZl6zwM9TjGEUnHJOP8fOR7SKO4tqZFoeM7ei5HWHTJkZyOt6Ycz0aq7ujC3KdV7IulCSoH63 WPf/lFfbbttGEP0VPhVUUblaihcRfTKcFwN1kaAOHMDtA2XRkgOBVBKpqfsXTfrBnetyueTa1JPE nZ3dnZ3Zc86M3NEyY6x2YBTuBKK9/dj1BLhmFu4JZMtATxCy9m4k1BOEzP3QiZjMWaSdlAkUxcIE mcPtOa9JGSkPqNKSXlFKv2q+2VretEId72SEqUMJyNIK2ayAroVa5uMvgA5N0U1WXsmKbi9U+ffx VpHRihMQxZXUfuQ9iUjFyKeTWnRkE/Wbz5aUmcG26XBQ93BYxQobv+lh5ciuY7lLNHVLU3LqvkLq CrxjYK8SkRLIsgR0miu60ngj31F0RVkx8eXbOyKaJfwjYC6wQeBZlfzqavo9V3RTw2cZqK0jIjtQ VNrT18MLyQus9OkXkq0gqePFPODRxz4ptp5UbhvoUtMC/t5RMlexatS3rA4AtIF6bMH0+9yo3xs1 pLeDYWaw3hlRpkTDHvlU2gGcnHavWrcneyRtfFIbutM4cNvTtXcVmPojsFyouMORpSkeenpoS+Ri P4HUGJUORx2/ogjL4QQcGSgCTNQVJgYEwQ8zaiHe8CeoATSONwgJJDvLowxRMicJBqcTvW9tAB3W NkI4XW+ROipfHQJ8I0TWh1+Xcdw+QslJtsiJEl7BdvF5Cd8HCuzf7yykrunGKM+C8lQreKkPrMos yicOyqtGs5ZD/ZmVGC+FejqWBY60xV48nnkQluqti/Ojp6Mv40auRhmhu5oXCk19RlgB3lGnxPba Df2HUZiXZZuotoOQVyV0eCTKVEflSJ6syyM5iFurfrtvfsGiThBhlaLQkm+p0r0qBf9b5uN30v8Q utnbO/S+7eRBX9s/iikglV7FiyBi1RfUS+w/eDCilwLWTlCOWftRD8xDhILrOguhkmQEoQIUc8kt Y3TDGPt+BvPy+IPwx66uNrZ78zVGU9cbkBMK3u3LBJIsMOfTgzB0O17lb7wz6N4dAZy8GTs81brW iYQUSVzXjTwDYFW11VTXmV0UpVIwnEVJ0n1qOKYsrWh3HnKziU7NlIPISNscfUmwiPc/y9imUmsV PrkpCzzr9JOv4K37B1d23stlt3Kvcum/KJ8rc2+V+jfqUX/hiLSYWl0yMnOeemjFx6qDlqk8Catu szqjxEyRw6N7lckPMylvuXckhSMkpCA5SYNfZqAhCyAP+roY53FTpPjUicczhKOOxq0JSkpNQRZX OBAW1/mvkLiDCQEkiOCaDUjT+F7uW+8dn5D/9vtKFJXYs1jWdbTRAlYvhIm1Ttjp6HZnoQXYhS+N BENWQPYuTJpAGt7AyZp62/ovncVff6wVhRvhuzq0ex2X0zzzD1mRFgsSwbjr7Y+0yxDOMJjzIQdW Ocl/V5nKTnj7i6VTYDfvSQx+mNHMP2fznhZkHhLKDNGU1IRfEcxSASOTVMDoMPWI1SVaekjnIGGe jrw6rsnU1uTSYSdQNaphoBThU4RIXbFygYRWqlOeWZqI+vHFEKHU0g5b8YR5HlNudNwEg58eXgY7 5EHqvbfNzCdbNjri1R5GJSX7D/9gLwR1bWlh0A9R9SvCBiPKCBGciF6Q6Dg/NRerAQM0tUB+9Nds nuWQlVN/+0Yfd7V+0rEnVhf9Y9eKKW4n6tPc5iSP2CFlP64lKb7pmVqiIvEL8T5eK05MkETQ1dGf de29942NyqarQ7tQAMmKyGByAKYcaQ5kk1PTONij9Ls9KWTXVknoQattZT08rPPgXjL9t9xTKBxw zc8BhgUKk2E+Hn3F0zuLHO2d83J+Z0n7EwO8CNwrzuKvVvZVVmS5xfjQvTS5g3kovAX0W2foqNID BQF/76aBmw6tTYOO/jHzKqcnLMolnIpkxQqA2pEVYoAaUcOgTbLSxOoJnfqynnBRHEJXyRRH0ez2 Y0dbImxCtIX7+rsyZ41ZmLDGLMJWY6bxZDCeBUjnbjaHIAsgGyitMn5Slqij3y4xW0V8S3nJoTbg 09hPqcUnrs0MlCMtYP35U636Apex8JjSUtvoQh59wfQFCxyVatfk+EgHNrr/DdMj4VbGuAXBWNgq RJYXcXvSE9SRv9cDE+mulQFomObi3VcmVGShBIMR3gjnxCSuZWXATajIcePsj7mhBeCd/Yy/HdfG mB9arF+BEsZxk8IZ8xMT+bGlc/t/AIb8t8cKZW5kc3RyZWFtDWVuZG9iag03IDAgb2JqDTw8IA0v VHlwZSAvUGFnZSANL1BhcmVudCAzNSAwIFIgDS9SZXNvdXJjZXMgOCAwIFIgDS9Db250ZW50cyA5 IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBd IA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNOCAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0 IF0gDS9Gb250IDw8IC9UVDIgNDEgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNjUgMCBSID4+ IA0vQ29sb3JTcGFjZSA8PCAvQ3M2IDQwIDAgUiA+PiANPj4gDWVuZG9iag05IDAgb2JqDTw8IC9M ZW5ndGggNTAyMyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiaRX23LjxhF911fM kwtwmRDuAO0nWbtJNsnG8i7Xu1WSH0BxRNFLgbAk2tl8RpLy96anLwMMLhRZKVUJxNzQPd19zunv F2fni0WsIrW4O4vCICxVCH/0ax6qAn6lavFwdn75lKvbJ5wN1dNtfXb+5/eRWj+dzWBtnBRqcXsG v8KiVIvfz669p40/S+ZB7j34s7QISq/xS3jb+rMog7cNP+9gVQTjslrjeOyt+KlgQZYFqbfjgUf1 EUZyb+HPyiDyrvxZnMD0d/7MfETha+k9yXL5upyr/J8Xfz0L1SwKojSeq8UrdCAsU3YgyhNyoNbP sCcPEu93H85MwIIQPvhovlt4n80j9c55yQKfufearFI+WnHHs+B0nMJTm+G590/au+HRJZ672cr7 s18EmZ3VT35k/FcVf1krsYsMIo8WX4PJS63Wm9/gJmPwVNdq3wS8VNGqOA/iPJormC+zwjh/7b2l Y3erDZibmhO/8BevyBn+7s5+9pbs35E34px6p3/db8RImntAWzKwRTaLN7xZPjkSlmvvB95DF/SL vUTzdkvnyLEbCtFvmBr2yt79icNySdODm8MouSYPYsbeylbeJK/3WvGC+6peaxsMSqrMJNU1xzL1 aj/0FBqXQDmEdvwRhuwLnSxXJEkE7w0aWkogUg5E5vHCLR+geB2Egybaz9A4jVJschub1GPLOgmF mR979x1b+Zv36j90Gm+qvuBxiT3EGml8XslunpVJezHrnqm87l4ttaxlWzTktXvJKV3yqpKYVKqq VxKWnU09yWOM/bafC1zQWjcc4Y2NOKcT2BaC55LTjZv+lJb/pW/wEYIKvUJ1csMGJbS3InF24z/I j5rmz937UW2yyXaosFgOrQJAl9QeaqLDM05ip07MJabNntc2Ox7SK9Vf1KnkaB71APbaXp+Dplx7 qgVIhLBG13L3XNn96qtqG2c878mFhRkdv9S1vrNIISg7BUhc5uM8ESbIE0QRl3CXuXcBN3VFdn3k mrq4ov2vF2dlGsSpKmKgzSAt1Qz/P+qzu85MmiZBFnfnsrgAiD60LZqbLTQ5j4J5TLNxAiw3OZuk 8wOz8tGJ6e8XYwohj0qjDzo5jSSa0g19kDxR700oYoEPi2Hy/Lcprtwm0a7pQ8SuVskAEt9yUkME vtDBCsyB2ThCSoJfEcTM+xt93BR3W0amDlQ8k4zm1Lbl5ZYDwpggsBavELgxNSH3TAn3i0irG0/O LdrSrlw/+iV+2y0l4WyHGnW9Xt/4dBihTEHaAwCgWtHpYpe5ndq1q1pre9MCEKruQ20HHD7T7c5a atBCNy/RCUdW1XLDsrLq0ZblN84RMZEfLVeoZdXCzygXQLJkXPtS5/tm21NU30mpv0HBZSv/Hxdm vrDorbrU1ALGyurDvkQAqyoScdY6VMbzDnS88lH+voErfu+bsF3SwA8/4dtr/P/OR00MVMUW4JIH /Axks09x+8MXvYDPxufCstl4xzOPCFdQNObxgQ775CdwxPOOzxq5za4mXmkG7FZlWh6FXDc468Lo sWg7RbFI1Q7DmpIzZNqPEod7Ac4N/Mg6F79vOJcBDKRZoGQKbOU70J0DKuYjEN3ORgKWJSR62sXh qVnC4alZxuGp6TAooV8z/00bBhCcpbmKjIzOASQiY+YBvM6SPCgRsttWrovYl1VdS6ktKylOGfkX 3x0llqpUBzcLF637WG1BCWWibrGlV9+72gZg6GmSmts43tkYTs5dZx2g6OepdkXdapColxfSd0Jp ZobwwZbCs6OYk+peV7ZURtu1UefiOJifEskILjQdc46l5RGqu6+3DWiMSu5B86EZpe376oBn4Eua nuBZCCkSu55de0bU7+sjDPlGUk5aAiA89ZXxENBPBEg9rrYtG006k87nRhJ1nInLQ86kc7O554u9 YjYncKvEaRh3fU0hgn1I0yv4yaG0l/BEXzD9Zr+aWQNNu1qWBnWOjltaoHKcLrdLt06mqmclpeMy b80F5LQAeAlQXGpQyraILenU+oCvBaLt8b7m5YHSW2qRVYKPrRI08WrcmLbYV21F1qlXFF6Rd39/ L/oO6uCwKzlk+gmegEpMh4zg6pWKJMTds+5qicDkpzXk17NIbZQhxiKGU1NzfmaqwzYRcYI22bkw bec+fq3qni90EtJbNmhHfhxzJwanAUO7JAc+QM4sfhleVZK15+dIuS9clmwYodCJ/ueCYlbvJqu3 27s4zQbXcb9mbx0GPucdq/FpaZA+kAb/xBg4njnWO+LYk25khGevvUa7DN/0oXpDZjkN1B9sOV9P 4KK0vMoJASHY/QTT7bBB691Np3144SaYkE+6iUlSPg0CuwKCgAMQgLRIuwXXXslOfBB6FHxRyUux ZmI+ycMRcg4tUthSYzAwSheQ0tTYg7xw+W9F6PbfzWLzEnd+MetuxfL+O60cwZCOAVFhlLyLIaTi Ydbk/JTIN5sH+EMKf3SK5P3oVMfFwVyEZucWxrPkJBhP0wGMT6DSm14VqappdOUW6wR0cA1Veykh t4c6IK/CobbqO5zGxpfjPU6wPnuo8xXTZFf8Na64q2ot9jqQu9RqpafEMghcZ/GUE0Bx2Slhi7EE e060dCE8YHjiAZunnIBypd2OisHUEkA4bGh7BG3S64HfkhKzZ8tp3XultduWv93XaG6YfIvud3/z MqzK7jV1DRBmz+dGfr3I7N0sH2BO9xuCE/SRUwDuhEJiepcYSXH0Obtes2i11SFR4uqohe7uodWy ZLa+n40lmTWTquUk10YrxiZb20js9uv7Zv/sdiVEPCUo0kIIJ7aFX1mdW63X8ntdddrDF6vHGkkV dJJjI1Xk0G5VK6bYS1MnWUuQf9EUDbDxGxnbc8ugqfmae6TmbfPxlkj2Ax31iUlbOg/pNzZbaUEO xpEq5jR3Q2S/yRRlzb4aIERXJOnVACDGzAsLY9BJ5iVzuM7JYGABJWTi5W5fSycneudbiQK3dnKt su6e2sBlxWH7zNGDtohvXnasoZ2yzeN6opucdj05Vfwl5cHGABSxZSABANUWX8c6GyPVf69Uvatn VF69OX7sdR/vWQIxpmPXZdHWaCs7AY7aiQFoW/GGgEpSygFt0kos5qakFG0fQH6XZgaTJKcmJq2G HJ3tkTN4ejwzJ0U6iKYJZjHv1NiPe5/wjR5PfhJBCj9DaIzmwbGaHuoRYDOXhVuzoPLBlth75rEV L3zmjd9yK/STb4CWB9/Q4BWOqWc6lA+6u9uYHDA8g2ZMaZSkiLHFO/om8mTQ3k0w4kD/QVl2aJBp Tka6zHNAOjrijcu4t6ii0Tseveupt1sun6kLyVFcHH8hWTTo8q494XBwRmRxbRwbV9L9yt5Pw7Kj 20w1ANVhtSapYUowlJWYnYMSt3MT8gtrgcWXXXtYfHUr4hjxhZ84CUBHSm6COa6ZDaZIYreXn8ro ldhjdqksoeOkPGX/LXO3CICmkn3PvZW7Wime09V2Rr+e4VOZtyGhbuD9EL1wFZ50QYcr8drrdj3/ Ry322MgoUczh5tGlHq7NY4SE1NhJ7o7UmSPrLndWPnAsdkjrIrwkjr1FGhdxKkiwGFjklWdFXeAO q+xstplwK75quLvKSj5dr/XPkoEThDxWrUjIYyU+RchYZETHThkT3zK3T9Gx2TyAANsCDqeIiken mIhH56BrQMNLC7hpeRrgJvOJROC87/cmhLHSkNVqCX0Jv4n0gjx3lRPn+DQPhZaE5AltjcR26GNS mCh2fIzLgz7GZZDEQ70Rxox9YVEQ9oFhBaZ6iSQvaYv5WuHg42c/hjy94dcbX9k9lOu3tLmmV0BB EAwZn/hoTiy8B9X7TmqkxkcsjwhaIFz0+oD/cW4cPz7GUWEqYeh/QiF+YE41LpXkIdgBpYixrnF0 jf+faIrsz9H+EqIrCgFchaDiTeTg5S2t3qKikuM07qFD+RhF5zxi+4pn3XhLHILrnb6FKA3yU1Rn mJkVx1Bgi1QGmxjaPjNEVYJVjfRVgoWNZrTaSFe74YGK6atluOUXmjngX5gYtX20f/E8NTGNRjyk QLOwvrhEZRuY78cTUiieRwB7CJNZYXixVUL/o7wKdty2geiv6FQ4RbsxZdmWi6JAkKKnoEjb3LYX OWLWi3olN6mDoJ+RQ7+3Q84bkkOJa/u0Sw9JzQxn3nsjJiqoYPIIqgMQScVoBDUUDlxQQwkmkd9B COkvCJPhEzex3/Ogl8rue0BVIHEb2xW46AzbeWRMiY+Gid5mGtshX9yXwaLo1iAySpAYomJYjJl4 BhblzAw03i+4OAnMbFQ4H+d1imjrl9j3B5fVW1QX3YT5wEf42WfCSz2n2HGXfONsq1FPG1liDvZC BgCMN9XCDDgqJYQWLukhkSXS24P/+YE1TvWN22t0HOGGc6ahwhUP1Ss+95o1+EW541vgSdbcokcR DtkSu48QROmCEfUY0pmvZfNMv2tXIJtUv0MXsQIryiY+P4ELKKeCFeKpYNVxT8zZxOqydRPstnUJ dnMJdbAD14GAhM2VUMd2EUHSZP9ie4/j7bKWwcAY2VTpyQKNWYW5BGfnBgkXxpbe74aotz6PGW4w 7dUe1j7S94MihG8XtOQwSjoqwb785Bu6+RVjy6+MIcWANq3z9fqI1q488ne8j+DtY/Kv9Bf7Fic+ yXU3ADgxAbozAqX/VQWqXW+cmtcjiXCt2NI5ZjKuRMp2dbuezAjPUa2uXhEJgXFnpk35zi0Y+1yP TMTXMIqsEny0EQ7pDOWyF6RUUyeAGlKLqaZeWJFrliGZfl+TCh0A0I8fArYqiD7YXKDN5YKb5qZU zDaO/QLhiLgyYqBxgwNNveOo+nH4GrbBZU6H/PrnC7fVLO6eJxG8ayQRrr3IIvma9zNz6AV3XqCN yVo2TypZuwISUZXMLMGMVuIQHJ/0AXNIycocUrLqoCfmHHsoVzdhT7OZwZ5ZDtHQmelLDzcMRQmW 3qAvg/ArgWrjY74+MEp50+TVPlj5JHByTLGVHVAKGdsO9L+ALkjjEPjNtX0T6S5AMv8u17kUydFE T+dhrlYOcq8P02HJREVz07biyjm43IlzB/dInjHxyyn/gZrX3yF0X8m4AXyiTHXInC1GU3v/r4/G 1HfNBK3vJW/jMFj8m1SOei8w9Gsw9KjFv/XSoFp5dzeuldw3/D9m5xVnbbZSNnp6XXzsHTNNyGxJ Han8Lkxz1anLZo4wnxRyZ5Y3JI7caNs8cUvQ2uWiD49ccMbsWp+ka/0x7c6p3Nyb95HflRIxrUMh ViKbncO5qESCjdoi2EpKBOgHJRK2X1AiCQYG/2anPLn/Jtq9hLBplaD33AMJtFpX1idr8WBR+lXd g/Sf1WgcxX2FCw/jWZR9X2H3F376DLb+ySthPhFA45sSMYvI+7w4XbyWfHIuDi52sR9sldex7n3J Bv3/vevzQE5aPAumR/jG/eP5yuCB0TcFP4vTMmpEajjH1sz9E9QNYCgjDvYPuG3Sy5na4hoOagv9 FdRVvsZ+CCy1YHSP6ipfy2bfrVkqlTPQW6pfoahY+xUFF5+ftDsEV8EKwVWw6rgn5gLgUQQMeMls IdrJjQms+QcbCMt3OQkqKCTR371rXj9G8EhrFqK3O37Qd99qeSZVL9Q+Dmiebi8tbwUGXHXtYZba CzU/flCFs6TKvjNmV737mb7S25PcNoK4ymgjhTl0WSm7Nv2U0p5p7nbbDb3FXb2RT1V0myHuXYDL h77qhfblot5W4xCRwUOGj6rqTid8dOyC7AkbO93h1Lp1u976SJsa3w9xhdSIy+k12yTe8z5P5tdM C8oj/X2WCBKwmiZS5Sh9CDD63mZoPel5bg/0cql7nLlp40yxUt1TsnL3lKwJisyZNQq4xlkbj0JX K4umdoCglUXCoG9iQQeq1DOI9RCb8IPtZWfnf5eVTar1Mrfo6WUaJwd4fZwr40hmKhq2CHTfBfbg hu4dB+J/ao44trFsx+D2ElnQQvlNFSc5f4EOK4qOT5lo1TKO3/JJlqSljeMD1FO25M3HoPPydd06 QX70yUv/l30zrKLcEBW48lLlogqMhZUguK+sFRS8wiWzOJ0sv/6Wq6RZ5Mi+t+EXEi9edqzcHOhB nQ7SiWHEFZz/Ned/tziCDuRvIIHjsQhdihb243nopTpFOgxjbzX8SzkIuMeeWcrjh3k2THtRQPqp 6jQzlOmW8/JM2MvB16GjkYwI1gTczpo1NpxStl06uXi3Ej0sU+/vrO9+QeGjxOtts5aZNofJde0q rgiTXE+TalJ1PLECJgtWgcmCuYAJSxIGdTpm+iIlEt0u6Rau0h8p7B2FjbqyJys1+Ahh8dknk5R2 9cI0m93SVR12P5y5/KQahZJWUuLfYanpe74IQVaiV8+B3kSxorJ+8h63GSfHK/XgiDdhMCk+GX2H AIPzWnu5nj5ZwYonK1jlyQrmCeLvVs7DqwG/nQP76YT4lnFbNI40xlnNdKnee+KdCWERfQEQfiiM CoyjLdVmteaY4TywGRY3BImliMZIA8A4ScNv2XbgMPYva7e4kDYcmU9dHVJnOHWPTwJYLwgyDDDP LB7fc04fuT4NRqyadN4w2GOeHFdD1G0z2Vk1fsibscxkB9cgXMN1rNJTniYlYGmyrDnozjKa8Qfx GnVq8X67h3KJj8e4Z+aOpZmQCOI57qa5cxj++ByPfvEY2mzuHEz+HFvisf8HANxnL9EKZW5kc3Ry ZWFtDWVuZG9iag0xMCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMzUgMCBSIA0vUmVz b3VyY2VzIDExIDAgUiANL0NvbnRlbnRzIDEyIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIg XSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMTEgMCBv YmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQxIDAgUiAvVFQ1 IDU2IDAgUiAvVFQ3IDIyIDAgUiAvVFQ5IDIzIDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDY1 IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNiA0MCAwIFIgPj4gDT4+IA1lbmRvYmoNMTIgMCBv YmoNPDwgL0xlbmd0aCAzNTg4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJtFdZ b+Q2En7vX8GnrDqblkWKuuZpN3awSDCzmSA9SAAnD7JbPjIeqeNjJvM38pDfu1WsKkrU0XbvYmHA LR5FVn2s46uT04dcXT6oJC6Vdv8fLtvVyb9+1Or6YVUlqtBVnBmlbRLrXG20xtF9s7pafb1dnWy3 sKS2VyudxEmpEvijLyeZxFZtP6wSN4/nJmp7if8+rSK13v62+ma7+n2l1a1alTYujFz2gYdZ6W67 W5k0iydD3oxDp9tkDGrcORP8h+z46UsFygQmBwroDFQvwdq0JFt/GO02AEflr9SJwdEInDEkXmYC ywbWk9I6cOJE5ykidB5d3K43xsZp1O781/VX643O4Us1a5PGVXR3+2G9KeMi8lvqx3URZ37ctaqj rVfrDb4iQP/r9jvEft4mUPUog/KqjMsytOg8qtXDWmexjZo13nmJSlpQZqfe02fT7Os71vH243qT 5RGbdFi/vMrxbY5TsSziNJ8DPUPQz6NHh6pF0JI4jwDS1MSoUBLdgxmRqkHx2lmURvzTwaIzS7C2 US3nNLtnjAB3g5/jjCiyuLRjnPf3qEIZdaxK80C/rKRoJo5jyZTDyhVpbO2RyuXwjibRcxinhLHT SLAyjLGN9mtjwYuvnHrGLztz0sg5c+5nyZltJLvVI3/cNM/YlOu4CiLVlM/alJm4POA0DLG8ef/4 Svyn7l3kBn277N+j8e9x0dGSiN+A0DPGQHrKj30g63aF6RiMKSqfk8+jT+u0IrRBnZs16XfvXqCh 0cM61ZBs9jTiyUvYUUWP6rFjkZZ+eXiPMhYf3D1VTbN3iF75nKWgjz4yweZpsvhoLr1aMvbFkeMi puHdIuQyg/t8xgID6B1pgC4xw40CfdHbeCEWf/qWP2TD31BNLfKqqUcGNgNTRKZ73gdh39GVIsnx Z6n2nUe3FDgZJgVX3Lg+cGGQ1aZ9lCr4fDJLbJwd+QBZlWECXI78bi/u0D+Dx//fnWobKAAvxzKr 0jg5Mp6zMsWENnISSTZ1e90o0LIFADG3hK59xy/vVRbtmIwhv8pL4VsZpkpmQql1t86szFAqPkZI kk7xZ8ipoAgaqwoD+ju65f67tX7FWhLr1zKIKLj3gBhdOKJwAWkcraW2WlyT62YXtTM3d+YCwURc 8CFnyfIMRc4KPfOIu6daXmhDXrbv2N3EpxS/5BP41gda6muOe3EW+EwP/2rhpXueDWoL7UbIYSg8 ezTkzZ5mT8Y5k2y0b/gt+5ynDIELlJih3sO93vv18REzC/ZbBMj0ad2B99Fh2afInSRZH9TANzDI BzxvTsv8+PYgyyftAXiEKDIqAr5G9TwD+VK/AHzpopHdn9A4A8S7Pah0dmRWz+yU/w+Inyu5hkvu HfO4um2YDqp/gHZF9O4MH4IzEvC6fxI7uEM+biMRg1QK/50dVvjkQVvs8b1Clh7sFYYMovkjpP9L r3Otmt+fZLQnF/MtRhuyv4PmpMd3DZmZ6xp2zV5STMcpYlyxntia5qBG5vhWIdPYKixUrqeejPCP FHuLTuFi9ZSatNcSk8gBfhio/iNtO6i3Pr4dyJJJO3AeDZk+K/x+yh/3nmvWUqF9RvnroJ7J8Uzf VlOmD6EnjOWm3ntSQBrc1Ly04wVOFGKBPMRuwhdmNLbl8YzdliPGzu3I93wf8Jh5AnNQkeJo4m3z KfH+3/ipa18lQaSYjg9pnB9PqW22RKkn2ap+uu6TTlgmwEfZL2ssGAeVzI7n09ZO+TQ/ce0LLhii pf72dXfqcyFHZXIyw1FnVibMY0B0kU1MGeqMTWlGdGXAJgBo0G/7G6pHFJQJ8pS89stwoWc6o2VW HakQYtxLBwxsKh1iIub04kRzF8VxeSDu4mfKuxfFeZ3Fx9QckDzZbgsAf3s1R4VtmuLlgOcg4pz7 puQpr5vrpt29ksbvVH1Bfa06w1IFnxZLGDW34C71xYXLW0XUfKTV21qiEva13SBE6eMWovOKv5Fo 6IgPUKedD2ie6jj+eyX8MbUTVXK5G7F+++aStPNXYiXLIlaQ9t59plEsljrHTwDrWFtTqe0ZeZwL IHI7ANYQsLQtzwvcRouBZJAaTFEytj+tNxCpJeWxEitCyIMbJATCB4A+1iokMbdUkf8QCkoh+ySF Q3FYX426lyYM/qavoVhO73yTs5/0P8PiykvXT8PsRtv4gJNwKKu1fDRjSjaS/0r03nXtn56NSMbs tUYDhqTEt3E86XiVe87tl0Fq9ngk82A49XzRG+zmHZ7uC2kT5bonb4vU/02P8P8fOdV3KORZ406m vhbsmnFxUhed77YUUxLU+nNABcL6gLiOggOmwoIooG+dZIGt3BvS4R258c94ci5A3TT1TrBTnsft u5BEOYftH4i47PV1E+5aRifxa3LD7uky7C7Q11VqWK0Lme4bh+ApnmjIITlnS8D2oegPlZm6mH/x 3UxHyVZCZvAvBpIyPXD5PuW8GPKaT2n7/gRebCev91rY/il3B2/pKElpfpZ27evPIYXs6p36JQrD qFWX/asOoFDdlTvV9PHVjp9t6AfC9eu2bWTyl7XY1fYXt13Lpk/sgv06C4qAHmTy1FdJQ7A6FAiD kjHIo+GceneGWHgkMlbXOCSG9MugJ6CtZKJB2Gnd2UWVzhA+mSteRhCCOIekJb5peGfMoxdUtHHQ 9n7zvcsNvjBJirzzoP81cBNfgGYL2gWWsibsLPoMJs4wjGz55RQEDI2fzSSj8BslxgsaikIL2bFn wXilCy1fDsK3oSgNAmKUWNn3pCA8hE1p14oKPqXDee+nCWcawn3V2nejU8fQAaESD69d6RNMONiO 4gw3J2HScQE0KlOy5FFrd90IcpRqJkVR8vqtuIHq9t63fKKUlHRgjeV9lC9VJaBs2ZCy6Ur3UT3h vtqTwTdEK98RcfyZ2OcGL9WQc3ET+F69k6/7De2/4In6odlBAGEi5Jl7hCwHl6Ph3q3K6AEZDF18 RQfd48UQ0B8amHG3yt77DwiG48v06AX4oGPJsqPl30c5KrjZ3/QFzsOvGEGEmoVoAPAirj3vNeBD 0E1gJgEAi6pH+5WDe+M2DLjxoGnTsdE2dYtVko1eAYJX64xe4VvW8C2hfrOT/oBSajC1NlmVYfpm KJjBFhFymwy9HvKCYT/B/bmuovHjAr5FxC84OBqcBdfPtgwQlQo93Ino5Nh7YY/lPlIL2d8qk0P/ YRPtG1dCSTsgxp0u9IMWRaCLS0jEIVN596wIGAU5vyyhWaXyAzq8Jd/AAqQBMT/rFdQW8+ffXRXa VJxYK6pBqPw321UJJQhuL5JJL9mvYLMZ9rjchR4QyysU4f7VBEsZtLfV6EDwjbjI58W09XLlWM6k y3Im9XI5eJgN5Ko8LssFuaqI09zJVdAjDsVScLel61I4kq/TqY4TOwfYnKCsgeAYzK+3E3+pEmVs 6X1lnPKW4iz37hTEWUbukornV+hmHFUccMM1CrRKAq1ygZZyoAntcmfoqkAW8oYmXLAVFGzMk6vg Sm0TCxvOWalu/8hff5LTghufYcbS3FCUHI+QwdjRq+hXFpFDNF6q/TTekrlqR/GTUvxkTOCqyM96 o92xEj8lpU+nzEwE2XwpFGBlOYIOiGWLEZTa5QiaE5MIArnFCJqTkwgCucUImpXjCAK5pQiaE5MI ArHlCJoTlDUQfGEEIXPiCAp61LnOD6nwfPOqgh6qa8fMVXhhI7zoBaR8ylkOUBbjKcvZkxTyO1f7 uEyFTIN5xZhBnBIX+C8ZxFkdsAZFV8q2Wk5rXI+FG+ZIjpsJSM6IeiBFqA6TD9qyRD9ynJykxZTo R5VjguzTIrWykqFy38/1E2tTZS7lRTTBGTH33diGhqfoP7lv/yhD5kxZNbiWgZsxT/U6oxpMOzJK c3KYv/6cL9ECU0UwQUA4PzcqhdBNATzIwjr3hQKSIbkYwzohIymGay9E4EHuKjSGlig5T1CeoyVu FiyppKTgx0vYiS4LpEjzeZIXLTSHw2yRuKz2jGQODy+pxKLJ/6G8SnYThoHor/gYekBxTLY7x0pU KlIPPUWFUlQaEJFa9e87q7PgpIEL4Jk3dsbzZl661txhT8mKQd+DGYJ9bwxsU4etT9DD7peklo8V BicQu93aIhn6zRNOM7G3A3XR7m2hAlbBnITRamb0vD4KjWiZFWEdEibcfTokjmeqEI4hwmJd6ULF EqCrS6CGPYHSaCPfF3ZkOXPUKV9XJ7MeCo6OepkrO+LcQqv4T3aEtdEs9WEzG7q0nnGEIdPIeFkE JYiFt5YpdgSAygxGjjEjAFRWMHCcFQGoMkKgY4wIINXEyJlscCWwIazL7xrrGxmeMlg/dITSgL2a Cidv6UeseIlV561O5aN4fe8b0zBQpcKBJvVBozcaaCcrM9TK9mHsGZyXJsQbG/V1wdEfnkUBkIPk xBM7v5AZydFdNZoJPaFoCLMgXa965iLWTw3uE1gpcO+zWPuQeDyjDixm+sqGdwkF4waTS8ZC8xjK A/ru7VvbK4jCqQ+8WUETvF0W+mNYUvQg8YcF6vcm3d9uzjeXoS860A+Ik0Olk9lS/x6WN5E3XyH3 wAkvPXGFXLpLc3mWLeYhwRytcqpYFsJrSG6JOtsl0SO7POPrGJbHF6wC96OGFqAq4WYIBWVKCYdL QHQbk3C1/BXrUaK8MbaiN1I3tJ5riWnEcKWWar2/Op7kWzZTN6N+71h4FF7caFfvdlG/X64ZCJem 1LllfafnYLs+zHkR+5jA1m4qzz+UHyrYLnSQliv9LfVEQEKX+sKEgvkTYACR95sbCmVuZHN0cmVh bQ1lbmRvYmoNMTMgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDM1IDAgUiANL1Jlc291 cmNlcyAxNCAwIFIgDS9Db250ZW50cyAxNSAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0g DS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTE0IDAgb2Jq DTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiA0MSAwIFIgL1RUNSA1 NiAwIFIgL1RUMTEgMjQgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNjUgMCBSID4+IA0vQ29s b3JTcGFjZSA8PCAvQ3M2IDQwIDAgUiA+PiANPj4gDWVuZG9iag0xNSAwIG9iag08PCAvTGVuZ3Ro IDM3NzcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInsV0lzG8cVvvNX9Mk1SITR 7APIJ5lMeSlZVkK4nCrahwamCdCiZiAsougfkt+b1/2W6R5gSCWXpFIpVnHQy1v7Ld/7ZnHxcrEo VaoWtxdpEiczlcAf/ponqk7TOM3U4sPFy8t9pVZ7d5yo/aq9ePntdarW+4tELVb238NFpCaL3y3D jBjGWVrkakrfxdXFFBgns9xSZHGVpoUlu4m+n0zTKs6id5PpLNo0O/jEVaR+vhpsTLJyXsK9XyPc 2HZ0cpjU8P/zZJpncRr9OuH79ayM6+jytWXzbpKW8Sz6ZTItEjj099Tkt8UPF2kRV1VVW33TIpuL vkkmFt5E794fLPM0+g5E1lEzmcV5BFokcUlsyjidJ+DSkMls5pjESQoSHKerBVhdR2+uLT8gdmbO gfON80YdpZZrHv1GSwWKp1UFqjt7gMRpnzuLQFoU7k6RmXBVf1Zb/WivzKL7yTQrgGWnG9T5L4uL WRFnhaqTWVxAENh/U/d/Zy5uw8OiyOMy84/LrI6z2bPEdJI5cu+ogs+8UuV8wBaCJq6r85Rp4ZPO hqRZPk6a5T5pBYFYBKTzKp7NRkjndZxXTDoHc33KHIJzTGgOXHuhaZ7GSXHehae0dEa0Q/d+80wO V3UZVzaF/5+o/0OJWtXZuWAIDkcT9VniYjxXi3lcFKO5OkbM6YrUY+k6Rs0Zi9RjGTtKTUmL1CNJ O0bMeYvEo3k7Rs7HSP4vp27hfj2Zu4lLA5sOEsGlRDCl7U+QAkV06+LTfYFvFplJEu0wzvYYikq3 kLo5bNy5wCuiFu7cy8Iojcf3tHMglh6rVh+ctLtPLsnzyBBLvtvBXdWEYkg+XxGB6+PgxsYSLw1f fLBswBLTKiw1s0jDDawrUC62pFQniq4w92TdvKRfx/YLLouUJUpJoRw0ms81+K9RRNS1vM1sQ9dh Pid+EbOPV8+9GradIF/8rMCv8+i9+29w67CfQETWUYzc+mBCvuk8dXwtS4ybxZ8oRgqJkRxlFbFT F4Lgu8el+1lhuczgOWowqKHNV9YcqHIra8/c2uPI9H5/Rz9v8QYvV/rAG5ZPR3xaWGWROtJyj+yY CE/XdKhukMMV1u9rrOyXuHJ1FBT6ivoQnEztFtRUIjealTc7K6aytdoZ8eBU4nuoIFtk1D5QnPf5 CzlM5xBzIA1vtQGvgRk/4v2fUfG/o+JT3DynrDxrmvrvyvGCL/ca75fRJ93SrwP2VasXSy8hZogZ VY4yTuZQp5InCscrl8qUwB9cQoNakn5cNni9MYqC3Xw8hhnO+wNW7ZAVZQnXKLWUbNzgSZ/TuP5M ZWaKuz/ix3m4Qg9XbIDNTqGm+81Rc0bSDmGVvmCdPMKUPDfEH4iX6FWu7ggrQWAX9BL/5kOBEiX0 oIRqhKTsKw7Et50tzdut3mEosVvhyGBaoZeyyBUnqGRbvvDKhal6jaGI71JCeeNkBM/kEZThg7vH G8Y9F7imu2VB6GJxJ+zw5RaZsUTjkoU03foLPOF7mla+3K5lwXyrc7egJaiACV3D0/tPZL1ppMhd dkepX441AawpOdtrqjcRcN8a4s8exJTvOSvNqvkhXpIKgXKKeHSoAd/chgoNXk5toDCwEopksRdo ++jYE3c+O7JssX2kV0ir8HBGchrkJ0WijDlR9lgQZ6BIDYpsGRAfbKPc0MqoVeeOW9ogmh3u3jOz FfqRyXQbEFnEIVcJlfBZ424q/Bxpc3dHt5HPmnX7AWl/otPv6fsWkYXq5blrTNaJ7mkZMWcLPQ5c 5xzIIdX7ffvTNifxDTPa4Qzh+KklE+4N2RJ6DNLVaXeJVU71zHwPslorqcSIYvaKfMn6YUCE0OCm b4OclS7wfpnkCXwXrj4X0ntN2Ogwd3lFUU8VIrgSNFBFK4IdmnDEEE5gXii9WjGU2DVO+nnswHY8 EnirmQNTH911voas1FJ0R2l7/QFK7J5VlGaNwZxJ22cTuoAp2b6lS6I3Gko0Dk+CG07ylPsOjBV1 WvxHEEDfN7cdtWrdI9lzWF4RNu/60eA9ImO9ZErjADOvuo4uMAc5WDNvwtaDKcTGM8aWMsJ6rdv/ ygY+6mfS9diu0HyxRJP72KMbGTh84AXt/37oJs/RrQmnMH6d8Gn64aW5kxGv9iYyasB2VGRE97VU YXhLVtH0mrH2Z5HZdLzp9kMgc+Wde3n4JQ+XPewcAs5GsY2q7UIfKAubesB54tIQq3aNIdul3/3N tA3bdwYLnwyUHbt3kDoiIjTG9hCmCC9uwwQwIRR2L3E6XvqDHwbd3dPQg097OKmHcIxmF8Yl9Akw z/QM0gPHj6GRaV/lXI6G8+sZg3JJpQytqmJKXHVlq3BOfaWiom3TM7PhuqRlx0ntchgPsVVUUen2 oDK7FT0XE7r2jD/phFm1KNdOl57YEzUs7516+3pS2GaBPTXH4dUtkXVfh9xE5HfzjCVt3efeydMr G9VI7DpMamFM7cByULReBVYd6XBvMFUrSFU4KCBVp5A8t6iVMLZqu+MxtUNQcVLw9ivDcEYLNmM0 tMdWG6BG83llGOgQmrpztYmJENR8TcmORj3I8GjPWAwjJJdh+lMXHDbBaoAWJe9CdffB+1vIkkpM +IiV9H4I9Cbo9941L9Trg+nBseW04hO937Nmt+wDQnk6wKIDwMiP4d7CPoV7lSTFt7iFyzA92M6D 4ZGnLstt6LjKU1lOiYtBfFzID0vyepLP4XNpn34evcE7L8jwvxLp9WQG5kEOWYq4V2UwavTtMvEb gRyemVZuouuDnswwoq0Pj9YnVsuZRGBQMZ6UFARqmqYVOucaeUo7oopsXkgXGe8gAFxc54IxsazA maZ9CkhJa4XyzZXeSCPWYfPy2iMefKLqrx3gSku50QOhvkfVfms23a3LYXg6QUxnwYKSi4MLfrMb t4s8B1OqNLIjjnFkYNKjDYsR2CI36z0SQjl91BtRw7bjRpE4A2ytjoaxjXRhm/Vej+V9K1+8au94 1o2AF7e5MfoEBQR85Alv+9SV+sOK9GiVvG3VeQwBMXalWZRarl9hXKocuxOUvH/IhRwuyLaIb1TT sVeGior0QHMNMyy3G2u4Z4ALA+NpXwvSDidJ+FVwoXERYFEkAwrzGXd4jck0JwHQuJyeBaGHewYe CEOYiHchFQi5EFc+ICZn7l++tjdTmGOhkJXRL06srWu0i9Nt/8I1ZueWcczWuRN+kAiP9e1AGpEM dFH8AzGTRbRXCxoP31yjGoSgjq2IFfetQm6mEVjFw27m+GIwWFM0KfBsf8YAkaTpmpNY4Rhac+of 20awsZen6VxQnFfvz0C5EyUW1L+8kYcjTjd9BcQY9QrxSI0ihakAzTxAzdPMo1eCnQVpXM/K2lfV xTNBTc437ecbqFWlEISeYD+p+mI1HK1GDBgt7DJkcW08Ty+tJFwuhzULjEnLvui2DQ9O0hU0D5aN +SDoQ2r3CywBR66/OxIkbY2oqR5bX3RUjajkyTzTrL32phtun30n02sexp54Jgmj7rQ3S1kLOtQT TUyel3Q1XrdYb6Dt6LXunzkosocgJ6bndM3KogxDahmGVGGR/Wko+/1LkdRhk+7Bh7wo20tfaRA+ qAheZpj6G9sdMmqAW2Yrmnh+DF2hvX6v/MZLQQEASSrO2vT27vrcek6rZ8KFgnBIap7I99TOmA8e zjir2lM6+Tnh+3/Xl49BKHovQRp3gjyJahBlQQAOI8/2WZfWAzGnaJJqqfl45L3toIz0SGWjwwp1 gkkDyNV0PgIc9hdmP/XmA+tzCSW2fh9gIl+ky648Luu0GKsEiBCPW9bEj8d7xDgnRnA6dVx/ARZJ x1tv+vfhR26lz4QPdF4m5kJYjxz4CqXrSWHnJ47tXpnh+IHLLwWsYb8+M5YNEYIkw7cSOuGIA4q1 FERnWu+SnfSRvePFk3jyJCyP8Grd8nfuDysOnkEDDeINlTh9nfBVho/UV08K7mGR/IPiUC+lXfnV mOR9YW/3PDRxJR4R6Ay8a+lH5jF7m58rTsv5Pymvet62YSC691do9OLWtmSpHoOgW1EgaLZMUskq QQvRQ10g/74k74PHI6Wkk2FJPB6P7717h26kBsp4G9kJ3yrAFkp1vzRWTwJkz0yzieVMNlwag4oy MW7E3WOBoRb7QAK2cXmdWNzFBuiCSA+vVvUuVYYg3y/K7HhlyA4ngOdvxthpTF0Fi1uxw0KVVFmF TdXjGokgM8Smgo/Chsv9SAYVsctOt2LCj0kj9n3f5z7EWEWPeeHSOXpGWSfZb46oRb1Acju0aIJO Ysv2ECazZIJjPQiR7Fx8aHX54rZKet4SInC0VV5aMe9BCEucyk7C5KTOJK9P7G/UBQdumdycbXkV OuxIQMzYBfhS/3PkC4ZYzkWPPAt7GnQygpa/sPrvMdvG1k1BBQS1/gosVf58fiaraeNpipbMAsAm qcEewcWr385PhRahfoWEr9l34E0XePO0awG6bWIL5BZP7i86pOt/ICz5H0yrg8ETKnj5v4UO1kBl jkGUbDY/nujLlJ9ASguX7rW4iU7cI8decfbxxaIQlhcN4KEPH89Fmn75wGkRu4W2PO26QlFqSM+G R+1yipkDATLRPXuO6KAFAgLvCUoFAKpi4ohvuk9l/TZbSioh+inmarhPkNVYJ0SsY83bng79BYg3 iqp2Q+8D1FSL+oV/lLdOprpWr8lmf7aaKzeGcWm81cZzsuMwzSdKUVVnXBQvufB/ic9qBY1UbB6T casdewpdMUneG3IGBV2c0f33HRLgQUUWeWKu3d+QEEQ3R6zZA1+2ppfPwwDxzkJbzpezPxeHuzoi q5tfgcH7jIk4lXSFgDC5X+gJri8kZYT/v4H2tF9Dy7wb+HYX9hh2j/FRj13Uf3MXQh5397D0KwTi t5RiFJAfsPtNqonO+RUWcIAHKkNc9B2S4MQwyMjHiU/pl2Ljvh63M3xILxZrVRqeB/i101U19O34 R8XnT9dQt2K/VrwtmaxiXBXmjLmeeSarnQd35rq0EWvmG7xgK8GWJWPHl8cP/wQYAFl0Wy4KZW5k c3RyZWFtDWVuZG9iag0xNiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMzUgMCBSIA0v UmVzb3VyY2VzIDE3IDAgUiANL0NvbnRlbnRzIDE4IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3 OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMTcg MCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQxIDAgUiAv VFQ1IDU2IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDY1IDAgUiA+PiANL0NvbG9yU3BhY2Ug PDwgL0NzNiA0MCAwIFIgPj4gDT4+IA1lbmRvYmoNMTggMCBvYmoNPDwgL0xlbmd0aCAzNzg2IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJpFdZj9vIEX6fX9GPZGBpeEii5MAIvHGO DbI5dhUkwGweWsMeSesZkh6Ndsb5Gwn8e1PddfRByrERGGORzerq6jq++uqb7dX1dlupUm3vrspi XqxVAf/wqYS/Bh7Xa7V9uLr+9Wmlbk/ue6FOt93V9e9+KNX+dDUD6WK9VNvbK3haLdT2+eomW83z WbmaLzKVz1blJvtLPlvPq+zR/qyz/pSXy3mdKd216tauLbO+48X+Lp8tCpBWeVWD9DGfVQtQ1eVF 9kRqWVF7pu0itFe6bU2rDka3hsRm+DOAAt4Ij7TTwCMdTT/+wJkzYA8S6scMPmZsWk96yMTv8O1v OXhjlf3DqlllP+YkE15A0Rl8EfCAJl2terd1q032xx/QX9d5AzLBqlOs8n9u/3BVzpv1slGzcl4u qo3avrP+L5cbFwmMwv1xl7uTH3Gj5rd6Az9HMMfgysmuNKR4Vs+XTbmINFul8Hn709X2F0nIF0WF p31LV+KrKX1PF6c7W6crPQzG3riuwCAOOW85aNn8Se2PP+ez5WpeZqbzEkZ1InQmzxmXSFN5Yrok pvzhIwZf9RhASbn2GNtMSXI+4W+iTZL2l3Jnyhm+Gb0+G/YF/yo9urwZJYdco72mJ7KHtejjA7nS pnGLl8EwQqCKeV1UJUanNQNv6j/iMbK1E68P5FFN5zy5BOTrjismzm2viCuP9SVexYANUozO7J+d Od65Ur6gV77xlg73jK+QerVHw+Iw9x4J+E5KvOOhQeMuCdnQ33tXRIkQuuST8snWOAikcGDdLLBu oFIpMjvjjoOT8TZgjFMFO4+8MqAvGpsSjYU7dEhlC7ieb/i6rsagYFTo0QrvscnI+DprNYsbkuT3 g3nAc7AwNqKCz1da7eixZ4Bt+LzOsJ5nu8DWkNB7vKUyH85syCA37ninyhcNBNSVPiy3vRzMvQLq 3qklJ/mbO4NFo8O8krxfODQrrcvfRfiFIaDQDZz2xrcvv/t/Y2G9aWpU+J1vM4xR8OgTHWGNPr2S w7DfSTVytZiHBC+PD7jzIa6uLqjkCUiFFobFHcY8FI37LR/Wmj3fwRCcBT26NTsPU9LyAsQPAUp9 DoXge5dYFoOw6XQCJ664PdpJ+wPcK5cYCepwL/msgewYcirXqBHSa5f70t6krfEZ8/J4f6+om8YC Z3y7f8rr0jX9Ll+sPYm5w55dYWst0jSc15U13Rls2h3n4XvqUhGYJbAp35hICVwl3aSdIxyR3EF3 eyM5QRRpBwck8ZeY6hhDJeg+x1VsETQ0sXVkZQKtY1vjmkhyEokKuzOuznG3w+xp46K2GTNRygzP 9bIOaU0tOKMYTQnDCIYIeD8D5sB8NIFZAHeCvDo9AHQlEDfD3QP3AjqKPzOq0rIJUZICDZuG4f5I EnrHW6Q1YHv5iN8x9JD8bS/IG4Nsh/Iq7Ma2b9qTSQlcQ53JCupWmEJldr5P+9aeDpBOZZLuyayz 5EmjHxhGBYaYnHOycI7/3/TEofaInoCXYDJQruVVI6J5sCVLkfT5LUXYf4ZbpZzFvXKp7Y/MiYAd J0gwCAb0e2EopHW6CFzZTFXCTfa92XPathTGV9KrPfQWRY3yswdqEjq3hna5Q3cwI5hd6IyyWuGe N27LJnvz5muf4vY+glWfJzSB0mD1OoYXnrAAsUJY4yD5zpRECxI9u4+Sf0V4WC5HmSDzrcQ1ab9G cZ/l2UDmC3XQwhogmyDk0HdRTzAkSGzfYoeamr8iwv7hnCamn2wuIG9gLUN5x7lL5ndK7/rzU5Ro EYW6gLSMnA4KhPky4yVE2MUAcX9kBGG4IerpAY3wFQGGEOgFhY8xhqdA2u3ZCWJNjP1mDIeoITGa 4rhAFrszBx2za5GjQmNpiILY4uwX3k7E2lFcOb6NfaMntihSfcFLFIKDCe1lvn8WVY904ol8PonR EFiqPUFSTpQT/p7iIQrcrQW44CWEUGGe9EtoawuQ+rsMcEa3gcaYOnGKxoMgFCtXr5Zk9pViuFTv fJEUIJvOgLx1YiiUygyQpk1Ki3afp51jUwjvySTYsC+6Pm0rKfR4f+TkRQ/cDJC6Y0cKRRNiF8ww 9JE1d0kslb9UuHwOQkhLMvUc+jim9hQBO29DMiVxwM74+kLNkHjswWjpz4r5gPKOknj83SUCXi1o 4UWAnsJR4y5LStlpUZ4Ft/aTGuZX1Br+xbkWp3p0QagJscBWI3OUqCiCEYjjSZc5BBUy9rPa6zOt 7gNAP/HAFYfsHL/GvSRmK1pIkwtLkEuj/ve18UxGg99SRYVHPLlJ59ALn2PtgZC7/pkl2jiAvW9z rJOYwztMjj/HTf31qL6lLQN5NsLoJE4wqVYYp6B6hULoLuyzgloBR/Tsrw3DhpfpLsQrYC3dGDuA p/fD0MsempqEPuuAmqYAA/xkGNJ0UUbKmJ0YMhEPub6GGo+uIZ+aTrgxhn1t2NROxybbw1quqp7v I7wsFh5MAoZkeQheaqL3uc1sQXhN5pu6S1oDC/EmiwOhL7jqGCjO0osk9XqWUfE4o1O6ChE/CC3E CZAwlOCILrQ/szvaz8GQ3muxNOGa1y7ccSvG0z6pPh1qQv+IeyShnWgC1FOE3IYn5eNu1vMJHdrk FRdjOv3lk9RoGPmWtkr5pCybuYDPfYGnoJOEDUja484XQdBWIi5vU4Yvkzb9ThzetSkqkoxwNC6a L9T1xdRAIEf2X468v4kLZIwAzlG+q4cutlkh2T2CjVFnvRkNQlp1LHXBT6FxYuRUuk8BeMQF1S5p 4UlS6ACBhEqP5jNBB59V4biHmq0TxX57+aqZl+VGFXZwuxndZ4JpQ8f63Fw5psK2nSXOlSQP2EvU YjAwMzLOzpalGy2hytbNmqBn1Fh9q2H7gwMCrslmfAooo59NnvVHzmBUxknz4cz3oJVp7wjMJ9J8 apRLYc2GWOgQTTpNZ8BWfQo8xamZ9uSYA6Z9/DDdmIOElvK5RAXD+BQuMouKQyMAGHgjCT2jgpnF EEA+0mTK+1HMJK9+318cJMplOkZEjCKwysT81QiUjehrkujc7iHk6YCXuM6rnMyNJCn81Hcx2xIY uqbnUZMMexnsOQ99F+ecBz0dY7WPergqLoVhYm9eXXCMVKNxQJ2yEDSOb9QG0v+OZtD+vD/85zO4 OUV8vwhy0neenzyKpBIISL7Gv4QQ4MP1drtUpdreUYUgdiFZWAhZqLFW/urUukvBL/CZ05O9dwM3 aOztabmj35O1e+MazdqNRbj8aJeBvn3fw65KlEWqWMXeibyicylUbAbud7S6TGVo1dyy+scjCdA5 H3MYfTL11orXNqS2FRqtzMvAt3sk0ROKTuBI4lVwZhU6c7VqvDdH1EtSwBeSZ5a9MMd1SCAde4lJ pZ6C46M0lSk+Gnf+Mugb8fcA0zyNT9hwn8BVf46/J+29BUB7ISiz02S5TCVfR7lbzpv1skmcbr1X xjleAC0o1em24x0FAX3RbKzjb6DSkOg+Dfjw+hoNvX7O640jZ3C8bUfubQ4GW3/gnrt5nxOmNi4r aWpg4AYIJUlHIQNRWjf+88ytt6GQzp27755OeQ3mZ9eTXwlJUAfILbLIRgodqr+F/zew032iC9PN 4kUUH8LzelaI59EraqSXe3swbiWTh+ieKHxEj94hxK1jo54C55HWLjSpwJcKf+Yuyd2OF6flyUX9 N9urslqpag2ppepFMy8WCqqtqdSjubq7+gY+WxqmXHa4p0VTW6FqDam2UtsHlziFSxxXzVjIs3o1 r8pFHebdhSqufB7OViuLGzxShTyJW0Z7pjLC6S4gvcEwICIpYR11/KDu9K5PiILrnxG1EOY1Eown OJUU7b4jPXeJSdzQPYEYIvghk3i6iDDDc7o+RgwZfUZAF4kFZl9Au1EXDNraTVbPpWNQ4J5ogckP KByesT/ogbioo57QDY5EEGrLqMNj2WtEshaiVbXYDpPPdBLOVwteZSEiFJbsISiXFBzYsfuJhAzp 4JN4i7t2PV825SJhv8W6wjyGi1Meu7JsbKFZW/9k38rsbW4DtJ25ktuGHbBMa8I9NqRsFxbFprA6 qNn1Ia0/c0VHE2Uv4Sd22o/o6QUtLp1/Jbwx5fxFUeKtm/+yXjW7bcMw+FV0VA4tkLWp2tMwpMe1 2AYUG5Be5FlIghZysNZA9yJ73umHHy3SyYANu8RwLNOkKH4/l6ubmuj381SoNXdjKvTKvpmFu8iy 4Uco9335HRcp7mWOn77j9GmaF9/Pil8PSoGSo+iSWwLXTv7H1VdLUT6y12OnJ0ZTk+aJrYW6fckc sJwtexYfR+wDOvH6h0Fq9WFQI+XsfaAB4vEZy/i81RNrdsH3ddydFCfL3OPcCXq2/pALdfZTvXwt i5zlf4vaO9aaDaPlOXb2ZpX7ufZwpqSv04xriwcVP9+Jv27M5+boFnH6zirngd5I1PvHDm3sVhGT s1+Cp6wGjJbvVBWmG8bYT04i6TmMo6wgxUmD42Wy3V7zGihnLjmnwB3SCpk+KlHypEMPTxI2VzjZ lrP0YkK4BpT+mypHMnvFQIosPd1vR7kZIdIsa/ptWDsGyGp6qE4RluJbR7R3r8LLDsTtqJ5nx2m6 gBh0+EOIIq8hEkbdYkM+4tT27EM9fO/Oxxi4Q4+2vgrfqtTC7jhAC3KWZPuTCM0/S+6sEJGKMZTl FWW5rAibZWkDIkMlYNBkKM8UdyZ7NeTzmeOCeC7s40JDVPlbxkXOoklFTZzKrmYQ6+ssOcDvKNY3 udGiIb7qFHIkvIFltS3mVxpqzoayw9fa/aELtEd2mowmVGPBKqsQu6mUcq9hsSG1TPNwS+BtCLZc OasrHBhn7+rlYXGWWfMbrRYc4Q8HlOxRJbozsQ+lrZGgMZMz/dJiwPKkpscIK7bmQRgYAq4bJBhI PzOi+KMuAFAwCfc5agaW2lDJUnEzkjIANC4kIAxDVC8NgleLTR+kV9jXkW4y1aBWMIkBIt08NVUl C0NZB63tWcw/SQRMFAROkEwYGEaathKWbCwwqNCZV4iNEO0eUZr1LF3b9wYG87cAAwBRqCy3CmVu ZHN0cmVhbQ1lbmRvYmoNMTkgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDM1IDAgUiAN L1Jlc291cmNlcyAyMCAwIFIgDS9Db250ZW50cyAyMSAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIg NzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTIw IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiA0MSAwIFIg Pj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA2NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgNDAg MCBSID4+IA0+PiANZW5kb2JqDTIxIDAgb2JqDTw8IC9MZW5ndGggMTA5NCAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIiaRXS4/bNhC++1fMkQogWW/JJ6PdDYoUfSRYATk4PdAWd21k V3LiuNu99EfkkN9bPmYokZKzwRY+SCKH857vo39uFsumSSGB5naRxFFcQyx/5i3Jc6jka11D87BY Xp1K2J30fgynXbdY/nKTwN1pEUrpuC6g2S3kW1Lm0DwuNoxHQZiUUc4gCMuyjCr2Jqjk520Q5nGU MjgFSRFlrA9iBt8gSLOoZocgTHMphHtA31/0UeCwC8I6KuQhLf6gvuyj75ZocitQwRfy4fjZyHBU YBSSelwUyhWjmbxU3n2WuhiQqr1cEY55u6VDIUuidUNCG9xYFoM+AVZblkYl49qk1vHRREEqujvY coxMtNB3EPzV/LpIoqouKgiTKMnTFTTXWJJclWSDOciMzorxTmvI2bHHFRKAe20nUx5ECXtSu7lK ivxAUWlTObtiJIpCa4zhT9eWU9WMoWE4WIsYTo7hmBQUrk0xaxE4egKkvdOHdma7N5sPRoUUiaVa mb8jR4GP4+jIn69Gjvy8vlFCCbt6a57wgbkZ62ErTA2aVzLT1mGlk2Lh41jIaouZsYq0kIypp5W9 oBxaL9SRjKEvHwKzvTYntROhbIyiSqadUJhOSL2RLJlWneqWo/bD3oZPZ3+IqA1loWxHovComWlC O1pDhf/Q4KELvR00d0Jx/W/tztD7rcD90DzQtyMNtMDi2J3eC+hRPVK259YD2UGh3joZFSgh7ADD 9snswNUeF32AwgSSTkKZ1ky5HemLk7pR2fxXnl7JY/GKAOyPcyfoPY3j0lS7ZpfVTOF2GnDbD1m+ mF+KTAo7uGay+AaX3pq4CYykANYB/FS4Zb4deimWicFDa20gr+TKew28tYbZwz06J5xxUW1GhSFU 7YCqZiRxnRQQap5cQCWUf8KYvz1v56vNpl+KZJWYUtgJQGvne8tieNTPEUkiJA8OwF5wW5nIsTwz 7BuWTSZ8pu0pU+OpnRbyPNDQwfPfS4oNdNJL3KVZKwjU24MKGmM8aSX5/OCNKNGUrD/PIIu5aPg1 9fhWBUqbCgi3ZtvvvVsPBYUr1g7ZxKh/iJx9ilki/Df6WbL+RsVbjRuhGiiPiIp3yIqPhiMcApdd vaVaZ7YRMuZR0PPXA1qATqgIC7LWzzDcD9wlHOa6lCZkrnzS1wRE1Cc0QbKAVBK/bZE5flfXuZ8M fl0ZGJIXywnrqHW+vXer/SJ0Cx1k+r6s7a6OrrxHC9lEdfvZOyrygwOijdSREFaHM3ETZ1KY/d38 pdXtdctG3hXXuy9wO9RUJEKeT2c64k23GudLDPduxEZIuy9HoDV859/IpZbcsOLZPjwTkkJvdfO2 PUwvUV5SHaiXE0sH6FYiujFev4xBJFC0Yy3XBmYq9puGmXKo0MADo+5qh3uAJVa59DT8e7JteKmI rjf/k3Z8zpjcKREX5Rn/n1S7Nj6+bhb/DQC+hVOSCmVuZHN0cmVhbQ1lbmRvYmoNMjIgMCBvYmoN PDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0 Q2hhciAxMjEgDS9XaWR0aHMgWyAyNzggMCAwIDAgMCAwIDY2NyAwIDAgMCAwIDAgMCAwIDI3OCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMjc4IDAgMCANMCAwIDAgMCAwIDAgNzIyIDcyMiAwIDAgMCAw IDAgMCAwIDU1NiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIA0wIDAgMCAwIDAgMCAwIDU1NiA1 NTYgNTAwIDU1NiA1NTYgMjc4IDU1NiAwIDIyMiAwIDAgMjIyIDAgNTU2IDU1NiANNTU2IDAgMzMz IDUwMCAyNzggNTU2IDUwMCAwIDAgNTAwIF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0v QmFzZUZvbnQgL0FNT1BKQytBcmlhbCxJdGFsaWMgDS9Gb250RGVzY3JpcHRvciAyNSAwIFIgDT4+ IA1lbmRvYmoNMjMgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9G aXJzdENoYXIgMzIgDS9MYXN0Q2hhciAxMjEgDS9XaWR0aHMgWyAyNTAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAyNTAgMCAwIDUwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCANMCAwIDAgMCAw IDAgNzIyIDAgMCAwIDAgMCAwIDAgNjExIDAgMCAwIDAgMCAwIDU1NiA2MTEgMCAwIDAgMCAwIA0w IDAgMCAzMzMgMCAwIDAgNDQ0IDAgNDQ0IDUwMCA0NDQgMzMzIDUwMCA1MDAgMjc4IDAgMCAyNzgg Nzc4IDUwMCANNTAwIDUwMCAwIDMzMyAzODkgMjc4IDUwMCAwIDcyMiAwIDUwMCBdIA0vRW5jb2Rp bmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9BTU9QS0UrVGltZXNOZXdSb21hbiANL0Zv bnREZXNjcmlwdG9yIDI3IDAgUiANPj4gDWVuZG9iag0yNCAwIG9iag08PCANL1R5cGUgL0ZvbnQg DS9TdWJ0eXBlIC9UcnVlVHlwZSANL0ZpcnN0Q2hhciA2NSANL0xhc3RDaGFyIDExOCANL1dpZHRo cyBbIDcyMiAwIDAgNzIyIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIA0wIDU1NiAwIDAgNjExIDU1NiAwIDYxMSAwIDI3OCAwIDAgMCAwIDYxMSAw IDAgMCAwIDU1NiAzMzMgMCA1NTYgDV0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFz ZUZvbnQgL0FNT1BMRitBcmlhbCxCb2xkSXRhbGljIA0vRm9udERlc2NyaXB0b3IgMjkgMCBSIA0+ PiANZW5kb2JqDTI1IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgOTA1 IA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IC0yMTEgDS9GbGFncyA5NiANL0ZvbnRCQm94IFsgLTUx NyAtMzI1IDEwODIgOTk4IF0gDS9Gb250TmFtZSAvQU1PUEpDK0FyaWFsLEl0YWxpYyANL0l0YWxp Y0FuZ2xlIC0xNSANL1N0ZW1WIDAgDS9Gb250RmlsZTIgMjYgMCBSIA0+PiANZW5kb2JqDTI2IDAg b2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTEwMTggL0xlbmd0aDEgMjAxNjQg Pj4gDXN0cmVhbQ0KSImMVntQFPcd/3x/v707XsIhIC8T91xB4oGmNiIiKgp3gwEpKKYHQzJ3yMsH elViwDGJj3ZMT+qjSTuN1cT4bEYn7ilaNEaTRlujQ2KN05qYVM2oNU1i1OpYp/W23z2QSP7odL+3 u9/n7/veORCAAVgGiYofzRg1us7v8QLlBcwtn9Xi839Am0cCpSpAr8xa3KqOv+U4xbLPAEt5o7+p pepoSy5gzWb6w6Z57Y3jriQ1Ao51QNrG5gZf/bEbGx7lozrYJreZGTFxEawf/R+mhzW3tLbFTLLm ATF8fuyNeQtm+VBb9hJQwOfF3m7xtfmtrxDblg9mfXW+r6Xh+PvKJaDsLMfj8i9Y1GrcZgnKOk25 f2GDf4Vunpdu55ietxxCavjegTQlEymA8Xe+r5nv0GzjuikLLTC+EF+w9f7eu+c6jKPowD7sYAjC Tgrq0Y7VDO/hHwhgC9ZTJxZhCbYx/ja9I/yo4Somw4/38ThJ4zR243kaACsG4gN04ymsN9ZSAqKR iiIsxEF5Qv7VuE5umg+BdBRjOg7I6zhHiphgSbEsMnJgQST+iG5RxnHHIwljMRXlqOWYdnKsx3Ge sixFxgU4UIgZ7Lkda7AVJ2mtaBDPim3yhGWmscFgL3xSBDLhxmzWWoTnsIHz+JaiKIHeoysyRdkY uhW6Z2zjzIfjCUyGC89yNsdwCp/gCv5FM6lROEWV9CsWpckYZHRyzI9gNJ5kmIaZ8GIpXuSKbUJQ bJUdoWOhuyCeKYkcjnos8jn/Gq5VNz6leEqlDBpOJTSDZtNm+rewiXFiudgm7kqLzGLIlVvlfvm5 vCBvKiVKm3LVGm1kGaVGs9FmvG4cNS5xTYcgC2V8Zi2egY+zeg7LsRIvcbc2MmzC69iOA+jCQRzC x7iAS7iFuxRLo2k8FVAjzaM2eov20+/pIzojnhY+sUV0S03WsO9tCpRipUJZpJwJIZQX6ggFQx8a scZe40/G18Z9ruYQrnkGVzQHHjSw559hPV5lj7uwBzrDIZznHfmSKxfJYKdESqZh9Bjl0CjKpQqq pBpqolZqpxW0htbRq7SRdNrH0Ryh4/QpXaMbdIsrw2UW0SJODBFDRbbIESNFuWgSq8Q6sVvsF4cZ Touz4pw4L66Im+KejJeJDENlpiyRT8pauUC2yXb5gtzF9TwlLyoK9y9OyVKylZ8q25U9ykfKV8o9 S7RljeVly28sVyxXrLDarROsFdZm66+sXdZPbNJWaWu0vWB70bbCdiACEVrEbuzl7Qhypg9dohZv 4GM6gr/RDpkodlGF2Em/pliZgrnyt/RnSyl+LgqETtPEIPlPWkyLkSTfpNu4jQNCEefIqeykzTjM m9Qh5oo2JY5+rLyp3KdW5YwixWXsENdNP9ZEZSd7W8z730ITGWtCC14TiTgltnEXfoI/4DVrpFjH fV+LTFGCMTTV7I34Fl/xdsTTJMzhPblPWy2t4g1aIq+JGDxF98UFGm9pRaPVjuW0T5TLU3SZN+8w z0spNYtxVIf7uEpb6KqYiWliJbYqTZaz9Dk5qdzSzPMH5aKcKhtFgngb37/2oJM3oRtl8gRq6Ze8 /d3CialiATbJd+hLdNJSpUk2c5RtQqGVvAu7sU+WKNGYgk7ZiSP0O/kXcmKP0kbz6WXDdf9p3LHu UN6SQUuuMtg4GfqMttNp45C4ibHGSTkz1EQblVTey6W8vQu5QtHYxfYb+YuxAxGMZfA+ruF5TeJv WyRvuZu/XGV4hm7xxqzkKuVSFsrFUMwVk22qNRGwDQcKJ1cVTpo4oWB8/ri8sWOe+OHoHzw+amRO tnPEY1nDMzOGaUMd6pBHHxmcnpaakjwoKTFhYLw9LnZATHRUZITNauEuErJdmtur6pleXcnUSkpy TFrzMcP3EMOrq8xy99fRVW9YTe2vWciajd/TLOzRLOzTJLtagIKcbNWlqXp3saZ2UU2lh/FfFGvV qv5NGJ8WxpXMMDGACYeDLVRXSnOxqpNXdenuxc0Bl7eYzwtGRxVpRQ1ROdkIRkUzGs2Ynqz5g5Q8 kcKISHblBwUiBnBUeppW7NJTtWIzBF1muHz1ekWlx1Wc7nBU52TrVDRLq9OhTdHjnGEVFIXd6NYi 3RZ2o84208FqNZj9bqCjy446rzOmXqv31Xp06as2fcQ72W+xnrzkcsp3JB8+sMiz6mFpugy4Umar JhkIrFL1zZWeh6UO81ldzWewrchwewNudt1hVjFlFAdihm+m0pNUg+YyOd45qh6pTdGaA3O83JC0 gI7p7Y69aWmFB42LSHOpgSqP5tAnpWvVvuLBwUQEprfvSy1UU/tLcrKD9vieagZj43qRmAEPIw19 sjAWVjex0ul95SQzIm0qj4GuzlI5Eo/GieSZj4Y8BGblsRpf1cRWej23YbYeWeQN2PNNvmmvWzLs mhq4A2679s3X/Tm+Xo41w34HJmoOR9+AsfwBrjud+ogR5lzYiriRHOPEMD0mJ3txl8jV/HaVX1w+ VHjYrDp/FNfc4TC7urqrEHVM6MsqPT20irr0vSgc5azWhdeUvPtAkjTTlCx7IOkz92o8vp0w/94l 6RGZfb84+6AEV3O+ToP+h7ihR146QyutrPGoroC3t7alVf2oHnlen6wX0xOKPDJd9GIiXYalPIm1 fcom4YnRlQz+WcOTXN9li+BRDHNIdet2b0nPszrK4fg/jbqMG6ZV+PWdWW+Yer6zPz2+H90vvJiA 5ICVTFFaVRMIRPWTufm7Ewi4NdUd8AZ8XcayOk21a4GDYrvYHvC7vA862mUcWp2uu//LerUAV1lc 4bP/694YYwLIw1JmgwVK04RHIvKUXCRBBCRFIAkRDCYpRR7yuIUGeSSUtqSlII9KCdhSIdUhQYEb hBuhEjrVFEbqYA0wI9rOABKSQNTBAoXw9zv73/9yuTBKO03m22/37O7Zs/ufPWfvrydhE9PFIHir Ro/v+Y4oG7fHJ8rG5+XW4JWaWDYhN6AJbfjUxyft6Ya+3Bq8hX1KqoWl3ErkFo0W8PSA5lVdnWt8 RKWq11AC1S4MClIyrysTVBjUHFmCkuEvBV8eX98z9OZYGu6tvf5J62jv63jVeCITl37QUi6CPDsw DL92UsQafsoHnvd0oTozm14VK/FuraQ3tEp7g96Fmo2dFMTYvpDlgxdqA+1NGL/O8Ive4GJgLjAF WANUAVeBcuBXGL+A57KOMPzC8EqaY2bbJ7HeJLOO3gaeQX2ycYamWANhRx1l81yDKAPyZ6DraauS 8iAvQv8ByHLBf0J7KuprMc9G/T3Ub3pWC4LuQ6i3QJ4KPXHAm7C7TD+MsX57mVYpkqAzD8jAGn7w LGAGxvE++rFc1NFjos72on8E6o9i/eFqvJ+KoKOJzwxnwvPH8lmiXYr6Ntix1SC7FXUCeuIFMBOv moPaTnsC9l/h7Buoo4O85/CeYH/Ipjvh2DgjElhzaSRu2XYHSqPwtp4m2oA3Az5gqHaMZhtj8P3O 0CjzHI1neEl0wjnlYY8XjSJa4iX7Ddj5prkX89AOw0+jjVfofv0yDUDfi9ZG+gJy0voC/6LXtWZ6 yepOB+BfOdBfDuyEzoXKF4poAub3UnrO4bedn14FeO0e7jnx2XiJKjyraTnO/YaXfbiSTgEnRJ3w AoT5pVi/mM+cv7vIbm2AnnEY8xzQFfI5Cn6KxVnV4Lt+Af8+BV1lIT+cfItpcshvw2AbXCg/C0Gd fSXegJVUCxwBPsaZrQFGov4UsBvAGOHF2p3gRz2Uv8JncA49lH/AN9j/+Vspn3X2kKt8TN0ZYWJ+ R+jZBOywdtJioArYgTENfF/YZ9lOVzffKfYZl5V/z6S3tEqtHe+TfSrMfPeI5obvIHzLZb537PvM mo8GgLP1NBrIPsv+5jKfi7If95HvRJhv7dWGfc8prqfZIV8vdZnvKZ9FmNdSjjrvAO1FfZoxnwr0 n1Gm8Xcq0m7SbnMAvuVMexnvTWuin3hr6SF8yyy0y6N4E8NTL2aYtXRJnWc9/Q48z6jXHjbqhWlW 2RdMEkfMKm2Zqt/B0RC1Th8zI7Lvv5X/L9BOmFU0DfVGs962sZ/1fCc8TaIPkOgy5AGgFEjyfl9s 8s4UQc9ESrCILlt8F3w0yPRRf6OW0o32iANE3SGfaH5KC/TVNNhooh+KUuSCehHraY8csJEe4rW0 E7SCwfrBcyP86Dafi/Yll11/jWaO+SGfUhy6e0vvwgPhk4JzA8dnlR8QoxWUv9ovhP3zCBWAn3T9 83Y/tesi/LMZejtF+2U0q9yC+O7eU74b7v45PnKM4xjJcQ6/NHu646P51nyRhntSruLwMcoL3e3f ABuAQvT1gJ3/xP1fzLEMa31kZVGh9S5N179NBVYe1mumqVYadca+L4Vz6rN2cyifprq5lM8J/c1u HjX7kFfFs/cpR8Wb9ylF5VHYxvnT+iO1Wh3IE5rbwvdQ3cF5lMm50ZhGG4319gXs4/f6WzhvyI0c +qnqIxqif24fMwrsBs6J+gYVg4qMl+2z+ln4Hs991p5tfkivWIOpKKyPx4BZxvZb79B5A3s0d6ic v9aNx/ztvSvtRs9p7P8wnTP2Y0wXOm8e5b3gDPqpPU1Sc7fZJazLk23vNy5QoVkDGaDmLLGbQueR HXkWyof5LKDTmqxy9iHzOPoK6WPPFMrxFGDdeXTe0xEyXms1vn8v8I/toypflyK/pVCR/iV8a5by xRnmcvtdPUjSzcN6He7dCvuUuQT8I4D3rhhxH/dHvTfgI9YuvM/4PbEBOb4b/daqoEXWB7TIuEqL zDMY34/S9RbcIwP1EXZDKG5n6hbkVxBz4d/OW8Z5z3hG2qesrWq9TGUDv1P8tFT/nHK0/ZSOWDLO Wwlfmazy9Cr43z+ASw7oz0B6CE860O5H33H46Itob9UTxGOob9TS6G9apdEBsnjOucZyet7IplS9 L+JIG7wpjtM2cY226PFkG0dpixGkk+Ia8mQ7+krfTeP1vXRDyT+gORiXoX1IQ4xNiN9DcIZl1GDk U4m+h67rH2EP0xDrMc9cQ5fMbpSCc9+ifym8DHGGGvVsarR+QVt4PR4HHIT+AoYxklLUvAgoW11E 2ayNpmJ9FP0c9n6Gevlt9sLWsJ1l9Jmy8S72KTtYL+bxGGMLrSCyTwPdHb45LoI73ANOR3AiM75p BecFaxli3gnEvkl4s7SlUui8TNQ6DNiPcbngZsgGo94LGIB6DGQLwdXgB4BpkGOM/RfIMozOuCtO nFoM2Qz0ByE/Cv4r2vg10lpHdOMi8ICD1gfB64AlwHpgBEAOX//Escf+AXgZZNB342XMuYJ2Gurl wDWgBdgKrMKcT9GfDIxGuxiYzr59x7vm/853z2f3yhy32E7wANzDhuicdM/sfs9v4Ojc5X7/b+KI N2gUO+fg7iMil35tznQZKvpEArF5KGLUEI7LHBs5Hqt4FGL1DnDiYiPnEPBKxMHLHIs5HiIWv4d4 uBy8AMxv0MMYs9C1a8+EkmFttNdoF3AIaAEM6oMyC8gHdPJprwVeSvMFQfmKqseOSy1lHvNUqmr7 Rjp8X5zDMYMc7pPG4yqqM4u5XVGdOshpJ/V12t26p5YMS9AqSGBhLuNR9gbSgRLAwOIV1e27ONNi HuRp26u/1Tk1/pC2HSO2Y952ZeJ2333obptlZXm0lmH9RRO0bVVliSrzVZmuyt6qjA/1NvLqqjyk yl2q7K3KdFVmqXKOKtV4cRH/zfhvwn+jaPS1pWRBUiQkiwQpfMnCJ0WNiBGxgUfkuqCI9fV/RPZK HC5TgbTEJ2QyWAKLk0bKFKBrUobsL6CXYoRGXurYEd++bRuvLyh27r+5Mq51ZRzFBEV6IGmMHBYj BiHv8nKPApsBI5A0X76D2YmqSZSoVQXk9ZSgyA7If8ugVwTkNRnUhK+dvCrPyivygPxKjpJHkqpk DUZtDsigDBoY9YekoFbli5er5NMw7qwslrPkC4mqa1ZXkC9WFmJSXlKezE0M8ipjE9UqT0io2Scz 0ZmRFBRin/TJX8q0FDU1lafuk33lfNlLquWSneW+59jWk2mf/C4We1itkiknxsXE/Yfxag9u4jjj u3enu5NkS3eSLMnodfJZsvHZliULCdsCCWOZxMI2xiRIGPEcXJiUxsQ4w6Nh0gc1fVDUkNLMZIB0 pqWUiRnZToLstA0l9DVT94/SSdtp6TAdCumkJs3E8aSJLffbs3lkpn90dfft7rc/7e6332+/3dNG c3/lche53AUud4zLreFyLVwuwuVWcLkGLhfgcgqX83E5F2fhTbzAG/gSXsfzPMszPMUj3lJYuJVQ 4PqILKxAMjj7QTJqWaCIpMjtEiEK8xTqQHkznaJSva04lb+6G6V2SfnZXrmAdT1b8hq5FedNKZTa 1GrPr1RSBW5hYz6qpPLchr70KMbfzoA2T50oYLQpXcDlRHXckTetTU+AV8uPn3SQfOH4yUwGWZ+N 2+Om1WJTe9v/EDuWpPIw2ZXPpNSGwxPg5fQ451nFQbUXqjlSzZGq3ZU/k+pN5y+5MvkQKSy4Mqn8 6V5pa3oCX8avJtsm8AjJMukJuhZfTm4kerq2LZNJgWtUHND+MsFdJhng+HdQnODg2vOOimPwIk5W cUC7RZxVQrKKk63SZ3BuPEJwNSQDnO0Wcqs4t+3WI7jRSTnZNirL9/uaVDGTi33lYyrE4wGI16NC YKt4VIgHUyqk/SGkbglS/wBSr45E44cYzyKmVLqPKSUjKf9X2tOqKMl9hCsb0qM8as2s3bqYW4WB 1arfS8tX/9AxiX5Pv4f0Siavk1vzerkVxeN2RYjhAFuSZ0HFwUvQLV77MQd8EeKLKroE1KVLTXVr 6taQJmAvaTKA2rjUZD/W4nVM4otLTQKoRRjjkXkePDgECdmT+9oePINLaWgpP4hS+ZreVD7esyU9 ynHJfGJHWwZ0Dfd1en2ysHB1UVkPyhhR0vQD4AOdVrsEhNV4o7sWd3twFKaQUQZhKjDQoyt4cBD2 Jtl75NSEH0RxDnWMUvhNcBoLX1TRMaRhCrj+NRrpOFJ4HaNyntWQdgrReO24tu9nsJizsflYlzAT 65yPoTiUhTkQwQav6BV9IGDHozmJvjqX0KBPkcRcJSN9f+GmJqK5gSrhlG3BTOL4DmlAel56ueSM rNkrY9mHG8Phcp/PodcHdTq/5HBUQG1Zo14fQsGgLFc4fA6Xr00ftADA57eHwxU6vwWQyCFZZI0r qAv77Uy03Gdt1AeMfrsurG/0lfOu2go56ECSW9PsctG1khk3S7Re1lf0uydcuWAB3x1nrV3LC3h7 oiTQZTwQ7WLLY/sH7QrY1zk9Az9hZmb+NpBoOj5tagqYbE1ikwgSi6amJnhEm1odNtQrzwnX+eF6 u8JDAQu/GRYM1znBECP54stf59VSsAFl8YGsj2XlCv+KcCQaifqrSCHSGLKWWVjOaotEbSTj/Bha V4T9cgVbZjH7q1gOcmtjiP74ubHP/3qmb0tyOKw3bHt1z8mRF//8lcOPt55rHVqz90R/8bun47U9 ze1PFd/ce6K55+WB753qf/y9sYNjj0VWDVatTGwa2fWDod1v759+KXOo55vHe4f2b6aPpLojK1t6 DnRtn5v96FoitunpZ85CsIYbN/4CmgIflr+Bk0hHJXEBz4wzzXeACjPTKD4dbGiMNnLPKlO1U1PA LzQEwsP4VX4tT+hRErOaJKP+kdo2xiY1BerEON88SKg0rfZA+sDQh/pWK7+tKT4PvdGZqam5H5E+ MZpcuKv5E/DHgc6Pn+GxGY6acaMYVo8cg0EMC5IghkWpVAzbiSqoF8OM3WKn/Ja40E4fEhjBYLGW lQsmY5PhBT1uypFjiDHV6enyOkaLjsLUdiYsxqMGa00DhwMc5sJOw1pXeC2hwh1hJnugc1q4P1kg Qva2MD8jAgOwCQTMPptVNxl41sYiWUKiYI54Qwy40C9LHCsSr0WYG9e2Fl/5S/Gj4q/u/QG3/BN7 bVdcr58qfngh97exl2YpxlEszuF23IC/hem7n9wQz599/3fFf/z93i/JuvbBvh3TTCIjktALiQ6b BEY6iUAWydJgyVsYIzZKFNyCnB7scHqkAA5I3DoNlgTBjTB87mCP5MW4mqLMTYK32oj4ZTV8T4VQ wFxCNKIAjNHuHcAYC6i9x64ElFgWw0bIdk53CbOdYHtMmUe340pMmEcxzbBKeZXM2ewBRWnE3pDN TZVZKBZoKvsaQ1FC7Qjhb5Vf9vbhEJ48v+nQpSefGvnpl3adKv7x3bNH1kfWNa/v++KOdWeK85pJ m+f8vRdHizdvPue2XXCZ5LqOXZ++MvaWxwbe2gj+CoH1GjSUsFM0vWQRVY0phvZWaxCvuQZBa3nC wVGUlqaPwtUOaxetQu2sFoyytU/g5Yic7jGsHOkS/o3tgSyUA8qRTuEDqJAyMfX2oqkxMHVYs2Rm IwYDuY04dL34AfUfWTP5yb8uEK9sWXiXiTCrURVagX6e6Omrwz6dTy+X+GqbcQdmA3wTv9n7OS8T rq3RM4FqfyltRD63XK3Q5lJdaFm1otTqSiGSlVorPTZs22j2LOP8upCH1tvSRiu2FvDbCXdAYv0R o+RGaUEekCl5wZ0QTWHkFtxPu2n3T6hDKIr8IFW2ZpXO2SywlcSweSgRzsan57O3SZQygDGIBC/y kihGwhc8hMIo+zAogeMqSeipIrGHqyKxyQbBiaMhANlkvxl8bKDUWBSJ0MK2y7tPv9bztZ2r8BMd ZfXxw898x3tl5YcTvxhMl7c4rVeMq/yb+899uXXfzi0Xdny1JzUynPl6r6nE4OoIxitDe7LCuYvb 2geeGCh+fKw7tC2M7xgFrUHZ1rR+1/ZLZI3bYI0fA9+bkYzmEv3LJNjxbiIYb7dvqOwb4o/FCZFd LgZ8cd+6sifL+svYI15MmyxlFWaYpIl2VtKsx0xRMtxN4doOpEF0pcfDcuZqpLN7jHqtZIo7MXIG nHFnt/N9p8bpLOC3EiVIC5tFS74TzOb/cl2twU1cZ/TefXr1WK2klVayLSRZsjCVEwGyLUwcSwYb SAgxj9qIEMcOmIdxjZExYF7BCc8EQ6AJ9SQ0tcnQhiRTyIAdy2SoIVNIDE5wZzLp0B/QTt0y08DA 0KbTgVj0u7syOJFGe3fvrqS5557vnPMlcVHMKUxGOISiqBLVkoBQ7VeJVb3iJ6xqAUr9jTBKUukl nSfnW7R7CTDrM+uywalrlmB1d4JgpKMjj9lGNghrvvJH8koXGamxMJ22CZGGjZrIW3l1DyyaSfBc OZ7a21Td8dyRL+ZvfGXX0w3dT/ysCb/2cm3Xyldrlx2PTGLPjv6nsuz6Nwf+1VUbam4ZxD05+w7u xpmb9rzd+d4GqLP1gLUd+JyFOmK6YrpBXpXVyTGqqlaBxhbr9pupF7MapG3CZumdDJaT7fIkYSaO U/EMzuQXF+mxfzKqQ4dA/kFg3Xre6Wb0KO4BUaPwXdHu4QPZpjgSJZES57qmzSWU/a8qMeC4IDY/ ktgRVVlrNFnVmGnxk+UTWc3h0gSkvb3lD7p//+c3MP7tx1+exutfaupe2haPH8M7rV9c+OvgSTz/ 1IUuw4qWN1I3X9u3bw8w6hewykFVS93oRD9ygZ3A4ixklbXAK4HmRMblpBsMSeOnIm8XZdck3meb LS4WOVnBIezV5duqdSt17HQ8VVdim4tn6J61cQ6TyaDXy4IBZbkF3iTqZDelNw6JccOQZKo1NZu6 TYwpif2feiUPG/AE+nEuSmcNFYQREjVuR0vgAwwIQVjYru49iQuw+7lpBEgtWsPYh2W7naisuvci RUtHP+wc7LrTdmlFW0/q6w9Sk/PXPLu1fs+u+rLGhjnvnr7xzee4rHuAeur+LHyuub2q/aP7rxyc vv9bUmFrAI8y2HUnykHn+5EXcBAAEDexVTtBJU5Q4fJy9jv2OxmHc3YmxaNe50UnHaDz9Zsy92Yy iDyLsjIRbcFmkwv5JVwHHQOW8Hw4gY6DycrMNx+ydFsoi4XxuA28AsywJKlfxrJkT0bA5/KYYoqn AJkk0zrTDUCq1B8o1egR1PihwaOSg+TO0ZrEiBbElOLBIKFKS4LYMHCFAaQekUXmvVpsKsLedJqi 538SSN05t/HiqmMYHfnD38Uf7jGvL6/pSfmpn+N9ja0DuMGy81bT8O6TeHbXraHnF7qdR97bgrdk G/Yd7oYqqYFQOxPyiB1diq3xQWjBk/TF/A3rDZl14IClyEIzIDGMjbbY7HYznCPWoDfQekE02+0+ xIJ1sZUiFj0Clql82gqIMDRnBzWytsp0q0RhytJqswl2exwJTCs4WYgkliQl9yjClQ5Qmy3SvTH7 GoGLMfsagboJAUxEUkok8h4FOiWIsIxJv6VYGuRZqaSEhw9BLQHKH7b6IuFIKQXU4lUl4cO8j665 8L7rfbcjvH55xU7vi6WFEdlx2XX5Av1uR2eivsz1G0fh8paOH1YSBhWmFjO7gEE5KIxd/SigVdSU pDZOJRyKEsWeIk+hGEexUBVYEWgvZHODkwupXEuuLYpK3IzdbstXFJ3OmWfMczidPp0CzqhgP0IS /EWSOhgLG0NumXfkKVye26jj3C6TwyE4nXEBngO0BGWHgt1KSGlXripMrYIReGqSyu0RfB4JJfHV WDbledOLvRelQFSHkQ7rCvIUSafoCnSBWoBVKgEdD0rnaxL4n+Cd/5BGg1vuQb5pwU4Q8LSMD6uD CjlMOUPIQWipYn4b2KoaLQtoBwk594rQGIyFfkJPReHsilq4kci4io6EaZHSaGuVFftjVRep6X1U Tu6U54/PCeVZDnQdu/bxre1/Svh/962v5cru9v6lN20TmsuXfNJ0uHHGtsZInbm01GyvKh6ofvP2 tTM4/51LJx88/PDc6hk7FjqpRU2ReQu2Y27TzqOzD18m+/Y0HPyghJDWcSim+4C+RN+kv6cZARrL 2HOhaQWVQrswLNBuISR0CaeEAeGhwEGjyGCa46G86TyK530MlsnMcuKsHMvxeZD3KYHn1zKCBIES C8Bv8oMO+MF2ZpihmJjeVMBsyAD7ZJTq0nH2GUwEAVjwyF4mNu/JqPo1IRqIMrHSXPXqzNyANiuW eWFWzoODxafdck3WxuyQNirpRwWZPOqaqF6ddnqjwfGvJaRyasanwHQBkePttCmTzeTZcVUTTKj9 ijVM44pgTzBVfr33OnP7q68eWJnAg7+QrqUIsHWp2KZiVXUsrmTb2WGWzsBuNsR2safYAfYhy0OY 9T0Ks4gGDVAD7FokWDTo0AC6iqh2NAzbFdND7lvNaKmjdgw2glqLBhqKOSxRNAYaIqCpV2J2BK4A LETAIlNnvBFtBJDQGEiIgKTOAkgojTYZ+8rITZ/lx8g9gu4nyI0LzoBUCwnPRZBMUl9Dbp4FyJRD OCgGtVDQndh8P1/IUz7Kn1FEzcqophYbVlKbM9rMH5kHMj4zD2UMmkXarlAMR1OKQpDCMakY2hQA TDAYfEZJlmCiRcJGo2SFTEcncSpmpijM5RkUoxFqHElGSUjivtOGODQ7fTFj1IglY6Wx1thsZIyf UdvB9yh89rQSh972bMz6OOBVO5BiTPNTbYXAokk3CEOQqKsqsiXBaAlySiOgArBqKHGitHDmgNO0 5pIgp0XssDXMpyMcT/usaT/i6fLrxyc2nn351bcy9/YesD1Tsf9aeBUT6G+q79jw1I7R7dSxZaHC GV/+O2UBEtSDWy8E9EToBNv6kRm0dRFoaxaJxBMFXJezLofi2CybPIFeIr9gq55Q7W621bm5mSxu lTbKWzO3TOih2Ww3w0NA05s8KPZEqAAFvE4P4iV+HU/z63MCK8Yls+A8LZYRFUuQdg9WZpUi2jIo 1WwjxGBLqUdppL6v8/vz372dutO57Upj76Hm6S3LKmzuw2urOhKF+C0cGTpxd6gvdfHEms8P/+po qG7r7OVLD3Ut+PVVKJmH36UamDmwPjPyovuxnAp3NfOS6QVbo4mdbit0VzDzTM/Y2FzmSVPQFmFK TKyUfHg3tgAWn00QWOJow5sdr+NO9D8v53QEDNPwHLxKWu3gMrzYYqZol0KZzemSkyTRBZyByuMU 9//Zr9aYOK4rfO7cmd157GOWXWZ3FgPLGpanAQXMw6JlKbZjsHkYywSbUqCWcWhdPxAmJsgOSGlw 2rTUJsREchSrSXHaSpUBY2MrEbZVKVSu2rSqqkZVqlR1k1YVLY3In6Jdeu7MYKdVGlIpyq+d4Zt7 5snec8/5zndciicHXFIoCMHOIBec5zKimawDkDweLMPnjGxUWR3eI0E4h6UghOV7X/xI2SBmWej4 j6xYLxvLHTgumQliiX4PqryHmh+jBIPEqBIo+jooeRAqHFO/2dQqDOt1IZmUXEnvGG+ZXDx2+dXW hd7T0x69b/el2yNdOwYOfyneK7zxfPfud34xFf/HVOPd2AKte6Kwppl03hgdrzv/azMLaTv62Q0r 0SGJPiONi+cl3ubUnFPim/xf+X9RW4TL4StIGbeLDJJnid3l5qjCud2W9yQU/YrlPrdJXG4U91GX WgoSoy4VI7SYtQJYv7vgBFLYMmaVmV8UWlWDx+7dJFXwgMo+6DCapD4ks5sASEC+DIueXH5kIKdm 0tIWvzHOpFmMZBARvp7/0OXrVGSE7rqb172MQbyeiqbioZiCl7e0vNRS1lRfVNG5WHmQj7w9NJD9 Wvg38aV4K+PzRsw7iv4qgA/mlDw36uP5td/O4kiZvNHRmHBeyrgUpgP0Sf0FZcLBKywgQ0wE4ZjB ntqOxjfptwOvKlNOficdVM4pNM+RmRHeXOHgQw6FpobFMI488WdqLV7IJCQ3mO61C+m5SmooqhK1 nxQw0SyRthDrRQlThVF1SzoqnWUxBFlqFpe1rDGPeTJzS0FTNe5djWh3ClvvmCl9Mr9hpSN2vwPN viWks5MPei7Wcnn82HsySY3JbgoWo/XM95Yb7Qbmd3YkM5vJFBaafrMTS8bAZHuyzwjUyP654pHW 06czs+J/zKndvnht8Vf8ND986iuPb0k781ZZa/ebo/MjI+TrSuOxnV01RXl5Q3ru8V1nr9286Og6 0frII5Fg2cHSfU80Tba3txs96d+5C8JrEIRz0bx6d497wD3qnnS96L0iXd10e9NfvDIQQkF3Q5JS 4HHY9HSquJc9WAdm1P6kWyQOXi5l1tcmOea5lBlnv/I6l4LBmgISOknJLMBgVaUxiUrz3NhsSsVs IJ/1HCv3V9Af7Gh2ZSikPYZ4ZtGTZTfmubW0nAlnbzllctnsMsjf0mq+cDRaHBwZSx0r/+XembTp IX9WXtX4856tOTs2n+V6nyPCmfjZ52JzJ7RQGOc3jHE1wEewCsWjp3RRlyaU6/br8vvJfw7YJVGS nnY8E5iwT8g/pj+0idlyeWDAPiD3O04FbAWkSK301Hn4ZD2AxVHTfRrWwqdwuTWdFUdB9InFWBxF IggiiLomiaic3diW6gFZCOZouiio/jaNlT13oK1aJ6repHfqx3Ven+fOzKZghrOKuckRKhbIW8K7 wrJAi4RqgRN0v+AXgnLFHYv+GlnSNiytLLH6iINRH5ESmYxawgpZVWVSHCuQTByPohFgKelSTXWM jGd1uOWoqayOrQxVMp5tpvrC4tDF8PDcd5PqHt1zvjdDS+2a+8OV27/7Tk/tK9zh2IH9RVW19Wdb y79F7qH4IvB9VBiD6FMZXoruTsqmIcdOOepodjxrPycNO35ApuQbRLEJgqzx2XIFCLIklYiCTxQF nJvIlRDwocSQRJEJCRlkqQ1EVeTQG8koLtpCpJgsE3qcjBGOrCm3SAN3Goy46Yt92LHEJm20X4x2 REsOWHroZAdS2zVRTvKXkvwDGbTEq/nLylEhkeafXG13a6V7yaGF2GU+ErvR9fbJC9xTxnwgvpc/ g/PxwWR0X0grVqKOqDYqC5JDcWLbI+cpFU6bKEpOl8sOJBm8RKRuVS2xu3x2u8vpku0qdYpul0uW JZso05AXmVp1EfxzyW0SucVdgGRCp7G3VO8XLRUhNbCoN2eRVOmpRFYwls9YPLOPNK6o/E/FKmNa nnKrqzGmhBNiXKBUbC0PF5Rum55pDnjI79+ItX918lB1vOdHqp7R/jifG3v/5ZfpY6sNV/vA2vo3 Ble4Abr+T1zbGHQeI+r6J0No/OxhmwEQ0wAkHkDGoqtg1XZgOXK5TLi/9hDq0yY8dwGSMAN8sonk bQAafsd/ASDwHoB+/SGClxJIIIEEEkgggQQSSCCBBBL4PAAcEKPv9QFlFgkibLDhRo2jZJ15PnIn dd2IZFtG0cd9YPuOnY/uqquHPQBNsLdlH+xvfaztAMCXN/7fn8vGwzAeg6DiVGUIQQQKYRtsx997 BHrhKJyAARhcW8Nn1u/V4r1u494x6GP31v708bvl8f+1oWvX/vmJT4jQY32DghePxPrFXtxN24ZW hK0oL+GVCFRaNgcu6LRsite/Ydk82uOWbUP7Zk1DU3N9bX5NX2/30YK6/u6jvYc+3SWogQZc0Wao R4fk41kfuqQbnVIAddBvWL1wCFrgMDryFJ514xOf7p3P8inTa/R1PFTDQRDQMyoG6n5MiDxcVYrn 6BTyPbwj8mixs/URergkfP3B9t/LU40bRDEuBkX2mZ/bV+mktUrce0cKV5+s7XRXfSjqovH0K313 F9g497Opi6vvxI6IV+yrwFKLmGv57wEAEXT3oQplbmRzdHJlYW0NZW5kb2JqDTI3IDAgb2JqDTw8 IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgODkxIA0vQ2FwSGVpZ2h0IDY1NiANL0Rl c2NlbnQgLTIxNiANL0ZsYWdzIDM0IA0vRm9udEJCb3ggWyAtNTY4IC0zMDcgMjAwMCAxMDA3IF0g DS9Gb250TmFtZSAvQU1PUEtFK1RpbWVzTmV3Um9tYW4gDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYg MCANL0ZvbnRGaWxlMiAyOCAwIFIgDT4+IA1lbmRvYmoNMjggMCBvYmoNPDwgL0ZpbHRlciAvRmxh dGVEZWNvZGUgL0xlbmd0aCAyMTQzNSAvTGVuZ3RoMSAzOTg1MiA+PiANc3RyZWFtDQpIiVxVCVCU Rxb+Xnf/MwjBCznixcBwKYMcQUQkSoRBFA88UDCHDCqXIKMSo66JGuJR4JFYRGVXSVyXYELWDCYa Ne4G3eiuV9B4u0a0ovHY1bjGWG6J0/tgj0p2vvqnXne/7v7e69dfgwB4YykkssZNjI7Lz8yZB/wm hHvHTi9zOE39rN2AjY8B2jx9foXlR9ulZTx2GTAfLnAWlv3pgz68gsfvAFNsYenCgm41A+cAiYmA vaZopmNGy4t9Knm9Cp6TUMQd3X/o/gjofIHbIUVlFQuahvsd5XYb0DOitHy6g3ZuSwBeP85tW5lj gdNb0K95vmJ/y2xH2czkSymbgdrPmE+Ws3xeBfPmX21N+7hz7kzn9cQa5tKP+XfxMdYCxmgE8tdb 1qAXoK/xd52/W+5Rus2YBau7RF+VPjz79//5gFBswHsIwX2KxUE0YxQ+wAvIQg1GoAWfoDMW0jEo WJGG7QilQAikw58M1OIiXsJc3MBVRCATV6g7r2OHE34YrG/zfyZW6b3s5YlU7MA+KqWJiGY7Q9go kndep5vhjwh9Ql/g1hbcoBDdhAy2vkc3hGMJ3kF3lOCobmvPIPLRQIvpNoKQh2oVr6r0LAzBLpyl TLbGYKFxodMulPKsbeRPzbpV38QfFWEmr/QmVjHjnWgWA2Sq8T4sCMPzGAsHj/4KF8mHYmWKDtfD dS33NuCBiBSHpZl5RGIkpmENtnI2zuE6fiIvGkhbqJFxiu4Z7aebiVexiOtqC2evAR9jL8VSrPAX /pwtf/RDNo+tQz3v/ylOUiblUjMdkPVGjHuY7qF99U2t0R85zPA9HOA9HlIM+/AOMlhWqL6qwoh7 uowjnIHNOIlTzOMK5/0nPKb+jGviDbFET9Hb9Q3m4oFAJGI8pqIc8/EafsunehBf4R/0RHRizxZ1 yFhk3NfrObdhGM7cx7H3RF67mk9pJ/YwznGU3cjCUSTSWJpAhbSONtAeukgXhUkEiTnijnTJY/Ky SjAMncQr+aEv72vFFBTxCbzB2V7P8W7HIRwhXwqjKI7oHM9/JIaINMY20SKuyOVynWozVrivuv/m fqKrYOYqG8F5eBUfcRZ+ID/m0I9KaB59x8zfFp/JzrKrtMqB8gU5SebKVbJG/kV+reaqRnXJGGk4 jEazwz3bfUpn6rc4FwQT8wqHDfEYxPVTwNU0i/k5GXOxGMtQhbVcL+vxPho57i9xBGfxLf7OJwAK Ys7FvHsZV91yWsuopY/pAB2iI3SNHrVDBDMiRIIYJlJFuigUyxk14qQ4J27J3nK6XCKXMurkbnlR QSmljThGhlFtNJiOmSPMGeZ8j+Ntd5/2f5r79Iob7p7uF90b3AfcN/VkvZD5hyIKA5jpSmZZyzVY z/iIK3E3DuM4zndwfUCCDK74ALJyNdj41IbRCBrJGEPjGdmMKTSV4aB8KmIsoaX0JlXSW7SG3u3A Jo6tnj6k3YzPaR/jLLXS93SHHgguYiG5mkNFuIgWgznSVDFCjBMTGIWinOEUc8V8PqEG8anYK85J Hxkqo6RDzpG1coc8KM/IfyqhbCpaJavJqlBVqhZ1Sl1QT4xAw24UGXXGQVMvU7wp21Ri2mT6xHTL 1GY2mbPM+ebF5jNm7RHKavVnjnsXfv6LNrXQPKOHWiBa+V4ESKexkrI5YyYxSZbKtfIbo4DuSwtd oipZLGfpbTJdPJblNFl8ScEy0EiSBVgNTY3imngobipfmiRuU4R6hz4X5TJVmNo3MU4rX1Vp3ALE eSSJ16lZHJKVslL/AUlGHbUadeIULOqq8EEr3+qVYiNP+loUi2rkqHjjCYo57x8aCzjfQ8Uq6i/P qDrckFbxI92nDawaJ2iUChGviMHUyIr7lPriLs2Bk95FCn1B39IeEG2XDTRaPMOn5RLeNIgfoRMy iM5IT+S2c6Qw4UtZ4r7IlvtNJ+VAIlaJb7CIJMVw7fz358ZsvgE1Ipw1zc5qcpriEICNrPcP3fvb Fdu4YFRznW2VNkxADF4Wx5DEd+MGIwcrEId9XIOrECM2YbFeSjNY98ewfgrsoRJEkxerpT9zW8Lv hZ8IZi2cxrs+Zv0/yqqfSffwGln4ZjUjQrWPrFZ2VqY81t9qxgy8zK3NWG/aZZzGOPIHlMVdx1V+ Ga/wm/Md798TycxvKrYqG7O2sDLP4Rmb3RlIYazAMRJ4nTkP5XuepTJYeTfoEo6wmN+o0fwmHkGx 3ohUPrsJulJXY5reql9CISbq7ay/8/VOJGClkSsmG5EqnjX2CH3F79FfqZp1OwOXWI9CKQB3GDuY /1DjC1Sp86ydw/RqfRa+nI9gzlA+v6LXUYZ7nLcM2Yzn3GNFk06XTn6hWjFeN+hA8kSRLmXl3Y96 s8HasxR9jXquXaQMz56UMmzo88lDkgYnDkoYGP9cXGxM9IAoW2T/fhHhYaEh1uAgS2DfPr179Xw2 wN+vh0/3bl27dPZ+xsuzk4fZZCgpCDa7NT3P4grLc6kwa0ZGVHvb6uAOx8868lwW7kr/pY/Lktfh ZvmlZwp7FvyfZ8q/PVP+50ldLclIjrJZ7FaL60Sa1bKHpo7PYXtNmjXX4rrbYY/psN/usL3ZDgri CRZ7QFGaxUV5FrsrfX5RlT0vjZdr8vJMtabO9IyyocnTi00vtlz+VmcT+Q+lDkP425OaBDy8mZSr pzXN7nrWmtbOwCVD7Y4ZrqzxOfa0XkFBuVE2F6VOt+a7YB3u6hLZ4YLUf7FeNbBRHUd43r53PyE2 Pv/w5zPkjscZ2WdjfsrPmQJX7LsYTJMYG3PnOs0ZTAS4Taj4iWijYBTxkwe0JUkjgghCqI0QbsOz SVqbSsioilBa0bSqDEpC25SEtrQJRAhaQSS/frPv3nG+0EKrWv5udmd2dmdnZ3b2yWVMd53pkcsE 1vFuaE+gt2rQ2Nvvo1WpcF6n3tnRnjDVjiSvURjGuvXmuG9/PP5OF5MX1SV2ZUv9qhEbvy7AXcPY FTCPNCWypUH+TSYxhylC8ZQRx8J74cLG5gDWEjuSCVPZgQUDvA/ek727NXqMOan1AfMBfbG+1lif wsGUGiYt3xrsKy2NDlgfUmksYLQk9KC5yK8nO+rLekvIWL715IRoYMJISXVVr6/Qdmvv6IJ0Iy8/ u7EmI5MtOZxbjcszflXYIn0JwsEMrA7AkoSOPc3jnzXzyFg9D8Pwl1SgZXbiPNaZD9SlDF8t+D7W N10hnx4wbhLOX//0k5GcjjTHHfLdJG5ylGQCDXKnbYbDZmUlB4inDicKGxfK/uzqqi39wtQ3+AIg cB89Bt92JGtr4PxgkI93T3+UVqFjdjcl7H6AVvn7KFoTTpoixZJBRzJmBUu6HUlGPaUjjt8k/r4Y Y3rLM/8FvrHFsbW1pjL2P4jX2PLGZr2xqS0RiBmptG8bW0b0bPm8jCzdUmwBHG5qIXhqiY7QW96W YAb+XaG4HluXakCqwUazuC6h+kXSbgm/KqdC/LZnZuZOIo/n0kJuGf+d/R4vAlhylEDc9KUa7N/k qGDwPpX6rc9YS5I7auk9mbXhkf35I/ojzMszVBislYvGljbDGDVCFsdlZRhxPRA3UkZHv9W9Sg/4 dGNATagJY0Ms5Rx/v3Vqj9+M701iE2uVWoS2oMW9urK7qTeq7G5uSwz48Im1uyXRJxRRl1qc7J0C WWIggPtZcgVzmcmdAHdQ35AVfcIrx/sHokTdUqpJhuyv7ldI8rwOT6HV/cLm+RyeAE+zeVHJ4z++ KepaEtkxIBMrWS0fAPhCDQ7HaKWPPt80XO6TnOw/t+GOKGXcEg7wwlbraQc+NkPAN9zHqcEdwS6+ RU2QtQDTwN+vPU8hjH8K/WbQ/SJCKvhLgc+AKqAZCACrgASwDHgWaMJYE/guz+FA3Uftnq9Th+ss +VytNBlYiraufUSV2kYKot3Afaw3S51IlWhPhqzCMxFjz1qXWY5xk+W4VuhtpG7IF6L/IFDk2Ud+ 0AKgGPxSzHOMbQZtVM/wXq1raG+BHUvQ/hw0DlvrQZeB/yjaC4B86HxZRKzVaBeivQC+KUQ7D4hB 7xbrYHw+bOyEvAR9wWOxbj6on8dizgr1guJXDuJNdYF6tRYqgXy0BPbNe3b2xPazTf8GcbYvG7Z9 EmyruGPbFyBysEadJc9qe3qvh8Q52qAesa6jrbtLKMbwXKBJ2N8nQETrpAmeidZfYeMS15s0G30v MF6C5zxEO9UbFIUs7H4FcdNJC8UMCGZbt8V3aKI7RA9jv/A3TYXtSY49xMIUjGuW+p00SbtMpWhH GV6iP2f8BN/g7BtB6+D3q16yPsUcdQzMMwCcgf44rF/DPuBzV1qHezD2CmTPABsRIxOAcZDvkTEM HdbHOl/hNexzIJ+MQYBjD5jpIH0+Dh50IP1/XGIsMA6YC/C6rwA/Bx4BXuYxmHcsxk+CHc9xzHBs cnxwbMj4RzzJmOVz3AjfcIzZOfMj8STtBkqAKnyU7EyjEmNlvvA5ss2cCzw3xxbHjEMhL7fjXrnG ++SYyqK6q0quLXOQYyuLVnDsM1Wjcg8VYpDmcMzavnaotCHG+cg54VDHHs5PmSOgahcVs+/43B3q +CJDj1AIsmWu9+hhbQatVN9G/Lej/RjoXPjnsMzBa9oP6GOxg4RnkKpwlpy7r+bQAwzPkLIe8w3C l+XaOXpV0iExWRtSXK4e64qrRzxnw2ln01wog7aMKSNb9t/y/xeI864eehLtv7mGLEsbohexV/L8 XZkOBBwKfh/QDVR6w8oBb5fS71lBPsTNDeBpLYrv1yjN1QZpkTZG5l0I/BWYu0brovnQU/Gl9oK6 go66e+hL6hDOEWuJ8/Q8g+cH3ZCJo9yY+2IsSerE610o50C+Q2VORaw/yLyKWH+UORmxhm1KEa4N fD/L+kDybi504jUTl69RuXozKz5z4jQrPudDz5cbl1l0NNN0bcl38hQ6Y7nW8P7l/dgq80nec5D1 OeNzaUb/OPWL49YH8h4+R21OXgMzgBDkv0jfI7iHcd5cM/dZ7e5nrHZ1qdWOff7UvQv0unVSTLV6 MzU1RDPTd1mpU0vZT65zVJapoyF6NH2fhbieasdQw+06Wizr519ovOu6vNtmSns5DzkHa3DvTUUd /4d1Wyuip9QXiFTkJfMRI00s07w0Rv0T7tyltEk9bP1O3S/voJg6TEk1jByGLnw23iWozFVPjdAh OR+PAWUe2+/WEJ98FzSgj7Ny7mU+e/dtygemuq7iPmrFmONyryF5jx+gKewHqbsZdQVzecJUpAkK p8eEpM438V6Q/sAdmOWLdG1eyHO6l8uYLZA6s6zb3iKKMFyv0xysH5JrNVCtN0LlrlbrqnxXFNEj 6lmarjbQQ2iXyrjfhRpVgXrZgPoIqB8Bw4hNn92XtVpS65as99tkPc9z1dBK+Z5gmZsmuStoGkPT IUtRtfo65nkacXUb7TcsS74Pfk+FvDb48fT7hN8JQubLb6H3DlVzjrENst6wPQcRb+/SQ1wTPUfh w1Gcg4oCf5el62AR+gL0e1n4fppXZlMlKN6jVilroQ/FaXFCnLa6+B2ovk9PqD/E+Z2goNqG+v02 auN81PCl8NVvKKH+Gu3J4B8GtuDtt4kKtALqVC9h3EzINkDvHOY4CjljJ3Qugr5BC9Rf0jp1EO+D S/xGoKC2GfRxoJ7qlB9Tl7hFXe45qMnzrdfk/IxN1tckjqJuXkrrpiFtdXA3m7fibXcXe6Wt2Xay jXexj+fgeaUexmgaFRBZF4GQTYebxD7qAY6I9zH2q7RVOWadUg5RXLkMHErjJ9QgaS/QhBybrTwL TNNm08+A7WhXgZ4GTth9Ogh8AOzA3GdAT7rxqcAQixHPoOAdBg4Av3Jk2eC17sbPhstvnRrRfwu1 BlBuYA83RsrkmttpDtaboy2wTjHUK6ghgHsblXi2UIk6FfxJ0Mvpu/y4596iKfey515Q3qXp0oc2 ovezx/sF5y7X5//XfPcLnO824HFpw1XcxzKGaLRy3roI2qqcR93ejLsUQL8a/WLHn845gf+S5Oec H2KFVLL+mcvP7eee67364iQ9kQ0nDjLx8CItZGiLMB7I7XvfoX9xX62xUR1XeObO9d1dlutdFkOE jRmb9WIbL7FZSkxgG98lJsQPxU5DgbhSlvIIEg/ZFNqoqh1DW1pI09oNJBBIsENxE9V2vdzFZHm0 WKpIlCgBV6raqlLBtFT9UVV1HlDR2rjfzN5rzDrIcZr+qVbf+eacM6+dOzPnzEMC2kX4Lo7X1dcn QB1ylCNiTtiD+eN1rYbkCyh5mGumaIMzB4zql3GvAqKubK8jXgLy7ALKKcRiYNS/GHc+MGZdHxDr yo4k/fb3sb9L6vfB/Az1ElCHfPYSKQE/AY7YPLq/rfvirj3/eHK/j+riLvlLSp07Z+LO2cBZuVef /0/A2XkXeBt46389FiXYq4AXkDnqMrJCW4zcczXBc3X4PUKGMsDTERdw8oYGUP4NyuuBIpTfhO0w eB8YV83QbdhHEEcY+JiaifydkH0A+rjdkGw7fBN4JtnH8DlC/v17C7uS7YeeBx6BD5nZ0CngDeDn QDna2P38GPoO8K+gr0z2NYTy8DXg+0AVcCjJQ88Bwu/CGL8T+cgnvEM/V77X++PTsvXOCNs87g0x GV72qfiuN4f9/Sdi+y3xCSzXwZq/NmY+93rj3MXYP66xQC7tFzmlyKNFLpuG/Fnkj6Ms3m2PSp5u 9WOzR8RAkTuL/DVtEXLm5DuvaMx7cIUdN8berfRjcgzwAlkWb0WdW3jrXEJs8uBOvYH/d0JAxjYR 1wDM97L0/3bkgqgDfh96NviGHdPsu3XcHTtBTPu89cnGyM8QU0MWoim4l93GEgsVAqmxeLKYKHZ/ 5lh+jxg9Nk7/t7od521MlJeOywMm0Cfqb7J6at4xaT0lL7H1VIzzp+49O5/JJJmjSDl3k4V4W6i9 d3J/ew6p53j0vNlvhGbE1DHAPVCAmFUIHMd9UQJkAz7gBdiedQ6RkLObhKD3Aqdh+zt4o/CB2+gP cbndHBmG/m3oXvV9WXethY0T7efUfSvyc5kfYs3kPdgq5k+KgWWADzgJbLe/tXh7Yuy/KucJEe9c tW7khnoJSMkBJ+TFZAfQDd0D3XOWrBrpY9fiK1aEjAS46H7JZkFh6IxwmJmzQ79g15Qukk84DFfN mVnSc8VcvtwqPLAkWYjPXxC6GpnCrpB/AAq7wq5i0WWreMH9ocGIDgNlz+KmpoSTdvZHEgMUYrA/ xPPmhdousPfgf5e9QzbKZu+Y+rQQOnybvUl8hLPTrNfy9MbTp4VIZCdCCiV9kP3AADAIqKSevU6a gRagB1CJB5IDxUCNsLBO1ol5dqC9B7IYqAdaAJWsYj+DfauQ7A22hcxF2+fZQTID/AN2QPIJcCb4 OOxzwK9BF9xm6UfBwn/Esr8MfSb4sMWHYM8CvwRd8IuW/g1sa9Ful8XtbKc5h3sjc+DPAUoAhtJB lA5i6Q5CI5CUfYdtkyOdBIfA25OM5Woyc/3yGzXF75sVaseSNmHpm7ByTVi5JqLC1WjXaUzWWcAa UacRdRpRpxGrUsJ2YrydIlmA9AI5AMO678S6C3sMsg/ol/bvQrYC7UJjz2AdCzGr/WyLWcCxyTbH HzRCZefY01hqgz0dn5UdarmjuaaIjQhOt9gj6m6S3k1x11Rh3RTPzE4yam2NpLMN5FuAgqtxA8kD vgCUAyrbYOYV87PsMbLdSYx03qw0s2a1OU0tKae+CyxEapFJc+JjC0gYFQp5NExL17kaXLtdzOvK cZW4DFetK62eNbMWxjgrZmWshkVZWmKkz3QsXQQyVmpLF7W6290xd5+7350W0/q0fm1AG9TScrQS zdBqtXVag7Zba9XaNVer1upQ1rkb3LvdzOvOcZe4DXetO407aHtkL1uPv0kgvUAD0AqoWOMo7Dns KSCKrxHFUjwFO4Ek0LxAP8oD4DRoHtTzoJ4HVg+sHlgJpPDUAuuABsurjXrsNqL+oPAAeBawdFjT sbYDkIOiBFRC06Hp0HTU6leGMEMvZA5QCzBpGwCwayBtX4nlXwdo0j8o69g+Q7RVhoyv5vcV0lgh bS+krYXUCJdFQsZcCJ/PF/VHA9GCaIda768P1BfUd6g1/ppATUFNh1rmLwuUFZR1qMX+4kBxQXGH yv08wAt4h9pS3VN9ofpytRqtrq9urmal+HRxs6gkJHluQHCvOSszVOqJLFN68HeikG3AVYARDlkM lAH1gKr0QHKlG9ZuWLtJDRAF0tCiW1wvkNzyCXub9ImS8Ct3+Rn+eJe5dFFNpBJXbhRoAxj67oK/ S9ZOlnqkPQY5IO01Vv12aeeQdhuGC65OXnN1OH51pAyIAg1AGrnM1pCrAHqG5EAD0AOorA6/NWyN 0o1fl9LFgoa+cAYnM2cSQnzTnN6IV5mKPaAjuAp5WMr9UpZJmWekV+o3K/VfVurfq9TzUVAKSASO g1LmGu6Ifiqi10T0woiO3u4juURXZkipCUn/JuVjUgaNjFz9Vq7+Ua7+Qa7+aq6+I1f/Yq5oNxtn V1cypHQLSV+SslLKeYab629xfQ3XS7ke0ekxitHJcinnSJklJP3wlKfcQ1zn6IekHD1RM1zIEwqR REfMcAR02wyvBA2b4WOgf5nhA/w8vUVlSKM3zbzrPDKDfkwrVKF/ZPEHtIJ0ggfBm8E/JWEaAJ8w w3tE/Z+g/RHox8lcp6j/GqmV7dpohbS/arV7xQyux6hHzeA3MeoREpSjHjKD12E9YAb3g14wg9tA LWZATHCLGZ7PI9PoZpKniLobSEARM6m2RnwUPW8Dr0w2XmEGRatyMUCCPmz6F4LyxSzPUz+plcNx 0y//ZDbxyy5mE7+cdBYJSE6nHjl5ncyV7DT9e9CLdipwnf8zfE78cXKDesxj/M/n8f9WQ/0TrTA7 +a/PiOUy+eVgggZO80v+c/xiXoKuNnlfMOGE40IwodBefhKLHENdhZ7mPcHNvNsvvR1+ePGp28IL +FF/HX85AN3ke4LnxTTIdvzj1XA/GXyIV4c7+SOBBIXbCGMwYwpf6v8afxDmJQlaEe/kC/MSYiol 6KPzNJ+PEef55VS+XHpWWUwc9OtG0LHLsd6x2vG4Y5ljkWOBI8eR7ZjtyHD6nF5nunOqc4rT6dSc qlNxEmdGYmTAKCI4hRmaV5CmCqnKslcREkLc+gp1Kjg7semsSql6YjmN+apI1arlsdKiqoRj5Eux JUVVMWftV9aepPRHT0KLKfsSlKxaiw0qTHuzYr6H154hlBbv/Q/r1RobxXWF772zT+9rZne9Hntf szNeY3vwer3j9YsFj+1dEroBkhiMF3lrm8U8CpIfu+sI1OKgNDikSpOqTQpRFagqIdoiscZtYtwK Gxq1Sn+USkn/tKhJVfpQVSuoJbQqYHrurAVB4k+lXu055845394z891z79x5zUvtl19+LZPB6dJy DqX3CKU7/fAcFc/tLumlXh55prv5bucmrnNz8glqZE3Ljxovf77x/tJb6f7B0g/8mVKMdh74M+nS U/3C0OBlMknGU8nLZIKazOBlfJRMpp6nfnw0mXkIQyKZABhKUENh80ikMCTieQ32jAaDMhVTyTlR LIOu4S0UBOVzTQPtL49VCylgrGepARgJoFptrFoSoDCoh/Jgjs8PZkXYoQ3msCJtMB8FzYXDAFkf ppC59jAA5sLtWviHj8JSuHw7GRTW8oRxRsuD8SNMfRkDVbCGISbAyP/PNtb7P4Dx/OiNvbnUmJQa kVJjICOlr00f4Esv7hGEub03aEAoMXUje3IHqB0dK92QxpKlvVJSmBvNPSGco+FRKTmHcqkdg3M5 dSx5aVQdTUmjycz8uZm+9GO5Tj7M1TfzhMFm6GB9NNe59BPCaRo+R3Olaa40zXVOPaflSj/fi9PP Ds6ZUG+mb6hs54mlAtbDiDeU6fWwE5u0xbEhxB/zLuoQvLYscqZklXpLNhAaaupp6qEhWJ00ZAe3 Yy3EH9sQ8i7i82shFtyc1ItkxKcOJh/+8vl8gUqxKIMuFHnNV4BFG+pPlzY/t3uwlCglUiV1JJnB dDqKa61vUGWXEtcTZDwxk3g9cSZxMaEvFjPgdi6J10UyLI6LM+Lr4hnxomiggaHBd9XEGfFTkSlC NeECtFRSy1kECz96WSjmaUOQIA9STicX5b7BHhHl4LSL4WTehFwgEogC0g+iRz8D/SHIH0H+CaJD L4H+Jsj3QOaph2limlL8wSTNmJHppsMzsfloPNaxAHZ0X9n27y7b1LayTfTEeLCXupWKHgccvDFa BP1LkN+C/A3kPyB6JsbEtMGL5arN5FFexnD7CC4KVOXlApahgyndhbwsIyq0wGEGACrjx+se4XwR ARUwIWAApHnz9G9Fah8BYQ/2IaT30dMyMqKtcwT/hFyBY6qRLF1Cet0CufIjBlUYaefHGFWbDPol iBPE4AZkxofwFxEvs3cS9xPb2NuJrfcTqBv67D1QLdEQF+LCoLBPh+4JzPI9VY/uIkG3DEx848FN PI6uIQuSVR9SDRZGNatdcbPaHR824zPmi2Ziftn6paN09MkpWV5B3Sst0XDMU+k2SGJdvLUNo2a1 JxLp6bmm6UizSl8qt+BBDPoD8Nn5bdWt8iP8Wf4TXod4lSfT6AQi9h4XPggnIDM+C5+6jNY3QV+C P/8bOfBB5AEPwv9Q4d3uIGaC9WaTlTBoEf8L4FtUp93uULl41DHjeMNx1qFzVFctklp8E3gACrJy Yiu7cpOlPHQnOGcn5jrRZyv38Gey3BJFWTyZdYUVzu3xVFWG4ptInGtdV1cnicZb+AshV2JolYx0 eCqM4Zpwr+4X3707O9URIOEw8bccJTe+1SgEgjBj9F71R/TPwDOGMKNmLF6L/wT7JvsbVj/NTrtn 2VOu05UfeD/wf8SaeM7p9gcYYyWerXklQOpNhqAXhURj0GsLSVWh6mC93W4j1fVwzjX5EtudGDlZ p+CMOlWn3rnw4Pfv2mxkp3OLRD/6NnXHVQkLEp6QzkqfSIwUqjK4XGRnlRWIAk2hVaLRYGVZstOg OQ011Gl4RxzNafRAyUGRaJrNwrTekbNTW2FqE+wKFa6zk9LUd0T11QQclWzYXRdw+AZwTSUoPxcc wF5X9QBaq/fjx1F2Ek9lJ5W4Emtv06iUpHhI0DkrWaMhtM6jxBDHImBXUgZqPb51WxVSj6N449UL V1eLv5sZ+CuOrf7q1u58uD2UZw7PCOvDr65e+XD1T1c+2uPDm3EVrsZJP62qBoR07wHjAiqpXhax WEACVsVdZD95gbwqnBa+L1wWrFhcwF9XFfvetp1kKEDMQS8TEj3tXm6jWBH0siFJCAooilRYan/x cXCUlwhjQhfwYbJA3lebPU+i02yu0Pis0LwVGp8V74RGs4/4ZDVCb9+mPFIab2YpjcAjnpJxFlcx ocf5qawzGCo5d5XHoyixtjbdW6HC3T8rA+FKjaB9h3cJrDX2Uu47xw7gF4yrb4Q7hAJziJITxo3q kXsX+oOV7kgRWHnxwR90ev0h1EF2qdXON9fDqdNBLPANpqtHDXp5O95OzFzXAt6s/rqto62G8eqG +eHq4Zphr0Fv09tR43KXrmAp2Ar2acdEYCI40TwRPWk6YZm1zdq/6piVz+vOK6zTpthabXG/4m/1 x5txM2nSCQEh2NDQpGzCm0i3LlodDUSD0dDG1o3xp21PN+6wDNh2sQMNA7IfDvDEqwTj3rYd/I7q HTWZ2JAy1DoUH2rb3W5nLJYGl8XbIFmErg0N0a4p55TrZO0p46nm09Hzzcv1Vxt/Li933epybzN1 eNE48V7E1zHBMxjjRbTApFVb/O0Wn9c/HvQGAot+6mmtftvdCHNhtbutVrtsbbTr6syaMUj4PkKG +hZGqnebyQWsBsRWjIN1uG4BSyrbzC1x5GMOC9xF7mOO4RbI7HvBCwGZNWMzBQTPRPBS5NPIgwgT UZ+Kq5HrcMGgiBCJRpYjushP8WbUCSXLr21DWXkSFtbU7ZX7sMzuT3U2axto9wpdZM4q2JVAzdoj sv0r7Ps8Yv9+ewWzK1BBtJfF7CT0tXXYVhs1uurrLOvNCmpw1Cm41gXKGIXLiiargizW9fI6tlHB DntDY9gpKcjUbFAwLFE2wSbKqvxyOn4cZ9FUFl7y5pxln20/m5P/S3X1xzZx3fH3nn13tu8Sn8+x Y2yffWfnDMkluQTbcS4J8a2BhpBAwkiAINxYHQvboCsJE1q7snqDlgFbG8rUVtMkgoa6qvsBhB8K P7S5gw2xLVKn8Qf/UKIqq9qp0TIpmyp1JPu+C0ibo3fP9+6953zf9/Pje87CMAjiuI7GUAE83hL4 kNd0NnnNNDRqb8PYl2wkyQQbALRWx4it/bZeslzSl44RwG82k1qdqklRR0ivrQbKt+Qcv9Ckwi93 f+0HeuenvznZ+4+b7Zn4rfAqmdO08M4r+w+fyrWtXjp3um/2V/tfaK0Oqx5m35J+bPKZl7d2pnsP jz73460/eehm8jED/+WNU8Wju9aO1sdufeuHg2/8NbsqblA96AQ9uAB6EEf/tNp24V1kl7wrtg/v I/vkfTGXoebVfvVt5q3Iu8w7EY5gORak/E+AInjVJBdKojgRvS51mpQtvxus3aquzEte2G4AnYf6 Y5qsscIuty0Hbpv4blsO3InqYFyPUTGupCtQTIyNxCZjzth1sgYFlz+zeKoVQVslgrD7JWVPgTqo ri8WaNUSWy5P8Vm6wRTvzcAB62BVK/JhZwZZfBbak0cf2y72qAMEV7wr3gVFKYCF+ZMpmoMklZB0 OvBEXUBmWUiL33nWm+L98b2Dv42k+o1H7zeB9P5sZE1mE5cSmb6l3w3WtOW+WDwcr9O0jDLuFCr9 +3fjTnqqvUtfJw7QEw4dtWos96SbFN3Y4WRYLgVvjowzRRxSHghRXR3GmFxgGRpHW5Z2ViyXFRmF OcCUGGeJmWDIJIOZY01wnASqFvdN3IxUNAgvnfBWt2WxsHmR2o9u1y0bvrr+4wJECtULDRZLpgmR glFD6ZKF1ounlzbixNKHzL7Pl/rZPbBjz/K847jjPFqL1jl6LhLSNbjTUvIWPfa8RbMWiHCNmovn yZBmZ05DQnp6ecHiJYkMpYN0Ctx/eJmmC74sWgGa5bQ9N21yds81NNLIFDcsaUyjmLO2vikjWG7Y VLBkmV598EiYXr5nxegkQXC+HMIhezRkzwiJWozrqHciA7h/W9cLEigBfGaMR1CbmPf0GWzAjU3Q cvmBrt8W7800N+l6xHqej55IE2lbC5aUuFnKv+u+6nFIunQYHU6/ik7yJ7OsLAXbxHwp73RH+5g+ doOyIdHXZuWPyy5PJaegRA/u9fTwPdneXFdbz7od/F7+FfdRz1HeOxg8EiTx/EieFF1plOlorG3I 3MARJCBhuXzVbQpreFOgsYfbsqIwIBALLkXBodjdIcEpdISml+9btbzZHxoJPR9yGKGXQyT03biI acRNHVYHgbAPNJQaSEMWzm3a8bTlc/KN5QbcUNRQukIQMhk4+P9ABtih9A28F9Ugjf5ipYm0uFbS JjSnpS1opKRhTaSTtBukC6AZAMzFzcA03mvFIobZzFmVpsINcCXOIXJ4gcMDHOa6Oru+uSLEY+Pj +mZQUx1cmkIO2NYhrvz9uwBV4uKjuYI4P5afHwel1n2mDUvduMhSTE05BIwKwyDZps9GJShyd7Y9 mmT8udaWVsK6XR4XYdWEkiBsljcV5JP9UST5vfGKKE4k2xkzilpdGQVnM7wUFaO4MgGXNrYjSuV1 RZxtmdb1urq674FGj+MxNAaiDIq8cyov4cIwLuhoHOT5cjNECoicnRLt7mqlmVMg9unlT6YE2s1a PG+GFN6shhalaA/zpgdSmVtDew/0Hujd0Lttef/fzzDEqbHcSm2fa2nJga5TRQlUP6n3qbpXBwO0 dqaCkwvQ8dU+WAP2AEOk+0c1LetGvhOr/dNnO7bltRQxUppx4cyLW9qjkqfaKwqBjgOjzW34rfr+ 9dtb+44+51v1/W90Na//9vaa46OJRH1b49pMw/aJ2vhT+itLd4+0V3EVHa1vrj+NCx2r6ovmxhGq UU8vzzk2AfNV/K8plxM/4T4J/1/Za/OXDWpeN1dUD6hEBTBfoaRXZWDrZX8VGYIvf7xK1UBudgA9 gXp6IX97HlMyztxubopclOyq+2BdQwYluyoKLdUVOxgS9Q86tzHb2EFuZ2RnlNvLHGJKqKRejvxe +UCZRX9j3DncjbeHhqIjyWKoGD0UGo+ekF7zT/gmQu/gc+R88hJ+H9/h7qz61DUX/buyiEMs2STt kE7GTyql5EKS8yn45vIsUqDFIdlIRpQ8TaKKi2pJJUgVVUUdUGlcE+qkekEtqx+os+qCWqGOyg+h BLwT1NwchHd/qsqkndUqmRAkr/45LuB+4XWBCIZo18FFdABNoAuojGaRmw4Q9N7B8JEwGQjjM2Ec nsaCJS2wGLEiq7BNrMUybFei6xo5tVLmjI9tni+Mjz0aK8yNjdMCR9fz8/NjNu3mpBUOWZ5t8lfk g7LjtAxcGhsGFrW2tuJWEHjwsnEEdKPgRmLIjABmr/pNRhRNTK1FpKguXxRXwIr14WE8hlmAHclm UPrxqyhY4eoVpFat4NKxSbt/5KefYHz52K+b69tjPj6Z7NyzbuvZ489uyWXw7iu3MPvwPq58fXPK SAUOxWObnj177ouuxhcg+vXLc1BRvwaFQAPpfYytlGFRZNWyIRtUrhWA2WBDihz02F7PK9REfBRP ikCBptizYfRzy4akEqIrlOh1x0dIpiILd3JcmnZ8ZIl+y11JhvxVSIPE1dc7bLfIP9DnDWj4sTs8 AG8o2+AEf4g8PtsvS7AKKbzDQZdGD8jYkosykeM8bMMHgQbsUNBJ1RP+wyraK06vF66EPlEUo7HW nmMHxw6xrNHooxY1o/tWnKo8o+u0cH1QKMzk56FozT+A349cQ8Zy+VJ3d8agFHlKb8wUjZecLzEn nCXjvFE2OMsoGQQZwbqAPsQMuQb1NzluI4cVI+fp9mz3vO38ed2kwZWNBZ0o8C6nXge086BgGzqU fuUZZdSzX3lROYPOKO9x17g/1PEpl3+18CUp5l8fkFcH/0t1tce2bZzxO1IiqYcpihIpyaL1iE1Z tiRbjiXHcpyIjRwnlePZib3GjqbZaAp0HTbYFpquK1DEWZoVbgvYCNCHiy3Otrbbuj/iOs6iFGjj bekjWbMa25ClGfIYEHTAMg3ZlgYDOjf77uQMGyXyuzvekXfH3/f9ft8DWqCuJwjDbKa4QnctGMfx eJC1BZEtbA8RcpCVcXVaPaGyQXVOZdRbTYMczPVktCVF7OkdaS7Xkju4nsX1V9ZKRdAe5CBZXAmW 7PRkpM8q/8afoaqh0b82EjMJjXpEaAqhmAkuUV4P4WZzPIRQjCrtQ4dQsZMgHPA9hUtTRYitEFmr QVSGIAqBleC1UW9fD6Uec33aSWT2OoaZD3LT+Zdu/OtX3x5whLy1sRrsTDjCqj9h++J2C9e9v3Vk e2HxG4VHe7d8/t57eEf/T7+/s1aqn/z86g92aM76qfP4cs9kZuBrH174AyB6F8TLIXYRuVEd+/Q6 oqOC6laQ3QEQRCI1Ig2YopI0EA5BaGAQkuACG0VjJSkYTqcTSsjm15084iWe4cltMpqn0RX68aby vUt0BBQunCbeYGqz2WhgIOoHEERQVSwWKayvxlZaL66QUFtFc50yjY5DOGJDNDqx1UlU3yiQlxgN BMISH+IXeRbx40D6x3kTf9T0Q9OSiSWv4mFpxBMjBM5udzAA6yRFWC3AnqwWjKiSJlEMBqooB921 UoX96kWYa/EcpG8b6VxhpgTuhk8e8xZ942jcfYk1+0IaUKyWUQ0tEySzsubyKSFIKCJIIRZN0eah 5paUn/NZRlxfVcc8+7yFWh6zFo63CHaz8iA3w7zAPWt/TjpS9yPmZ95Trt8znziuSHeYf7IueZwf FyZhdTOWX/AfOm7zwHR8zTMMayF+woGf5DssvcwOy0BwmBm2PMyUmBnXjG/e9ZrlNWtZOGVZtH7A /Jm5Yb9jdQurPEb8Ks9MEUv2bg42bZHn+KdNbpRUFTJVl5yRx5SDyoJyXTEpiv93JgxfcBUIxETk hYuYy8ZOOUP2+Ct+TL4I/5GgRv0Zh4on1IPqrMqqd9zuaQEnhTmBSQqzwnWBlQRDgJUIi8INgRPe FBUTmiG4YuOGnBQNcVBkkSiJIZG9LWKRzMQCeynmArm+qmeCfOtfm+qWQJwVwVRAo0mEaEoEUrGS Ez4R6KQJBXQSSSaAeYB6MjRR6uxEU0WcG1nmEGaYqVEq7MhB1dQZxMPbbPUZu5HI1MApEMaJZviq ITFiyV+t+av31mvWas1arVlozRAtGUXyZXwhZ6YGThoK/k9hjY6OujhI1zZ2bPKsM5hMGEwP01xu A3cFP/LIs/uOJILKhVdev/X3n7/6/tqz+Cdmybe/Y+gws/mjxx/f/6R75k8Yf3IL879+s2ukodM4 BHpoACH2KfMLKMYI696tJyhfJQxCOwmaE/khfxQ5LIhNWCB1LMNe/8WQiYOKMnV9SlIiR+jJApxk FRr0gAchR5OjjP1LMieg1mxlRVrJXqxIlSopASWtSOek98nvHEla7tPSGeSgYxAMNeqauAZ4ktCE qSNijnggZogj02lcNmzUG2k71K+cJrdEMRG/T0FXyQVefxEYKFsh7rj1+dC8Mh9he9ge+07fEfaI 3fyqCbcmDobnuDl+QViwHJOOORcTFomDODXWPBZjNEFcDghHN+DlAF9mBSNYH1gInA0wAWeD7sGx QUhcks1NspMTeKsEAC/jPSdnIVkpM3eXcHOsjCWjJtqEZYdTOupw4AYC1pPj4ylqu7qqNput2oY2 ag1VC6fmREwgPiZOiiviqsiJvvjbLMfyVQVVrIKyvwLQpVlJN5hPizdLwEJZIKO1Und2DbIS2AjK P7Le6FYjuhLR1aiGGt0NGl5nHUI1CE4QSU43IK1dCacBbh1pZ326HeQ71e9UMVUFE6h2pV3Bb2j6 1qG1q03Rbb6lpZFTU4+NdKUCnvZ8MBhpMbS/srvW3pjeEG9oiPY8zOzb2T3z7oGeRGcgHf6my9X2 6KVtOwF+aMsXvewfQZNvRg+iUfZl4zuyOvhyZL6DRQmpwDzR/MQQg5q5Fm7P8yFTdtNAYWLTgchk YdY0az7secY7m35u6+Hts33fHXjR86J3fqBsOmNe9ix7z6fO960UVgs3CrcL/tqQ0i6l3R3BgvnH Qr4j60cq2xHO+5EvJzslh1hjt1ktFpfLbREgYZT18r1ryzLwkE4+h9ueJdawybbsgn5CP6uzehkf OzUSmw5jSA2uGTWkr7wQPhE+G2bD62OohSFh6Gt45/I4b0Br3oCmfJy4Tn7Qjd1lLBiuCQEfFKDg hMcIaW4+h3Nlts2w+/LWVh8e9E37GN87zG8RB87Vj7rhlpXjfbvx7njc0f8umwS+C8A1g/rZpBGU kngiOZtcSLJJL+HXpJ24RDKdaWGnh/EwWVsNeCsULixLblq4tky6DJOkz1oDjjSsB6M4SjHoqU3N RvFAdDK6El2NmqIi6Qm37iwTl4fC3wyZBIzogVAhWTAKx2HPzQUyVLPZUwVx9qVe3CuRQb1tIRU7 1En1Ywj25Xv/MJxknGonwkClc1TLzDuGaz6Ls21JdpBlBlmMWIllWLKVvroUtfBUlryeyGRSOE3W yD62r/A2fhLyOutbM95Y7C5xC4jlldIaLVRipZtSbOourcRKJPrHpqSboN2KJYhI66Sw9imhiKxU KQF3gMooSaQ/dAaWWP44fD3MAE+U7lRAlMVIi35dh5YScTwniFuIOOTExMKfetxTfXu7tjektTqP F5sj+sa29rZUG8s9EBmItOjNkYf0YQ1rmwMa6kv3h9A2nA2hLeashgYT/RraExsO4R5vr4a/3LhX ww/trevyQ3f/ZrSrLR/Cffl0h8HkQhDHt5q6Nfyl1t0aGmraHULbPTkNUQaRumNkevcv1Nv/ezSD 45MDl4qE7KYotRnWFgkwmpbkTAsA4i2Z5k+jOAIClEQB4B0SCXjgofr1HIojytNDf/QOSavSKUim OjbRUXgDdKD0lU41RjD3vzWop4f3XTx+ePyXMZHlzKwj9q3Oc6/37IgHw0lt8jdbihNf/95/2K66 2DayKjx3/DP2eBx7YsceO7EzY0/iThwndmJnnJ824zZNuondRkudn4p0w24QiH2o24cVKitakFYg HooBARJIbCUkHuAlKmkbJBYKivYtUAm0D0i7KgihatWFalmV1W7rcs4ZO00FlmfmzJl7j+f6fuc7 5/v0d28s+eSS8FIxO8l6FrfmisvVl0+Otz4ezU9tvbXzi/Hij/7KThvfW//mnuVye6Nx0eU+1bh6 Kzw4GZZVwelwef2NFy++8t3VsQlFGTjufaW/0J8+z3/jtcs/WT1+6fKb544//tr42kBeP3blVDES cULR5/xATv8GNTfBf7tdGxNlCxM3KMoiFUJR0fFeieONAmKNcgKMexYpPKULQaoMYrXsR8egVixl ckxzShJf1yiGllMwRm736Sc76AXj0Q4+yHVyDIwHVoCKMsXLMVBhFRFKbTccA3AcgSPDFaHwBkqW F+aWJriMnBh2CgDr0VHUglB1HzwAULb1IDWtwb23x4J7WduzDwJx75A2XCt2Y0qW6Ay/mClCUAwp Z0QqvyKVXJHKsqiQSyGXQi5FKZtMI7dGbo3cGqzmIbENGB/u4AMwHt/GZ7lc2WxXbSrabXsfmy5Y BcjIfZnyCkDca42WraGSWN6EvjkwEBi8Wm6WndvlO+W7ZUfWzZbLm+UGuqwyUz2KkZR3HQFLTuWM ZGYxJRrJ4GJaM5KDu44uayRdyoxUisnSHFMzExytEtoqWQ6KMUX3NkW2LbKA2BDfFP8oOkUkqYEc p+kj/bnl3GaukXNezTVz/HaOQcXK3cndzTlzm+bPQB0GH2FDiZ3lE/sKdRkzEdYyI09OkjDEP5+o Ihzvc3ncA72Dfa5YHxM8cSGB5RmSlgr0xUvcBgPyymKJxnqMaYi1OtKu1SYUaxKHboGkIXjHzImO ExQjq134euV0ozfUJeat1rEea0x09M/lC19a7Jmcb00dTYeVQH+8Z7SLdbuuPXn58smVz1o/b/16 VVX6dD0zGDzN5n5wfrR4ptV3fqRf10NiecVx1FaPHLTlM3ASIF98XIp/wc6YX3E6FIIEwrnbT3D3 awoiWVMQ2VpIcXihghCXg3GPgO9FFYiPwfjDLRzt9SsdxgfjbzvtdLvXSbd3blK2qbuQAdEz2gXt CpTh1AXI4U03c1Mnix35bQzgTrlD0A2+A6S+vxF815aSADL7DCkBnJndQ4x1MsGvUg5odMY4O0tL baNSsQ0rZpruuuVmnPu6m8cf5ThVSwkhXN4jqw9ner162k/54OcR9n7KB1yZnQ8KJj7lD3hu2ymk pw/lgK0x4d3f3Z/d3yA90k6FWFNnm3pDb+rX9Ye6S9WXdd7Ck44Fc2ysSNfylH3N5e1reoCu1kgs XoQECS2m/EayG9IiE6uoSW1OikmhJixlkuNSkhDqFpte5p3EGnzjRAkvVmC25HhVkvwxv65Y2UkF ffGJqWJTYcsK21QaSlO5rjxUXMqN9I2fUjrga3+AOQCl9wO7TYXKC0sLtpOBlgQfgPoGuwRYH2u3 nVBHQge4JlhnOrg2hqanh4Zmpr8aK1RaJ06M9HqFZLzvSBcLu67hg5mhoemW9kRdmQQgx2fq7HPf H1ZjAb0BCDkKqA0AanvYdzqYjcKWEWbDkpsJbc3jRBQxN1I0k5C6EExgvE+sLXVgKSF4EY1gvHcT 50iut4CePXAIXAgA6guFiaPDPeBAbh47kET2Pu+hKjrExJkQIS8cxnMIpnGc0FZDtg5ykiaSOkCS 7MJBhg0kSYpGniPTWcCQjZ3bzeid6MOoI0oCZL6IV2tqcrrIojf8WxPLUWZFl6Ob0Ua0Gb0OAwXJ SAqLKWYk3Zl0OOOvhJLhOXglwS1yTPdL7TASQaE0XWxKbFlim1JDakrXpYeSS7oROQQFmxJnZ55t PrQhpElo75/f7852fyVWXGjNzo7Eu/qV+BGZya5rn1ZWygnaW4f14wWbkRgnc5w7D8pi1fGndgWP rlMFXyddG5Vpa+V6Nd+ptXncUNw+9FgB3ON8lkZlC+Z8Z9R8ZxR6LA1HzVcWKjSuQkCpEFAq1TD+ WrUzr9qp7dVOADA+sWI4tipimGqWpmdpetbEhtyHDjOI0+D+z5YP55l9GNikxgKHmjw95zGGKVMM mWLI6u7T+3YMNY9j4P73dgx1CGPA/V8sHw5V+fbzx4BRiKNGYqNjJ08hqaoLZ+sWjhmtszP1C/Ur dUd9xb1QUAaGfcLMsAv7DOw0AM4bG8CiT+7gp9NrIOj+12xDHXvUPWBcvL5NzJs9QP4MhIfoPsEl nK2vCEphQSbEy6oTL2qWGoss+bJmhe4qdFepwjreJ/Cr6pqJrRm6TbtHI+NDemqaa1WsQOisdjII jI/pabW6vtZOHPngHIQ3pwOWwNGa92dnUUMAerf9S2fXfsvNP73PnYRjFI780/s340pMgYbI/qz3 Wn1F4e76vyKOqwDxdexgsn7WXIdGRTWSyi7/eCdlGskCGJYvVTWSC4sp2UhGoVfZSWeNZH7X4d9J V4zkPBjWsXQ9U6ucTdbnPIZZsyaNIx5OGFhYWcWNGRiWRJ/gdrqEhflCXomK69FoPCjrWl5lDXVb 5dVdVrICpjGS1ct5kzXMbZM30ReprVb0arW/tlzjr9aaNZ6rBWt8DfL6VjhSrG2ure/y536pQZez y7beyGZPf4R6a6YWhGbnI+x1/m5fZk6f/PzcPyDJ8TNL3xr8V7OkmFAqcQddUKcPSulSwD+QHtQl rY91BVJdA4f7IGiDsuziBrADdDzUBv2fZsi0u6EMdUNC9BmPHLiFQ13Sc9VknC1vdee+OL7yes8X ri29cFGL+MWJo62Z0LQWFZ29mZXSq1We75mabxWqkz6XNnxmovSZXKyw1JqeHYtT5ckEWDjLP9gK DA5tvfTlpaX61Out11bUCDRN0WBaXmbfaoxYpVO+bGuJOildl18EX8FKDJutnnMTvbreO11n5384 rLWrlARa5D/AZOP8AZOViMnyJDQKdO7yBCJppIQRvEsndMNDlOQhPvAQH3giJFkiJFkiEuZ5pENP YLxHrATGP61BHB7hEjQ5QYESFCJhkGIxSIwYmDw4x8DkwaFGh+QM5DYRZxhcH6/nkUi8BcuL7zvm /w0UxCAcKVvDWF49oI8J8WGeuGR0lARLEJSL/Lxqyd45xB9BJJCgLVye0cb50QhmMf417nqBbHqB gh0/oHuoenqIKTzEGp4Ij64IuSIedEUipSKXoJEJciT+y3j5xjZx3nH8nrvz+Xz+c+fzn9hn5+4c 2zmfbezYjoNMWHMQ/qcQOqaRUFzcFa1aYcVJRyG0gIs6GFslonVvKqTSvWCbKk0E1K6BDSnqMlbU pkQT68SbbS8QG1q9SRNv2Lpkv+exHZCmSY3iu8f3nM+P7z6/7+/7JZPd5Ifio2ZHLkwsJvgM0yz3 f9kAA7ZtTRkSDF/G9d9X3lmulevl6bJtFYssMm7Au5kyN1NeLNMzZVSDA3NlppsPmqrYCjOmqSa2 9fCm6tkW7zbVeCvMFIz0uj61sCFKxYsl8osT8bgoeoSuYMI+zaMZHol8nb/A3+JZHoeZiFnqTqQ1 c6dZM+sm2zCnzRmToUzJpE3cxx1Q8GatvxVoMl8+0MihMMOxyTDTFUU2LmRTOmUMVVydgH8INJMk z/zfNAMV+fjBRyaghEZ+/MORg3rQ4yysXxr0WSWBXbf9yMtODy5E/6YCJJl2HTY/HPn62leXpnZr YZJjxFF05PjEqaXuarAbKm3zfvS1i1sUXGc0iPZd5irUmUh10652pUXBBhJH5yJ2zkVsnuR0wlZh ce3gSTywfPggS05ju5K8U0pSrc5I+G1HjEJfh1MHnsfnKfjDEcyUwvoJcX6XRBycROwbS3wAHrKs 6nJpKgaLtCIMF/Qi8iVwYWuj3AignwZ/EfwNuumY777j4OS/CGiLY2Nwd+C76A3HWfFOxK5ZxTKr DQN2FzR0I3BToS0NbeU7q5FZ/NAzsnNoFFBk0SLe7mRrbJ2dZmdYjv3cZcGk5brgol3D6vBIKLND ejCZ2d7EYTczMpPaNTKz86k9l13q1ssau/Wre8auU67lOYqFl7Y8h1vg8NivKIUpUizlZ4r3pfuR x95Cdxhv/yCAaAB1y0lPL52M9gpJrtcr+nWqGyk6CjpgFLLDyOeWdBRhYBNwdulU2AYbEiEyK3/Q NhD2m0AdGh6zvIfpw9wx4ZjnmHw0eDh0OMpXx6tUdXgvPJSo5K1E4BWAm37ZWcFXGscxpAvnEAgi Bk4iA109HBfwy5hJ6Bw0tXjiwMu3Tt469vzxT3aVD6y/cOrZE9/azFx6+8ylV75oXPzBz088PLJu 6O1XP1r64zu/fvBGDULH8sOlbcw1YM2gKnRPmzVz0MKqWhTSeCdwGCUh5AtTOmP6iAb79CAxZyCu 73X8GtFdHUPkJsaOSWVk1sMp10Bbu3DkAPuRS3oGxjm7QVSYIipMIaATFBacW5MILmnJ+ZbQzs1J N0BY84TYjrRepYrLX7yPQSwKmMkQHgrC4BpYHeHWRzTSp7d6AIcX9XcrQsyaDmelOI9BobAHFuPE q8ELwE96SGopI2opJojnYks8FzKY6hPCIKa1Im2VnpbOetnTWTSYHRocyT6dfcH7QvYlfso7lX2d v2i/zz90uPsGx0rj/Qf7WWsQ5XkmZco+sFXh0z0+MFdGnDJio4ZKbaDlTIphc9IAwiuh7XhN4ZCn WNCEaYGuCQ3hksAIf9Np3yx63oro+s5YPUY3YoiKSbGZ2FxsMWaL1dZ8ONIOM2slooqTTRxomkM4 1XatpFrGI2H/Q4jW82W7m0/297p6+5Jle1FHeTdsSo4BHRWcOZ2iVtAFoZyYrFITVUCQSZYC2Olg Du2EQ6NjYErB1Y8Ckq0lmGCBym2jQyOld/O50e/vnfhe/d1tA6liV2VkSQ+vNnwBKa6Gkqjf4fn2 rv1PPLXXGuvLJ5jK5GdTzx58/Xbz/MmAuGrp/jMlNZlEQWdhP/ON8b6Q5+TSu4fia8Z2fPPq7yZ2 hGSctNwA9AfAcgq93yY5lSYkc1qX1yAWwghpqB24Hs8nWsd9aB3foGFmvBhkjcQnjRgNjeQSciKS mFAw/EuAO0T1As6eUeOQcdJgjJQ95GIAqQWcQ5qQQv7HO0jzNzp+oaPCcXy5XvjsIcdJB+2AC4Q4 WCnB2UtyBl7jvwjOGs5tWJjx4AM8p2lp81HLh+tT+aGFhepKp49Yh8Bki0W6KFq0JZ5i7VYa7Usj DbNIXP3puGHo63pVYwMlONNevy4hNtRwIEdFciHXOMNQdvDt+zhkcYjLaWmUprwJTdN01NCndZrS JfDxc/qibtNr5k9eJGK84sQn705MYh7XSs3JZtXbctwVqoMlOJFJ6MIgbwHcgkHg4j0db9zuuh0r 3e676MmXplZv6U/EdwfkwKo+n3v9E0uZTT1hweaOK5ohoABz6dNPh7PGwEa/+czS1icNaLGJIHG9 z73zlShus8DL/uW79O+BlwLb3+bFKBFeShbuoTQK4eePQvh5IzGi8IYLHzdi4uzyn0nDFbHcFfG8 WLDzhhhj5YwNTdnQQRuyJfMIobQ9fERFz6lITeoKqil1hVZkJzU0X61Cp8rDHnZVkLwhjAh054Xb C9Ltlt6t0FGMiQbPpoOqnLPR6YK9dZmwPGJDB2yv2GhbMm3foKL96ndUWk3KToRX+E9LwbSIYqmo 8B7iNQ0Z7wyjVGzr2nxrPw+drlrFL2l+vjokzcsVmIBFYXRMRzacpWU5Zzkr2ZSzEvKPu/b0npd+ lLAJdiElmLVSvdQocWJpFunWGZDIj90fe+YT88k/xD9L3MneY+/F7yXuZ53yULaafXHV8ew5dI4+ xzQCDaURaUTPrjqXc4tIpAXG4eKiQvajnptxPsoE/XI02B02I9m3HG8J5/U3428mnHLGncpuy46W 9pWOmkezpz0/i18q/ZW5F3WZfEGlrtMq0lAe0WgWZa5Q13OzSLG86ZAavh5RFU1BkqLDncOT4etB PNkjy4m428mKBtnZVPRbKpdPFygK31TlRDgcmmU2Wf5gHt9Y+hMZIflW7E+xf8SY2Czjt5x1EdXE ujgtMuIsGrDChhLOaTzisxcMVDPqRsNgdKPPoI1rSKeKSL880imO7c3JB8TC/qc6PHZlOYaq45U8 dP8rywiGoODNuzAPjQmb27tSs51VuyrgHQRw0wm30+92O894chnPcWl+PERJnz9oVieR1HzQbI3J sAXReznd4e6nMuNE/qMpU9MlL2fXvBBvOZOPQgmrUcqeskVRS/pfew07ZPgux7//y3e1x7Z11eFz rl/34cd9Ob4P27mefV+zY4ckTuopmm9Zn9tKwzTWBWFS1hW1E0jNoLQdTFhCrInYIIzC2lUiFX/Q PyYgTV8pVdV0KlIlCI2EmDSksv2RSZ2oRzd1U8XmhN+5Tqrun9m65/zO8fE5xz7f+X3fF/mE/0T4 1Ak2RsH4wlWFTnUaT1PTgWnu9dhUckqb0qfSxx54LT/dEwURU8TjCHQODOMq+UrhZ6XjheOlUGOU SBvBMdQa46g17LE1Ch4dhN4sW9OI3lPZWhm6Sv7D1KJ8VqzHDVIA0c/qNb9Sa4W5lZuzUi3fqaJQ nZNqJUXqzCV25kqIsIQIS4i1kiGS79z2EgkYlqgF+BisEyMT3PbEGKwTgzHwKIL/oOIXveC/GfXT lZAn+QgUWKorlerkLZ/r8kI/4T6gPqvgCzXCl8RNUFM568A3Nj1ldI+9+tdL+5/8Ti6ZiuVy6d8+ s3HHt5b/3dNz/IeD2/oFXowG/rR87VfPPdqzznHLm3f97sVjWVbDm1/++VdrG7859VBtx/jRVCKu QA6TVz6khoNXkI7bqznMzHgi5LCMRxIUF1UIe0WTEg5Jfij5RCbNrdz1CU8izOdLOvJfRMl3JI4u Jbrk4BzWZxEOA5O1FxcqraurHHYDNFnl8/lJTfkut8svk/fFcB43fXeqrQUqBJ5Mon0c5hI6Tu6V 8VYZ+8t5AEVYm9NxyJdwId/yhnwWDMEGP/CnIDv1+Q+C/533BZ+USd9neRcXiHJvLzYa8/wCf7XR sbrFIhyrfgHFYAPro7UxPEZR9cwx4Zh6OXm5a069qUamM3hSw9uj22Nj0bHYxwr4xaRiK4GupKJq AUwKWT+BA8ne1d0GeikKh6NVsumu68l3kv9NBpK7Zf1viJvDt7ySAeRZrmRmMlQGYRwMhgryiISb EkYSL81I89Ki9K4Ulnam35hcE3Bt38ryjTugHVqQJ8DctpcIdfIt+GgJA30ieETIzSDJfGX2PHGv Qn8yD1KMwKyfOATLqgr56iDw5hB+9K23+p3cw4Kdb24oP/3gL4e+15Nyg1eW/7Gp/cfRh13nmV39 Y7uoPbmuvVus3YQZKXCg7cARZFK9q6jqsj2CHkhsBCyYMxzSNO7pISO76gOWPMmX/5o/UBPTZJy4 BjdxzTFAcOcsGSgW1gxCXDHDnBFXwplSnIvQcIfPEoNAs6hyo7gAJwqioc63bnVwuFD0q/kbxft1 1I6IR++k99EBmuUMTokXzBTM2pmSwzSBD2YJdrAPKmxoQdLSfImlsaRPE2naMnzkGWHfPhgW7PYj H3si0YfkIxL42BNF21rFnkBKKPgFaPjFPAFiHUDoCzHQgwuEUavY3gk0adiEH2bs4AA31P2QsaV7 ixHSaGk78Qe57VnTztM2Xh/J0hsMzszQc3ijJ7HINIGSyO+JsxzLcTmDGIM4msE4gffhaXwdB/Ec dckzRVUriOKINCVRTShmpAABnbEKOwCd9eaPP6/TgIoAfoA+RPBW7wCxRXZ+T6kBdfB6OiGkE1oa 8YLOZ9KoiPlhYAvUwA0fiLIv/FOhfHUNh6DbItXcKjqhZVcDuxK5rm47vvxBzw9+tHHbeCk9tAWv H60Xv/tY7euBI+1/Tm9OC/nxN5tfHn25iY+t79Ox2T7eHBl8nIp8ZYgyidpfWQqdAYyWAgsdjJ6z clkhTpWIuYwjxlLooGN2hxNhBDmsXq9UwAm1F+E1jytwDGtm0oJ8sIGcpJL2RZJfgvKD06Y7pWIx QeT4kx8q4RLab2KT2+9gh+vMXir15HLlHoICOH2yVr1Rb/A3Gv5igq+j/ASknxLLhJrS9WqXDZJZ MG2jPFbey+wrv2++79w17zpRMmBWqvrjrundA7ly2X12MKOq3XqeLwdZK2OVrJr1tdTJ1EnlpEVz 5lBhyN6OHsfbIlvpzYVN9jZnmzsRafJN4RVzwplwm+XX+SNksHmRv2BecC6Xr5nXnLfNt53FcjcK BSPhZDDFmBGbccJuNfUI/4gwEnoi8pTyhDvJ/YKfUCbVyfyEOWE1y6nDzEupw1YgxoziA/wBIcgw tGXZpsniCEgvPiVkeSOfyxrILWVRgo1nE91qNgtG5aXTtGNDenjR8xSzYNARmokUXEd2XceyLdPu pRmZphnIt2qywJoyy5r5QqFXUWVFUV0rr4L9YOgIC+dwEd9CBsriW6e7cUIgLR7FIdvCveZ5sCQG okgnRiUYglFYuYifQyai8e+9hOPBZgsFhzM+S+xmQSWeOjOPdrv5OUx7SU+vjKj4hIovqdfVd9SA +mqhokCiP28kTMzDocOZnOaiA+ZFzCMLJeHiRT22MmZhz2palAUp/wzzol2h/4x1WE73WAO8aNO5 7VAOyWbwVedEhNxXfcTFTRcjl3cN13Nn3Hl30Y24O3vu8UDrTrExrmqt9hLIuHHljtZSedKlQQd8 rCxpQA7kaaHORdUIQ9SHCWkMr747caujHA+HOjIR5KJSpEkQWgvWeopFkJAtzM9/cRnh6WF6GEi1 0RjHDbj2zxNR1CiCujtr8XK0TqTWaaiBn9+dzdRS91UyqW7PpmomqZJ+61Syhte01ejoqJRLhomm kiQbkGFXoRnptImg6rRxPoDzGJAXw01ILFf/MqDYXcP4zJasTC9eke0azu1wl//uvrf8sbn8r8y6 4cARM5hNd5faH+I/HB5OxQOmGUjxeTnZ/gh/OmhIWco0Y3s/+w+1tX0+QG3tjxEWjC5vCtyBDNNH PbDKgjLDFB8MoIM2tjNiWPb9oQz55pzghwIJKT+kSNjnh30QniI5qFVsFW/Bu15ZII7vvizkZZki ysgC9UIf7kMi5JT8C2SNhCz3IzTQfy+13GhcBT4hmWWe5OUv9c7wjz359CWkr9xF6sptpMHfyfLr 4DWqe28wvMjV48Vfu5Q0UO56dvAnoZ+GKYYJibRKa0xR1iymIBY0q7gOD4pVfbO4h9nD7lW/re3S 95QO0ofYQ+oB7fv6wdIkO6keRUeZ17TfFC+ixYH3wv9nv2ximgiiOP7fbim7K7alVGGrra2ltnQX UGggqKGg1C9oi4ioKCLRakgEtSAEE44qARI9ePJi4sHEeDDRqNEjR6NGD3LlIPGqMXpRAd92FwEN 1gMxHuZtfjtvPjt9H52OnzJfUdRwWOIEyvwC2ekpgFrhgUPK9zg2CV7Z5doclpw0QFWUYlFwkuVo StglmiVBpVKmfBb8BQ66UcES1H7urLTbYLm/xm2LFBa6ZC0n112TuCnpo2Q6IZ2XPki8NBwVk2Kn yIvDdCBa69zKpM3L2by3vCbvtU6VK1ejqkmVKyN3fXfodFMSnzvS8emOC9Mzn+kfFV21ErFUw3tE 4zPTip4385eqq8Ki/KCSGmuWTYeFFOAuKJQBSiZs9btAJk6DdDPQIpVCN5fLHIOLrgHV3KZMaOdx 99aUlvqmXubnChsVLhwIFYny7FjV/f3bmqo3+2pCkmd3cf3sE5tPthdWUggH3cHYbAX3tSTkEFet DgTMRT5r9Hvv5ZEGNVy51lZ75Jbp4YYyf549D7oMrACvFuAerBx88Z8xb12e3AggjGZHjCxldZmO bRxwHAfW1gJFE4C7HfDSeH/dAoH1QMl7oDQBlD8DKq7oRB4DNZeAba+B2n6dHZM6sRsMBoPBYDAY DAaDwWAwGAwGg8FgMBj/BzCBgyZO8JrGuQgLsgq/pJavzf9NgkZZrhdV1fMddUQDdu3es3dfYxOQ bN7fcgAH2w4dRjuOZf/sfyJmjNB7Pez0VfPgRRm20J6b0IoOdKEb53ERgxiam6NRC70HMr0ncRZp vXfu3XKPYfflhc/SDwg4bazCZ+zPGTt30qPrFtJCmmfNIrWEsN3QTbDilKHz1J42dDPpNw3dQvpE fTzZ3BhTWrt7Un2J1GDLuZ6u3r9tQz3iSKIZjYhBIct1owcp9CFB70G04BzVu9BLWgpnyJ5nqZb+ 61krPY4sZhnFJ7LRAHLJQnYK3DYg5zn5mKc6GYe7jhwIZtK02nyJ0yYHGf+n/OqmKAnFvBdDgrbM C8HK9xneIh+PvTm6s9O2/YsgC5nRt9+5J7Ty6dtHoW/9M+N2CFaqav7LrPxDgAEAFpQcswplbmRz dHJlYW0NZW5kb2JqDTI5IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQg OTA1IA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IC0yMTEgDS9GbGFncyA5NiANL0ZvbnRCQm94IFsg LTU2MCAtMzc2IDExNTcgMTAwMCBdIA0vRm9udE5hbWUgL0FNT1BMRitBcmlhbCxCb2xkSXRhbGlj IA0vSXRhbGljQW5nbGUgLTE1IA0vU3RlbVYgMTMzIA0vRm9udEZpbGUyIDMwIDAgUiANPj4gDWVu ZG9iag0zMCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDEwNjcyIC9MZW5n dGgxIDIwMDU2ID4+IA1zdHJlYW0NCkiJXFYLdI1XFv72Oee/9yaSiAh5lj8ukcqNR4oGESG5KEIS 2iaWci9BkBCVQdTSoqXSUMV0PDu1PFYrxR8pE6FEPcdQr8ZoPUZbmTHjsUI91hD3n32vjmH+s/57 9zl7n7O/vc/e370gAIF4DxKZQ4Z2SBz9OGcMkHGaVwePKXQXbYv9iwMY8DlAs8dML9YzGvKWs+4S YFk7rmh84Wt/TOgHWGcC2uPxBSXjDg+4kALE1QAhN/PHuvMON/00no/SeU/XfF4IyLbtYYfFPG+d X1g880+Pntzj+UogqL5gyhg3eruXAT2+4vm9QvfMIr/+tIjxGGyvT3YXjk0aaUsABiUznqlFU6YV m7yb59FefdHbY4ty111uAKI/BAK6atWI8r2bEaViEQWYdf99PZPMOq/OU2DWiX/wadFP39+eWThP bSkc9ykE2+klHMfXuEDtMBsnKQ/NEYYG0Ro6abAgHMOwBcfJilxUmv/EF3gTNxXhE1wlB97ACQri 7L6OdRhMzcxy3CBhXuUTuiMTSylUm65doHnQSIoPzA4I5J3zEYoUrMU5mu2306zFq/hGDTLvYCWF i3YIQhH+jnrGlyCSxFtmIdx4FwfIItO05aYDk9EgF5gbGIkVQ9nvKMzBH9hrCtWI7VoeotEL/TEA b6EQm7FVjNPqQRCIRQFjP4rrtJUuyuvy38qmRqoyrY2nF/tshVeQxJGNwmhMQxlWYh+BWlI2rdIS n8zlnOh8Qie2eQ/zsAiVrA2iJtSM3qB1Yo44JW6rL7UL5im26ozpjGk+DuAwbuAuWag9daR5tJvO CBIl4pHUTZh7EYd+yMYIzMBcLMUq7MBezuYBkSHT5AxpqBvqsecQAjCcMb2DSvwZtXxvIRQtYsVN GSM/kBvkCXmfI2mq5rPtVY6iI2McxGMoxz+N73khlmA9yrEL1YznNM7gIuoYdRJNotn0Ge2hB/RI xIhWIllMEb8XhqgWP8vmMksOk1Plp3K1PCLPqSaqjxqo1qld6kdLguW61e3Z5PnFHGzmmHPNZeYe 81vznHkbftxprWCHAxM411M5rnc5k9uwj8cx/BU/4EfurDquOlAARVEXGkBD6XUqoLdpCX1MK2gl HabvhL9oIpqJISJTjBcLxDFxSnaTPWSVilOJyqmGq0mqWC3QEnlkaGXaF9oWrVyr1xosIZYtNthO PGn35Ion3zPdc9n0N4PMFmZHc4J5Hxpa8O25MZ5zsoZzspGr4yvU4BBOcFa+Z3SXcBlX8DdG+Csa KJSaUziPKHJwbQ2miTST5vItrqQ1tIF2URXtpYN0kk7TGTpLF+gn+pn+RbepXkgRIVoKu4gXo0S+ eJfHArFcrBKrxXGuk1PitDgvrotbMli2kh1kEo9k2Vv2kaWyXJ5WzVQYZ3uI+p2axRnfrGrUAXVG /aJBC9aaaq01hzZQ+0ir0Y76Yg6yhFtiLZMt8y3vWzZZqqzK2tza1TrPusi6xrre+r0t1Ga3fW7b w1HEUQRF4rmHcugItstBlEsLaRgFUinlIlTEY72aKgaoteJj0U6Uey0t3ZSXoSC/xBJJorFaKj+h FdhJhB54n1Iwg5bxTR+hIq4uB1bL/dIj+hLTAm2kJDyQp5iTajlbnakT9cMAcUx9px0dsVC0FiPp BzXS4qeOYLnYo1yqiyLObQnT9odyMbritpwmr3FXFKql3JGzSaGn6IF7/H2eayiY2oj26EWvyQjK lOMokuP07q1llpggKkQvHKIVYpKMo3coEffhQaV2EKu0bFVrDlY7TZ1XZvmSsYXP4RipTLrUy+ab noe0UIaLAzJW9KS7yi0meLbREOos6mQnmiaK6TFVUhxX0HGRIXpTpNjItX8fN7mGGnAHO9Ryudi8 Iss9WWIvWmsjcJYZzYIsUU2/4hzz6T6uChtz7lbVFTvlZNRLl6gST+iheIjPsI1ZeLtoSxdFKm5Z RqmrVDcliFrIccxpApuYlUfL2+ht/oSWVGyeMvdTFPdLNfPSHe2gmIJlzBf7mFHmMI+5uZoLEEAl 3AFBPCq59u8yP4Tx9WjMoZO5T1czX1YzX9Qya1xn/SU84N5dhYuCkGlZy8jr8S3H94hs2I1E/s0I 4l66Zj5QZzl3X2ORJBy0NrWkqAX4RttvTUntMyy1V0rP5B7duyW92rVL51cSO3Xs0D7BEd/u5bi2 sW1a21vF6C1bvBQdFRkRHta8WWjTkCbBjYMCAxr5+9msFk1Jduxw2vu6dCPWZahYe//+Cd653c0L 7ucWXIbOS31ftDF0l89Mf9EylS3H/Z9l6lPL1GeWFKwnIznBoTvtunEy3a5X0fCsHJYXp9tzdeOW T87wySrWNwnkSUwM79Cd4fnpukEu3Wn0nZ5f6nSl83kVjfzT7Glj/RMcqPBvxGIjlowwe1EFhaWQ TxBhzu4VArZARmVE2tOdRoQ93QvBkG2c7jwjMyvHmR4VE5Ob4DAobYx9tAF7H6NxvM8EaT43hiXN sPrc6BO84eAjvcJRU1pWFYzRrviAPHuee0SOId25Xh9N4tlvuhE261r4/6Z8eEhazsLntVGy1Bk+ QfdOS0sX6kZNVs7z2hjvZ24un8F7RZu+rtK+7LrMm8XwDgzEC98bytOgxtqd3hXXRN3ws/ex55dO dPGFRJYayC6J2REZmbqb/zdEOvXSYTn2GKNXlD3XnR5dEYrS7JLKiFQ94kVNgqMiuMnTbFYENf5N CAh8Xhj7TOeTfOZeaWD2s3SSF5H9P6xXC3CU1RU+/2t3w0NWIKnTlHbDEmlZ7EJSMISBLAkJJAEC ScjsRloWQgBNLdjtKCBD4qMGN6K0FBSFUjpjpYvQTUJt8AGBdoZBBacDC5nWmQhUCywpjAJ1IOTv d+7//5tNqIqd7uy3373n3Me59557zt1iuEHUVeOCJX43FpLDP7U5FK7JQTN8AhJ6RZfgGB6MphQE w85clnP/qJbpdLvC1wjH7u661FeyyJTYMp3XiIvsHAkHg94qRz2e6Jgx7Bf2AhwkbJwq6hPuG/to m1zlXul0gbB9NNePboFcL/Y8I4NPtanNR4tRiTbM8xt1Fy1ObyGf1xOIykHWtFua1PmsabA0ie5B N9x3H/FbOTXquDfxHeJMG1a4PDcqpX2JutbQl1a4S+dV+12F4aC5t6WVfWqGPiehM0uSocCGR9VM 7FSxGx5XXu1nAb5aZpG78MHgTNww2BgdVuBX0uWAUZLTFTEU3HZBYmSu+AfxWGqmTbj9kqgCtxUC yVUUdQZnGr+BARkZX9inze5I6tSmX+Fegnq7mUuK5nr61if3qfexblBYgb3qvXJpZXU4PKCPrggx KhwucruKwsHwoja9YbHb5XSH9+M1WBBeWRi0Tr9Nf7MpPVr0XACLWC7lwrNlym92S+vnNfuk9RXV /v1O/FtYX+lvwWuzIJgfaB4FnX8//qT4hFROSLnm4hqVSrgVLbJDqNL3+4gahFYVAlGvaZNIyByW TKKaNtmQOYUMH/x9gaPYp/bMoYIUz81nbtWmTKMM5Jmkj/K2TXgTkTzJRITWKe9JXjVEi4Fq+wh6 UztCEemf0kToGuWIHlRG0FH1dXoV7VMhKwNXy5P019D+aeAzYC2wHMgBngR+B5wEGrmOPhuBCozx Bx5H8Dnqth+jn2tH9AuYrxw4DAS0KqqEbq5tEv2R65hrBsaYjPI8yBfYMA7KC6BvRdsKwUeoGuV1 0F9H+S2Uz9s30BWtSj+MchzybMw/HGP9But5HvOfVkN6lxyRhmLsBdCXgB8HrwY/hrY/QdkHVKFP Odbqgnw2ynOxP8UsB9aq5/Rr4DXYn3zo70O/l1HfiPJW2LUJc5xAebBKNBJtquQpFFVG6OWY/1ms u8tcO9tYmVgT7Bc29cV0k9ewfckw7OtFr223YWMfhGiPkk1nwKuAMcBY+Zg4t2roZ2of4ywAB0nf xT6twtr2qEvoVQfpB2DnDm0fnUf9yQRCNF7dpu9TrtJy6N61bcFrdgn8azxwnXbJl+hXtkxqxP7l YfwfA/djzHuEPyzBmYf0S+AV6sewP0S7gO87iA4Ye6Rf4L1BfQPOFevWu1EmFb4M2LHuTuAW24H5 n+U953OXqnoUlHmeNXz+mPMx4Gfo34P2m9ifcTZ2jNWEOT41zgHzMQPse8lgGywIPzMh9j5CIZlf lxHay3uFPZsD/ADlu4DpQD3wEeb/NtpPEf4Kn2HfZP9g38BYpXxWwmeNNVTAx7rMO/MO+seBXcA2 2+u0F3gfeAXrucL3hX2W7bTGZt9iv7ZY+HcdPSdHZCevk32ql3HecVrNNog7CN+ymO8d+z6z4qHZ 4IASo1nss+xvFvO+CPtxH/lOJLh3rddh+3pm9N8ufB2+aLG1Fwk+QwGx3/jHo16HD59FrDpJfq2M 1iqFtFPbCVkd9icGuYdWO2I0HGdZhr5b+/FLDHtMeghzxdTd2E/ML/Y1Jo9UY5Km7ca5k3RU2y2v E+XbuD+kdkPHzEjWfV35/wL5lLablqJ8UYvpOtbzS74T9rg0DnBZDHkL0ACMcXiklxx1Upt9Pjlt RFeBFaqPcjUf3a+2416mIuYRZUI+35Yv4u5CzFEhxaWJSkzy2lNpg5pBi3gu+RR8AuDxwSuT/KiP z/X3JYstf+3P7IemTwXM+DvDjG39eQjwTc4NHJ9FfkCMBsoNf9WbEv55lGrA5ZZ/9vVT/XSSfx6D f47t75f9mXMLx3frnvLdsNbP8ZFjHMdIjnMcA6z2/bm3v8T56UURh49RtXm3twMR4KfQjUDe+rMR h/U45w5bjEL2PAopRylkO0TL7I/Q07YjtAzr7kzk1IV6s5lPs61cyvuEvNhs5VEtn74h4tkBekDE m/00WuRR2Mb507aTztvyaKgZV+J8D/kOok2lyDdvwe5/61dh+6+Vy1THcvVR2ix0jSKuf6Ke0D/n nKhspZUiF3Xo59R8qhd9d+g/tHmRL/fQU4nxuA2YZWy/PU1yqBdgX7vI+euseMxn7zikn3RUIU6c pOvqDcSwOtqmHQLzHkSEP5aLvkf0pWKsOv2sNgqxi9sAahxcr//N3A8Rb4SuStQPi73AmNiDPeI9 EcO+RqQUe4wC9gtoH6MO3DvIgHbawrbgPp4S+foq3kcx5MZCvA8+NXK39g/9fdyzbyXy8F2I+Tf0 44i9c9F2ppmry8TbAvdHvDfgI/bhnGP1E5oH8TNC70G+0f44fHIXNcGGctzfGepDVGqLo/yG3mHG 7SrlEMZ8gp4S75PEO0F32Q/px+E/xnuBbeB3CtvzMmL725SDNc1K8WAtLbQT/tcEv+sE/mWADgM+ IA8oNiAPgu6v8FHOtTuUTZIX5S1yLW2TI+pgyKDHO/L39ID6Cs1RXqMB6lLkw4v0vOylRmUOzriL GjWFPkI9ro6li0oX2n1Ol2FXozaAlkM+TknD++Q83o8BGog1n1JbaIWi0yX1Hqx/M3nQL6610Rmt BjnkRzQOiDPkidShplCHrQlvWszH4wOHMX4GQ11NWaJfEoStFtjm3ybZvJlWKU8g7rG9m7FvSfay rQk72+ks2/jf7BN28LjoJ9r8nTYQ6R8CmQb3zEvitDvAh0nsYuY3OOcFWyv8eiFi3yq8Wd6gjRjz M6JutLvFc+Kldms7ZAtQngxkoTwSskfAv0C70yjXQX4c+Atk+Wo6TTPj1C7Ue6DvAEfAD6PN3WC0 7f4T0c3LBm55UJ8GuIFlgAJ5EzjH4J5P0K8YPNPQdbegz0HgXRNphqx7OjAHfZ6BrBCYgnoIqGPf vv1d83/mL8hnd8q9+Uu/weifk+6YrfP8Cu6fu6zz/ypOeoP2ZXMfrHUk5dIvzZkWwxXzkoHYPAkx apSIyxwbEY9FPDJZvAM4LoZw70K0F8D7nQZyLBbxELGY4yHi78Mqx/ubsCdEtZZdzZW+NmV2qzc7 i7llaraoFhYb1bmi2lJtUG12AyvT04WydehwgwcOzhoyLVWZTfXAZUChPPyWAS8AOqDSEFMvK7Na pZHfCb6jlKJeSjL5lOLWgoKs+oNKMcJiMXUCipCOE0YVt06YYLB3vMGjRxs8MhMTD0LzPKAe+MDs ronuKcOyvNMylBKoSjDPC/g9CHwAdAKXAQ12lZAXKAOCwI6EtFP08iklrd/L5flKzAWXtA50/of1 6ouN4rjDM7Pr293zgc+Hsc84Zu6wYS97jW1sHzbijOfOdupwCXYwGF/IyU4pqvxAamNDhJSGthKi kdrk2kj9Q1WMKpAQfmB9pvbZoNpq80BIkBCiLxUlVsULqWh5SIlKAffbnXOgEg996N598/1m5pvf /HZ2bn9zjb0Jv9INx90Y0I1wnZJiSDfcdrvDuqcNf2NgbnmR3cqJRKM0tsZd4/Z0PNF4M1HJbmNQ A7uFVHGL9AJDwHVgCbgPaPhzeItkgdOADQ9qSzaxgX2KcVl2BaVwbeHaDa7d4Noh1w4VNGcJBY5g zBl4OkMYOyM2Di55ljS24FnQ2AXPBY1NeCY01uPp0ViJp6TQVpLIKEksUBILlMRdJt1HmcSKJ8kg cAFYBJYBD6lHFjkGMJw9txAOOC3tQA/wITABLAA6uYCSuroVzWBh9DLgIX4WQy3m+opBE8PCxLDS Tht1e9uBHqdN2YFPUkmyFny24BNjMazyZ7lws7vcn64YV1eMT1aMK46RX16cPrgu7vLddTGng+7L wXAa3i3wkQIPFbhOcs5qbnKpSVKjpM2SGiTVS7IkvSgpIiksqUJSuaS1ksokrZEUkLRKkk9SsUPT ViEYUwZjymBMGYwpgzFlMKYMxpTBmDIYUwZjymBMGYwpgzFlMKYMxpTBmDIYUwZjymBMGYxZWKGw w3gKtTGexzNw6aqkTyRdEcXgg7Vxftep032Cg98FjgBDQB1gASYQdjRKe+6DF0Hbp0M1fDBhKG04 37Thl9iGH3gbUZWt06Ew53gftWLbtmKjtmLrtmLbTqC8ACwAytd9TInNwO+H7XHMXzmDUL5yQ5l2 I6STkvol7ZFUJXaCHwJfADeAd4C3gb3Aq0AH0AbEgBZKAkv0PmWBEfp9mqUKpcSgDD+Bigq84QOl urjEkLuJwd7PDa+B/9/lIt/BHdCLJKJSwuk0HXTZJsMuTxKTbgSfB/eDf5uzTmHYBHYf6DfYYaAD uUg16Nu5SAi0PxdpAL2ViyScdc6Zp3jCoHuJqTsO+4lFT4L35Kz30b1bUl/O6gBx6WF9LvIRTxTT ajLMJqGtIqbLlcRikzn+0MyrNMf/ZebZ5Az/yurhX1h5nc7wu9ZR/qdInlFRwm/WXeM3wtf4HyP1 /A/DUIpivjh8jf8e8qla18FJC6uN5l9ZrfynFjZDHZpRfwdDj1iTfASuMN13uat+O5ynJ9F70PyI H7B+wIdM1Gf4oGXxvXV5ujHHd2EaCF9FrX+GpzD5K4WJv2lFeScm73DizPFExPUo4IGKKt4WvsO3 IYaWuks8Zm3jm+vu8Bqri28YhqNZvmeVscpoyeZpjdiiZf+iZQ9p2T1atlnL1mvZqJbdpGU3atn1 WrZaK9MDul9frft0r67rHl3VmU70svzykvgGwauszON3yKM6perafuaUKFASRnVGdpCAvUZJsVRf 0m6NpvLa8i67JZqy9d59A1OUfpB2Wu3F/ST1rZD9oK8mT72vv2EX1SSpHUiR1O5k0GY/ylOyewC7 3BlwvMoOdAzMEUorj/+kqsDpdMfAPN7R5YSOpUn5kfZge2B76daXO59TDBXK6NMr+IwdTfUencP2 ODet8S0aqn2oZp1q1qkGq+2fp/oG7PPVabvRMZar0yn7/b7QmwNzLMjKuzrnWIVD6YE5dZoFu3Y5 7ep0ZzqdwiN2dchuQehIrUPQrdZJyNGR0Grd1bFJqeOswtFFHIIueJZwV8eDZ12dSh3d1HCoq3Mq FHI1OIMPu5rhGvKMZo4Oklqoamul6jQddFR0sOa0o7KjriPThKTOdCX0BWK6jkz6giuJPZWEC5LB ryWDruTHTyWWlCjnVyTKeUii/4frQLJruC9JU70DUzpJpjvelFzuH9nu7oxVldvPVs2TG8rfSHE0 bXtrknZxDRJ/ezDqj9P6DAbkjlGaSbvWPxzL47M9kGmA42FbOPhe1bxK6DnXgw/NqwpdLyVeSjhd 2PNO12o0lxS6gu9tC1fN03OFLj+aSzHv825hbGw8OvZsw3NV/9tFgl3DnfIbLADuD7sYHxt3rrGu TnzHScq2+lJ26+tvDExpWpcthjrTaKtbaVMUt23KMMBvdabHCld0/PA4JsJqic0CpwaBI4PAeUHg sCBwUhA4JggkcIHsLZC6BfK2QNIWyNinE173PHfaPc9NuPYE0mcTFThVCBwpBBK6QDYXOCYIZGeB 84VAWhc4YAirGido0y3CTf+1SG5gz1xpEsUdOx3jINl1OErHVppXVst5LaEowgfJVCPxi4zOerQ8 +6cIkiJ1ViFeTZ2lpFL3FM0yxTYWbmPfPIg/ju/0fxl/7XGctMP2P0KxuSFcGi7diAKvP/IopCw+ EkXk3ySkLmKW5buYZX/RPObw0nKx+3ODCh8N+UZ8f1ZuqmqP76i64Lvuu+8r2qRYasToV/q9v1R/ 4dUMg/heISnPDl34PEQ3NOo1DFbk8WzQjDJNM1RF2cCMMsYMI8/SOVX3OueR1XgRKkUq82gaU3RP nv1QFIe0Yxrr1T7XmHaJriUGUVhaeDmrZyNsiaksz2ZECTGEMWJcN1Ri+A1mXKaNpJjl2CwJRiv9 X2ZGH2SC91wjeA+3HvfH2+OBrfXOGtw7UVQX/Z7/4xN1QYc0fzx+4uP4lId17B4QfkOUVjYbEcPX 3GNQo0ilpYGtJIMHtbmBjmYyo/QQGaVhJUzDa8KKQtWyx5fsJ1eVNtrz9yd/7d/z5BTtfHK5aP7h y6yV7Xycw4qSNFb0M6xoKeHk12LD8SBtIbFAqmJvYC+fXztXcXXt1XKDBwKc0DJkoDUBLMzFUqKv d09s6xjFo/dXRojX72XedSJMQ2G6gAD4ZfYzEmC1+K/RKUoXyXXCGoggvdgg8RCpyLPzU41IEf4H mdE7j+/s9GdGDz3IvHYPrxN3MzgoLAXuLUMyTTTcWLFeXVvGNI/mqTGbGre0bAnEmjeZm2pq/sN0 lQA3cZ3h9/btpd3V7uqwdleSpRWWLdmKLeFDtoiLlmBOFzBOAniCyzQd2nCkRWYajjANDSTmKEdm SmgbOvUktZswSQOUgjlSmAkZ0wwMTKYhXNOEKYdJq8FtCC0B7P4rOQy72v33Pe3T0/z/933vex24 Dm/urXlm20+frvnzxkV93/uw79d9O8Z3rF44vf6V95nDjKNp4dZDP84Pv7b0qbjvX5VNs7F8cNdv /W47A/NHbtAtdBaVobH4D9bzK+Ov+l8OvBLcFGfcNGFNVEdE92R/S2BabIN/Y+yQ/6/+S/5LsTsV os/AybpzZDA5mPqi7n7i6+TXKT5qjHN3uBe5nzNeNA6hg/6L1Kf6OWPQ/2Xsn3F5noHHRoMkJHMu jCIjURztBxT7g6mgFVwWPBv8IsgEI7IikGpPNTVUjatt41xrZAsx7i3GMnchWsGQkq2OeUUEhaMU uCXQAvQTyPMQsKOfRK3KiAVjIxYMjFgwKmLBCCWCR6A6VTTHtYRDWA2ZISrUT02y/FK7qw7BC9Qy 5bgC+yxVMZWUMqIwSj+VtYQ6E1QmqmCM7bf1qhbNyjYs0HBKs7Qz2ucarRm1T3ysJ2basE7MyN/O 5Tvtx67b+fu5LoD5A+iG42pnLpu3HyA2uzKdyXwOQGwD2a1lxqZQZydUuyuHc7Y0qtgSMggubDkg wlWUpU5cnk7X1fpKvICFEq8WqYixbNmYioZ6AEVjGlBRNobFLFf41gdQSTfiG8ODqVsfnT7hqqvS h2+66Ozvn1z/7gdfnZ7knj5tRgfG/sT5J5JTH5+wPOOj7upbe3pXpJZe/8t3W54cN35y63sbfnXA 49KbozXjs8NHOdZfG/1O7aTsDxYBflaN3GA6gEEKCqJPrJ3lgVlkojTLO12fHlwZ5B4XxunjAvNK 2kJrQ31ot28A3UCD8n/RV+SuIFcJ8ZIV7mUAawJ1cFIYy06/SHkYSnMSGSNFMWXsleEJC54YI/pj IicrSFZRO+wdsIntTQTpwXswxWEftFO4DTM4pEYRuEyTHwJ/ea0Ua5Wni1TLuzOgEl3JfMJmWTYP 57csgwpoGQRlgE+3rDafKEoK6oxEGkdzi+pqNU8EFxNayDFFx4aH9Jk7F/Sexmb+3JLlOHy/cflT M7tnr5n9szeXt064cnkE79pNld+707V2yeWFy7cOD0LGVgDjlgHjNGTi89ZrG9ybwJSFsXuzY4Nz vZx30B5edfgEEuT9QljUXUaJJ+w2O3h+k9od/sBxQD7luOT4B8+JnOBWsUqpRKXVkBpuCU8yhTnO HzpXcyvdK8MbuR3mW45e51HuGH+Gv8CfFS6KN7lb/DfcXf4/3nvB22FfwrXBTc0N/yj8pkBMXj9m 4m0mNvupW5aGsArJpNrsNGPMuktjHs5xircpWB6vt6NVYoTq23g8C7ZNhXSfhYQzfD81xapzszFJ 5Nc4TpXqW3SqVMd6C/KpPtNHfGvHmNF18JPRIseGFFq5FqmcoxcKlMvb967cbZsxE22/yhY1gLUn rtaKESjNjmqBHfcBsYsLtk044Fg2b7PHKLUFoNSCUaW2CpTaKlBqPXwZ2AdYaH7Q2dWM3RlbZgEc wK0u4F9hanXkf/uEjMOeQcjwxVBoOYotR7ElF1p75cy3ZqLDFmwcKXKvkbHhgxrqG9MRm7Hlo/Tk 6PkPUnjV3G2Q4dZ7u84N317Vi2s/vD78DV7c0bHFwIddjsUv/zLxxhtY+fzi7uv/vvDcfI/wwguv rgMEWcOz6XuAoHJUj1utzWYad2vrklS6bKazdczMKrpCi6fGojpMG0oFpqZoA4GhNNmUXJt+r+bt JN2WXhFfll4f6o4z42qmBCaHpj42T2diiXhNk6fJyCSYak9lLaVLomhgBkm6VK0TQ/QHAqZoeKEz IFbKfoNNVZVwlTFZUJFpb8/sQNBhEkVMsUSMjREZ0s1URRSxIW6Iqv8INQYFkEFNt8zABCQmxe0i UURTPC4SInrgoU3sEY+JQyIn9uOPrEAaYLK1Iopcqst0Dblo17UGURMbhF+kbEY3FzBzJ6+CuHbl r6pXC13Hsw9GddbmN/AZCF2TYB6SPPMoxzsLB4K6g/LmNMbrs2tmy2hjkfVuW2i1xgiR6UL7Uf6D vk7EydDEcc80VvpVQ9jxu10nN9xZu3jP2Dh29lePb1vd9/0r1/HTz7e3bmld3Tbj51Vm02M1yUg0 OD62rnbN5b8dwU09yxYevb/50wNLp5m/+ZOH0le91PXJs7lNq196FpLaDgv0W6Ct4CoxZ20yHVPJ dkcPOKshB+vDOqEUSiEUqByj0zrzNve+4yQ9wA5wn7F5Kk8GaWcZXcYkHWk2zc1h5rJrHa+zr3O9 bC83SJw8xRPkIHuoPeQ4dZycpc6SW9Qtwtu2EBNYIBHFYJbQMDXLmhzy2j3bSQ/ZQwix2acZ9aSf lFsyDe6XhlGcgDgV1sed+9h2BMFSOFgkt3N4Fvz7rTwHrufQ3lEpziXA9hTdjn2qdxK5R6S4UKKM 7f7sy14WQYyBVeDwCgaPs03eehxOD18J4fDfh68wh4fvb793ERwamgN/5ghww8BLrP0Ch3nEg4Hl FdrNs2agjScGhf+oXuZucjdVehANKl+q5GN1wDegX1Lp/dJB50luQKT7SvbxB4T9Ip3WJrN9Qp+T LtcahUZn2kuXo6hQ4STnhc/ECzLZreB3uXcc78hkFfeiskolk4UpzrkCoTRdh+VMkhSHIPIlWOdF 0ZQUL3RgXTcN5DUMJEqSbgjuKobDiFUkZKhiu1RwN1Matkv4ljQiUaZ0RqIUKSllJWJKL0mU1E/V WpLePsvAxla/pBmFvM6AvBboABqYAxW0raQ6uszZFvsRYy2PJrlbPnECeFC8NT8kwyglQAiLMsiP DO1TM0r/yHkIQn+h5YSwV83gR+Tu/+xXfWxTVRQ/593b91776Pq6rq/tqK5bP95Yu04ENqfIOgTm ZLCBCJuIYzBRDAEHguIHziBqiNH5kQFTgUTEACbMr1iVhP2xKMQZiWYmaBSICxoj8QuDirae21aI kJgQP+Ifva+/+8699933bs+59/zOUXIhicJKXWeOBzVwPOr+JS8tWr+p9N7UsXX++svr+mKB8vmp YzyysXV67z2XPfPbC9L8h4pr6m6dN2l/qolsWEkMeSvZMIYvvwHB9NGEldyIN0BVOElO2VobpFvi Ea1Wjwfil8QT8Za4xVagjqnWGkbdEfzEPhz+0q4qQUvYCLrCofA029SgIkvW4kNxFoiPL6sOTy1r CCfiC2B+wRx3izHbMy80J9Iea4nfEX0w2lew2709uj3WH3/X/a4xEB2M/Vw8miyp2ayB0rJgKByx F1UAR0+JFx3eEm+7dwWdPhFyFhb6K4roCBBxLsTtOIAck8yfcBTyigrNO6XKU+dp9jAy1w2vqaFD JprC1KY2AUzdDJiXmAnTYj4aL5miY6gKUISzUgvshffhG0oGk1JZYlSzjg79kC4FiPeTuOOVyslZ 4qQ4U7hAXdBntIv2wBn+5Fn+5Dn+5Dn+FPeXiQ+zESV5y2yO9SrHIpRgQVtmdqLILyjULyjULyjU nzgzhb5XmwmXPBnq7IIuwZxiyBXO+tAJ482IGTIjOerzWESuUibiVUNcFLySQ61EI7y8fdEVY9xG R+rXSR03rkfpvQ/8qVPuqsT11zeX+x7+oKEz9cXx0zgm1toYuzh6kccIzL105rp18+/r7Y5ffpE5 0Swv1suvvOLa1Zs+20V7py/9BQtYeun8DyV+aGaPsSOMfujh+IT6lPYJZ3fzDfwBdYOPIzqUas7s bCs7wN7mh9kIl8vZfWwjY5KkcIsFZFBkq+w1JMPilJ2KrhvOL9Wj+le+b2XnkdFHcYQfk/kR5bB6 xHnYxwflQf1D/Ijz19X9zkF8h/Md6vPWnd4dvn58S5G7nd2jn+S9aq91O5dbvXda13q75W6lW5fL fFN5g7WVtVrb3HKZGrEG9JCz0h3xymEpzAI8YCmVS2klmsa9hsF8zABF5RooFq6hLDEDaYwX2Aqc uoslpasTYzjXONMo3CI+Y4oDME2aMSknAB2/pb1jujTnUL/YRBSt2eUhhbx0WsF+ctRvSTcQRauU 5Vg1HNpG88b5RM7j1kI9Rr8xYLBsJDdgnDQsxptSExSjW7h1sQ1PjJxcSTx8l/4TbUdv1cmTXSNQ d0LkOkTREwUPq+R8wFs1Ihx8VFQOKg8JlyS80J+dkMiGyJllIjJXzbiaMBunBFkurlKy/Fzj6os9 EsTGGXtj/Qt8FTWupsprZm7eGG5js4Z3v53qGU5dtdZZGlaGHatvGfsS7qH/s4UY4nseAQ21N0Cj c1BYC8n0gURbYe1sGcF+o3KdjXivCCIQxKhlHDbCVTgX5mAnrsK16nrcCk/jNulZtsW6xbZZ67Hv gn77QdsB7ZB9NNhduAbWalugD3fDHjyIH6NNTkprEsVoVRXZJoiSgY0oVrMRS8iU2tiS0k+JwhKt TmvXWFpD0HSKhJgmtO5qsS+032Zndml2Ceth0hBDJvq1FnmhfBu9iWy6D9+HUdJ+rAdv1CeSTvp5 T+hdGZeQIVjy/5hLbe7N+PuJg2QE/UQmyRHqJUdeGiTHbXhErlgq3XRqGIunl8jq3QWoYjWPpMbu m+Q85sEByJYl/y9g8iykN/978F/OQo4BqMuzsM3NQtt4Puwzz4eD+p0vZlH4dR555JFHHnnkkUce eeSRRx7/NUACzOS9RcCEhMUEGf5+CQGYfzU+BaDhargGmkRjlqjmzoO2f+DD/1DhcAsIreikFw71 tN4OuAluhqWwHG6HNek0jWZ7O3O9q0Rv+vNzr5x+zy8MIP3dX65BhSW52Qw8VGNuZR66srJMUlxY jlupJw5Tc7IEBbSerMyo//6czEnem5Nlkj+tn9Hc0jQtWr9yacey2OQVyzobb+9YtnTxhXWTImZA M7SQMadBlForSSEdsAxiMBlW0L0TGklpomcpLIbZGUWuplYHPXlhc//Np7MaZvuoqoN5YCEt6lAF 15HKPyN7M2qTArGHRlROkmj9cYclUiFNP1PONWUdFUjQEtao4jVDKnIpZ1Hp+M0zV71jb3dM/FH1 qZmnn5u1v1rcXzu48/HTD/76m7VeFU8KG2fe/PsARreEOQplbmRzdHJlYW0NZW5kb2JqDTMxIDAg b2JqDTw8IA0vUyAvRCANPj4gDWVuZG9iag0zMiAwIG9iag08PCANL051bXMgWyAwIDMxIDAgUiBd IA0+PiANZW5kb2JqDTMzIDAgb2JqDTw8IA0vQ3JlYXRpb25EYXRlIChEOjIwMDYwNjI0MTc0MDQw LTA3JzAwJykNL01vZERhdGUgKEQ6MjAwNjA2MjQxNzQwNDAtMDcnMDAnKQ0vQXV0aG9yICh3d3cp DS9DcmVhdG9yIChQU2NyaXB0NS5kbGwgVmVyc2lvbiA1LjIuMikNL1RpdGxlIChNaWNyb3NvZnQg V29yZCAtIDQ0OUREQjZELTM1MUYtMDhENkRGLmRvYykNL1Byb2R1Y2VyIChodHRwOi8vY3JlYXRl cGRmLmFkb2JlLmNvbSBWNS42LjQpDT4+IA1lbmRvYmoNMzQgMCBvYmoNPDwgL1R5cGUgL01ldGFk YXRhIC9TdWJ0eXBlIC9YTUwgL0xlbmd0aCAxMDk5ID4+IA1zdHJlYW0NCjw/eHBhY2tldCBiZWdp bj0nJyBpZD0nVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkJyBieXRlcz0nMTA5OCc/PjxyZGY6UkRG IHhtbG5zOnJkZj0naHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIycg eG1sbnM6aVg9J2h0dHA6Ly9ucy5hZG9iZS5jb20vaVgvMS4wLyc+PHJkZjpEZXNjcmlwdGlvbiBh Ym91dD0nJyB4bWxucz0naHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLycgeG1sbnM6cGRmPSdo dHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvJyBwZGY6Q3JlYXRpb25EYXRlPScyMDA2LTA2LTI1 VDAwOjQwOjQwWicgcGRmOk1vZERhdGU9JzIwMDYtMDYtMjVUMDA6NDA6NDBaJyBwZGY6UHJvZHVj ZXI9J2h0dHA6Ly9jcmVhdGVwZGYuYWRvYmUuY29tIFY1LjYuNCcgcGRmOkF1dGhvcj0nd3d3JyBw ZGY6Q3JlYXRvcj0nUFNjcmlwdDUuZGxsIFZlcnNpb24gNS4yLjInIHBkZjpUaXRsZT0nTWljcm9z b2Z0IFdvcmQgLSA0NDlEREI2RC0zNTFGLTA4RDZERi5kb2MnLz4KPHJkZjpEZXNjcmlwdGlvbiBh Ym91dD0nJyB4bWxucz0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLycgeG1sbnM6eGFwPSdo dHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvJyB4YXA6Q3JlYXRlRGF0ZT0nMjAwNi0wNi0yNVQw MDo0MDo0MFonIHhhcDpNb2RpZnlEYXRlPScyMDA2LTA2LTI1VDAwOjQwOjQwWicgeGFwOkF1dGhv cj0nd3d3JyB4YXA6TWV0YWRhdGFEYXRlPScyMDA2LTA2LTI1VDAwOjQwOjQwWic+PHhhcDpUaXRs ZT48cmRmOkFsdD48cmRmOmxpIHhtbDpsYW5nPSd4LWRlZmF1bHQnPk1pY3Jvc29mdCBXb3JkIC0g NDQ5RERCNkQtMzUxRi0wOEQ2REYuZG9jPC9yZGY6bGk+PC9yZGY6QWx0PjwveGFwOlRpdGxlPjwv cmRmOkRlc2NyaXB0aW9uPgo8cmRmOkRlc2NyaXB0aW9uIGFib3V0PScnIHhtbG5zPSdodHRwOi8v cHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLycgeG1sbnM6ZGM9J2h0dHA6Ly9wdXJsLm9yZy9kYy9l bGVtZW50cy8xLjEvJyBkYzpjcmVhdG9yPSd3d3cnIGRjOnRpdGxlPSdNaWNyb3NvZnQgV29yZCAt IDQ0OUREQjZELTM1MUYtMDhENkRGLmRvYycvPgo8L3JkZjpSREY+PD94cGFja2V0IGVuZD0ncic/ PgplbmRzdHJlYW0NZW5kb2JqDTM1IDAgb2JqDTw8IA0vVHlwZSAvUGFnZXMgDS9LaWRzIFsgMzgg MCBSIDEgMCBSIDQgMCBSIDcgMCBSIDEwIDAgUiAxMyAwIFIgMTYgMCBSIDE5IDAgUiBdIA0vQ291 bnQgOCANPj4gDWVuZG9iag14cmVmDTAgMzYgDTAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDA2OTc4 MSAwMDAwMCBuDQowMDAwMDY5OTMyIDAwMDAwIG4NCjAwMDAwNzAwNjYgMDAwMDAgbg0KMDAwMDA3 NTg2NSAwMDAwMCBuDQowMDAwMDc2MDE2IDAwMDAwIG4NCjAwMDAwNzYxNTAgMDAwMDAgbg0KMDAw MDA4MDkyNyAwMDAwMCBuDQowMDAwMDgxMDc4IDAwMDAwIG4NCjAwMDAwODEyMTIgMDAwMDAgbg0K MDAwMDA4NjMwOSAwMDAwMCBuDQowMDAwMDg2NDYzIDAwMDAwIG4NCjAwMDAwODY2MzQgMDAwMDAg bg0KMDAwMDA5MDI5NyAwMDAwMCBuDQowMDAwMDkwNDUxIDAwMDAwIG4NCjAwMDAwOTA2MTEgMDAw MDAgbg0KMDAwMDA5NDQ2MyAwMDAwMCBuDQowMDAwMDk0NjE3IDAwMDAwIG4NCjAwMDAwOTQ3NjQg MDAwMDAgbg0KMDAwMDA5ODYyNSAwMDAwMCBuDQowMDAwMDk4Nzc5IDAwMDAwIG4NCjAwMDAwOTg5 MTQgMDAwMDAgbg0KMDAwMDEwMDA4MyAwMDAwMCBuDQowMDAwMTAwNTAwIDAwMDAwIG4NCjAwMDAx MDA5MjIgMDAwMDAgbg0KMDAwMDEwMTI0MiAwMDAwMCBuDQowMDAwMTAxNDU1IDAwMDAwIG4NCjAw MDAxMTI1NjQgMDAwMDAgbg0KMDAwMDExMjc3OSAwMDAwMCBuDQowMDAwMTM0MzA1IDAwMDAwIG4N CjAwMDAxMzQ1MjUgMDAwMDAgbg0KMDAwMDE0NTI4OCAwMDAwMCBuDQowMDAwMTQ1MzE5IDAwMDAw IG4NCjAwMDAxNDUzNjMgMDAwMDAgbg0KMDAwMDE0NTYxMSAwMDAwMCBuDQowMDAwMTQ2Nzk0IDAw MDAwIG4NCnRyYWlsZXINPDwNL1NpemUgMzYNL0lEWzxiOTVjNGE1NThlOGU1YzFlNWEwMTFlNGFm MGI2MWZlMz48M2E5NTVlZGMzNTY4ODgxZTg0YTJjODM1YWU2YzVlOTY+XQ0+Pg1zdGFydHhyZWYN MTczDSUlRU9GDQ== ------_=_NextPart_001_01C697F0.491F9D31 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap ------_=_NextPart_001_01C697F0.491F9D31-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 26 01:07:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FujJt-0006dT-Gp for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 01:07:33 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FujJp-0006TB-7y for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 01:07:33 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DE28543012D for ; Sun, 25 Jun 2006 22:07:27 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2864B43008C for ; Sun, 25 Jun 2006 22:06:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0D756144800F for ; Sun, 25 Jun 2006 22:06:45 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id DF9201448002 for ; Sun, 25 Jun 2006 22:06:42 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5Q56gEq020273 for ; Sun, 25 Jun 2006 22:06:42 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5Q56ftj020265 for ; Sun, 25 Jun 2006 22:06:41 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Sun, 25 Jun 2006 22:06:41 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.com Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [Capwap] Update proposal for Packet formats X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 66ff42a56498684039efb58366a4b354 HI, In the last proposal, I remove a field used for retries. In verifying whether it could be done, I found a problem. Below is the updated proposal, which includes examples showing how fragmentation works, and how retries work. Please let me know if you have any problems. This is what I plan to have implemented and demonstrate at IETF. --------------------------- Proposal for CAPWAP Packet Format -------------------------------- Updates from 22-jun-2006: 1) Cleaned up terminology definitions. 1) Added clarification about initial values for the "CAPWAP PDU ID" and "MSG ID" fields 2) Added timing diagram showing no fragmentation and fragmentation 3) Added timing diagram showing CAPWAP control message drops and retries 4) Put back in MSG Seq ID into the Control header, but re-labeled as retry num, and reordered fields. Updates from 8-jun-2006: 1) Made to look closer to CAPWAP-02 2) Added CAPWAP Fragmentation Header so that both control and data supported fragmentation 3) Updated descriptions of fields of packets 4) Changed how fragmentation is indicated. 5) Modified so that the Data (or Control) header is on in the first fragment of a CAPWAP PDU 6) Cleaned up Data Header, now that fragmentation is in a separate header and made the remaining fields match those in CAPWAP-02 7) Updated the Control Header so that it closely resembles CAPWAP-02, except for 'F' field. Updates from 7-jun-2006: 1) changed diagrams to make DTLS experts happier 2) renamed "CAPWAP MUX Hdr" to "CAPWAP Pkt Hdr", and made it 2 octets long instead of 1 octet 3) made the packet types start at 1 instead of zero 4) fixed a few typos 5) changed the formulas for the message type value and message element type value to multiply the IANA enterprise number by 4096 (shift left by 12) instead of 256 (shift left by 8). This means the the enterprise value must be encoded in 20 bits, and the specific type value in 12 bits. I checked the assignment of Enterprise numbers, and there are now approximately 16K, and also checked the OUI assignments and there are approximately 51K. Thus, 20 bits (1M) should be enough! --------------------------------- CAPWAP Packet formats: CAPWAP Unprotected Data Packet: +------------------------------[--------]----------+ | IP | UDP | CAPWAP | CAPWAP | CAPWAP | Wireless | | Hdr | Hdr | Pkt | Frag | Data | Payload | | | | Hdr | Ctrl | Hdr | Frag | +------------------------------[--------]----------+ only in first fragment CAPWAP DTLS Protected Data Packet: +-------------------------------------[---------]--------------------+ | IP | UDP | CAPWAP | DTLS | CAPWAP | CAPWAP | Wireless | DTLS | | Hdr | Hdr | Pkt | Hdr | Frag | Data | Payload | Trailer | | | | Hdr | | Ctrl | Hdr | Frag | | +-------------------------------------[---------]--------------------+ only in first fragment \--integrity checked-----------------/ \--encrypted----------------------------/ CAPWAP Unprotected Control Packet: +------------------------------[---------]----------+ | IP | UDP | CAPWAP | CAPWAP | CAPWAP | Message | | Hdr | Hdr | Pkt | Frag | Control | Elements | | | | Hdr | Ctrl | Hdr | Frag | +------------------------------[---------]----------+ only in first fragment CAPWAP DTLS Protected Control Packet: +------------------------------------[---------]--------------------+ | IP | UDP | CAPWAP | DTLS | CAPWAP | CAPWAP | Message | DTLS | | Hdr | Hdr | Pkt | Hdr | Frag | Control | Elements | Trailer | | | | Hdr | | Ctrl | Hdr | Frag | | +------------------------------------[---------]--------------------+ only in first fragment \--integrity checked----------------/ \--encrypted----------------------------/ UDP: All CAPWAP packets are encapsulated within UDP. CAPWAP Pkt Header: All CAPWAP protocol packets use a short header that specifies the version of CAPWAP and the type of the CAPWAP packet. CAPWAP PDU: CAPWAP consists of both control and data streams. A CAPWAP PDU is either a CAPWAP control PDU or a CAPWAP data PDU. CAPWAP Control PDU: A CAPWAP control PDU encapsulates a control message, which is a control header and its message elements. CAPWAP Data PDU: A CAPWAP data PDU encapsulates a data message, which is a data header and wireless payload. CAPWAP Fragmentation Control Header: Used for fragmentation of CAPWAP PDUs. A CAPWAP PDU that will not fit in one UDP packet will be fragmented into multiple CAPWAP packets. CAPWAP Data Header: This header is used for CAPWAP data PDUs. If a CAPWAP data PDU is fragmented, then the CAPWAP Data Header is in only the first fragment in the group of fragments constructing the CAPWAP data PDU. Wireless Payload: The actual payload from or to wireless devices. The format may be 802.3 Ethernet II, or native wireless transport specific encoding. DTLS Header: Protected CAPWAP packets use the DTLS protocol to provide message integrity and encryption services. DTLS Trailer: A field used to provide protection service for security of CAPWAP messages. CAPWAP Control Header: The CAPWAP protocol includes a signalling component, known as the CAPWAP control protocol. All CAPWAP control PDUs include a Control Header. If a CAPWAP control PDU is fragmented, then the CAPWAP Control Header is in only the first fragment in the group of fragments constructing the CAPWAP control PDU. Message Elements: A CAPWAP Control PDU includes zero, one, or more message elements, which are found immediately following the control header. These message elements are in a type, length, value format. CAPWAP Pkt Header: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version - the version of the CAPWAP protocol (the first is 1) DISCUSS: should this be split into major and minor, and if so, what are the implications of an increment of the major or minor part? Type - packet type, values are: 1 - CAPWAP Unprotected Data Packet 2 - CAPWAP DTLS Protected Data Packet 3 - CAPWAP Unprotected Control Packet 4 - CAPWAP DTLS Protected Control Packet 0,5-15 - reserved CAPWAP Fragmentation Control Header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|Res| CAPWAP PDU ID | Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M: The More 'M' bit indicates whether there are more fragment packets needed to be combined to reassemble a complete CAPWAP PDU. When this bit is 1, there are more fragment packets. When this bit is 0, there are no more fragments and this packet completes the CAPWAP PDU. Res: The bits are reserved, and must be zero. CAPWAP PDU ID: A 16-bit field whose value is assigned to each CAPWAP PDU. The CAPWAP PDU ID space is managed independently for every WTP/AC pair, for each end (an AC or WTP), and for each CAPWAP stream (data or control). For example, if AC #1 communicates with WTP #1 and WTP #2, there will be the following independent CAPWAP PDU IDs: WTP #1: ID1 for control going to AC #1 ID2 for data going to AC #1 WTP #2: ID3 for control going to AC #1 ID4 for data going to AC #1 AC #1: ID5 for control going to WTP #1 ID6 for data going to WTP #1 ID7 for control going to WTP #2 ID8 for data going to WTP #2 The value for each CAPWAP PDU ID is incremented with each new CAPWAP PDU sent whether or not the PDU is fragmented. The value wraps to zero after the maximum value has been used to identify a CAPWAP PDU. When a new session is established, the initial value is a randomly generated number. Fragment Offset: A 13 bit field that indicates where in the CAPWAP PDU will this fragment belong during re-assembly. This field should always have a valid value. For the first or only packet of a CAPWAP PDU, the value must be zero. The fragment offset is measured in units of 8 octets (64 bits). This provides a maximum size of a CAPWAP PDU to be 16 bits (which is 65536 octets). Note the CAPWAP protocol does not allow for overlapping fragments. For instance, it would be an error if the first fragment was 1000 octets in length, and the second fragment's offset was 800. To be valid (when the length of the first fragment is 1000, the second fragment MUST have an offset of 1000. (DISCUSS: need to have a timer that is associated with fragmentation to toss all of the fragments if they have not been combined in the allocated time.) CAPWAP Data Header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RID | HLEN | WBID |T|W|M| Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Radio MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Wireless Specific Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RID: A 5 bit field which contains the Radio ID for this CAPWAP data PDU. WTPs with multiple radios but a single MAC Address range (for BSSIDs) use this field to indicate which radio is associated with the packet. HLEN: A 5 bit field specifying the length of the CAPWAP data header header in 4 octet words (Similar to IP header length). This length includes the optional headers. T: The Type 'T' bit indicates the format of the frame being transported in the payload. When this bit is set to one (1), the payload has the native frame format indicated by the WBID field. When this bit is zero (0) the payload is an IEEE 802.3 frame. W: The 'W' bit is used to specify whether the optional "Wireless Specific Information" field is present in the header. A value of one (1) is used to represent the fact that the field is present. M: The 'M' bit is used to specify whether the optional "Radio MAC Address" field is present in the header. A value of one (1) is used to represent the fact that the field is present. Res: The bits are reserved and must be zero. Radio MAC Address: This optional field contains the BSSID of the radio receiving the packet. This is used in packets sent from the WTP to the AC, when the native wireless frame format is converted to 802.3 by the WTP. This field is only present if the 'M' bit is set. Given the HLEN field requires the header size to be a multiple of 4 octets, this field MUST be padded with zeroes (0x00) if it is not 4 octet aligned. The field has the format: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Length | MAC Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Length: The number of octets in the MAC Address field. The length field is present since new IEEE technologies (e.g., 802.16) are now using 64 bits (8 octet) MAC addresses. MAC Address: The BSSID of the receiving radio. Wireless Specific Information: This optional field contains technology specific information that may be used to carry per packet wireless information. This field is only present if the 'W' bit is set. Given the HLEN field assumes 4 octet alignment, this field MUST be padded with zeroes (0x00) if it is not 4 octet aligned. The field has the format: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Wireless ID | Length | Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Wireless ID: The wireless binding identifier. The following values are defined: 1 - : IEEE 802.11 Length: The length of the data field Data: Wireless specific information, whose details are defined in the technology specific bindings sections. For 802.11, when sent from WTP to AC, the data has the following format: IEEE 802.11 Frame Info: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSSI | SNR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RSSI: RSSI is a signed, 8-bit value. It is the received signal strength indication, in dBm. SNR: SNR is a signed, 8-bit value. It is the signal to noise ratio of the received IEEE 802.11 frame, in dB. Data Rate: The data rate field is a 16-bit unsigned integer value. The contents of the field is set to 1/10th of the data rate of the packet received by the WTP. For instance, a packet received at 5.5Mbps would be set to 55, while 11Mbps would be set to 110. For data sent from the AC to the WTP, the data has the following format: Destination WLANs: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WLAN: This bit vector indicates the WLAN ID(s) which the WTP will transmit the associated frame on. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be set to '1'. Note this field is to be set to zero for unicast packets and is unused if the WTP is not providing encryption services. Wireless Payload: The format of the wireless payload depends on the encapsulation mode. There are two formats defined, which are: 802.3 Frame - this is the standard IEEE 802.3 Ethernet II frame (DISCUSS: this needs to be confirmed) 802.11 native frame - DISCUSS: finish this CAPWAP Control Header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg ID | Retry#|F| Res | Length of Msg Elements | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type: This field identifies the function of the CAPWAP control message. The Message Type field is comprised of an IANA Enterprise Number and an enterprise specific message type number. The first 20 bits is the enterprise number in network byte order, with zero being used for CAPWAP generic message types and the IEEE 802.11 IANA assigned enterprise number 13277 being used for IEEE 802.11 technology specific message types. The last 12 bits is the enterprise specific message type number, which has a range from 0 to 4095. The value of the message type field can be expressed as: Message type value = IANA Enterprise Number * 4096 + enterprise specific message type number Msg ID: The message ID field is used by the CAPWAP control application to match responses (or acknowledgements) with requests (or reports). The value must be monotonically incremented for each unique request (or report). After the maximum value is reached, the value wraps back to zero. The paired response (or acknowledgement) returns the value from the request (or report). Note the size is 8-bits, and thus a maximum of 255 CAPWAP operations can be currently outstanding. The message ID space is managed independently for every WTP/AC pair, and for each end (an AC or WTP). For example, if AC#1 communicates with WTP #1 and WTP #2, there will be the following independent Message IDs: WTP #1: MSG ID1 for requests (and reports) going to AC #1 WTP #2: MSG ID2 for requests (and reports) going to AC #1 AC #1: MSG ID3 for requests going to WTP #1 MSG ID4 for requests going to WTP #2 When a new session is established, the initial value is a randomly generated number. Retry#: The retry number field starts at zero and is incremented for each message with the same value of message ID. After the maximum value is reached, the value wraps back to zero. The paired response (or acknowledgement) returns the value from the request (or report). Note the size is 4-bits, and thus a maximum of 16 retries can be be currently outstanding. This field is used to match a request (or report) with its paired response (or acknowledgement) so that accurate round trip operation time can be determined. (DISCUSS: maybe put back here the text about how this works. The examples of operation retries should help.) F: The 'F' bit field indicates if the message is the first message in a message pair. A value of "1" means first, and "0" means second in the pair. There are two types of message pairs, which are: 1) a request and response 2) a report and acknowledgement. Thus, the first is a request or report message (with the 'F' field set to "1"), and the second is a response or acknowledgement (with the 'F' field set to "0"). Note, both a request and response (or report and acknowledgement) of a operation type use the same value for message type. The 'F' bit is used to indicate which is which. This allows new message types to be added that can be processed without knowing the meaning of the message type. That is, when an unknown request message type is received, the response is the same message type with a message element indicating that the message type is not supported. Res: The bits are reserved and must be zero. Length of Message Elements: This field indicates in octets the length of the message elements field, which contains zero, one, or more message elements. The field is 16 bits wide, and thus the maximum size that can be specified 64K. However, the maximum size of a CAPWAP control PDU is 64K, and thus the max length is 64K minus the size of the CAPWAP control header, or 64K - 8, or 65528. Message Elements: The "message elements" field contains, zero, one, or more message element field, which has the following format: Message Element: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Element Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Value .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Message Element Type: This field identifies a message element of a CAPWAP control message. The Message Element Type field is comprised of an IANA Enterprise Number and an enterprise specific message element type number. The first 20 bits is the enterprise number in network byte order, with zero being used for CAPWAP generic message types and the IEEE 802.11 IANA assigned enterprise number 13277 being used for IEEE 802.11 technology specific message element types. The 12 bits is the enterprise specific message element type number, which has a range from 0 to 4095. The value of the message element type field can be expressed as: Message element type value = IANA Enterprise Number * 4096 + enterprise specific message element type number ------------------------------------------------ Use of the CAPWAP Fragmentation Control Header Example of a Nonfragmented CAPWAP PDU For both data and control CAPWAP packets, CAPWAP Fragment Control Header has the following content: first, compute next CAPWAP_PDU_ID, which is CAPWAP_PDU_ID = (CAPWAP_PDU_ID + 1) & 0x0ffff; 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0 0| CAPWAP_PDU_ID | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Example of Fragmented CAPWAP PDUs 1) Here is an example of a CAPWAP data PDU where the length of the CAPWAP data header and wireless payload will cause a single CAPWAP data packet to be greater than the max IP packet size for the path. Assume that the size of the CAPWAP data PDU is 1560 octets, which needs to be fragmented into a fragments of 1400 and 160 octets. The first fragment would have the following CAPWAP fragment control header, and be followed by a CAPWAP data header and part of the wireless payload and would look like: first, compute next CAPWAP_PDU_ID, which is CAPWAP_PDU_ID = (CAPWAP_PDU_ID + 1) & 0x0ffff; 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0 0| CAPWAP_PDU_ID | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The second fragment would have the following CAPWAP fragment control header, and be followed by the remaining portion of the wireless payload and would look like: (Use the same value of CAPWAP_PDU_ID) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0 0| CAPWAP_PDU_ID | (1400/8) = 175 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2) Here is an example of a CAPWAP control PDU where the length of the CAPWAP control header and message elements will cause a single CAPWAP control packet to be greater than the max IP packet size for the path. Assume that the size of the CAPWAP control PDU is 1560 octets, which needs to be fragmented into a fragments of 1400 and 160 octets. The first fragment would have the following CAPWAP fragment control header, and be followed by a CAPWAP control header and part of the message elements and would look like: first, compute next CAPWAP_PDU_ID, which is CAPWAP_PDU_ID = (CAPWAP_PDU_ID + 1) & 0x0ffff; 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0 0| CAPWAP_PDU_ID | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The second fragment would have the following CAPWAP fragment control header, and be followed by the remaining portion of the wireless payload and would look like: (Use the same value of CAPWAP_PDU_ID) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0 0| CAPWAP_PDU_ID | (1400/8) = 175 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------------------------------------------------ Use of the "Msg ID" and "Retry#" Fields for Retries Only the control path has message retries. Since control operations are not idempotent (that is, are not guaranteed to return the same result when redone), operation results (the response or acknowledgement) to a request or report must be cached and returned if a repeat of the operation occurs. A repeat occurs when 1) the request (or report) is not received (however, the receiver does not know that the operation is being repeated) 2) the response (or acknowledgement) is not received within the expected operation round trip time. 3) the request (or report) is duplicated by the network (this only occurs when the control operation is not protected by DTLS) Here are timing diagrams for 4 cases: Abbreviations: P_ID - PDU ID M_ID - MSG ID R - Retry number 0) No timeout/replay/duplication: (P_ID=56, M_ID=23, R=0) (M_ID=23, R=0) WTP----------------------->|----------------------->AC - process | | and cache (M_ID=23, R=0) | (P_ID=75,M_ID=23,R=0) | for M_ID=23 <------------------------|<------------------------ and R=0 | NOTEs: 1) AC and WTP have different spaces for P_ID. It is used only for CAPWAP PDU fragmentation reassembly. 2) The P_ID is always incremented for each CAPWAP PDU, even for retries 3) the M_ID from a request (or report) is echoed in a paired response (or acknowledgement) 4) each originator of an operation has an independent M_ID number space 1) message never received, so resent: (P_ID=56, M_ID=23, R=0) WTP----------------------->|-->X AC | | |timeout | V (P_ID=57, M_ID=23, R=1) | retry---------------------->|----------------------->AC - process | | and cache (M_ID=23, R=1) | (P_ID=75,M_ID=23, R=1) | for M_ID=23 <------------------------|<------------------------ and R=1 NOTEs: 1) the M_ID is not incremented on retries 2) the R always starts at zero for each M_ID and is incremented on retries 2a) message response (or acknowledgement) never received, so message resent: (P_ID=56, M_ID=23, R=0) (M_ID=23, R=0) WTP----------------------->|----------------------->AC - process | | | and cache | | (P_ID=75,M_ID=23,R=0) | for M_ID=23 | X<--|<------------------------ and R=0 |timeout | V (P_ID=57, M_ID=23, R=1) | (M_ID=23, R=1) retry---------------------->|----------------------->AC - find in | | cache for (M_ID=23, R=1) | (P_ID=75,M_ID=23,R=1) | M_ID=23, <------------------------|<------------------------ update R=1 NOTEs: 1) only the M_ID is search in the cache for a match (the R is saved, but not used in search) 2) the R from the request message is returned in the response message 3) the R is updated in the cache 2b) message response (or acknowledgement) not received within the current computed value for round trip operation time, so a message resent. However, original response received before response to retry. (P_ID=56, M_ID=23, R=0) (M_ID=23, R=0) WTP----------------------->|----------------------->AC - process | | | and cache | | (P_ID=75,M_ID=23,R=0) | for M_ID=23 | |/------------------------ and R=0 |timeout || V (P_ID=57, M_ID=23, R=1) || (M_ID=23, R=1) retry---------------------->|+---------------------->AC - find in || | cache for (M_ID=23, R=0) || | M_ID=23, <------------------------|/ | update R=1 update RTOT(drop) | | | | (M_ID=23, R=1) | (P_ID=75,M_ID=23,R=1) | <------------------------|<------------------------ update RTOT(process) NOTEs: 1) without the R field, cannot determine if the first received response was from the first time the request was made, or from a the retry. Without knowing which, cannot accurately update the round trip operational time. 2) it is possible to process the first response and not drop it, but if so, must remember the time when sent each retry. If max retries not too many, then not much of a cost. a match (the R is not saved or searched) 3) message request (or report) is duplicated by the network: (P_ID=56, M_ID=23, R=0) (M_ID=23, R=0) WTP----------------------->|----------------------->AC - process \ | | and cache (M_ID=23, R=0) \ | (P_ID=75,M_ID=23,R=0) | for M_ID=23 <------------------+------|<------------------------ and R=0 \ | \ | (M_ID=23, R=0) Dup \-->|+---------------------->AC - find in | cache for | M_ID=23, R is the same so drop NOTEs: 1) the R field in the duplicated message is used by the AC to determine if the request is a duplicate. 2) if both a response drop (or delay) and a duplicate occurs the R may be less than the R in the cache. If so, the message is a very delayed duplicate and can be dropped. --------------------------- Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 26 01:38:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fujnz-0004nf-OG for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 01:38:39 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fujnx-0007ns-9v for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 01:38:39 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8A9E443011E for ; Sun, 25 Jun 2006 22:38:36 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A396443008C for ; Sun, 25 Jun 2006 22:38:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8D729398007 for ; Sun, 25 Jun 2006 22:38:14 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C4FE6398039 for ; Sun, 25 Jun 2006 22:38:12 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5Q5c9ok027305; Sun, 25 Jun 2006 22:38:09 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5Q5c91X027302; Sun, 25 Jun 2006 22:38:09 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Sun, 25 Jun 2006 22:38:08 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Mani, Mahalingam (Mani)" In-Reply-To: Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] The Mux header flux X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 HI, Wow, you sure did a lot on the summary. However, I still fundamentally disagree with an assumption, which is you don't need a capwap header that comes at the beginning of the UDP data that indicates if you have protected or unprotected content that follows. Also, there is an assumption that the QoS marking on all data stream are the same, and all control stream are the same. That is, for some wireless devices, their data may be VoIP, or some other real time media, and others may be plain old data. This is one data stream between a WTP and AC. How is the STA traffic defferentiated? For control traffic, there are different types. I would hope that traffic to "add a station" would have a higher priority over a periodic statistics report. Also, one of the things that is different about LWAPP than most (maybe all, but I really can't out one) of the other submissions is that the 802.11 control frames are sent in the data stream. In the other submissions, the control frames were encapsulated and sent in the control stream. If I've correctly interpreted LWAPP (and which was carried over into CAPWAP), this seems problematic in several ways. First, it creates problems with QoS marking. Secondly, if this is the mechanism used for localMAC, it seems a little strange. (Let' talk about the other issues at another time.) So, in summary, I believe the following: 1) CAPWAP packets must always have a header that indicates if protected or unprotected content follows 2) The QoS for CAPWAP control and data streams should not be the same for all packets in the stream. Thus, I believe that the questions to the IETF subject matter experts should be: 1) what is the best way to indicate if the content of a CAPWAP packet is protected or unprotected? And does 32-bit alignment matter or not? 2) what mechanism is the best way to provide the QoS values of protected content so that intermediate systems can use it to remark the QoS values is CAPWAP packets? I believe that you may run into problems because: 1) no one used used DTLS before to do what is desired in CAPWAP 2) the TCP assumptions are not the same as when running on UDP 3) the TCP programing patterns for writing servers will not work for UDP servers. Oh I wish that CAPWAP had had an interim meeting. Oh I wish there was some working open source code. Oh I wish that DTLS in openSSL was bug free and conformed to the defining RFCs (4346 & 4347). Best regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 26 06:15:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuo84-0007L6-4i for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 06:15:40 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuo81-0000KM-I2 for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 06:15:40 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2EC91430112 for ; Mon, 26 Jun 2006 03:15:37 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7390B4300B3 for ; Mon, 26 Jun 2006 03:15:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6086043083D for ; Mon, 26 Jun 2006 03:15:06 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [61.144.161.55]) by hermes.tigertech.net (Postfix) with ESMTP id 0F52E43082E for ; Mon, 26 Jun 2006 03:14:57 -0700 (PDT) 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 <0J1G00J5NQ2XI6@szxga03-in.huawei.com> for capwap@frascone.com; Mon, 26 Jun 2006 18:20:57 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1G003LQQ2W5F@szxga03-in.huawei.com> for capwap@frascone.com; Mon, 26 Jun 2006 18:20:57 +0800 (CST) Received: from sachin ([10.18.7.96]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1G00MNJQ5EK3@szxml04-in.huawei.com> for capwap@frascone.com; Mon, 26 Jun 2006 18:22:27 +0800 (CST) Date: Mon, 26 Jun 2006 15:41:34 +0530 From: Sachin Dutta To: capwap@frascone.com Message-id: <000a01c69908$e7fdb5f0$6007120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests=HTML_MESSAGE X-Spam-Level: Subject: [Capwap] IPv6 Multicast address for Discovery phase X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1935610968==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 This is a multi-part message in MIME format. --===============1935610968== Content-type: multipart/alternative; boundary="Boundary_(ID_SyZ5icCcPzyKfzDyvk3Q9w)" This is a multi-part message in MIME format. --Boundary_(ID_SyZ5icCcPzyKfzDyvk3Q9w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi All, As IPv6 protocol does not have broadcast address so can the CAPWAP protocol be more specific for the multicast address to be used in the discovery phase 1 Have one address assigned for AC "All ACs multicast address ", this has advantage of limiting the traffic and also it is extendable for new solution like some communication between AC etc 2 Use all node multicast address. Please comment? Regards, Sachin --Boundary_(ID_SyZ5icCcPzyKfzDyvk3Q9w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi All,

 

As IPv6 protocol does not have broadcast address so can the CAPWAP protocol be more specific for the multicast address to be used in the discovery phase

 

1 Have one address assigned for AC “All ACs multicast address “, this has advantage of limiting the traffic and also it is extendable for new solution like some communication between AC etc

 

2 Use all node multicast address.

 

Please comment?

 

Regards,

Sachin

 

 

--Boundary_(ID_SyZ5icCcPzyKfzDyvk3Q9w)-- --===============1935610968== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1935610968==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 26 06:16:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuo82-0007KY-Gp for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 06:15:38 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuo55-00004v-3D for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 06:12:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BD90743012B for ; Mon, 26 Jun 2006 03:12:34 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3CF6043004F for ; Mon, 26 Jun 2006 03:11:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 32934398007 for ; Mon, 26 Jun 2006 03:11:19 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [61.144.161.54]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1B44E398012 for ; Mon, 26 Jun 2006 03:11:15 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1G00GARQDIW4@szxga02-in.huawei.com> for capwap@frascone.com; Mon, 26 Jun 2006 18:27:18 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1G00KLRQDH7K@szxga02-in.huawei.com> for capwap@frascone.com; Mon, 26 Jun 2006 18:27:18 +0800 (CST) Received: from sachin ([10.18.7.96]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1G00MKIQ4NK3@szxml04-in.huawei.com> for capwap@frascone.com; Mon, 26 Jun 2006 18:22:00 +0800 (CST) Date: Mon, 26 Jun 2006 15:41:08 +0530 From: Sachin Dutta To: capwap@frascone.com Message-id: <000501c69908$d83974b0$6007120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.001 tagged_above=-999 required=7 tests=HTML_MESSAGE X-Spam-Level: Subject: [Capwap] Duplcate IPv6 Address message Element X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0053408440==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 This is a multi-part message in MIME format. --===============0053408440== Content-type: multipart/alternative; boundary="Boundary_(ID_iWYvVnZSzhYfJn/w8bcf2g)" This is a multi-part message in MIME format. --Boundary_(ID_iWYvVnZSzhYfJn/w8bcf2g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi All, As DAD ( Duplicate address detection ) is the integral part of IPv6 protocol so no other host/WTP with same IPv6 address can join the network, therefore section 4.4.20 for duplicate IPv6 address message element is NOT required in CAPWAP and can be deleted ? Regards Sachin --Boundary_(ID_iWYvVnZSzhYfJn/w8bcf2g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi All,

 

As DAD ( Duplicate address detection ) is the integral part of IPv6 protocol so no other host/WTP with same IPv6 address can join the network, therefore section 4.4.20 for duplicate IPv6 address message element is NOT required in CAPWAP and can be deleted ?

 

Regards

Sachin

 

--Boundary_(ID_iWYvVnZSzhYfJn/w8bcf2g)-- --===============0053408440== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0053408440==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 26 06:16:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuo82-0007Ja-Je for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 06:15:38 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuo4V-0008Ve-Ew for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 06:12:00 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CD0EA430109 for ; Mon, 26 Jun 2006 03:11:58 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7BD6E4300D4 for ; Mon, 26 Jun 2006 03:11:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 55391430828 for ; Mon, 26 Jun 2006 03:11:17 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [61.144.161.53]) by hermes.tigertech.net (Postfix) with ESMTP id 37262430834 for ; Mon, 26 Jun 2006 03:11:00 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1G005YUPP0NB@szxga01-in.huawei.com> for capwap@frascone.com; Mon, 26 Jun 2006 18:12:37 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1G00MVTPP0C5@szxga01-in.huawei.com> for capwap@frascone.com; Mon, 26 Jun 2006 18:12:36 +0800 (CST) Received: from sachin ([10.18.7.96]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1G00MIHQ44K3@szxml04-in.huawei.com> for capwap@frascone.com; Mon, 26 Jun 2006 18:21:41 +0800 (CST) Date: Mon, 26 Jun 2006 15:40:48 +0530 From: Sachin Dutta To: capwap@frascone.com Message-id: <000001c69908$cca3c1f0$6007120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests=HTML_MESSAGE X-Spam-Level: Subject: [Capwap] Binding element for scanning report ? X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0809066744==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 This is a multi-part message in MIME format. --===============0809066744== Content-type: multipart/alternative; boundary="Boundary_(ID_F04ANlGZJMC4AghYErN8xA)" This is a multi-part message in MIME format. --Boundary_(ID_F04ANlGZJMC4AghYErN8xA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi All, As scanning is part of MAC protocol should there be a TLV to send that report from WTP to AC? Because for RF solutions WTP need to perform scanning and analyze that data. Currently for these solutions vendors have proprietary algorithms. Should the data collection part be standardized? (The data interpretation can remain vendor specific) This will help in achieving greater interoperability, as AC can collect data and statistics from different vendor's WTPs but the algorithms and solution to analyze them can still remain proprietary In this regard should CAPWAP provide the binding for sending scanning report/statistics from WTP to AC? Regards, Sachin --Boundary_(ID_F04ANlGZJMC4AghYErN8xA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi All,

 

As scanning is part of MAC protocol should there be a TLV to send that report from WTP to AC? Because for RF solutions WTP need to perform scanning and analyze that data. Currently for these solutions vendors have proprietary algorithms. Should the data collection part be standardized? (The data interpretation can remain vendor specific)

 

This will help in achieving greater interoperability, as AC can collect data and statistics from different vendor’s WTPs but the algorithms and solution to analyze them can still remain proprietary

 

In this regard should CAPWAP provide the binding for sending scanning report/statistics from WTP to AC?

 

Regards,

Sachin

 

 

 

--Boundary_(ID_F04ANlGZJMC4AghYErN8xA)-- --===============0809066744== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0809066744==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 26 10:09:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurmS-0005kI-Tj for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 10:09:36 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FurmS-0002g5-RY for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 10:09:36 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FurmP-0007J8-Af for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 10:09:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id EDDC9430122 for ; Mon, 26 Jun 2006 07:09:23 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3A099430058 for ; Mon, 26 Jun 2006 07:09:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 18360430D86 for ; Mon, 26 Jun 2006 07:09:02 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id 2EC6D430D8E for ; Mon, 26 Jun 2006 07:08:58 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 26 Jun 2006 07:08:58 -0700 X-IronPort-AV: i="4.06,176,1149490800"; d="scan'208"; a="1832609973:sNHT58347684" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5QE8ujm016394 for ; Mon, 26 Jun 2006 07:08:56 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5QE8uke018049 for ; Mon, 26 Jun 2006 07:08:56 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Jun 2006 07:08:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Jun 2006 07:08:55 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202182ACA@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Keepalive on data channel Thread-Index: AcaZKg+sDPr7U0bQThi3hSxJPT/Mzg== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 26 Jun 2006 14:08:56.0658 (UTC) FILETIME=[103A7320:01C6992A] Authentication-Results: sj-dkim-4.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Keepalive on data channel X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 All, In a conversation with some of the L2TP folks, they have experience an operational problem that we need to keep in mind. Basically, they multiplex their control and data frames through their own header, and mark their packets priorities based on control vs. data. What they have found is that networks do route path selection based on DSCP/ToS values, meaning that they send higher priority (control) frames over different links than data frames. The network is not designed to perform this solely for L2TP, as this is something they do for all of their applications. The issue is that their protocol relies on a keepalive frame that runs over the control channel, identically to CAPWAP. However, the operational issue that they've found is that if the path taken by the data channel is broken, and these frames are never delivered. The L2TP folks have found that the lack of a keepalive mechanism makes it impossible to diagnose such an issue. When it occurs, the administrator first has to figure out it is occurring, because the protocol does not, and then needs to manually follow the path to find the failure. As far as I can tell, Scott's two primary issues with not wanting to support UDP ports were: 1. NAT Traversal will require a keepalive on the data channel. As noted above, we need to add a keepalive on the data channel in order to be able to detect network routing failures. 2. Modifications to the state machine to handle data channel failure. Given that such failures can occur, we need to be able to recover, if possible. I wanted to raise these issues as they are real, and actually experienced in L2TP deployments. I believe we need to address these, and if so, then I believe the complexity associated with the dual UDP port ends up being resolved. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 26 12:22:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FutrN-0001Dk-N3 for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 12:22:49 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FutrL-0005aU-OO for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 12:22:49 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 08A3C4300FD for ; Mon, 26 Jun 2006 09:22:46 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 67676430058 for ; Mon, 26 Jun 2006 09:22:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 57B3B39802F for ; Mon, 26 Jun 2006 09:22:04 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6C39D398047 for ; Mon, 26 Jun 2006 09:21:57 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 26 Jun 2006 09:21:56 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k5QGLuxP022214; Mon, 26 Jun 2006 09:21:56 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5QGLuke022204; Mon, 26 Jun 2006 09:21:56 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Jun 2006 09:21:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Jun 2006 09:21:55 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202182B52@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] The MUX header Flux Thread-Index: AcaX8nLBTVv43WMSSSOPmSqBoxhm7QBShrTg From: "Pat Calhoun (pacalhou)" To: "Mani, Mahalingam (Mani)" , X-OriginalArrivalTime: 26 Jun 2006 16:21:56.0279 (UTC) FILETIME=[A473FC70:01C6993C] Authentication-Results: sj-dkim-4.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 43 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.4 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] The MUX header Flux X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1259111160==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 64b72a8e61417554b4b727cb14e7034d This is a multi-part message in MIME format. --===============1259111160== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6993C.A42529C8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6993C.A42529C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Many, I would like to include the thread I started today, called "Keepalive of data channel", and also ask that the Internet Area Directors also be engaged in the activity. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Mani, Mahalingam (Mani) [mailto:mmani@avaya.com]=20 Sent: Saturday, June 24, 2006 5:58 PM To: capwap@frascone.com Subject: [Capwap] The MUX header Flux Importance: High =09 =09 All =20 http://home.comcast.net/~mmani/muxflux.pdf presents a summary of discussions that have been in progress so far on the proposal to use a mux-header for multiplexing control and data flows. Apologies for late summary. The attached also includes a proposed set of questions for consulting other SME (subject-matter-experts) as suggested by ADs. Some of them could be framed better; some more could be framed. =20 In the final analysis, we are positioned best to determine the best way to go based on inputs that may need clarifying not only from SMEs but also the current practices in the industry (enterprises, provider environments of various hues). We may not be able to get them all; if we do get a large subset that is goodness. Else, it is inevitable that additional field deployment experiences of the CAPWAP standard alone can help us refine it (a -bis, perhaps). =20 Preamble: More than a year ago, around when the WG was being rechartered to work on the protocol; it was suggested to treat the data-path independent of control path and leave it out of the CAPWAP protocol definition itself. However, architectural taxonomy indicated trends that found usefulness of split-MAC with tunneled forwarding of data to a centralized AC already having found some acceptance in many deployments also merited inclusion. Hence we are ending up classifying three modes - two in split-MAC and one in local-MAC. The Split-MAC treatment of data-traffic has led to questions about its protection, encapsulation and multiplexing with control stream. =20 Since then there has been a lot that happened including succeeding in getting a -00 version of the WG CAPWAP draft protocol out for review and a -01 following it. A member of the WG, Scott Kelly, has proposed use of mux header citing several reasons. =20 It also appears that - given the nature and intensity of discussions; as well as the stated/claimed deployment practices in enterprise and provider environments to enforce local policies - it becomes imperative to validate them over a broader network equipment vendor and customer space. =20 It also becomes apparent that a best-practices (applicability) document may be useful to guide operators (enterprise and provider) with best choices for given topologies. =20 While the presented approach of tables may not be the best way to summarize - this is captured in chronological order showing the progression of topics; it is interesting what has caused what looks to be a simple issue to resolve technically to take this magnitude of debate. =20 We would like not to linger long on debating the questions; simply send in your additions/changes and we (chairs) will recompile them once (hopefully to general agreement) and send it on to the ADs. =20 Regards, -mani PS: The technical merits of the reasons have been debated. Also in question is the concern about compatibility with existing implementations and behaviors on intermediate switches and routers processing along the way leading to performance inefficiencies. The discussions are not citing any correctness issues, however, mux-header or not. We will try to summarize them all and see why we gauge consensus in favor of mux-header. For those more used to other SDOs: That does not mean the perceived consensus cannot be opposed (as it happens ever so many times in other SDOs based on respective process mechanisms and influences of varied hues) or argued against/for - on technical merits and pitfalls. =20 It is customary, both thinly contended to closely contended issues (technical and otherwise) there is a need to call for consensus by stating a conclusion and calling the question. This may happen at many layers - not always requiring the chairs to intervene - as happens with many cases in the issue-tracker. However, in the event of strong dissent the chairs are required to/called upon to assess, gauge, state and validate "rough" consensus. This is what is happening. =20 =20 ------_=_NextPart_001_01C6993C.A42529C8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Many,=20 I would like to include the thread I started today, called "Keepalive of = data=20 channel", and also ask that the Internet Area Directors also be engaged = in the=20 activity.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Mani, Mahalingam (Mani)=20 [mailto:mmani@avaya.com]
Sent: Saturday, June 24, 2006 5:58 = PM
To: capwap@frascone.com
Subject: [Capwap] The = MUX=20 header Flux
Importance: High

All

 

http://home.comcast.n= et/~mmani/muxflux.pdf=20 presents a summary of discussions that  have been in progress so = far on=20 the proposal to use a mux-header for multiplexing control and data = flows.=20 Apologies for late summary. The attached also includes a proposed set = of=20 questions for consulting other SME (subject-matter-experts) as = suggested by=20 ADs.

Some of them could be = framed=20 better; some more could be framed.

 

In the final analysis, = we are=20 positioned best to determine the best way to go based on inputs that = may need=20 clarifying not only from SMEs but also the current practices in the = industry=20 (enterprises, provider environments of various hues). We may not be = able to=20 get them all; if we do get a large subset that is=20 goodness.

Else, it is inevitable = that=20 additional field deployment experiences of the CAPWAP standard alone = can help=20 us refine it (a –bis, perhaps).

 

Preamble:

More than a year ago, = around when=20 the WG was being rechartered to work on the protocol; it was suggested = to=20 treat the data-path independent of control path and leave it out of = the CAPWAP=20 protocol definition itself. However, architectural taxonomy indicated = trends=20 that found usefulness of split-MAC with tunneled forwarding of data to = a=20 centralized AC already having found some acceptance in many = deployments also=20 merited inclusion. Hence we are ending up classifying three modes = – two in=20 split-MAC and one in local-MAC. The Split-MAC treatment of = data-traffic has=20 led to questions about its protection, encapsulation and multiplexing = with=20 control stream.

 

Since then there has = been a lot=20 that happened including succeeding in getting a -00 version of the WG = CAPWAP=20 draft protocol out for review and a -01 following=20 it.

A member of the WG, = Scott Kelly,=20 has proposed use of mux header citing several=20 reasons.

 

It also appears that = – given the=20 nature and intensity of discussions; as well as the stated/claimed = deployment=20 practices in enterprise and provider environments to enforce local = policies –=20 it becomes imperative to validate them over a broader network = equipment vendor=20 and customer space.

 

It also becomes apparent = that a=20 best-practices (applicability) document may be useful to guide = operators=20 (enterprise and provider) with best choices for given=20 topologies.

 

While the presented = approach of=20 tables may not be the best way to summarize – this is captured = in=20 chronological order showing the progression of topics; it is = interesting what=20 has caused what looks to be a simple issue to resolve technically to = take this=20 magnitude of debate.

 

We would like not to = linger long=20 on debating the questions; simply send in your additions/changes and = we=20 (chairs) will recompile them once (hopefully to general agreement) and = send it=20 on to the ADs.

 

Regards,

-mani

PS:

The technical merits of = the=20 reasons have been debated. Also in question is the concern about = compatibility=20 with existing implementations and behaviors on intermediate switches = and=20 routers processing along the way leading to performance = inefficiencies. The=20 discussions are not citing any correctness issues, however, mux-header = or not.=20 We will try to summarize them all and see why we gauge consensus in = favor of=20 mux-header. For those more used to other SDOs: That does not mean the=20 perceived consensus cannot be opposed (as it happens ever so many = times in=20 other SDOs based on respective process mechanisms and influences of = varied=20 hues) or argued against/for – on technical merits and=20 pitfalls.

 

It is customary, both = thinly=20 contended to closely contended issues (technical and otherwise) there = is a=20 need to call for consensus by stating a conclusion and calling the = question.=20 This may happen at many layers – not always requiring the chairs = to intervene=20 – as happens with many cases in the issue-tracker. However, in = the event of=20 strong dissent the chairs are required to/called upon to assess, = gauge, state=20 and validate “rough” consensus. This is what is=20 happening.

 

 

------_=_NextPart_001_01C6993C.A42529C8-- --===============1259111160== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1259111160==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 26 13:24:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuup6-0007Vm-7f for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 13:24:32 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuup4-0003ZY-Eg for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 13:24:32 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1CFA743010E for ; Mon, 26 Jun 2006 10:24:30 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B3D2B43006B for ; Mon, 26 Jun 2006 10:24:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 912F9398049 for ; Mon, 26 Jun 2006 10:24:08 -0700 (PDT) Received: from smtpauth08.mail.atl.earthlink.net (smtpauth08.mail.atl.earthlink.net [209.86.89.68]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9D479398022 for ; Mon, 26 Jun 2006 10:24:04 -0700 (PDT) Received: from [209.86.224.47] (helo=elwamui-rubis.atl.sa.earthlink.net) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1Fuuod-0000rw-Pb; Mon, 26 Jun 2006 13:24:03 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Mon, 26 Jun 2006 13:24:03 -0400 Message-ID: <9086333.1151342643738.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> Date: Mon, 26 Jun 2006 10:24:03 -0700 (GMT-07:00) From: "Scott G. Kelly" To: Pat Calhoun Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710eb8f75f4a61c960b9a736a21cd782a4f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.47 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Keepalive on data channel X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Hi Pat, Since L2TP is a remote access protocol originally designed for dial-up remote access and then later used for generalized remote access over the Internet, any comparison with capwap is apples vs bananas at best. However, I think this opens a more general question: what is a reasonable set of reference scenarios to address for capwap v1.0? Must we support each and every scenario any of us dreams up, or should we have a more narrow focus, with explicit plans to defer some things to later revisions of the protocol? A case in point has surfaced again and again in the multiport vs single port threads: must we support tunneling capwap control *and* data across arbitrary hop counts and administrative domains while expecting to maintain granular QoS? Personally, I find this scenario unlikely to actually work in practice, and think that at best it's a corner case that should be relegated to the "not in 1.0" pile. I think it would be far more efficient to focus on an 80% solution. At least then there is some possibility of finishing in this decade. Scott > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Monday, June 26, 2006 7:09 AM > To: capwap@frascone.com > Subject: [Capwap] Keepalive on data channel > > All, > > In a conversation with some of the L2TP folks, they have > experience an operational problem that we need to keep in > mind. Basically, they multiplex their control and data frames > through their own header, and mark their packets priorities > based on control vs. data. > > What they have found is that networks do route path selection > based on DSCP/ToS values, meaning that they send higher > priority (control) frames over different links than data > frames. The network is not designed to perform this solely > for L2TP, as this is something they do for all of their > applications. The issue is that their protocol relies on a > keepalive frame that runs over the control channel, > identically to CAPWAP. However, the operational issue that > they've found is that if the path taken by the data channel > is broken, and these frames are never delivered. > > The L2TP folks have found that the lack of a keepalive > mechanism makes it impossible to diagnose such an issue. When > it occurs, the administrator first has to figure out it is > occurring, because the protocol does not, and then needs to > manually follow the path to find the failure. > > As far as I can tell, Scott's two primary issues with not > wanting to support UDP ports were: > 1. NAT Traversal will require a keepalive on the data > channel. As noted above, we need to add a keepalive on the > data channel in order to be able to detect network routing failures. > 2. Modifications to the state machine to handle data channel failure. > Given that such failures can occur, we need to be able to > recover, if possible. > > I wanted to raise these issues as they are real, and actually > experienced in L2TP deployments. I believe we need to address > these, and if so, then I believe the complexity associated > with the dual UDP port ends up being resolved. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 26 20:13:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv1Cp-0006M6-4h for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 20:13:27 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv1Cn-0002U6-1o for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 20:13:27 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 372394300F7 for ; Mon, 26 Jun 2006 17:13:24 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id C6DA9430092 for ; Mon, 26 Jun 2006 17:12:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id B976F39800C for ; Mon, 26 Jun 2006 17:12:35 -0700 (PDT) X-Greylist-Status: Sender first seen 25 days 08:56:53 ago Received: from co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by zoidberg.tigertech.net (Postfix) with ESMTP id E354E39803C for ; Mon, 26 Jun 2006 17:12:31 -0700 (PDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5R09FKC007332 for ; Mon, 26 Jun 2006 20:09:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Jun 2006 18:12:25 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] The MUX header Flux Thread-Index: AcaX8nLBTVv43WMSSSOPmSqBoxhm7QBi6+rA X-Priority: 1 Priority: Urgent Importance: high From: "Mani, Mahalingam (Mani)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.094 tagged_above=-999 required=7 tests=HTML_MESSAGE, X_PRIORITY_HIGH X-Spam-Level: Subject: Re: [Capwap] The MUX header Flux X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1397449569==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b55e50be03ae25e9a8d86e86275fb10 This is a multi-part message in MIME format. --===============1397449569== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6997E.5EA05BBA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6997E.5EA05BBA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have changed the file from muxflux.pdf to muxflux.htm =20 Hence http://home.comcast.net/~mmani/muxflux.htm is the one to refer to. =20 -mani =20 _____ =20 From: Mani, Mahalingam (Mani)=20 Sent: Saturday, June 24, 2006 5:58 PM To: capwap@frascone.com Subject: [Capwap] The MUX header Flux Importance: High =20 All =20 http://home.comcast.net/~mmani/muxflux.pdf presents a summary of discussions that have been in progress so far on the proposal to use a mux-header for multiplexing control and data flows. Apologies for late summary. The attached also includes a proposed set of questions for consulting other SME (subject-matter-experts) as suggested by ADs. Some of them could be framed better; some more could be framed. =20 In the final analysis, we are positioned best to determine the best way to go based on inputs that may need clarifying not only from SMEs but also the current practices in the industry (enterprises, provider environments of various hues). We may not be able to get them all; if we do get a large subset that is goodness. Else, it is inevitable that additional field deployment experiences of the CAPWAP standard alone can help us refine it (a -bis, perhaps). =20 Preamble: More than a year ago, around when the WG was being rechartered to work on the protocol; it was suggested to treat the data-path independent of control path and leave it out of the CAPWAP protocol definition itself. However, architectural taxonomy indicated trends that found usefulness of split-MAC with tunneled forwarding of data to a centralized AC already having found some acceptance in many deployments also merited inclusion. Hence we are ending up classifying three modes - two in split-MAC and one in local-MAC. The Split-MAC treatment of data-traffic has led to questions about its protection, encapsulation and multiplexing with control stream. =20 Since then there has been a lot that happened including succeeding in getting a -00 version of the WG CAPWAP draft protocol out for review and a -01 following it. A member of the WG, Scott Kelly, has proposed use of mux header citing several reasons. =20 It also appears that - given the nature and intensity of discussions; as well as the stated/claimed deployment practices in enterprise and provider environments to enforce local policies - it becomes imperative to validate them over a broader network equipment vendor and customer space. =20 It also becomes apparent that a best-practices (applicability) document may be useful to guide operators (enterprise and provider) with best choices for given topologies. =20 While the presented approach of tables may not be the best way to summarize - this is captured in chronological order showing the progression of topics; it is interesting what has caused what looks to be a simple issue to resolve technically to take this magnitude of debate. =20 We would like not to linger long on debating the questions; simply send in your additions/changes and we (chairs) will recompile them once (hopefully to general agreement) and send it on to the ADs. =20 Regards, -mani PS: The technical merits of the reasons have been debated. Also in question is the concern about compatibility with existing implementations and behaviors on intermediate switches and routers processing along the way leading to performance inefficiencies. The discussions are not citing any correctness issues, however, mux-header or not. We will try to summarize them all and see why we gauge consensus in favor of mux-header. For those more used to other SDOs: That does not mean the perceived consensus cannot be opposed (as it happens ever so many times in other SDOs based on respective process mechanisms and influences of varied hues) or argued against/for - on technical merits and pitfalls. =20 It is customary, both thinly contended to closely contended issues (technical and otherwise) there is a need to call for consensus by stating a conclusion and calling the question. This may happen at many layers - not always requiring the chairs to intervene - as happens with many cases in the issue-tracker. However, in the event of strong dissent the chairs are required to/called upon to assess, gauge, state and validate "rough" consensus. This is what is happening. =20 =20 ------_=_NextPart_001_01C6997E.5EA05BBA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have changed the file from = muxflux.pdf to muxflux.htm

 

Hence http://home.comcast.n= et/~mmani/muxflux.htm is the one to refer to.

 

-mani

 

From: Mani, = Mahalingam (Mani)
Sent: Saturday, June 24, = 2006 5:58 PM
To: = capwap@frascone.com
Subject: [Capwap] The MUX = header Flux
Importance: = High

 

All

 

http://home.comcast.n= et/~mmani/muxflux.pdf presents a summary of discussions that  have been in progress so = far on the proposal to use a mux-header for multiplexing control and data = flows. Apologies for late summary. The attached also includes a proposed set of questions for consulting other SME (subject-matter-experts) as suggested = by ADs.

Some of them could be framed better; some more could = be framed.

 

In the final analysis, we are positioned best to = determine the best way to go based on inputs that may need clarifying not only = from SMEs but also the current practices in the industry (enterprises, provider environments of various hues). We may not be able to get them all; if we = do get a large subset that is goodness.

Else, it is inevitable that additional field = deployment experiences of the CAPWAP standard alone can help us refine it (a = –bis, perhaps).

 

Preamble:

More than a year ago, = around when the WG was being rechartered to work on the protocol; it was suggested to = treat the data-path independent of control path and leave it out of the CAPWAP = protocol definition itself. However, architectural taxonomy indicated trends that = found usefulness of split-MAC with tunneled forwarding of data to a = centralized AC already having found some acceptance in many deployments also merited inclusion. Hence we are ending up classifying three modes – two in split-MAC and one in local-MAC. The Split-MAC treatment of data-traffic = has led to questions about its protection, encapsulation and multiplexing with = control stream.

 

Since then there has been a lot that happened = including succeeding in getting a -00 version of the WG CAPWAP draft protocol out = for review and a -01 following it.

A member of the WG, Scott Kelly, has proposed use of = mux header citing several reasons.

 

It also appears that – given the nature and = intensity of discussions; as well as the stated/claimed deployment practices in enterprise and provider environments to enforce local policies – = it becomes imperative to validate them over a broader network equipment = vendor and customer space.

 

It also becomes apparent that a best-practices (applicability) document may be useful to guide operators (enterprise = and provider) with best choices for given = topologies.

 

While the presented approach of tables may not be the = best way to summarize – this is captured in chronological order showing = the progression of topics; it is interesting what has caused what looks to = be a simple issue to resolve technically to take this magnitude of = debate.

 

We would like not to linger long on debating the = questions; simply send in your additions/changes and we (chairs) will recompile = them once (hopefully to general agreement) and send it on to the = ADs.

 

Regards,

-mani

PS:

The technical merits of the reasons have been = debated. Also in question is the concern about compatibility with existing = implementations and behaviors on intermediate switches and routers processing along the = way leading to performance inefficiencies. The discussions are not citing any = correctness issues, however, mux-header or not. We will try to summarize them all = and see why we gauge consensus in favor of mux-header. For those more used to = other SDOs: That does not mean the perceived consensus cannot be opposed (as = it happens ever so many times in other SDOs based on respective process = mechanisms and influences of varied hues) or argued against/for – on = technical merits and pitfalls.

 

It is customary, both thinly contended to closely = contended issues (technical and otherwise) there is a need to call for consensus = by stating a conclusion and calling the question. This may happen at many = layers – not always requiring the chairs to intervene – as happens = with many cases in the issue-tracker. However, in the event of strong dissent = the chairs are required to/called upon to assess, gauge, state and validate “rough” consensus. This is what is = happening.

 

 

------_=_NextPart_001_01C6997E.5EA05BBA-- --===============1397449569== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1397449569==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 26 20:14:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv1E9-0006uq-Li for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 20:14:49 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv1E8-0002dT-AA for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 20:14:49 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DF6F2430100 for ; Mon, 26 Jun 2006 17:14:47 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7B8DD4300EA for ; Mon, 26 Jun 2006 17:13:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6D05F39800C for ; Mon, 26 Jun 2006 17:13:14 -0700 (PDT) X-Greylist-Status: Sender first seen 25 days 08:57:32 ago Received: from co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2874339802B for ; Mon, 26 Jun 2006 17:13:10 -0700 (PDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5R09xT3007838 for ; Mon, 26 Jun 2006 20:09:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Jun 2006 18:13:09 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] The MUX header Flux Thread-Index: AcaX8nLBTVv43WMSSSOPmSqBoxhm7QBShrTgAA5Z1XA= From: "Mani, Mahalingam (Mani)" To: "Pat Calhoun (pacalhou)" , X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.001 tagged_above=-999 required=7 tests=HTML_MESSAGE X-Spam-Level: Subject: Re: [Capwap] The MUX header Flux X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2095907372==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e5958278d089090169a903f246b3f39 This is a multi-part message in MIME format. --===============2095907372== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6997E.78A358BB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6997E.78A358BB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some,Done. =20 -mani _____ =20 From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Monday, June 26, 2006 9:22 AM To: Mani, Mahalingam (Mani); capwap@frascone.com Subject: RE: [Capwap] The MUX header Flux =20 Many, I would like to include the thread I started today, called "Keepalive of data channel", and also ask that the Internet Area Directors also be engaged in the activity. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 _____ =20 From: Mani, Mahalingam (Mani) [mailto:mmani@avaya.com]=20 Sent: Saturday, June 24, 2006 5:58 PM To: capwap@frascone.com Subject: [Capwap] The MUX header Flux Importance: High All =20 http://home.comcast.net/~mmani/muxflux.pdf presents a summary of discussions that have been in progress so far on the proposal to use a mux-header for multiplexing control and data flows. Apologies for late summary. The attached also includes a proposed set of questions for consulting other SME (subject-matter-experts) as suggested by ADs. Some of them could be framed better; some more could be framed. =20 In the final analysis, we are positioned best to determine the best way to go based on inputs that may need clarifying not only from SMEs but also the current practices in the industry (enterprises, provider environments of various hues). We may not be able to get them all; if we do get a large subset that is goodness. Else, it is inevitable that additional field deployment experiences of the CAPWAP standard alone can help us refine it (a -bis, perhaps). =20 Preamble: More than a year ago, around when the WG was being rechartered to work on the protocol; it was suggested to treat the data-path independent of control path and leave it out of the CAPWAP protocol definition itself. However, architectural taxonomy indicated trends that found usefulness of split-MAC with tunneled forwarding of data to a centralized AC already having found some acceptance in many deployments also merited inclusion. Hence we are ending up classifying three modes - two in split-MAC and one in local-MAC. The Split-MAC treatment of data-traffic has led to questions about its protection, encapsulation and multiplexing with control stream. =20 Since then there has been a lot that happened including succeeding in getting a -00 version of the WG CAPWAP draft protocol out for review and a -01 following it. A member of the WG, Scott Kelly, has proposed use of mux header citing several reasons. =20 It also appears that - given the nature and intensity of discussions; as well as the stated/claimed deployment practices in enterprise and provider environments to enforce local policies - it becomes imperative to validate them over a broader network equipment vendor and customer space. =20 It also becomes apparent that a best-practices (applicability) document may be useful to guide operators (enterprise and provider) with best choices for given topologies. =20 While the presented approach of tables may not be the best way to summarize - this is captured in chronological order showing the progression of topics; it is interesting what has caused what looks to be a simple issue to resolve technically to take this magnitude of debate. =20 We would like not to linger long on debating the questions; simply send in your additions/changes and we (chairs) will recompile them once (hopefully to general agreement) and send it on to the ADs. =20 Regards, -mani PS: The technical merits of the reasons have been debated. Also in question is the concern about compatibility with existing implementations and behaviors on intermediate switches and routers processing along the way leading to performance inefficiencies. The discussions are not citing any correctness issues, however, mux-header or not. We will try to summarize them all and see why we gauge consensus in favor of mux-header. For those more used to other SDOs: That does not mean the perceived consensus cannot be opposed (as it happens ever so many times in other SDOs based on respective process mechanisms and influences of varied hues) or argued against/for - on technical merits and pitfalls. =20 It is customary, both thinly contended to closely contended issues (technical and otherwise) there is a need to call for consensus by stating a conclusion and calling the question. This may happen at many layers - not always requiring the chairs to intervene - as happens with many cases in the issue-tracker. However, in the event of strong dissent the chairs are required to/called upon to assess, gauge, state and validate "rough" consensus. This is what is happening. =20 =20 ------_=_NextPart_001_01C6997E.78A358BB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Some,Done.<= /p>

 

-mani

From: Pat = Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Monday, June 26, = 2006 9:22 AM
To: Mani, Mahalingam = (Mani); capwap@frascone.com
Subject: RE: [Capwap] The = MUX header Flux

 

Many, I would like to include the = thread I started today, called "Keepalive of data channel", and also = ask that the Internet Area Directors also be engaged in the = activity.

 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

 

From: Mani, Mahalingam (Mani) [mailto:mmani@avaya.com]
Sent: Saturday, June 24, = 2006 5:58 PM
To: = capwap@frascone.com
Subject: [Capwap] The MUX = header Flux
Importance: = High

All

 

http://home.comcast.n= et/~mmani/muxflux.pdf presents a summary of discussions that  have been in progress so = far on the proposal to use a mux-header for multiplexing control and data = flows. Apologies for late summary. The attached also includes a proposed set of questions for consulting other SME (subject-matter-experts) as suggested = by ADs.

Some of them could be framed better; some more could = be framed.

 

In the final analysis, we are positioned best to = determine the best way to go based on inputs that may need clarifying not only = from SMEs but also the current practices in the industry (enterprises, provider environments of various hues). We may not be able to get them all; if we = do get a large subset that is goodness.

Else, it is inevitable that additional field = deployment experiences of the CAPWAP standard alone can help us refine it (a = –bis, perhaps).

 

Preamble:

More than a year ago, = around when the WG was being rechartered to work on the protocol; it was suggested = to treat the data-path independent of control path and leave it out of the CAPWAP protocol definition itself. However, architectural taxonomy indicated = trends that found usefulness of split-MAC with tunneled forwarding of data to a centralized AC already having found some acceptance in many deployments = also merited inclusion. Hence we are ending up classifying three modes = – two in split-MAC and one in local-MAC. The Split-MAC treatment of = data-traffic has led to questions about its protection, encapsulation and multiplexing = with control stream.

 

Since then there has been a lot that happened = including succeeding in getting a -00 version of the WG CAPWAP draft protocol out = for review and a -01 following it.

A member of the WG, Scott Kelly, has proposed use of = mux header citing several reasons.

 

It also appears that – given the nature and = intensity of discussions; as well as the stated/claimed deployment practices in enterprise and provider environments to enforce local policies – = it becomes imperative to validate them over a broader network equipment = vendor and customer space.

 

It also becomes apparent that a best-practices (applicability) document may be useful to guide operators (enterprise = and provider) with best choices for given = topologies.

 

While the presented approach of tables may not be the = best way to summarize – this is captured in chronological order showing = the progression of topics; it is interesting what has caused what looks to = be a simple issue to resolve technically to take this magnitude of = debate.

 

We would like not to linger long on debating the = questions; simply send in your additions/changes and we (chairs) will recompile = them once (hopefully to general agreement) and send it on to the = ADs.

 

Regards,

-mani

PS:

The technical merits of the reasons have been = debated. Also in question is the concern about compatibility with existing = implementations and behaviors on intermediate switches and routers processing along the = way leading to performance inefficiencies. The discussions are not citing = any correctness issues, however, mux-header or not. We will try to summarize = them all and see why we gauge consensus in favor of mux-header. For those = more used to other SDOs: That does not mean the perceived consensus cannot be = opposed (as it happens ever so many times in other SDOs based on respective process mechanisms and influences of varied hues) or argued against/for – = on technical merits and pitfalls.

 

It is customary, both thinly contended to closely = contended issues (technical and otherwise) there is a need to call for consensus = by stating a conclusion and calling the question. This may happen at many = layers – not always requiring the chairs to intervene – as happens = with many cases in the issue-tracker. However, in the event of strong dissent = the chairs are required to/called upon to assess, gauge, state and validate “rough” consensus. This is what is = happening.

 

 

------_=_NextPart_001_01C6997E.78A358BB-- --===============2095907372== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============2095907372==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 26 20:22:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv1Lp-0006GX-TD for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 20:22:45 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv1Lo-0002pl-Ew for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 20:22:45 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D09E643010F for ; Mon, 26 Jun 2006 17:22:43 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A069F430092 for ; Mon, 26 Jun 2006 17:22:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8DFC9398016 for ; Mon, 26 Jun 2006 17:22:22 -0700 (PDT) X-Greylist-Status: Sender first seen 5 mons 1 day 08:34:36 ago Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by zoidberg.tigertech.net (Postfix) with ESMTP id 896C639800C for ; Mon, 26 Jun 2006 17:22:19 -0700 (PDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5R0I4lw012506 for ; Mon, 26 Jun 2006 20:18:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Jun 2006 18:22:17 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Keepalive on data channel Thread-Index: AcaZKg+sDPr7U0bQThi3hSxJPT/MzgATMV2g From: "Mani, Mahalingam (Mani)" To: "Pat Calhoun (pacalhou)" , X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: Re: [Capwap] Keepalive on data channel X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe It appears that in such a network - all flows marked for DSCP -based QoS are at a diagnostic peril - each of a different kind - in such a failure scenario. -mani -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Monday, June 26, 2006 7:09 AM To: capwap@frascone.com Subject: [Capwap] Keepalive on data channel All, In a conversation with some of the L2TP folks, they have experience an operational problem that we need to keep in mind. Basically, they multiplex their control and data frames through their own header, and mark their packets priorities based on control vs. data. What they have found is that networks do route path selection based on DSCP/ToS values, meaning that they send higher priority (control) frames over different links than data frames. The network is not designed to perform this solely for L2TP, as this is something they do for all of their applications. The issue is that their protocol relies on a keepalive frame that runs over the control channel, identically to CAPWAP. However, the operational issue that they've found is that if the path taken by the data channel is broken, and these frames are never delivered. The L2TP folks have found that the lack of a keepalive mechanism makes it impossible to diagnose such an issue. When it occurs, the administrator first has to figure out it is occurring, because the protocol does not, and then needs to manually follow the path to find the failure. As far as I can tell, Scott's two primary issues with not wanting to support UDP ports were: 1. NAT Traversal will require a keepalive on the data channel. As noted above, we need to add a keepalive on the data channel in order to be able to detect network routing failures. 2. Modifications to the state machine to handle data channel failure. Given that such failures can occur, we need to be able to recover, if possible. I wanted to raise these issues as they are real, and actually experienced in L2TP deployments. I believe we need to address these, and if so, then I believe the complexity associated with the dual UDP port ends up being resolved. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jun 26 21:27:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv2MP-0004Q1-6l for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 21:27:25 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv2MN-00086O-NA for capwap-archive@lists.ietf.org; Mon, 26 Jun 2006 21:27:25 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9A982430105 for ; Mon, 26 Jun 2006 18:27:22 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 5E8ED430092 for ; Mon, 26 Jun 2006 18:26:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 463371448008 for ; Mon, 26 Jun 2006 18:26:58 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id D96291448029 for ; Mon, 26 Jun 2006 18:26:55 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 26 Jun 2006 18:26:55 -0700 X-IronPort-AV: i="4.06,178,1149490800"; d="scan'208"; a="1833060312:sNHT32675284" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k5R1Qsc3017459; Mon, 26 Jun 2006 18:26:54 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5R1Qske017972; Mon, 26 Jun 2006 18:26:54 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Jun 2006 18:26:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Jun 2006 18:26:53 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202182F02@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Keepalive on data channel Thread-Index: AcaZKg+sDPr7U0bQThi3hSxJPT/MzgATMV2gAARmr7A= From: "Pat Calhoun (pacalhou)" To: "Mani, Mahalingam (Mani)" , X-OriginalArrivalTime: 27 Jun 2006 01:26:54.0196 (UTC) FILETIME=[C5EE2B40:01C69988] Authentication-Results: sj-dkim-1.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Keepalive on data channel X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Mani, Then I would recommend that you include folks from the Internet Area in your discussions, as they have a number of tunneling standards efforts underway, as well as operational experience. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Mani, Mahalingam (Mani) [mailto:mmani@avaya.com] > Sent: Monday, June 26, 2006 5:22 PM > To: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: RE: [Capwap] Keepalive on data channel > > It appears that in such a network - all flows marked for DSCP > -based QoS are at a diagnostic peril - each of a different > kind - in such a failure scenario. > > -mani > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Monday, June 26, 2006 7:09 AM > To: capwap@frascone.com > Subject: [Capwap] Keepalive on data channel > > All, > > In a conversation with some of the L2TP folks, they have > experience an operational problem that we need to keep in > mind. Basically, they multiplex their control and data frames > through their own header, and mark their packets priorities > based on control vs. data. > > What they have found is that networks do route path selection > based on DSCP/ToS values, meaning that they send higher > priority (control) frames over different links than data > frames. The network is not designed to perform this solely > for L2TP, as this is something they do for all of their > applications. The issue is that their protocol relies on a > keepalive frame that runs over the control channel, > identically to CAPWAP. However, the operational issue that > they've found is that if the path taken by the data channel > is broken, and these frames are never delivered. > > The L2TP folks have found that the lack of a keepalive > mechanism makes it impossible to diagnose such an issue. When > it occurs, the administrator first has to figure out it is > occurring, because the protocol does not, and then needs to > manually follow the path to find the failure. > > As far as I can tell, Scott's two primary issues with not > wanting to support UDP ports were: > 1. NAT Traversal will require a keepalive on the data > channel. As noted above, we need to add a keepalive on the > data channel in order to be able to detect network routing failures. > 2. Modifications to the state machine to handle data channel failure. > Given that such failures can occur, we need to be able to > recover, if possible. > > I wanted to raise these issues as they are real, and actually > experienced in L2TP deployments. I believe we need to address > these, and if so, then I believe the complexity associated > with the dual UDP port ends up being resolved. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 27 10:40:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvEjS-0006jM-6e for capwap-archive@lists.ietf.org; Tue, 27 Jun 2006 10:40:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvE0O-0008PB-Kn for capwap-archive@lists.ietf.org; Tue, 27 Jun 2006 09:53:28 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvDYT-000654-8U for capwap-archive@lists.ietf.org; Tue, 27 Jun 2006 09:24:42 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id ABDFF43013C for ; Tue, 27 Jun 2006 06:24:35 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C26B04300D0 for ; Tue, 27 Jun 2006 06:23:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 72578144802B for ; Tue, 27 Jun 2006 06:23:13 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by hermes.tigertech.net (Postfix) with ESMTP id DE76A1448026 for ; Tue, 27 Jun 2006 06:23:08 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 27 Jun 2006 06:23:06 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5RDN6pS011037; Tue, 27 Jun 2006 06:23:06 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5RDN6CU020542; Tue, 27 Jun 2006 06:23:06 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Jun 2006 06:23:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 Jun 2006 06:23:05 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202182F70@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] A commentary on CAPWAP-01 operations Thread-Index: AcaWVCsVDEbioswRRC6wfKn3DH6/+wDeM/bQ From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" , X-OriginalArrivalTime: 27 Jun 2006 13:23:05.0975 (UTC) FILETIME=[D31B4870:01C699EC] Authentication-Results: sj-dkim-3.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] A commentary on CAPWAP-01 operations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: ca81a19b939ce054f98c8f830c2d7742 Going through David's lengthy document, he has raised an interesting number of points that I believe require issues to be created. At one point I'm paraphrasing Dave's comments in order to be brief, and introducing my own numbering scheme. 1) Can message elements be in any order? (I believe they should be) Yes, and I suspect we need to include text to make it more obvious. 2) Are all specified message elements required? (The obvious answer is "yes", but this document doesn't discuss versioning. For example, what if in a new version of CAPWAP an additional message element was to be added. Would a new message type be created and the additional message element added to it, or the existing type reused?) This is a great question, and one that does need to be addressed in the spec. In the Diameter protocol we dealt with this issue by including a "Mandatory to implement" bit. If any AVP was received, whose bit was set, yet was not recognized, then the request had to be rejected. We could consider something similar here, but I believe with the firmware download component of the protocol it may be less of an issue - although not guaranteed. I would hope (and expect) that as the CAPWAP protocol extends, the AC would push new firmware to the WTP. This does require that the initial part of the state machine be fairly static, and this could be an area where the "Mandatory to implement" bit could be useful as it would allow the AC to fall back to older protocol behavior. 3) CAPWAP-01 doesn't do a good job of indicating which message elements can be repeated. Another good point. When we list the message elements, we should note whether the frequently is 0-1 (meaning absent or once), 1 (only once) or 0+ (meaning any number of them could be present. 4) Can "additional" message elements be added to a message? (I believe so for reporting capabilities, statistics, and events. For configuration, there is nothing in the protocol that says what happens when one end gets an configuration element it doesn't know about. Should it be ignored, and the other elements processed, or should the complete operation failed?) The "Mandatory to implement" bit above could address this issue. If an unrecognized message element is found to have the bit set, then the whole message needs to be rejected. If the bit is not set, the message element may be safely ignored. 5) The config has a concept of "default value" for each configuration attribute. However, the default values are not clearly specified. This needs to be resolved to be able to support "default values". Another good point raised by David. 6) the documentation of which "binding specific" message elements are to be included with CAPWAP messages is not consistent, and is difficult to follow. Has this been addressed in the latest (-02) document? 7) There are some message elements that cause "actions". This approach to protocol design is problematic and should be eliminated. Could you be more specific as well as provide guidance on what you would like to see? 8) The message types are inconsistently named, and do not follow the conventions of well designed protocols. Can the operations be named consistently with the following terminology: 1) request/response (used to get/set/perform action) 2) report/ack (use to tell the other side something) Could you provide your thoughts on which messages fall within which one of your categories? 9) Many of the configuration items, and status items are not listed in one section with definitions. (Well make it two sections - one for CAPWAP and the other which is "binding" specific.) For example, not all of the time period lengths are identified and specified in section 4.5. Unfortunately, the document has gone back and forth a few times and before we opt to change the structure of the document, I'd like to ensure that we have broad agreement on what we want - with the understanding that we will never make everyone happy. 10) each operation should have listed in which states it can be sent and received I do not understand your comment. 11) All strings, such as WTP location, should be changed from US-ASCII encoding to UTF-8 encoding. Agreed. 12) The term "mobile" is not really accurate when describing wireless interfaces, since wireless does not imply mobile. Can we just use the techie term "STA" instead. I agree we should use the term Station, or STA for short. 13) The WTP Descriptor message element contains too much information, lacks clarity on the WTP encryption field and includes version numbers, which should be in string form. To the first point, I disagree. I think there is value in knowing everything about the WTP. The AC vendors can expose whatever information they want, but I don't believe anything is unnecessary. To the second point, this is one of those areas where the concept of the technology binding creates complexity. Given that we cannot simply discuss 802.11i at this point, the only thing we can do is punt to another section in the technology binding section. That said, I agree with Dave that the 802.11 binding section is too light in this area. However, I would much prefer that instead of trying to address this specific issue, we discuss whether we should even be supporting the mode of operation where 802.11i is performed in the AC - especially with the introduction of DTLS to secure the data plane. Right now, it just feels like we have too many options and I am worried that interoperability will be severely impacted (not to mention protocol complexity). To the last point, I have no issues with including text stating that the version numbers should be in string form. 14) The WTP Descriptor information is not required at Join time. Well, as far as I can tell, I think there's value in knowing whether the WTP can even be supported by the AC. So the more info is provided by the WTP, the better the AC can determine whether it should just ignore the WTP or not. This could be done because it knows that the firmware running on the WTP is not compatible, and it has no new firmware to download. 15) Are the values in the WTP Frame Encryption a capabilities bit, or an enum? Looks like an enum to me. Not sure what Dave would prefer the text to read. There are various other similar comments throughout, which I will not repeat here. 16) The Discovery Response is broken. The AC SHOULD NOT be providing any info to a WTP (or something that claims to be a WTP). Also, the AC should tell the WTP what to do next, with choices: 1) Ok to try to join, 2) don't try to join, 3) try discover on a list of returned ACs) I don't believe there is an issue with sending the AC's information to the WTP, but would solicit input from the list. That said, some of the information in the AC Descriptor is required, such as the current load on the AC. No point is trying to join if he AC indicates it's already at max capacity. I believe if the AC does not return the response, then it implies (2). Otherwise, it is (1). (3) is handled during the join or configure process, which I believe is right. 17) Is AC Name text? Yes, and same with WTP Name. 18) Primary Discovery are not required. Disagree. Required for failover. 19) The text does not make it clear that the contents of the WTP Location is informative only, and as Dave calls it, a "scratchpad". Well, to be honest, I thought the example "next to the fridge" made it clear that the information did not derive from any scientific formula. The description also states this is a user-defined. I believe this should be good enough. 20) Session is not required I believe you may be correct that with the transition to DTLS, this is no longer required. 21) need to send "common name" as found in the WTP CERT so that the AC can verify The protocol currently relies on the MAC address being the key that binds the certificate to the WTP. I don't see a need to change this. 22) Result code in Join Response is not sufficient, for instance WTP HW not supported. Well, the protocol does not require this because the Discovery Response would never be sent (as the protocol stands today). 23) AC IPv4/IPv6 Addr discusses clustering, which is unnecessary. Agreed. 24) Change Echo to Keepalive or heartbeat. I call it potato.... 25) What if all of the message elements do not fit within a single CAPWAP control frame. We should address this. 26) AC Name with Index is all messed up... Not really. You simply include more than one, and the index field is clearly the priority. Don't understand the Multi-AC comment. No inter-AC protocol implied here. 27) WTP Board Data belongs in the Join, not configure. Agreed, but wonder even more why we are duplicating this information across both the WTP Descriptor and the WTP Board Data message elements. 28) The WTP Static IPv4 Address should not have the Static bit, but instead state that 0.0.0.0 means a static address is not to be used. I don't have an issue with this request, but in the end we have the same function. The reason why I state this is that we can refine this protocol until the cows come home, and at one point we need to draw a line in the sand. 29) WTP Reboot Statistics belongs in the Join, and the reasons listed are not clear enough. Doesn't really matter whether this is included in the configuration or the join, but if the WG agrees to move it. We can clarify some of the reasons, as long as it provides value. 30) The IEEE 802.11 WTP Radio Configuration message element's BSSID field should be an array. Disagree. 30) The IEEE 802.11 WTP Radio Configuration message element's Country Code is not clear enough. The text points to the actual MIB element in the 802.11-1999 standard, which very clearly defines the contents of the field. I don't think there's value in replicating the format of this field in the CAPWAP standard. 31) There seems like an awful lot of additional configuration message elements that need to be specified here! Having built a protocol based on this, it's not clear to me what's missing. I think it would be useful if you provided concrete details on what's missing. 32) Configuration Status is just plain broken because any configuration change operation may fail and there is no response to the configuration changes specified in this command. There certainly is - I guess I don't understand the concern. 33) Use of Change State Event should instead be Radio Admin State. Perhaps the two are not described properly. The first is used by the WTP to inform the AC that something has occurred with a radio. The second is used by the AC to enable/disable a radio. 34) Report Timer needs to be in section 4.5 or 11 ok 35) Should Idle Timeout be per radio, or per WTP, and should the value be defined in section 4.5 or 11. Per WTP, and yes. I believe it is fine as it is. 36) WTP Fallback isn't well defined, and should be removed. Disagree. I believe it is necessary to create enough resiliency in the protocol/service. 37) How are the "Rate Set" and "Supported Rates" encoded. This was fixed in the -02 38) AC Timestamp doesn't belong in the configuration, but instead in the join. Not sure this really matters.... 39) Add MAC ACL Entry - this is so strange and is being managed like no other configuration data. I do not understand the comment 40) Decryption Error Report Period is not defined in section 4.5 or 11 ok, and note that the information has been moved to the IEEE 802.11 RSNA Error Report From Mobile 41) Configuration Update Response. today, there are primarily two types of configuration models. The first is when config is changed, it is only changed in the volatile copy (the memory or running). An explicit command is needed to save the config to nonvolatile storage. The second model has config both running (volatile) and saved (nonvolatile) config changed when a config change is made. And there might be a special command to have a config change apply to only one. In this case, there is no need for a "save config to nonvolatile" command. It is not clear what is suppose to be supported here in CAPWAP, and how does CAPWAP support devices with no or very limited nonvolatile storage for config! CAPWAP does not support WTPs with no nonvolatile storage. The protocol has the AC push configs to the WTP, which saves them at the time they are received. I do not believe anything else is required. 42) Configuration Update Response includes the Result Code message element, which includes values that do not appear to be relevant for this message, and there are plenty of other failure cases ok, but note that we are sharing a common message element. Any suggestions on how to address your issue? 43) Change State Event Report. This seems a little silly to be sent in the "configure" state. It seems only appropriate for the "run" state. Some might argue that even in the "run" state it shouldn't be sent after a "config update" request that changes the operational state. However, in the "run" state, it may take a while to have the operational state change to follow the admin state. Thus, I think it is OK in the "run" state after config changes." I believe this was addressed in -02. 44) Clear Config Request. this operation has several problems, which include: 1) currently, the CAPWAP-01 spec says that this can only be done in the "run" state. This is silly. It should also be possible in the "configure" state. I wonder why the AC would even consider clearing the WTP's state before it even knows how it is configured. 2) the value of "manufacturing defaults" is not defined, and a poor term to use, since it implies that that each manufacturer can have different values. If so, then the AC will have no knowledge of the config on the WTP! The problem of "default config values" has already be mentioned above. After each config attribute has been defined with a default value, then the proper term would be "CAPWAP config defaults". Yes, you've raised this point already, and I agree that it does need to be addressed. 3) This operation is not defined to have a response. This is broken, since any config change can fail. Also, it is not defined what happens next. Does this cause the WTP to reboot an start a "clean discovery"? This was addressed in -02 45) Image Data Request. Yes, there are actually three different "Image Data Request" messages. Which one is determined by which of the three message elements is contained. This is completely silly! There should be three separate operations! Additionally, how does the WTP know which image to get? The AC should be making that decision. I believe the WTP is the only device that knows what it's filename should be. Why would an AC vendor know about file naming conventions used by the WTP vendors? I believe your other issues are discussed in the next items. 46) Image Data Response. this is silly. This operation can fail! There needs to be message element that indicates the result. How so? This is only used to send firmware to the WTP. Not clear what could fail... Reading the image from flash? 47) Image Data Request. when starting over again at the WTP start state, the WTP shouldn't use the "normal" discovery process, but instead "fast track" a connection back to the AC that just downloaded the image. With a little more work, we could probably figure out a way to reuse the old DTLS session. To what gain? What is so expensive about the discovery, and what happened if the AC was not longer reachable? 48) opcode - if this is here, might as well also have a value that indicates last block of the image file, instead of looking at the block size. But we're just changing for the sake of changing - the protocol works as-is. 49) since this operation does not have the block number as a parameter, the WTP must determine the block number via the CAPWAP message header sequence number. NOTE: DTLS does not provide in-order delivery of packets. Also, this requires the WTP to remember state. This message element should be re-engineered to have the following subfields: [edited] The control header includes a sequence number, and while we can change the current protocol to match your recommendations, the protocol does work. If it ain't broken... 50) Image Data Response. this is silly. This operation can fail! For example, the WTP can run out of space to store the block, or there could be a failure in writing the block to storage. (Or as "Image Data Request"(9.1a) is presently specified, the checksum match could fail.) There needs to be message element that indicates the result.) Note: don't need a block number field, since request and responses are paired. We can include a result code 51) Image Data Request. silly beyond belief Beauty is in the eye of the beholder ;-). Seriously, the protocol does work, so what exactly are you looking for? 52) Image Data Response. This is silly. This operation can fail! There needs to be message element that indicates the result. See above comment. 53) Reset Request. ... The comment is irrelevant now that Clear Config has changed. 54) Reset Response. this is silly. This operation can fail! There needs to be message element that indicates the result. I sense a trend. I will stop including these messages from now on. 55)Duplicate IPv4 Address. how often is this reported if the condition remains? Only required once, I think, but we may want to include some text covering that. 56) the list of events seems understated! Text and conditions please 57) Data Transfer Request. Nice to have - remove. Disagree. Providing diagnostics capabilities is required. 58) Mobile Config Request. the actual details of how this works on both splitMAC and especially localMAC are not well specified. That is, only the figures and text in sections 11.1.1 and 11.1.2 provide any clue as to events that would cause an AC to send this message type. Also, there are restrictions on combinations of parameters that can be included in the message. I wonder whether other folks agree that more details are required. 59) it doesn't say if one message can be used to update more than one STA. It should be able. No, otherwise you end up with the problem of associating specific message elements with a given mobile. One mobile per request. 60) IEEE 802.11 Mobile. shouldn't the STA MAC address be included so this message element can be matched with a (4.4.8)Add Mobile message element? I believe this is to your previous point, but the protocol assumes one mobile per request. 61) IEEE 802.11 Update Mobile QoS. s this for data traffic to the AC? If so, then why is this an 802.11 message element Intended to be a way to push policies to the WTP to prioritize mobile traffic. 62) IEEE 802.11 WLAN Config Request. why is a new message type that is 802.11 specific needed to modify 802.11 WLANs? It seems like the existing "(8.4)Configuration Update Request" message could be used. To be more specific only. 63) note here there are information elements to create, delete, and modify WLANs. However, for message type "(10.1)Mobile Config Request", there is only add and delete (and the "add" used to modify). Correct. The protocol requires the AC to resend a new add with a different policy. No specific reason, but if this is deemed inconsistent, we could change it. 64) IEEE 802.11 Assigned WTP BSSID. The mapping of WLAN IDs to BSSIDs seems like it needs a little more work What exactly would you like to see? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Thursday, June 22, 2006 4:31 PM > To: capwap@frascone.com > Subject: [Capwap] A commentary on CAPWAP-01 operations > > HI, > > I've attached a long file that summarizes the operations in > CAPWAP-01. > > Enjoy, > /david t. perkins > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 27 12:25:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvGNG-00016k-Lz for capwap-archive@lists.ietf.org; Tue, 27 Jun 2006 12:25:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvE0P-0008PB-AE for capwap-archive@lists.ietf.org; Tue, 27 Jun 2006 09:53:29 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvDXj-00063x-Ny for capwap-archive@lists.ietf.org; Tue, 27 Jun 2006 09:23:55 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 259AD4300E6 for ; Tue, 27 Jun 2006 06:23:42 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1CB0D4300D0 for ; Tue, 27 Jun 2006 06:23:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id CBB7D398038 for ; Tue, 27 Jun 2006 06:23:12 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0BFCA398008 for ; Tue, 27 Jun 2006 06:23:06 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 27 Jun 2006 06:23:04 -0700 X-IronPort-AV: i="4.06,180,1149490800"; d="scan'208,217"; a="301641727:sNHT2068161524" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5RDN4pi025399 for ; Tue, 27 Jun 2006 06:23:04 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5RDN4CU020523 for ; Tue, 27 Jun 2006 06:23:04 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Jun 2006 06:23:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 Jun 2006 06:23:04 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202182F6F@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue with state machine Thread-Index: AcaZ0VAPpflxkqAoTXKbvBSbETp5KA== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 27 Jun 2006 13:23:04.0545 (UTC) FILETIME=[D2411510:01C699EC] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.459 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_40_50, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Issue with state machine X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0571237417==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 This is a multi-part message in MIME format. --===============0571237417== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C699EC.D2132914" This is a multi-part message in MIME format. ------_=_NextPart_001_01C699EC.D2132914 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I just noticed that the latest specification's state machine requires that in order to perform a firmware download, the state must transition from the join to configure to image data. This is a departure from the original protocol, and I believe introduces some challenges. One of the benefits of bypassing the configure state is that it maximizes interoperability across version numbers. If we require the configure state to be run, then we need to ensure that the configure message does not introduce any new message elements that can create a backward compatiblity issue. However, the way the protocol used to be only required that the Join state have to deal with backward compatibility. =20 I'd like to see this changed back to the old way. Sorry I missed this in my reviews. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C699EC.D2132914 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I just = noticed that=20 the latest specification's state machine requires that in order to = perform a=20 firmware download, the state must transition from the join to configure = to image=20 data. This is a departure from the original protocol, and I believe = introduces=20 some challenges. One of the benefits of bypassing the configure state is = that it=20 maximizes interoperability across version numbers. If we require the = configure=20 state to be run, then we need to ensure that the configure message does = not=20 introduce any new message elements that can create a backward = compatiblity=20 issue. However, the way the protocol used to be only required that the = Join=20 state have to deal with backward compatibility.
 
I'd = like to see this=20 changed back to the old way. Sorry I missed this in my=20 reviews.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 
------_=_NextPart_001_01C699EC.D2132914-- --===============0571237417== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0571237417==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jun 27 23:11:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvQSc-0004iQ-SR for capwap-archive@lists.ietf.org; Tue, 27 Jun 2006 23:11:26 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvQSb-0001CT-DV for capwap-archive@lists.ietf.org; Tue, 27 Jun 2006 23:11:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3E4C9430104 for ; Tue, 27 Jun 2006 20:11:24 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id ACDCC4300DD for ; Tue, 27 Jun 2006 20:10:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 906A2398025 for ; Tue, 27 Jun 2006 20:10:58 -0700 (PDT) Received: from web60320.mail.yahoo.com (web60320.mail.yahoo.com [209.73.178.128]) by zoidberg.tigertech.net (Postfix) with SMTP id D34A4398010 for ; Tue, 27 Jun 2006 20:10:54 -0700 (PDT) Received: (qmail 73437 invoked by uid 60001); 28 Jun 2006 03:10:53 -0000 Message-ID: <20060628031053.73435.qmail@web60320.mail.yahoo.com> Received: from [67.166.240.5] by web60320.mail.yahoo.com via HTTP; Tue, 27 Jun 2006 20:10:53 PDT Date: Tue, 27 Jun 2006 20:10:53 -0700 (PDT) From: Behcet Sarikaya To: capwap@frascone.com MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.962 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_WHOIS, HTML_50_60, HTML_MESSAGE X-Spam-Level: Subject: [Capwap] CAPWAPHP Draft X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Behcet Sarikaya List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1428035005==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d --===============1428035005== Content-Type: multipart/alternative; boundary="0-1254032224-1151464253=:71263" --0-1254032224-1151464253=:71263 Content-Type: text/plain; charset=us-ascii Dear All, FYI we have submitted -02 version of draft-sarikaya-capwap-capwaphp-02.txt in this version, we have modified many things to align it with CAPWAP draft version -02. Also we added a future work section. It is worth taking a lot at. The link is: http://ietf.org/internet-drafts/draft-sarikaya-capwap-capwaphp-02.txt Regards, --behcet --0-1254032224-1151464253=:71263 Content-Type: text/html; charset=us-ascii
Dear All,
  FYI we have submitted -02 version of
draft-sarikaya-capwap-capwaphp-02.txt
in this version, we have modified many things to align it with CAPWAP draft version -02.
Also we added a future work section.
It is worth taking a lot at.

  The link is:
http://ietf.org/internet-drafts/draft-sarikaya-capwap-capwaphp-02.txt

Regards,

--behcet
--0-1254032224-1151464253=:71263-- --===============1428035005== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1428035005==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 28 00:33:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvRjo-0003qr-1g for capwap-archive@lists.ietf.org; Wed, 28 Jun 2006 00:33:16 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvRjl-0006WH-IO for capwap-archive@lists.ietf.org; Wed, 28 Jun 2006 00:33:16 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 80A644301AD for ; Tue, 27 Jun 2006 21:33:12 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 157F14300F9 for ; Tue, 27 Jun 2006 21:32:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 000A9398010 for ; Tue, 27 Jun 2006 21:32:49 -0700 (PDT) X-Greylist-Status: Sender first seen 5 mons 2 days 12:45:03 ago Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by zoidberg.tigertech.net (Postfix) with ESMTP id C284939800E for ; Tue, 27 Jun 2006 21:32:46 -0700 (PDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5S4SQdt007772 for ; Wed, 28 Jun 2006 00:28:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 Jun 2006 22:32:44 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Keepalive on data channel Thread-Index: AcaZKg+sDPr7U0bQThi3hSxJPT/MzgATMV2gAARmr7AAOJmEUA== From: "Mani, Mahalingam (Mani)" To: "Pat Calhoun (pacalhou)" , X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: Re: [Capwap] Keepalive on data channel X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Pat, The relevance of the 'Then' preceding the recommendation is not clear. This is merely an observation of the implication of the behavior on this given network policy instance. We expect the relevant areas to respond when ADs take this up with them. -mani -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Monday, June 26, 2006 6:27 PM To: Mani, Mahalingam (Mani); capwap@frascone.com Subject: RE: [Capwap] Keepalive on data channel Mani, Then I would recommend that you include folks from the Internet Area in your discussions, as they have a number of tunneling standards efforts underway, as well as operational experience. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Mani, Mahalingam (Mani) [mailto:mmani@avaya.com] > Sent: Monday, June 26, 2006 5:22 PM > To: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: RE: [Capwap] Keepalive on data channel > > It appears that in such a network - all flows marked for DSCP > -based QoS are at a diagnostic peril - each of a different > kind - in such a failure scenario. > > -mani > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Monday, June 26, 2006 7:09 AM > To: capwap@frascone.com > Subject: [Capwap] Keepalive on data channel > > All, > > In a conversation with some of the L2TP folks, they have > experience an operational problem that we need to keep in > mind. Basically, they multiplex their control and data frames > through their own header, and mark their packets priorities > based on control vs. data. > > What they have found is that networks do route path selection > based on DSCP/ToS values, meaning that they send higher > priority (control) frames over different links than data > frames. The network is not designed to perform this solely > for L2TP, as this is something they do for all of their > applications. The issue is that their protocol relies on a > keepalive frame that runs over the control channel, > identically to CAPWAP. However, the operational issue that > they've found is that if the path taken by the data channel > is broken, and these frames are never delivered. > > The L2TP folks have found that the lack of a keepalive > mechanism makes it impossible to diagnose such an issue. When > it occurs, the administrator first has to figure out it is > occurring, because the protocol does not, and then needs to > manually follow the path to find the failure. > > As far as I can tell, Scott's two primary issues with not > wanting to support UDP ports were: > 1. NAT Traversal will require a keepalive on the data > channel. As noted above, we need to add a keepalive on the > data channel in order to be able to detect network routing failures. > 2. Modifications to the state machine to handle data channel failure. > Given that such failures can occur, we need to be able to > recover, if possible. > > I wanted to raise these issues as they are real, and actually > experienced in L2TP deployments. I believe we need to address > these, and if so, then I believe the complexity associated > with the dual UDP port ends up being resolved. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jun 28 11:13:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvbiz-0002f9-81 for capwap-archive@lists.ietf.org; Wed, 28 Jun 2006 11:13:05 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvbVw-0000Em-Dh for capwap-archive@lists.ietf.org; Wed, 28 Jun 2006 10:59:37 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BE7494301BC for ; Wed, 28 Jun 2006 07:59:35 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 239C4430063 for ; Wed, 28 Jun 2006 07:59:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D7C5739805C for ; Wed, 28 Jun 2006 07:59:01 -0700 (PDT) X-Greylist-Status: Sender first seen 17 days 02:12:11 ago Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by zoidberg.tigertech.net (Postfix) with ESMTP id 92EBF398040 for ; Wed, 28 Jun 2006 07:58:29 -0700 (PDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5SEs7nT030654 for ; Wed, 28 Jun 2006 10:54:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 Jun 2006 17:58:26 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for candidates for additional WG co-chair for CAPWAP Thread-Index: Acaaw07oohHHM1g6R8ugIv6M/vCQ/Q== From: "Romascanu, Dan (Dan)" To: "capwap" X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: "Ops-Nm (E-mail)" , ietf@ietf.org Subject: [Capwap] Call for candidates for additional WG co-chair for CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 In order to increase the efficiency of the work in the CAPWAP Working Group (http://www.ietf.org/html.charters/capwap-charter.html), and in order to accelerate the consensus process in the Working Group, the Area Directors decided to create a third co-chair position for the CAPWAP WG. The ADs have decided to write down a brief profile for the WG chair(s). We would like you to consider this profile and either nominate yourself or other people that you think that would fit well in this role by sending mail to the OPS ADs. ( and ). We do not intend to disclose the names of the nominees in public, but we will probably solicit for feedback with various other people. If you have a problem with your name being mentioned in this context, pls let us know. Note that this profile is written for a somewhat ideal candidate. We fully realize that such people are probably non-existent, so don't hesitate to nominate somebody who in your opinion would fit this role quite well but doesn't fit this profile 100%. And the intend is to select two co-chairs that can complement each other and work together. As for the profile: - Good management and process skills, including but not limited to choosing and supervising editors, commitment and follow-through on the charter, active management of the working group discussions, and handling IETF process steps in prompt fashion. - Good basic knowledge of the wireless LAN and IP mobility protocols - Good understanding of requirements, candidate proposals and work-in-progress in CAPWAP - Operational background/experience is very desirable. - Enough available time. For example, preferable not more than one other working chair role in IETF. - There is no requirement that the candidate has been an IETF working group chair before, but it helps if there is some evidence that the candidate can fulfill such a role (e.g.. other management role in other places than IETF etc.) We would like to receive your comments & nominations by July 7th, 2006 and we plan to make a decision as soon as possible thereafter. It will be helpful if you indicate in your nomination mail how you or the nominated candidate fits this profile as best as possible. Dan Romascanu and David Kessens _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From christor54@aol.com Wed Jun 28 19:34:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvjY8-0007si-5X for capwap-archive@megatron.ietf.org; Wed, 28 Jun 2006 19:34:24 -0400 Received: from c020297.adsl.customers.cinergycom.net ([216.135.36.104] helo=10.10.4.11) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FvjY6-0005r8-WF for capwap-archive@megatron.ietf.org; Wed, 28 Jun 2006 19:34:24 -0400 X-Spam-Score: 4.2 (++++) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 30 10:34:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwK4w-0006A2-Ud for capwap-archive@lists.ietf.org; Fri, 30 Jun 2006 10:34:42 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwK4v-00028r-EW for capwap-archive@lists.ietf.org; Fri, 30 Jun 2006 10:34:42 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id ACC9E430081 for ; Fri, 30 Jun 2006 07:34:40 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 82DE9430018 for ; Fri, 30 Jun 2006 06:59:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 711FC1448007 for ; Fri, 30 Jun 2006 06:59:26 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by hermes.tigertech.net (Postfix) with ESMTP id 610D61448004 for ; Fri, 30 Jun 2006 06:59:23 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id m51so698857pye for ; Fri, 30 Jun 2006 06:59:22 -0700 (PDT) Received: by 10.35.103.12 with SMTP id f12mr513881pym; Fri, 30 Jun 2006 06:59:22 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Fri, 30 Jun 2006 06:59:22 -0700 (PDT) Message-ID: <26140d940606300659jce1befcx34a33a58d939d792@mail.gmail.com> Date: Fri, 30 Jun 2006 09:59:22 -0400 From: "Michael Montemurro" To: "Behcet Sarikaya" In-Reply-To: <20060623195910.13396.qmail@web60315.mail.yahoo.com> MIME-Version: 1.0 References: <20060623195910.13396.qmail@web60315.mail.yahoo.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Packet flows for new STA session X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0599736939==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f --===============0599736939== Content-Type: multipart/alternative; boundary="----=_Part_9197_6525344.1151675962803" ------=_Part_9197_6525344.1151675962803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline David, I created issue number 145 to track this issue. Cheers, Mike On 6/23/06, Behcet Sarikaya wrote: > > Hi David, > Roaming with key caching and other new developments is a work item for > possible rechartering. I think the present text is OK. > > Regards, > > > --behcet > > > ----- Original Message ---- > From: David T. Perkins > To: capwap@frascone.com > Sent: Friday, June 23, 2006 1:16:46 PM > Subject: [Capwap] Packet flows for new STA session > > HI, > > There is a lot of detail missing in CAPWAP describing > how a STA session is created for both splitMAC and > localMAC. It would be quite useful if someone would > take figures 5 and 7 and add the detail. > > Regards, > /david t. perkins > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_9197_6525344.1151675962803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
David,
 
I created issue number 145 to track this issue.
 
Cheers,
 
Mike

 
On 6/23/06, Behcet Sarikaya <behcetsarikaya@yahoo.com> wrote:
Hi David,
  Roaming with key caching and other new developments is a work item for possible rechartering. I think the present text is OK.

Regards,
 

--behcet


----- Original Message ----
From: David T. Perkins < dperkins@dsperkins.com>
To: capwap@frascone.com
Sent: Friday, June 23, 2006 1:16:46 PM
Subject: [Capwap] Packet flows for new STA session

HI,

There is a lot of detail missing in CAPWAP describing
how a STA session is created for both splitMAC and
localMAC. It would be quite useful if someone would
take figures 5 and 7 and add the detail.

Regards,
/david t. perkins

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap
 


_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


------=_Part_9197_6525344.1151675962803-- --===============0599736939== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0599736939==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 30 10:37:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwK7J-0006Qx-Nr for capwap-archive@lists.ietf.org; Fri, 30 Jun 2006 10:37:09 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwK7H-0002KK-4x for capwap-archive@lists.ietf.org; Fri, 30 Jun 2006 10:37:09 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 468EC4300E3 for ; Fri, 30 Jun 2006 07:37:06 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4A801430081 for ; Fri, 30 Jun 2006 07:01:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id F29D4144800D for ; Fri, 30 Jun 2006 07:01:58 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by hermes.tigertech.net (Postfix) with ESMTP id 90B021448004 for ; Fri, 30 Jun 2006 07:01:55 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id m51so699876pye for ; Fri, 30 Jun 2006 07:01:54 -0700 (PDT) Received: by 10.35.27.1 with SMTP id e1mr517976pyj; Fri, 30 Jun 2006 07:01:54 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Fri, 30 Jun 2006 07:01:54 -0700 (PDT) Message-ID: <26140d940606300701x64968f66g5fbda55b2bd0cb2f@mail.gmail.com> Date: Fri, 30 Jun 2006 10:01:54 -0400 From: "Michael Montemurro" To: "David T. Perkins" In-Reply-To: MIME-Version: 1.0 References: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Update proposal for Packet formats X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1663900382==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 1c75752474da50d4e2e5f8373cbb66b5 --===============1663900382== Content-Type: multipart/alternative; boundary="----=_Part_9281_24383419.1151676114542" ------=_Part_9281_24383419.1151676114542 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline David, I created issue number 146 to track this. Mike On 6/26/06, David T. Perkins wrote: > > HI, > > In the last proposal, I remove a field used > for retries. In verifying whether it could be > done, I found a problem. Below is the updated > proposal, which includes examples showing > how fragmentation works, and how retries > work. Please let me know if you have any > problems. This is what I plan to have > implemented and demonstrate at IETF. > > --------------------------- > Proposal for CAPWAP Packet Format > -------------------------------- > > Updates from 22-jun-2006: > 1) Cleaned up terminology definitions. > 1) Added clarification about initial values for the > "CAPWAP PDU ID" and "MSG ID" fields > 2) Added timing diagram showing no fragmentation and fragmentation > 3) Added timing diagram showing CAPWAP control message drops > and retries > 4) Put back in MSG Seq ID into the Control header, but re-labeled > as retry num, and reordered fields. > > Updates from 8-jun-2006: > 1) Made to look closer to CAPWAP-02 > 2) Added CAPWAP Fragmentation Header so that both control > and data supported fragmentation > 3) Updated descriptions of fields of packets > 4) Changed how fragmentation is indicated. > 5) Modified so that the Data (or Control) header is > on in the first fragment of a CAPWAP PDU > 6) Cleaned up Data Header, now that fragmentation > is in a separate header and made the remaining > fields match those in CAPWAP-02 > 7) Updated the Control Header so that it closely > resembles CAPWAP-02, except for 'F' field. > > > > Updates from 7-jun-2006: > 1) changed diagrams to make DTLS experts happier > 2) renamed "CAPWAP MUX Hdr" to "CAPWAP Pkt Hdr", > and made it 2 octets long instead of 1 octet > 3) made the packet types start at 1 instead of zero > 4) fixed a few typos > 5) changed the formulas for the message type value and > message element type value to multiply the IANA > enterprise number by 4096 (shift left by 12) instead > of 256 (shift left by 8). This means the the > enterprise value must be encoded in 20 bits, > and the specific type value in 12 bits. I checked > the assignment of Enterprise numbers, and there are > now approximately 16K, and also checked the OUI > assignments and there are approximately 51K. Thus, > 20 bits (1M) should be enough! > --------------------------------- > > CAPWAP Packet formats: > > > CAPWAP Unprotected Data Packet: > +------------------------------[--------]----------+ > | IP | UDP | CAPWAP | CAPWAP | CAPWAP | Wireless | > | Hdr | Hdr | Pkt | Frag | Data | Payload | > | | | Hdr | Ctrl | Hdr | Frag | > +------------------------------[--------]----------+ > only in > first fragment > > CAPWAP DTLS Protected Data Packet: > +-------------------------------------[---------]--------------------+ > | IP | UDP | CAPWAP | DTLS | CAPWAP | CAPWAP | Wireless | DTLS | > | Hdr | Hdr | Pkt | Hdr | Frag | Data | Payload | Trailer | > | | | Hdr | | Ctrl | Hdr | Frag | | > +-------------------------------------[---------]--------------------+ > only in > first fragment > \--integrity checked-----------------/ > \--encrypted----------------------------/ > > > CAPWAP Unprotected Control Packet: > +------------------------------[---------]----------+ > | IP | UDP | CAPWAP | CAPWAP | CAPWAP | Message | > | Hdr | Hdr | Pkt | Frag | Control | Elements | > | | | Hdr | Ctrl | Hdr | Frag | > +------------------------------[---------]----------+ > only in > first fragment > > CAPWAP DTLS Protected Control Packet: > +------------------------------------[---------]--------------------+ > | IP | UDP | CAPWAP | DTLS | CAPWAP | CAPWAP | Message | DTLS | > | Hdr | Hdr | Pkt | Hdr | Frag | Control | Elements | Trailer | > | | | Hdr | | Ctrl | Hdr | Frag | | > +------------------------------------[---------]--------------------+ > only in > first fragment > \--integrity checked----------------/ > \--encrypted----------------------------/ > > UDP: All CAPWAP packets are encapsulated within UDP. > > CAPWAP Pkt Header: All CAPWAP protocol packets use a short header > that specifies the version of CAPWAP and the type of the > CAPWAP packet. > > CAPWAP PDU: CAPWAP consists of both control and data streams. > A CAPWAP PDU is either a CAPWAP control PDU or > a CAPWAP data PDU. > > CAPWAP Control PDU: A CAPWAP control PDU encapsulates a > control message, which is a control header and its > message elements. > > CAPWAP Data PDU: A CAPWAP data PDU encapsulates a data > message, which is a data header and wireless > payload. > > CAPWAP Fragmentation Control Header: Used for fragmentation > of CAPWAP PDUs. A CAPWAP PDU that will not fit in > one UDP packet will be fragmented into multiple > CAPWAP packets. > > CAPWAP Data Header: This header is used for CAPWAP data PDUs. > If a CAPWAP data PDU is fragmented, then the CAPWAP > Data Header is in only the first fragment in the > group of fragments constructing the CAPWAP data PDU. > > Wireless Payload: The actual payload from or to wireless > devices. The format may be 802.3 Ethernet II, or > native wireless transport specific encoding. > > DTLS Header: Protected CAPWAP packets use the DTLS protocol to > provide message integrity and encryption services. > > DTLS Trailer: A field used to provide protection service for > security of CAPWAP messages. > > CAPWAP Control Header: The CAPWAP protocol includes a signalling > component, known as the CAPWAP control protocol. All CAPWAP > control PDUs include a Control Header. If a CAPWAP control PDU > is fragmented, then the CAPWAP Control Header is in only > the first fragment in the group of fragments constructing > the CAPWAP control PDU. > > Message Elements: A CAPWAP Control PDU includes zero, one, > or more message elements, which are found immediately > following the control header. These message elements > are in a type, length, value format. > > > CAPWAP Pkt Header: > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version | Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Version - the version of the CAPWAP protocol (the first is 1) > DISCUSS: should this be split into major and minor, > and if so, what are the implications of > an increment of the major or minor part? > > Type - packet type, values are: > 1 - CAPWAP Unprotected Data Packet > 2 - CAPWAP DTLS Protected Data Packet > 3 - CAPWAP Unprotected Control Packet > 4 - CAPWAP DTLS Protected Control Packet > 0,5-15 - reserved > > > CAPWAP Fragmentation Control Header: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |M|Res| CAPWAP PDU ID | Fragment Offset | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > M: The More 'M' bit indicates whether there are more fragment > packets needed to be combined to reassemble a complete > CAPWAP PDU. When this bit is 1, there are more fragment > packets. When this bit is 0, there are no more fragments > and this packet completes the CAPWAP PDU. > > Res: The bits are reserved, and must be zero. > > CAPWAP PDU ID: A 16-bit field whose value is assigned to each > CAPWAP PDU. The CAPWAP PDU ID space is managed independently > for every WTP/AC pair, for each end (an AC or WTP), and for > each CAPWAP stream (data or control). For example, if AC #1 > communicates with WTP #1 and WTP #2, there will be the > following independent CAPWAP PDU IDs: > WTP #1: ID1 for control going to AC #1 > ID2 for data going to AC #1 > WTP #2: ID3 for control going to AC #1 > ID4 for data going to AC #1 > AC #1: ID5 for control going to WTP #1 > ID6 for data going to WTP #1 > ID7 for control going to WTP #2 > ID8 for data going to WTP #2 > The value for each CAPWAP PDU ID is incremented with each > new CAPWAP PDU sent whether or not the PDU is fragmented. > The value wraps to zero after the maximum value has been > used to identify a CAPWAP PDU. When a new session > is established, the initial value is a randomly generated > number. > > Fragment Offset: A 13 bit field that indicates where in the CAPWAP > PDU will this fragment belong during re-assembly. This > field should always have a valid value. For the first > or only packet of a CAPWAP PDU, the value must be zero. > The fragment offset is measured in units of 8 octets > (64 bits). This provides a maximum size of a CAPWAP > PDU to be 16 bits (which is 65536 octets). > Note the CAPWAP protocol does not allow for overlapping > fragments. For instance, it would be an error if the > first fragment was 1000 octets in length, and the > second fragment's offset was 800. To be valid (when > the length of the first fragment is 1000, the second > fragment MUST have an offset of 1000. > (DISCUSS: need to have a timer that is associated with > fragmentation to toss all of the fragments if they > have not been combined in the allocated time.) > > > CAPWAP Data Header: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RID | HLEN | WBID |T|W|M| Res | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | (optional) Radio MAC Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | (optional) Wireless Specific Information | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > RID: A 5 bit field which contains the Radio ID for this CAPWAP > data PDU. WTPs with multiple radios but a single MAC Address > range (for BSSIDs) use this field to indicate which radio is > associated with the packet. > > HLEN: A 5 bit field specifying the length of the CAPWAP data > header header in 4 octet words (Similar to IP header length). > This length includes the optional headers. > > T: The Type 'T' bit indicates the format of the frame being > transported in the payload. When this bit is set to one (1), > the payload has the native frame format indicated by the > WBID field. When this bit is zero (0) the payload is an > IEEE 802.3 frame. > > W: The 'W' bit is used to specify whether the optional > "Wireless Specific Information" field is present in the header. > A value of one (1) is used to represent the fact that the > field is present. > > M: The 'M' bit is used to specify whether the optional > "Radio MAC Address" field is present in the header. > A value of one (1) is used to represent the fact that the > field is present. > > Res: The bits are reserved and must be zero. > > Radio MAC Address: This optional field contains the BSSID > of the radio receiving the packet. This is used in packets > sent from the WTP to the AC, when the native wireless frame > format is converted to 802.3 by the WTP. This field is only > present if the 'M' bit is set. Given the HLEN field requires > the header size to be a multiple of 4 octets, this field MUST > be padded with zeroes (0x00) if it is not 4 octet aligned. > > The field has the format: > > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > | Length | MAC Address ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > Length: The number of octets in the MAC Address field. The > length field is present since new IEEE technologies > (e.g., 802.16) are now using 64 bits (8 octet) MAC > addresses. > > MAC Address: The BSSID of the receiving radio. > > Wireless Specific Information: This optional field contains > technology specific information that may be used to carry per > packet wireless information. This field is only present if > the 'W' bit is set. Given the HLEN field assumes 4 octet > alignment, this field MUST be padded with zeroes (0x00) if > it is not 4 octet aligned. > > The field has the format: > > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > | Wireless ID | Length | Data ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > Wireless ID: The wireless binding identifier. The following > values are defined: > 1 - : IEEE 802.11 > > Length: The length of the data field > > Data: Wireless specific information, whose details are > defined in the technology specific bindings sections. > > For 802.11, when sent from WTP to AC, the data > has the following format: > > IEEE 802.11 Frame Info: > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RSSI | SNR | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data Rate | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > RSSI: RSSI is a signed, 8-bit value. It is the > received signal strength indication, in dBm. > > SNR: SNR is a signed, 8-bit value. It is the signal > to noise ratio of the received IEEE 802.11 frame, > in dB. > > Data Rate: The data rate field is a 16-bit unsigned > integer value. The contents of the field is set > to 1/10th of the data rate of the packet received > by the WTP. For instance, a packet received at > 5.5Mbps would be set to 55, while 11Mbps would > be set to 110. > > For data sent from the AC to the WTP, the data > has the following format: > > Destination WLANs: > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | WLAN | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > WLAN: This bit vector indicates the WLAN ID(s) which > the WTP will transmit the associated frame on. > For instance, if a multicast packet is to be > transmitted on WLANs 1 and 3, bits 1 and 3 of > this field would be set to '1'. Note this > field is to be set to zero for unicast > packets and is unused if the WTP is not > providing encryption services. > > Wireless Payload: > The format of the wireless payload depends on the encapsulation > mode. There are two formats defined, which are: > > 802.3 Frame - this is the standard IEEE 802.3 Ethernet II frame > (DISCUSS: this needs to be confirmed) > 802.11 native frame - DISCUSS: finish this > > > CAPWAP Control Header: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Msg ID | Retry#|F| Res | Length of Msg Elements | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Message Type: This field identifies the function of the CAPWAP > control message. The Message Type field is comprised of > an IANA Enterprise Number and an enterprise specific message > type number. The first 20 bits is the enterprise number > in network byte order, with zero being used for CAPWAP > generic message types and the IEEE 802.11 IANA assigned > enterprise number 13277 being used for IEEE 802.11 technology > specific message types. The last 12 bits is the enterprise > specific message type number, which has a range from 0 to > 4095. > > The value of the message type field can be expressed as: > > Message type value = IANA Enterprise Number * 4096 + > enterprise specific message type number > > Msg ID: The message ID field is used by the CAPWAP control > application to match responses (or acknowledgements) with > requests (or reports). The value must be monotonically > incremented for each unique request (or report). After > the maximum value is reached, the value wraps back to zero. > The paired response (or acknowledgement) returns the value > from the request (or report). Note the size is 8-bits, and > thus a maximum of 255 CAPWAP operations can be currently > outstanding. The message ID space is managed independently > for every WTP/AC pair, and for each end (an AC or WTP). > For example, if AC#1 communicates with WTP #1 and WTP #2, > there will be the following independent Message IDs: > WTP #1: MSG ID1 for requests (and reports) going to AC #1 > WTP #2: MSG ID2 for requests (and reports) going to AC #1 > AC #1: MSG ID3 for requests going to WTP #1 > MSG ID4 for requests going to WTP #2 > When a new session is established, the initial value is > a randomly generated number. > > Retry#: The retry number field starts at zero and is incremented > for each message with the same value of message ID. > After the maximum value is reached, the value wraps back > to zero. The paired response (or acknowledgement) returns > the value from the request (or report). Note the size > is 4-bits, and thus a maximum of 16 retries can be > be currently outstanding. > This field is used to match a request (or report) > with its paired response (or acknowledgement) so that > accurate round trip operation time can be determined. > (DISCUSS: maybe put back here the text about how this > works. The examples of operation retries should help.) > > F: The 'F' bit field indicates if the message is the first > message in a message pair. A value of "1" means > first, and "0" means second in the pair. There are > two types of message pairs, which are: > 1) a request and response > 2) a report and acknowledgement. > Thus, the first is a request or report message > (with the 'F' field set to "1"), and the second is > a response or acknowledgement (with the 'F' field > set to "0"). Note, both a request and response > (or report and acknowledgement) of a operation > type use the same value for message type. The > 'F' bit is used to indicate which is which. > This allows new message types to be added > that can be processed without knowing the > meaning of the message type. That is, when > an unknown request message type is received, > the response is the same message type with > a message element indicating that the message > type is not supported. > > Res: The bits are reserved and must be zero. > > Length of Message Elements: This field indicates in octets the > length of the message elements field, which contains zero, > one, or more message elements. The field is 16 bits wide, > and thus the maximum size that can be specified 64K. > However, the maximum size of a CAPWAP control PDU is > 64K, and thus the max length is 64K minus the size of > the CAPWAP control header, or 64K - 8, or 65528. > > Message Elements: > The "message elements" field contains, zero, one, or more message > element field, which has the following format: > > Message Element: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message Element Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length | Value .... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > Message Element Type: This field identifies a message element > of a CAPWAP control message. The Message Element Type field > is comprised of an IANA Enterprise Number and an enterprise > specific message element type number. The first 20 bits > is the enterprise number in network byte order, with zero > being used for CAPWAP generic message types and the > IEEE 802.11 IANA assigned enterprise number 13277 being > used for IEEE 802.11 technology specific message element > types. The 12 bits is the enterprise specific message > element type number, which has a range from 0 to 4095. > > The value of the message element type field can be expressed > as: > > Message element type value = IANA Enterprise Number * 4096 + > enterprise specific message element type number > > > ------------------------------------------------ > Use of the CAPWAP Fragmentation Control Header > > Example of a Nonfragmented CAPWAP PDU > > For both data and control CAPWAP packets, CAPWAP Fragment Control > Header has the following content: > > first, compute next CAPWAP_PDU_ID, which is > CAPWAP_PDU_ID = (CAPWAP_PDU_ID + 1) & 0x0ffff; > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|0 0| CAPWAP_PDU_ID | 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Example of Fragmented CAPWAP PDUs > > 1) Here is an example of a CAPWAP data PDU where the > length of the CAPWAP data header and wireless payload > will cause a single CAPWAP data packet to be greater than > the max IP packet size for the path. Assume that > the size of the CAPWAP data PDU is 1560 octets, which > needs to be fragmented into a fragments of 1400 and > 160 octets. > > The first fragment would have the following CAPWAP > fragment control header, and be followed by a > CAPWAP data header and part of the wireless payload > and would look like: > > first, compute next CAPWAP_PDU_ID, which is > CAPWAP_PDU_ID = (CAPWAP_PDU_ID + 1) & 0x0ffff; > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|0 0| CAPWAP_PDU_ID | 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The second fragment would have the following CAPWAP > fragment control header, and be followed by the remaining > portion of the wireless payload and would look like: > > (Use the same value of CAPWAP_PDU_ID) > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|0 0| CAPWAP_PDU_ID | (1400/8) = 175 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 2) Here is an example of a CAPWAP control PDU where the > length of the CAPWAP control header and message elements > will cause a single CAPWAP control packet to be greater > than the max IP packet size for the path. Assume that > the size of the CAPWAP control PDU is 1560 octets, which > needs to be fragmented into a fragments of 1400 and > 160 octets. > > The first fragment would have the following CAPWAP > fragment control header, and be followed by a > CAPWAP control header and part of the message elements > and would look like: > > first, compute next CAPWAP_PDU_ID, which is > CAPWAP_PDU_ID = (CAPWAP_PDU_ID + 1) & 0x0ffff; > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|0 0| CAPWAP_PDU_ID | 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The second fragment would have the following CAPWAP > fragment control header, and be followed by the remaining > portion of the wireless payload and would look like: > > (Use the same value of CAPWAP_PDU_ID) > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|0 0| CAPWAP_PDU_ID | (1400/8) = 175 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > ------------------------------------------------ > Use of the "Msg ID" and "Retry#" Fields for Retries > > Only the control path has message retries. Since > control operations are not idempotent (that is, > are not guaranteed to return the same result > when redone), operation results (the response > or acknowledgement) to a request or report > must be cached and returned if a repeat of > the operation occurs. A repeat occurs when > 1) the request (or report) is not received > (however, the receiver does not know that > the operation is being repeated) > 2) the response (or acknowledgement) is > not received within the expected operation > round trip time. > 3) the request (or report) is duplicated by > the network (this only occurs when the > control operation is not protected by DTLS) > > Here are timing diagrams for 4 cases: > > Abbreviations: > P_ID - PDU ID > M_ID - MSG ID > R - Retry number > > 0) No timeout/replay/duplication: > (P_ID=56, M_ID=23, R=0) (M_ID=23, R=0) > WTP----------------------->|----------------------->AC - process > | | and cache > (M_ID=23, R=0) | (P_ID=75,M_ID=23,R=0) | for M_ID=23 > <------------------------|<------------------------ and R=0 > | > > NOTEs: 1) AC and WTP have different spaces for P_ID. It > is used only for CAPWAP PDU fragmentation reassembly. > 2) The P_ID is always incremented for each CAPWAP PDU, > even for retries > 3) the M_ID from a request (or report) is > echoed in a paired response (or acknowledgement) > 4) each originator of an operation has an independent > M_ID number space > > > 1) message never received, so resent: > (P_ID=56, M_ID=23, R=0) > WTP----------------------->|-->X AC > | | > |timeout | > V (P_ID=57, M_ID=23, R=1) | > retry---------------------->|----------------------->AC - process > | | and cache > (M_ID=23, R=1) | (P_ID=75,M_ID=23, R=1) | for M_ID=23 > <------------------------|<------------------------ and R=1 > > > NOTEs: 1) the M_ID is not incremented on retries > 2) the R always starts at zero for each M_ID and > is incremented on retries > > > 2a) message response (or acknowledgement) never received, > so message resent: > (P_ID=56, M_ID=23, R=0) (M_ID=23, R=0) > WTP----------------------->|----------------------->AC - process > | | | and cache > | | (P_ID=75,M_ID=23,R=0) | for M_ID=23 > | X<--|<------------------------ and R=0 > |timeout | > V (P_ID=57, M_ID=23, R=1) | (M_ID=23, R=1) > retry---------------------->|----------------------->AC - find in > | | cache for > (M_ID=23, R=1) | (P_ID=75,M_ID=23,R=1) | M_ID=23, > <------------------------|<------------------------ update R=1 > > NOTEs: 1) only the M_ID is search in the cache for a match > (the R is saved, but not used in search) > 2) the R from the request message is returned > in the response message > 3) the R is updated in the cache > > 2b) message response (or acknowledgement) not received within > the current computed value for round trip operation > time, so a message resent. However, original response > received before response to retry. > > (P_ID=56, M_ID=23, R=0) (M_ID=23, R=0) > WTP----------------------->|----------------------->AC - process > | | | and cache > | | (P_ID=75,M_ID=23,R=0) | for M_ID=23 > | |/------------------------ and R=0 > |timeout || > V (P_ID=57, M_ID=23, R=1) || (M_ID=23, R=1) > retry---------------------->|+---------------------->AC - find in > || | cache for > (M_ID=23, R=0) || | M_ID=23, > <------------------------|/ | update R=1 > update RTOT(drop) | | > | | > (M_ID=23, R=1) | (P_ID=75,M_ID=23,R=1) | > <------------------------|<------------------------ > update RTOT(process) > > NOTEs: 1) without the R field, cannot determine if the > first received response was from the first > time the request was made, or from a the > retry. Without knowing which, cannot > accurately update the round trip > operational time. > 2) it is possible to process the first response > and not drop it, but if so, must remember > the time when sent each retry. If max retries > not too many, then not much of a cost. > a match (the R is not saved or searched) > > 3) message request (or report) is duplicated by the > network: > (P_ID=56, M_ID=23, R=0) (M_ID=23, R=0) > WTP----------------------->|----------------------->AC - process > \ | | and cache > (M_ID=23, R=0) \ | (P_ID=75,M_ID=23,R=0) | for M_ID=23 > <------------------+------|<------------------------ and R=0 > \ | > \ | (M_ID=23, R=0) > Dup \-->|+---------------------->AC - find in > | cache for > | M_ID=23, > R is the > same so drop > > NOTEs: 1) the R field in the duplicated message is used > by the AC to determine if the request is > a duplicate. > 2) if both a response drop (or delay) and > a duplicate occurs the R may be less > than the R in the cache. If so, the > message is a very delayed duplicate > and can be dropped. > > > --------------------------- > Regards, > /david t. perkins > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_9281_24383419.1151676114542 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
David,
 
I created issue number 146 to track this.
 
Mike

 
On 6/26/06, = David T. Perkins <dperkins= @dsperkins.com> wrote:
HI,

In the last proposal,= I remove a field used
for retries. In verifying whether it could be
done, I found a problem. Below is the updated
proposal, which includes e= xamples showing
how fragmentation works, and how retries
work. Please= let me know if you have any
problems. This is what I plan to have
implemented and demonstrate at IETF.

---------------------------
= Proposal for CAPWAP Packet Format
--------------------------------
Updates from 22-jun-2006:
1) Cleaned up terminology definitions.
1) Added clarification about initial values for the
  "CA= PWAP PDU ID" and "MSG ID" fields
2) Added timing diagram = showing no fragmentation and fragmentation
3) Added timing diagram showi= ng CAPWAP control message drops
  and retries
4) Put back in MSG Seq ID into the Control h= eader, but re-labeled
  as retry num, and reordered fields.
Updates from 8-jun-2006:
1) Made to look closer to CAPWAP-02
2) = Added CAPWAP Fragmentation Header so that both control
   and data supported fragmentation
3) Updated description= s of fields of packets
4) Changed how fragmentation is indicated.
5) = Modified so that the Data (or Control) header is
  on in the f= irst fragment of a CAPWAP PDU
6) Cleaned up Data Header, now that fragmentation
  is in = a separate header and made the remaining
  fields match those = in CAPWAP-02
7) Updated the Control Header so that it closely
 &= nbsp;resembles CAPWAP-02, except for 'F' field.



Updates from 7-jun-2006:
1) changed diagrams to make DTL= S experts happier
2) renamed "CAPWAP MUX Hdr" to "CAPWAP = Pkt Hdr",
   and made it 2 octets long instead of 1 octet=
3) made the packet types start at 1 instead of zero
4) fixed a few typos
5) changed the formulas for the message type va= lue and
  message element type value to multiply the IANA
&= nbsp; enterprise number by 4096 (shift left by 12) instead
 &n= bsp;of 256 (shift left by 8). This means the the
  enterprise value must be encoded in 20 bits,
  = ;and the specific type value in 12 bits. I checked
  the assig= nment of Enterprise numbers, and there are
  now approximately= 16K, and also checked the OUI
  assignments and there are app= roximately 51K. Thus,
  20 bits (1M) should be enough!
-------------------------= --------

CAPWAP Packet formats:


   CAPWAP Unpro= tected Data Packet:
   +------------------------------[-------= -]----------+
   | IP  | UDP  | CAPWAP | C= APWAP | CAPWAP | Wireless |
   | Hdr | Hdr  | Pkt    | Frag=    | Data   | Payload  |
   |&nb= sp;    |      | Hdr  = ;  | Ctrl   | Hdr    | Frag &n= bsp;   |
   +------------------------------[--------= ]----------+
          = ;            &n= bsp;            only= in
            = ;            &n= bsp;          first fragment
   CAPWAP DTLS Protected Data Packet:
   +----= ---------------------------------[---------]--------------------+
 =   | IP  | UDP | CAPWAP | DTLS  | CAPWAP | CAPWAP&n= bsp; | Wireless | DTLS    |
   | Hdr | Hdr | Pkt    | Hdr  = | Frag   | Data    | Payload  | Tr= ailer |
   |     |    = | Hdr    |       | Ctrl&= nbsp;  | Hdr     | Frag     |&= nbsp;        |
   +--------= -----------------------------[---------]--------------------+
            = ;            &n= bsp;            = ;     only in
     &nb= sp;            =             &nb= sp;           first = fragment
          &nb= sp;            =  \--integrity checked-----------------/
    &nb= sp;            =             &nb= sp;  \--encrypted----------------------------/


   CAPWAP Unprotected Control Packet:
  = +------------------------------[---------]----------+
   | IP=   | UDP  | CAPWAP | CAPWAP | CAPWAP  | Messag= e  |
   | Hdr | Hdr  | Pkt  &nbs= p; | Frag   | Control | Elements |
   |     |     &= nbsp;| Hdr    | Ctrl   | Hdr   = ;  | Frag     |
   +-----------------= -------------[---------]----------+
      =             &nb= sp;            =     only in
       &nb= sp;            =             &nb= sp;  first fragment

   CAPWAP DTLS Protected Control Packet:
   +---= ---------------------------------[---------]--------------------+
 =   | IP  | UDP | CAPWAP | DTLS | CAPWAP | CAPWAP  |= Message  | DTLS    |
   | Hdr |= Hdr | Pkt    | Hdr  | Frag   | Con= trol | Elements | Trailer |
   |     |     | Hdr&= nbsp;   |      | Ctrl &nb= sp; | Hdr     | Frag     | &nb= sp;       |
   +----------------= --------------------[---------]--------------------+
   &= nbsp;           &nbs= p;            &= nbsp;            onl= y in
           &= nbsp;           &nbs= p;            &= nbsp;    first fragment
            = ;             \= --integrity checked----------------/
      = ;            &n= bsp;            \--e= ncrypted----------------------------/

     UDP: = All CAPWAP packets are encapsulated within UDP.

   &n= bsp; CAPWAP Pkt Header: All CAPWAP protocol packets use a short header
           that speci= fies the version of CAPWAP and the type of the
    &= nbsp;      CAPWAP packet.

   = ;  CAPWAP PDU: CAPWAP consists of both control and data streams.
&n= bsp;          A CAPWAP PDU is = either a CAPWAP control PDU or
           a CAPWAP d= ata PDU.

     CAPWAP Control PDU: A CAPWAP contr= ol PDU encapsulates a
        &n= bsp;  control message, which is a control header and its
 &nbs= p;         message elements.
     CAPWAP Data PDU: A CAPWAP data PDU encapsulates a= data
           message, w= hich is a data header and wireless
      &= nbsp;    payload.

     CAPWAP Fra= gmentation Control Header: Used for fragmentation
   &nbs= p;       of CAPWAP PDUs. A CAPWAP PDU that wi= ll not fit in
           one UDP packet= will be fragmented into multiple
      &n= bsp;    CAPWAP packets.

     CAPW= AP Data Header: This header is used for CAPWAP data PDUs.
  &n= bsp;        If a CAPWAP data PDU is frag= mented, then the CAPWAP
           Data Heade= r is in only the first fragment in the
     &nb= sp;     group of fragments constructing the CAPWAP data= PDU.

     Wireless Payload: The actual payload = from or to wireless
        &nbs= p;  devices. The format may be=20 802.3 Ethernet II, or
        &n= bsp;  native wireless transport specific encoding.

  =    DTLS Header: Protected CAPWAP packets use the DTLS protocol to=
           provide me= ssage integrity and encryption services.

     DTLS Trailer: A field used to provide protecti= on service for
         &nb= sp; security of CAPWAP messages.

     CAPWAP Con= trol Header: The CAPWAP protocol includes a signalling
   = ;        component, known as the CAPWAP = control protocol.  All CAPWAP
           control PD= Us include a Control Header. If a CAPWAP control PDU
   &= nbsp;       is fragmented, then the CAPWAP Co= ntrol Header is in only
        =    the first fragment in the group of fragments constructing
           the CAPWAP con= trol PDU.

     Message Elements: A CAPWAP Contro= l PDU includes zero, one,
       &nbs= p;   or more message elements, which are found immediately
&nb= sp;          following the con= trol header.  These message elements
           are in a t= ype, length, value format.


   CAPWAP Pkt Header:
&n= bsp;   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Version   &nb= sp;           | Type = ; |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Version - the version of the CAPWAP protoc= ol (the first is 1)
        &nbs= p;      DISCUSS: should this be split into major a= nd minor,
          &n= bsp;            = ; and if so, what are the implications of
    &= nbsp;           &nbs= p;       an increment of the major or mi= nor part?

     Type - packet type, values are:
 &= nbsp;           &nbs= p; 1 - CAPWAP Unprotected Data Packet
     &nbs= p;         2 - CAPWAP DTLS Protecte= d Data Packet
         &nbs= p;     3 - CAPWAP Unprotected Control Packet
 &= nbsp;           &nbs= p; 4 - CAPWAP DTLS Protected Control Packet
            = ;  0,5-15 - reserved


   CAPWAP Fragmentation= Control Header:
    0     =             &nb= sp; 1           &nbs= p;       2      = ;             3=
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3= 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+
   |M|Res|     CAPWAP PDU ID =             | &= nbsp; Fragment Offset       |
  = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     M: The More 'M' bit indicates whether there are mo= re fragment
       packets needed to be co= mbined to reassemble a complete
       CAP= WAP PDU.  When this bit is 1, there are more fragment
 &n= bsp;     packets.  When this bit is 0, there = are no more fragments
       and this packet completes the CAPW= AP PDU.

     Res: The bits are reserved, and mus= t be zero.

     CAPWAP PDU ID: A 16-bit field wh= ose value is assigned to each
       CAPWA= P PDU.  The CAPWAP PDU ID space is managed independently
       for every WTP/AC pair, for each en= d (an AC or WTP), and for
       each CAPW= AP stream (data or control).  For example, if AC #1
 &nbs= p;     communicates with WTP #1 and WTP #2, there will = be the
       following independent CAPWAP= PDU IDs:
          WTP #1: ID1= for control going to AC #1
       &n= bsp;          ID2 for dat= a going to AC #1
         &= nbsp;WTP #2: ID3 for control going to AC #1
    &nbs= p;            &= nbsp;ID4 for data going to AC #1
      &nb= sp;   AC #1:  ID5 for control going to WTP #1
            = ;      ID6 for data going to WTP #1
 =             &nb= sp;    ID7 for control going to WTP #2
  &= nbsp;           &nbs= p;   ID8 for data going to WTP #2
    = ;   The value for each CAPWAP PDU ID is incremented with each
       new CAPWAP PDU sent whether or not= the PDU is fragmented.
       The value w= raps to zero after the maximum value has been
    &n= bsp;  used to identify a CAPWAP PDU. When a new session
  = ;     is established, the initial value is a randomly g= enerated
       number.

   &= nbsp; Fragment Offset: A 13 bit field that indicates where in the CAPWAP       PDU will this fragment belong during = re-assembly.  This
       field = should always have a valid value. For the first
       or only packet of a CAPWAP PDU, th= e value must be zero.
       The fragment = offset is measured in units of 8 octets
     &n= bsp; (64 bits).  This provides a maximum size of a CAPWAP
&nbs= p;      PDU to be 16 bits (which is 65536 octets).
       Note the CAPWAP protocol does not = allow for overlapping
       fragments. Fo= r instance, it would be an error if the
     &n= bsp; first fragment was 1000 octets in length, and the
   = ;    second fragment's offset was 800. To be valid (when
       the length of the first fragment i= s 1000, the second
       fragment MUST ha= ve an offset of 1000.
       (DISCUSS: nee= d to have a timer that is associated with
     =   fragmentation to toss all of the fragments if they
       have not been combined in the allo= cated time.)


   CAPWAP Data Header:
  &nb= sp; 0           = ;        1     =             &nb= sp; 2           &nbs= p;       3
    0 1 2 3= 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+
   | RID     | HLEN  &nb= sp; |  WBID   |T|W|M|     = ;     Res       = ;       |
   +-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | =             &nb= sp;   (optional) Radio MAC Address     &= nbsp;           &nbs= p;|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+
   |        &n= bsp;   (optional) Wireless Specific Information  &= nbsp;        |
   +-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     RID: A 5 bit field which contains the Radio ID for= this CAPWAP
       data PDU.  W= TPs with multiple radios but a single MAC Address
   &nbs= p;   range (for BSSIDs) use this field to indicate which radio is=
       associated with the packet.

     HLEN: A 5 bit field specifying the length = of the CAPWAP data
       header header in= 4 octet words (Similar to IP header length).
    &n= bsp;  This length includes the optional headers.

  &n= bsp;  T: The Type 'T' bit indicates the format of the frame being
       transported in the payload. &= nbsp;When this bit is set to one (1),
     &nbs= p; the payload has the native frame format indicated by the
  =      WBID field.  When this bit is zero (0) t= he payload is an
       IEEE=20 802.3 frame.

     W: The 'W' bit is used to spec= ify whether the optional
       "Wire= less Specific Information" field is present in the header.
 &n= bsp;     A value of one (1) is used to represent the fa= ct that the
       field is present.

 &nb= sp;   M: The 'M' bit is used to specify whether the optional
&= nbsp;      "Radio MAC Address" field is = present in the header.
       A value of o= ne (1) is used to represent the fact that the
       field is present.

 &nb= sp;   Res: The bits are reserved and must be zero.

 &= nbsp;   Radio MAC Address: This optional field contains the BSSID=
       of the radio receiving the packet.=   This is used in packets
       sent from the WTP to the AC, when = the native wireless frame
       format is= converted to 802.3 by the WTP.  This field is only
 &nbs= p;     present if the 'M' bit is set.  Given = the HLEN field requires
       the header = size to be a multiple of 4 octets, this field MUST
       be padded with zeroes (0x00) if it= is not 4 octet aligned.

       The fi= eld has the format:

        = 0            &n= bsp;      1      &nb= sp;            2
=         0 1 2 3 4 5 6 7 8 9 0 1 2 3= 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-
       | &= nbsp;  Length     |    &n= bsp;            = ; MAC Address         &nb= sp; ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

       Length: The number of octets in the MA= C Address field.  The
      &nbs= p;    length field is present since new IEEE technologies           (e.g., 802.16= ) are now using 64 bits (8 octet) MAC
     &nbs= p;     addresses.

       MAC Address: The BSSID of the = receiving radio.

     Wireless Specific Informat= ion: This optional field contains
       t= echnology specific information that may be used to carry per
  = ;     packet wireless information.  This fiel= d is only present if
       the 'W' bit is set.  Giv= en the HLEN field assumes 4 octet
       a= lignment, this field MUST be padded with zeroes (0x00) if
  &n= bsp;    it is not 4 octet aligned.

   =     The field has the format:

        0    &n= bsp;            = ;  1           =         2
    &nb= sp;   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
       |&n= bsp; Wireless ID  |    Length  = ;   |          =    Data       ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-

       = ;  Wireless ID: The wireless binding identifier.  The follow= ing
           &n= bsp;   values are defined:
      = ;             1= - : IEEE 802.11

         Length: The length= of the data field

         = Data: Wireless specific information, whose details are
   = ;            defined= in the technology specific bindings sections.

   &nb= sp;           For=20 802.11, when sent from WTP to AC, the data
     = ;          has the following f= ormat:

          &= nbsp;    IEEE 802.11 Frame Info:
    =             0&n= bsp;            = ;      1
      &n= bsp;         0 1 2 3 4 5 6 7 8= 9 0 1 2 3 4 5
            = ;   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    =            |  &= nbsp;  RSSI      |   &nbs= p; SNR       |
    &nb= sp;          +-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
         &= nbsp;     |       &n= bsp;   Data Rate        &= nbsp;  |
         &nbs= p;     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           &= nbsp;     RSSI: RSSI is a signed, 8-bit value. &nb= sp;It is the
          = ;             r= eceived signal strength indication, in dBm.

    =              SN= R: SNR is a signed, 8-bit value.  It is the signal
            &nb= sp;          to noise ratio of= the received IEEE 802.11 frame,
      &nb= sp;            =     in dB.

       =           Data Rate: The data = rate field is a 16-bit unsigned
      &nbs= p;            &= nbsp;   integer value.  The contents of the field is se= t
            = ;           to 1/10th of = the data rate of the packet received
      = ;            &n= bsp;    by the WTP.  For instance, a packet receiv= ed at
           =             5.5Mbps = would be set to 55, while 11Mbps would
            = ;           be set to 110= .

           =     For data sent from the AC to the WTP, the data
 =             &nb= sp; has the following format:

      &n= bsp;        Destination WLANs:
 =             &nb= sp;  0          = ;         1
            = ;    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  &nb= sp;            +-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+
       &= nbsp;       |     &n= bsp;        WLAN   &= nbsp;         |
  &nbs= p;            +-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+

      &nbs= p;          WLAN: This bit vec= tor indicates the WLAN ID(s) which
            = ;           the WTP will = transmit the associated frame on.
      &n= bsp;            = ;    For instance, if a multicast packet is to be
 &= nbsp;           &nbs= p;         transmitted on WLANs 1 a= nd 3, bits 1 and 3 of
        &n= bsp;            = ;  this field would be set to '1'.  Note this
            = ;           field is to b= e set to zero for unicast
       &nbs= p;            &= nbsp;  packets and is unused if the WTP is not
   &n= bsp;            = ;       providing encryption services.
Wireless Payload:
   The format of the wireless payload depen= ds on the encapsulation
   mode. There are two formats defined, which are:

&nb= sp;    802.3 Frame - this is the standard IEEE 802.3 Etherne= t II frame
           = (DISCUSS: this needs to be confirmed)
     802.11 na= tive frame - DISCUSS: finish this


CAPWAP Control Header:

    0 &n= bsp;            = ;     1        =            2  &= nbsp;           &nbs= p;    3
    0 1 2 3 4 5 6 7 8 9 0 1 2= 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         &nb= sp;            = Message Type          &n= bsp;            = ;     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Msg ID=        | Retry#|F| Res |   &nb= sp; Length of Msg Elements    |
   +-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Message Type: This field identifies the fu= nction of the CAPWAP
        &nb= sp;  control message.  The Message Type field is comprised o= f
           an IANA E= nterprise Number and an enterprise specific message
           type numbe= r.  The first 20 bits is the enterprise number
  &nb= sp;        in network byte order, with z= ero being used for CAPWAP
       &nbs= p;   generic message types and the IEEE 802.11 IANA assigned
&= nbsp;          enterprise numb= er 13277 being used for IEEE=20 802.11 technology
         =   specific message types.  The last 12 bits is the enterpris= e
           specific = message type number, which has a range from 0 to
    = ;       4095.

    =        The value of the message type field ca= n be expressed as:

           Messag= e type value =3D IANA Enterprise Number * 4096 +
    = ;            &n= bsp;            = ;    enterprise specific message type number

 &n= bsp;   Msg ID: The message ID field is used by the CAPWAP control=
           application to= match responses (or acknowledgements) with
    &nbs= p;      requests (or reports). The value must be m= onotonically
          = ; incremented for each unique request (or report). After
  &nb= sp;        the maximum value is reached,= the value wraps back to zero.
           The paired= response (or acknowledgement) returns the value
    = ;       from the request (or report). Note th= e size is 8-bits, and
        &n= bsp;  thus a maximum of 255 CAPWAP operations can be currently
           outstanding. T= he message ID space is managed independently
    &nb= sp;      for every WTP/AC pair, and for each end (= an AC or WTP).
         &nb= sp; For example, if AC#1 communicates with WTP #1 and WTP #2,
 &nbs= p;         there will be the follow= ing independent Message IDs:
            = ;   WTP #1: MSG ID1 for requests (and reports) going to AC #1
=             &nb= sp;  WTP #2: MSG ID2 for requests (and reports) going to AC #1
&nbs= p;            &= nbsp; AC #1: MSG ID3 for requests going to WTP #1
   &nbs= p;            &= nbsp;     MSG ID4 for requests going to WTP #2
           When a new= session is established, the initial value is
    &n= bsp;      a randomly generated number.

&nbs= p;    Retry#: The retry number field starts at zero and is i= ncremented
           = for each message with the same value of message ID.
           After the = maximum value is reached, the value wraps back
    &= nbsp;      to zero.  The paired response= (or acknowledgement) returns
       =     the value from the request (or report). Note the size           is 4-bits, an= d thus a maximum of 16 retries can be
           be current= ly outstanding.
         &n= bsp; This field is used to match a request (or report)
   = ;        with its paired response (or ac= knowledgement) so that
        &= nbsp;  accurate round trip operation time can be determined.
           (DISCUSS: = maybe put back here the text about how this
    &nbs= p;      works. The examples of operation retries s= hould help.)

     F: The 'F' bit field indicates= if the message is the first
       &= nbsp;   message in a message pair. A value of "1" means
           first, and= "0" means second in the pair. There are
   &nb= sp;       two types of message pairs, which a= re:
           &n= bsp;  1) a request and response
     =          2) a report and ackno= wledgement.
           Thus, the = first is a request or report message
      = ;     (with the 'F' field set to "1"), and th= e second is
          = a response or acknowledgement (with the 'F' field
   &nb= sp;       set to "0"). Note, both a= request and response
           (or report= and acknowledgement) of a operation
      = ;     type use the same value for message type. The
=            'F' bit is use= d to indicate which is which.
       =     This allows new message types to be added
           that can b= e processed without knowing the
      &nbs= p;    meaning of the message type. That is, when
 &n= bsp;         an unknown request mes= sage type is received,
        &= nbsp;  the response is the same message type with
           a message = element indicating that the message
      =      type is not supported.

   &n= bsp; Res: The bits are reserved and must be zero.

   =   Length of Message Elements: This field indicates in octets the
           length of = the message elements field, which contains zero,
    = ;       one, or more message elements. The fi= eld is 16 bits wide,
        &nb= sp;  and thus the maximum size that can be specified 64K.
 &nb= sp;         However, the maximum si= ze of a CAPWAP control PDU is
           64K, and t= hus the max length is 64K minus the size of
    &nbs= p;      the CAPWAP control header, or 64K - 8, or = 65528.

Message Elements:
   The "message elements&= quot; field contains, zero, one, or more message
   element field, which has the following format:

&nbs= p;  Message Element:

      0 = ;            &n= bsp;     1       &nb= sp;           2 &nbs= p;            &= nbsp;    3
      0 1 2 3 4 = 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+
     |    &n= bsp;         Message Element T= ype            =             &nb= sp;    |
     +-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       &nb= sp;    Length       =       |  Value ....
   = ;  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

  &= nbsp;    Message Element Type: This field identifies a messa= ge element
           = of a CAPWAP control message.  The Message Element Type field
           is compris= ed of an IANA Enterprise Number and an enterprise
   &nbs= p;       specific message element type number= .  The first 20 bits
       = ;    is the enterprise number in network byte order, with ze= ro
           being used for= CAPWAP generic message types and the
     &nbs= p;     IEEE 802.11 IANA assigned enterprise number 1327= 7 being
           use= d for IEEE 802.11 technology specific message element
   =         types.  The 12 bits is= the enterprise specific message
           element ty= pe number, which has a range from 0 to 4095.

    = ;       The value of the message element type= field can be expressed
        =    as:

        &nb= sp;  Message element type value =3D IANA Enterprise Number * 4096 +
            = ;             e= nterprise specific message element type number


-----------------= -------------------------------
Use of the CAPWAP Fragmentation Control = Header

Example of a Nonfragmented CAPWAP PDU

For both data and control CAPWAP packets, CAPWAP Fragment ControlHeader has the following content:

   first, compute next= CAPWAP_PDU_ID, which is
       CAPWAP_PDU= _ID =3D (CAPWAP_PDU_ID + 1) & 0x0ffff;
    0       &nbs= p;           1  = ;            &n= bsp;    2        &nb= sp;          3
  =   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+
   |0|0 0|       CAPWAP_= PDU_ID           | &= nbsp;     0       &n= bsp;         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+


Example of Fragmented CAPWAP PDUs

1) Here is an e= xample of a CAPWAP data PDU where the
    length of = the CAPWAP data header and wireless payload
    will cause a single CAPWAP data packet to be gr= eater than
    the max IP packet size for the path. = Assume that
    the size of the CAPWAP data PDU is 1= 560 octets, which
    needs to be fragmented into a = fragments of 1400 and
    160 octets.

    The = first fragment would have the following CAPWAP
    f= ragment control header, and be followed by a
    CAP= WAP data header and part of the wireless payload
    = ;and would look like:

    first, compute next CAPWAP_PDU_ID, which is=
       CAPWAP_PDU_ID =3D (CAPWAP_PDU_ID += 1) & 0x0ffff;

    0    =             &nb= sp;  1          &nbs= p;        2     = ;            &n= bsp; 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0= 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+
   |1|0 0|       CAPWAP_= PDU_ID           | &= nbsp;     0       &n= bsp;         |
   +-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The second fragment would have the following CAPWAP
 &= nbsp; fragment control header, and be followed by the remaining
 &n= bsp; portion of the wireless payload and would look like:

 &nbs= p;  (Use the same value of CAPWAP_PDU_ID)
    0       &nbs= p;           1  = ;            &n= bsp;    2        &nb= sp;          3
  =   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+
   |0|0 0|      CAPWAP_P= DU_ID           &nbs= p;| (1400/8) =3D 175         &= nbsp;|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+

2) Here is an example of a CAPWAP control PDU where the
&= nbsp;   length of the CAPWAP control header and message elem= ents
    will cause a single CAPWAP control packet t= o be greater
    than the max IP packet size for the path. Assum= e that
    the size of the CAPWAP control PDU is 156= 0 octets, which
    needs to be fragmented into a fr= agments of 1400 and
    160 octets.

 &nb= sp;  The first fragment would have the following CAPWAP
    fragment control header, and be followed by a    CAPWAP control header and part of the message ele= ments
    and would look like:

  &n= bsp; first, compute next CAPWAP_PDU_ID, which is
   =     CAPWAP_PDU_ID =3D (CAPWAP_PDU_ID + 1) & 0x0ffff;

    0       =             1 &= nbsp;           &nbs= p;     2        = ;           3
 &n= bsp;  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9= 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
   |1|0 0|       CAP= WAP_PDU_ID           |&nb= sp;      0      &nbs= p;          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+

   The second fragment would have the following CA= PWAP
   fragment control header, and be followed by the remain= ing
   portion of the wireless payload and would look like:

    (Use the same value of CAPWAP_PDU_ID)
&n= bsp;   0        &nbs= p;          1   = ;            &n= bsp;   2         &nb= sp;         3
   =  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
&n= bsp;  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
   |0|0 0|      CAPWAP_PDU_ID&n= bsp;           | (14= 00/8) =3D 175          |<= br>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+


------------------------------------------------
Use o= f the "Msg ID" and "Retry#" Fields for Retries

Only the control path has message retries. Since
control operati= ons are not idempotent (that is,
are not guaranteed to return the same r= esult
when redone), operation results (the response
or acknowledgemen= t) to a request or report
must be cached and returned if a repeat of
the operation occurs. A r= epeat occurs when
1) the request (or report) is not received
(however= , the receiver does not know that
the operation is being repeated)
2) the response (or acknowledgement) is
not received within the expected= operation
round trip time.
3) the request (or report) is duplicated = by
the network (this only occurs when the
control operation is not pr= otected by DTLS)

Here are timing diagrams for 4 cases:

   Abbreviat= ions:
     P_ID - PDU ID
    = M_ID - MSG ID
     R - Retry number

0) No ti= meout/replay/duplication:
     (P_ID=3D56, M_ID=3D23= , R=3D0)   (M_ID=3D23, R=3D0)
  WTP----------------------->|----------------------->A= C - process
          =             &nb= sp;      |      &nbs= p;            &= nbsp;    |    and cache
 &n= bsp;   (M_ID=3D23, R=3D0)      &nbs= p;   | (P_ID=3D75,M_ID=3D23,R=3D0)  |  &= nbsp; for M_ID=3D23
    <------------------------|<--------------= ----------    and R=3D0
    &nbs= p;            &= nbsp;           |

=    NOTEs: 1) AC and WTP have different spaces for P_ID. It
&nb= sp;            =   is used only for CAPWAP PDU fragmentation reassembly.
          2) The P_ID= is always incremented for each CAPWAP PDU,
    &nbs= p;          even for retries          3) the M_ID f= rom a request (or report) is
       &= nbsp;       echoed in a paired response (or a= cknowledgement)
          4) each ori= ginator of an operation has an independent
     = ;          M_ID number space

1) message never received, so resent:
    = (P_ID=3D56, M_ID=3D23, R=3D0)
  WTP----------------------->= ;|-->X           =          AC
   |         &nb= sp;            =    |
   |timeout      =             |   V (P_ID=3D57, M_ID=3D23, R=3D1) |
retry------------------= ---->|----------------------->AC - process
    = ;            &n= bsp;            |&nb= sp;            =            | &n= bsp;  and cache
     (M_ID=3D23, R=3D1)    &nbs= p;     | (P_ID=3D75,M_ID=3D23, R=3D1) |  = ;  for M_ID=3D23
    <-----------------= -------|<------------------------    and R=3D1

   NOTEs: 1) the M_ID is not incremented on retries
&nbs= p;         2) the R always sta= rts at zero for each M_ID and
            = ;   is incremented on retries


2a) message response (or= acknowledgement) never received,
       s= o message resent:
     (P_ID=3D56, M_ID=3D23, R=3D0)=     (M_ID=3D23, R=3D0)
  WTP--------------= --------->|----------------------->AC - process
   |         &nb= sp;            =    |          &= nbsp;           &nbs= p; |    and cache
   |  &nb= sp;            =           |  (P_ID= =3D75,M_ID=3D23,R=3D0) |    for M_ID=3D23
 &nbs= p; |            = ;         X<--|<-------------= -----------    and R=3D0
   |timeout        &n= bsp;         |
  = V (P_ID=3D57, M_ID=3D23, R=3D1) |  (M_ID=3D23, R=3D1)
retry--= -------------------->|----------------------->AC - find in
 &= nbsp;           &nbs= p;            &= nbsp;  |          &n= bsp;            = ; |    cache for
     (M_ID=3D23, R=3D1)    &nbs= p;     |  (P_ID=3D75,M_ID=3D23,R=3D1) |&= nbsp;   M_ID=3D23,
    <----------= --------------|<------------------------    update R= =3D1

   NOTEs: 1) only the M_ID is search in the cache for= a match
            &nb= sp;  (the R is saved, but not used in search)
   &nb= sp;      2) the R from the request message is= returned
          &n= bsp;    in the response message
    &= nbsp;     3) the R is updated in the cache

= 2b) message response (or acknowledgement) not received within
       the current computed value for rou= nd trip operation
       time, so a messag= e resent. However, original response
      = ; received before response to retry.

     (P_ID= =3D56, M_ID=3D23, R=3D0)    (M_ID=3D23, R=3D0)
  WTP----------------------->|----------------------->A= C - process
   |       &nbs= p;            &= nbsp;    |        &n= bsp;            = ;   |    and cache
   |&nbs= p;            &= nbsp;           | &n= bsp;(P_ID=3D75,M_ID=3D23,R=3D0) |    for M_ID=3D23
   |         &nb= sp;            =    |/------------------------    and R=3D0   |timeout         = ;         ||
   V= (P_ID=3D57, M_ID=3D23, R=3D1) ||  (M_ID=3D23, R=3D1)
retry---= ------------------->|+---------------------->AC - find in
            = ;            &n= bsp;    ||        &n= bsp;            = ;  |    cache for
     (M_I= D=3D23, R=3D0)          |= |            &n= bsp;          |  &nb= sp; M_ID=3D23,
    <------------------------= |/            &= nbsp;          |  &n= bsp; update R=3D1
  update RTOT(drop)       &nbs= p;  |          =             &nb= sp; |
          &= nbsp;           &nbs= p;      |       = ;            &n= bsp;    |
     (M_ID=3D23, R=3D1= )          |  (= P_ID=3D75,M_ID=3D23,R=3D1) |
    <---------------= ---------|<------------------------
  update RTOT(process)

   NOTEs: 1) without = the R field, cannot determine if the
      = ;         first received response w= as from the first
         =       time the request was made, or from a the
=             &nb= sp;  retry. Without knowing which, cannot
            = ;   accurately update the round trip
    &= nbsp;          operational tim= e.
          2) it is = possible to process the first response
     &nb= sp;         and not drop it, but if= so, must remember
         = ;      the time when sent each retry. If max retri= es
            = ;   not too many, then not much of a cost.
   &= nbsp;           a match (= the R is not saved or searched)

3) message request (or report) is du= plicated by the
       network:
 &= nbsp;   (P_ID=3D56, M_ID=3D23, R=3D0)    (M_I= D=3D23, R=3D0)
  WTP----------------------->|----------------------->A= C - process
          =           \  &n= bsp;     |      &nbs= p;            &= nbsp;    |    and cache
 &n= bsp;  (M_ID=3D23, R=3D0)   \    &nb= sp;  |  (P_ID=3D75,M_ID=3D23,R=3D0) |    = ;for M_ID=3D23
   <------------------+------|<------------------------=     and R=3D0
      &n= bsp;            = ;    \     |
    =             &nb= sp;       \    |&nbs= p; (M_ID=3D23, R=3D0)
       &nb= sp;            = Dup \-->|+---------------------->AC - find in
            = ;            &n= bsp;    |        &nb= sp;            =         cache for
   &= nbsp;           &nbs= p;             = |            &n= bsp;            = ;    M_ID=3D23,
       = ;            &n= bsp;            = ;            &n= bsp;            = ;  R is the
         &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            same s= o drop

   NOTEs: 1) the R field in the duplicated message is use= d
           &nbs= p;   by the AC to determine if the request is
  &nbs= p;            a dupl= icate.
          2) if= both a response drop (or delay) and
      = ;         a duplicate occurs the R = may be less
            = ;   than the R in the cache. If so, the
   &nbs= p;           message is a= very delayed duplicate
        =        and can be dropped.


-------= --------------------
Regards,
/david t. perkins




___________________________________________________________= ______
To unsubscribe or modify your subscription options, please visit:=
http://li= sts.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_9281_24383419.1151676114542-- --===============1663900382== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1663900382==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 30 10:39:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwK9E-0007Y5-9j for capwap-archive@lists.ietf.org; Fri, 30 Jun 2006 10:39:08 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwK9C-0002Rt-Qf for capwap-archive@lists.ietf.org; Fri, 30 Jun 2006 10:39:08 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 02EE643011F for ; Fri, 30 Jun 2006 07:39:06 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6F484430018 for ; Fri, 30 Jun 2006 07:05:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3F9FF398028 for ; Fri, 30 Jun 2006 07:05:38 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by zoidberg.tigertech.net (Postfix) with ESMTP id 25929398010 for ; Fri, 30 Jun 2006 07:05:31 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id m51so700690pye for ; Fri, 30 Jun 2006 07:03:58 -0700 (PDT) Received: by 10.35.111.14 with SMTP id o14mr517918pym; Fri, 30 Jun 2006 07:03:58 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Fri, 30 Jun 2006 07:03:58 -0700 (PDT) Message-ID: <26140d940606300703q64dfb8ffg86a7c8037c61d00b@mail.gmail.com> Date: Fri, 30 Jun 2006 10:03:58 -0400 From: "Michael Montemurro" To: "Sachin Dutta" In-Reply-To: <000501c69908$d83974b0$6007120a@china.huawei.com> MIME-Version: 1.0 References: <000501c69908$d83974b0$6007120a@china.huawei.com> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Duplcate IPv6 Address message Element X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1252157316==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc --===============1252157316== Content-Type: multipart/alternative; boundary="----=_Part_9325_25581418.1151676238238" ------=_Part_9325_25581418.1151676238238 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sachin, I created issue 147 to track this. Mike On 6/26/06, Sachin Dutta wrote: > > Hi All, > > > > As DAD ( Duplicate address detection ) is the integral part of IPv6 > protocol so no other host/WTP with same IPv6 address can join the network, > therefore *section 4.4.20 *for duplicate IPv6 address message element is *NOT > required in CAPWAP* and can be deleted ? > > * * > > Regards > > Sachin > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_9325_25581418.1151676238238 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Sachin,
 
I created issue 147 to track this.
 
Mike

 
On 6/26/06, Sachin Dutta <sachind@huawei.com> wrote:

Hi All,

 

As DAD ( Duplicate address detection ) is the integral part of IPv6 protocol so no other host/WTP with same IPv6 address can join the network, therefore section 4.4.20 for duplicate IPv6 address message element is NOT required in CAPWAP and can be deleted ?

 

Regards

Sachin

 


_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


------=_Part_9325_25581418.1151676238238-- --===============1252157316== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1252157316==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 30 10:39:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwK9r-0007b6-6Z for capwap-archive@lists.ietf.org; Fri, 30 Jun 2006 10:39:47 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwK9p-0002TB-MG for capwap-archive@lists.ietf.org; Fri, 30 Jun 2006 10:39:47 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4CFA6430125 for ; Fri, 30 Jun 2006 07:39:45 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 81F4C430081 for ; Fri, 30 Jun 2006 07:05:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 56C0B1448015 for ; Fri, 30 Jun 2006 07:05:38 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by hermes.tigertech.net (Postfix) with ESMTP id A1135144800D for ; Fri, 30 Jun 2006 07:05:33 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id m51so701288pye for ; Fri, 30 Jun 2006 07:05:32 -0700 (PDT) Received: by 10.35.90.20 with SMTP id s20mr523404pyl; Fri, 30 Jun 2006 07:05:32 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Fri, 30 Jun 2006 07:05:32 -0700 (PDT) Message-ID: <26140d940606300705x54c3a048qa5604f34f3d4b3a2@mail.gmail.com> Date: Fri, 30 Jun 2006 10:05:32 -0400 From: "Michael Montemurro" To: "Sachin Dutta" In-Reply-To: <000001c69908$cca3c1f0$6007120a@china.huawei.com> MIME-Version: 1.0 References: <000001c69908$cca3c1f0$6007120a@china.huawei.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Binding element for scanning report ? X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0188658639==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e --===============0188658639== Content-Type: multipart/alternative; boundary="----=_Part_9357_30096880.1151676332524" ------=_Part_9357_30096880.1151676332524 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sachin, I created issue 148 to track this request. Cheers, Mike On 6/26/06, Sachin Dutta wrote: > > Hi All, > > > > As scanning is part of MAC protocol should there be a TLV to send that > report from WTP to AC? Because for RF solutions WTP need to perform scanning > and analyze that data. Currently for these solutions vendors have > proprietary algorithms. Should the data collection part be standardized? > (The data interpretation can remain vendor specific) > > > > This will help in achieving greater interoperability, as AC can collect > data and statistics from different vendor's WTPs but the algorithms and > solution to analyze them can still remain proprietary > > > > In this regard should CAPWAP provide the binding for sending scanning > report/statistics from WTP to AC? > > > > Regards, > > Sachin > > > > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_9357_30096880.1151676332524 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Sachin,
 
I created issue 148 to track this request.
 
Cheers,
 
Mike

 
On 6/26/06, Sachin Dutta <sachind@huawei.com> wrote:

Hi All,

 

As scanning is part of MAC protocol should there be a TLV to send that report from WTP to AC? Because for RF solutions WTP need to perform scanning and analyze that data. Currently for these solutions vendors have proprietary algorithms. Should the data collection part be standardized? (The data interpretation can remain vendor specific)

 

This will help in achieving greater interoperability, as AC can collect data and statistics from different vendor's WTPs but the algorithms and solution to analyze them can still remain proprietary

 

In this regard should CAPWAP provide the binding for sending scanning report/statistics from WTP to AC?

 

Regards,

Sachin

 

 

 


_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


------=_Part_9357_30096880.1151676332524-- --===============0188658639== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0188658639==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 30 10:40:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwKAS-0007ey-KB for capwap-archive@lists.ietf.org; Fri, 30 Jun 2006 10:40:24 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwKAR-0002Ur-3r for capwap-archive@lists.ietf.org; Fri, 30 Jun 2006 10:40:24 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B846A430156 for ; Fri, 30 Jun 2006 07:40:22 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3159D430018 for ; Fri, 30 Jun 2006 07:07:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 13D2C1448004 for ; Fri, 30 Jun 2006 07:07:21 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by hermes.tigertech.net (Postfix) with ESMTP id A1AC4144801A for ; Fri, 30 Jun 2006 07:07:18 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id m51so702012pye for ; Fri, 30 Jun 2006 07:07:17 -0700 (PDT) Received: by 10.35.9.15 with SMTP id m15mr521535pyi; Fri, 30 Jun 2006 07:07:17 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Fri, 30 Jun 2006 07:07:17 -0700 (PDT) Message-ID: <26140d940606300707i7fd9773cy3ecf8fb3427d1fc@mail.gmail.com> Date: Fri, 30 Jun 2006 10:07:17 -0400 From: "Michael Montemurro" To: "Sachin Dutta" In-Reply-To: <000a01c69908$e7fdb5f0$6007120a@china.huawei.com> MIME-Version: 1.0 References: <000a01c69908$e7fdb5f0$6007120a@china.huawei.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] IPv6 Multicast address for Discovery phase X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0623097048==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e --===============0623097048== Content-Type: multipart/alternative; boundary="----=_Part_9417_6358034.1151676437572" ------=_Part_9417_6358034.1151676437572 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sachin, I created issue 149 to track this bug. Cheers, Mike On 6/26/06, Sachin Dutta wrote: > > Hi All, > > > > As IPv6 protocol does not have broadcast address so can the CAPWAP > protocol be more specific for the multicast address to be used in the > discovery phase > > > > 1 Have one address assigned for AC "All ACs multicast address ", this has > advantage of limiting the traffic and also it is extendable for new solution > like some communication between AC etc > > > > 2 Use all node multicast address. > > > > Please comment? > > > > Regards, > > Sachin > > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_9417_6358034.1151676437572 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Sachin,
 
I created issue 149 to track this bug.
 
Cheers,
 
Mike

 
On 6/26/06, Sachin Dutta <sachind@huawei.com> wrote:

Hi All,

 

As IPv6 protocol does not have broadcast address so can the CAPWAP protocol be more specific for the multicast address to be used in the discovery phase

 

1 Have one address assigned for AC "All ACs multicast address ", this has advantage of limiting the traffic and also it is extendable for new solution like some communication between AC etc

 

2 Use all node multicast address.

 

Please comment?

 

Regards,

Sachin

 

 


_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


------=_Part_9417_6358034.1151676437572-- --===============0623097048== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0623097048==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 30 10:41:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwKBD-0007ff-G8 for capwap-archive@lists.ietf.org; Fri, 30 Jun 2006 10:41:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwKBB-0002Yd-W8 for capwap-archive@lists.ietf.org; Fri, 30 Jun 2006 10:41:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9C3914300E1 for ; Fri, 30 Jun 2006 07:41:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8DB684300A9 for ; Fri, 30 Jun 2006 07:12:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 76723144800B for ; Fri, 30 Jun 2006 07:12:32 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by hermes.tigertech.net (Postfix) with ESMTP id 69AB01448004 for ; Fri, 30 Jun 2006 07:12:29 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id m51so704141pye for ; Fri, 30 Jun 2006 07:12:28 -0700 (PDT) Received: by 10.35.110.13 with SMTP id n13mr524793pym; Fri, 30 Jun 2006 07:12:28 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Fri, 30 Jun 2006 07:12:28 -0700 (PDT) Message-ID: <26140d940606300712ne310cdp217c0f5f726b8036@mail.gmail.com> Date: Fri, 30 Jun 2006 10:12:28 -0400 From: "Michael Montemurro" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A202182F6F@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A202182F6F@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue with state machine X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1146467274==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be --===============1146467274== Content-Type: multipart/alternative; boundary="----=_Part_9570_1834398.1151676748435" ------=_Part_9570_1834398.1151676748435 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Pat, I re-openned issue 85 to deal with this issue. Cheers, Mike On 6/27/06, Pat Calhoun (pacalhou) wrote: > > I just noticed that the latest specification's state machine requires > that in order to perform a firmware download, the state must transition from > the join to configure to image data. This is a departure from the original > protocol, and I believe introduces some challenges. One of the benefits of > bypassing the configure state is that it maximizes interoperability across > version numbers. If we require the configure state to be run, then we need > to ensure that the configure message does not introduce any new message > elements that can create a backward compatiblity issue. However, the way the > protocol used to be only required that the Join state have to deal with > backward compatibility. > > I'd like to see this changed back to the old way. Sorry I missed this in > my reviews. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_9570_1834398.1151676748435 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Pat,
 
I re-openned issue 85 to deal with this issue.
 
Cheers,
 
Mike

 
On 6/27/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
I just noticed that the latest specification's state machine requires that in order to perform a firmware download, the state must transition from the join to configure to image data. This is a departure from the original protocol, and I believe introduces some challenges. One of the benefits of bypassing the configure state is that it maximizes interoperability across version numbers. If we require the configure state to be run, then we need to ensure that the configure message does not introduce any new message elements that can create a backward compatiblity issue. However, the way the protocol used to be only required that the Join state have to deal with backward compatibility.
 
I'd like to see this changed back to the old way. Sorry I missed this in my reviews.
 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


------=_Part_9570_1834398.1151676748435-- --===============1146467274== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1146467274==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 30 11:10:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwKdK-0004Fs-FF for capwap-archive@lists.ietf.org; Fri, 30 Jun 2006 11:10:14 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwKdH-0004yK-G2 for capwap-archive@lists.ietf.org; Fri, 30 Jun 2006 11:10:14 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DC35743011B for ; Fri, 30 Jun 2006 08:10:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D046F430018 for ; Fri, 30 Jun 2006 08:09:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B8EEE1448007 for ; Fri, 30 Jun 2006 08:09:05 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by hermes.tigertech.net (Postfix) with ESMTP id 29978144801C for ; Fri, 30 Jun 2006 08:08:59 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id t32so696060pyc for ; Fri, 30 Jun 2006 08:08:59 -0700 (PDT) Received: by 10.35.60.16 with SMTP id n16mr584396pyk; Fri, 30 Jun 2006 08:08:59 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Fri, 30 Jun 2006 08:08:59 -0700 (PDT) Message-ID: <26140d940606300808p1d3597cfjbf6b910dd3a4b287@mail.gmail.com> Date: Fri, 30 Jun 2006 11:08:59 -0400 From: "Michael Montemurro" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A202182F70@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A202182F70@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.8 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_10_20, HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] A commentary on CAPWAP-01 operations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1687181172==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.4 (/) X-Scan-Signature: 9ba883ba659fcd62a05a0ed0aea6f612 --===============1687181172== Content-Type: multipart/alternative; boundary="----=_Part_11227_19898693.1151680139014" ------=_Part_11227_19898693.1151680139014 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline David, Pat, I created issues 150-198 to deal with the points in David's email. Happy hunting! Mike On 6/27/06, Pat Calhoun (pacalhou) wrote: > > Going through David's lengthy document, he has raised an interesting > number of points that I believe require issues to be created. At one > point I'm paraphrasing Dave's comments in order to be brief, and > introducing my own numbering scheme. > > 1) Can message elements be in any order? (I believe they should be) > > Yes, and I suspect we need to include text to make it more > obvious. > > > 2) Are all specified message elements required? (The obvious answer is > "yes", but this document doesn't discuss versioning. For example, what > if in a new version of CAPWAP an additional message element was to be > added. Would a new message type be created and the additional message > element added to it, or the existing type reused?) > > This is a great question, and one that does need to be addressed > in the spec. In the Diameter protocol we dealt with this issue by > including a "Mandatory to implement" bit. If any AVP was received, whose > bit was set, yet was not recognized, then the request had to be > rejected. > > We could consider something similar here, but I believe with the > firmware download component of the protocol it may be less of an issue - > although not guaranteed. I would hope (and expect) that as the CAPWAP > protocol extends, the AC would push new firmware to the WTP. This does > require that the initial part of the state machine be fairly static, and > this could be an area where the "Mandatory to implement" bit could be > useful as it would allow the AC to fall back to older protocol behavior. > > 3) CAPWAP-01 doesn't do a good job of indicating which message elements > can be repeated. > > Another good point. When we list the message elements, we should > note whether the frequently is 0-1 (meaning absent or once), 1 (only > once) or 0+ (meaning any number of them could be present. > > > 4) Can "additional" message elements be added to a message? (I believe > so for reporting capabilities, statistics, and events. For > configuration, there is nothing in the protocol that says what happens > when one end gets an configuration element it doesn't know about. > Should it be ignored, and the other elements processed, or should the > complete operation failed?) > > The "Mandatory to implement" bit above could address this issue. > If an unrecognized message element is found to have the bit set, then > the whole message needs to be rejected. If the bit is not set, the > message element may be safely ignored. > > > 5) The config has a concept of "default value" for each configuration > attribute. However, the default values are not clearly specified. This > needs to be resolved to be able to support "default values". > > Another good point raised by David. > > > 6) the documentation of which "binding specific" message elements are to > be included with CAPWAP messages is not consistent, and is difficult to > follow. > > Has this been addressed in the latest (-02) document? > > > 7) There are some message elements that cause "actions". This approach > to protocol design is problematic and should be eliminated. > > Could you be more specific as well as provide guidance on what you > would like to see? > > > 8) The message types are inconsistently named, and do not follow the > conventions of well designed protocols. Can the operations be named > consistently with the following terminology: > 1) request/response (used to get/set/perform action) > 2) report/ack (use to tell the other side something) > > Could you provide your thoughts on which messages fall within > which one of your categories? > > > 9) Many of the configuration items, and status items are not listed in > one section with definitions. (Well make it two sections - one for > CAPWAP and the other which is "binding" specific.) For example, not all > of the time period lengths are identified and specified in section 4.5. > > Unfortunately, the document has gone back and forth a few times > and before we opt to change the structure of the document, I'd like to > ensure that we have broad agreement on what we want - with the > understanding that we will never make everyone happy. > > > 10) each operation should have listed in which states it can be sent and > received > > I do not understand your comment. > > > 11) All strings, such as WTP location, should be changed from US-ASCII > encoding to UTF-8 encoding. > > Agreed. > > 12) The term "mobile" is not really accurate when describing wireless > interfaces, since wireless does not imply mobile. Can we just use > the techie term "STA" instead. > > I agree we should use the term Station, or STA for short. > > > 13) The WTP Descriptor message element contains too much information, > lacks clarity on the WTP encryption field and includes version numbers, > which should be in string form. > > To the first point, I disagree. I think there is value in knowing > everything about the WTP. The AC vendors can expose whatever information > they want, but I don't believe anything is unnecessary. > > To the second point, this is one of those areas where the concept > of the technology binding creates complexity. Given that we cannot > simply discuss 802.11i at this point, the only thing we can do is punt > to another section in the technology binding section. That said, I agree > with Dave that the 802.11 binding section is too light in this area. > However, I would much prefer that instead of trying to address this > specific issue, we discuss whether we should even be supporting the mode > of operation where 802.11i is performed in the AC - especially with the > introduction of DTLS to secure the data plane. Right now, it just feels > like we have too many options and I am worried that interoperability > will be severely impacted (not to mention protocol complexity). > > To the last point, I have no issues with including text stating > that the version numbers should be in string form. > > > 14) The WTP Descriptor information is not required at Join time. > > Well, as far as I can tell, I think there's value in knowing > whether the WTP can even be supported by the AC. So the more info is > provided by the WTP, the better the AC can determine whether it should > just ignore the WTP or not. This could be done because it knows that the > firmware running on the WTP is not compatible, and it has no new > firmware to download. > > > 15) Are the values in the WTP Frame Encryption a capabilities bit, or an > enum? > > Looks like an enum to me. Not sure what Dave would prefer the text > to read. There are various other similar comments throughout, which I > will not repeat here. > > > 16) The Discovery Response is broken. The AC SHOULD NOT be providing any > info to a WTP (or something that claims to be a WTP). Also, the AC > should tell the WTP what to do next, with choices: 1) Ok to try to join, > 2) don't try to join, 3) try discover on a list of > returned ACs) > > I don't believe there is an issue with sending the AC's > information to the WTP, but would solicit input from the list. That > said, some of the information in the AC Descriptor is required, such as > the current load on the AC. No point is trying to join if he AC > indicates it's already at max capacity. > I believe if the AC does not return the response, then it implies > (2). Otherwise, it is (1). (3) is handled during the join or configure > process, which I believe is right. > > > 17) Is AC Name text? > > Yes, and same with WTP Name. > > > 18) Primary Discovery are not required. > > Disagree. Required for failover. > > > 19) The text does not make it clear that the contents of the WTP > Location is informative only, and as Dave calls it, a "scratchpad". > > Well, to be honest, I thought the example "next to the fridge" > made it clear that the information did not derive from any scientific > formula. The description also states this is a user-defined. I believe > this should be good enough. > > > 20) Session is not required > > I believe you may be correct that with the transition to DTLS, > this is no longer required. > > > 21) need to send "common name" as found in the WTP CERT so that the AC > can verify > > The protocol currently relies on the MAC address being the key > that binds the certificate to the WTP. I don't see a need to change > this. > > > 22) Result code in Join Response is not sufficient, for instance WTP HW > not supported. > > Well, the protocol does not require this because the Discovery > Response would never be sent (as the protocol stands today). > > > 23) AC IPv4/IPv6 Addr discusses clustering, which is unnecessary. > > Agreed. > > > 24) Change Echo to Keepalive or heartbeat. > > I call it potato.... > > > 25) What if all of the message elements do not fit within a single > CAPWAP control frame. > > We should address this. > > > 26) AC Name with Index is all messed up... > > Not really. You simply include more than one, and the index field > is clearly the priority. Don't understand the Multi-AC comment. No > inter-AC protocol implied here. > > > 27) WTP Board Data belongs in the Join, not configure. > > Agreed, but wonder even more why we are duplicating this > information across both the WTP Descriptor and the WTP Board Data > message elements. > > > 28) The WTP Static IPv4 Address should not have the Static bit, but > instead state that 0.0.0.0 means a static address is not to be used. > > I don't have an issue with this request, but in the end we have > the same function. The reason why I state this is that we can refine > this protocol until the cows come home, and at one point we need to draw > a line in the sand. > > > 29) WTP Reboot Statistics belongs in the Join, and the reasons listed > are not clear enough. > > Doesn't really matter whether this is included in the > configuration or the join, but if the WG agrees to move it. We can > clarify some of the reasons, as long as it provides value. > > > 30) The IEEE 802.11 WTP Radio Configuration message element's BSSID > field should be an array. > > Disagree. > > > 30) The IEEE 802.11 WTP Radio Configuration message element's Country > Code is not clear enough. > > The text points to the actual MIB element in the 802.11-1999 > standard, which very clearly defines the contents of the field. I don't > think there's value in replicating the format of this field in the > CAPWAP standard. > > > 31) There seems like an awful lot of additional configuration message > elements that need to be specified here! > > Having built a protocol based on this, it's not clear to me what's > missing. I think it would be useful if you provided concrete details on > what's missing. > > > 32) Configuration Status is just plain broken because any configuration > change operation may fail and there is no response to the > configuration changes specified in this command. > > There certainly is - I guess I don't understand the concern. > > > 33) Use of Change State Event should instead be Radio Admin State. > > Perhaps the two are not described properly. The first is used by > the WTP to inform the AC that something has occurred with a radio. The > second is used by the AC to enable/disable a radio. > > > 34) Report Timer needs to be in section 4.5 or 11 > > ok > > > 35) Should Idle Timeout be per radio, or per WTP, and should the value > be defined in section 4.5 or 11. > > Per WTP, and yes. I believe it is fine as it is. > > > 36) WTP Fallback isn't well defined, and should be removed. > > Disagree. I believe it is necessary to create enough resiliency in > the protocol/service. > > > 37) How are the "Rate Set" and "Supported Rates" encoded. > > This was fixed in the -02 > > > 38) AC Timestamp doesn't belong in the configuration, but instead in the > join. > > Not sure this really matters.... > > > 39) Add MAC ACL Entry - this is so strange and is being managed like no > other configuration data. > > I do not understand the comment > > > 40) Decryption Error Report Period is not defined in section 4.5 or 11 > > ok, and note that the information has been moved to the IEEE > 802.11 RSNA Error Report From Mobile > > > 41) Configuration Update Response. today, there are primarily two types > of configuration models. The first is when config is changed, it is only > changed in the volatile copy (the memory or running). An explicit > command is needed to save the config to nonvolatile storage. The second > model has config both running (volatile) and saved (nonvolatile) config > changed when a config change is made. And there might be a special > command to have a config change apply to only one. In this case, there > is no need for a "save config to nonvolatile" command. It is not clear > what is suppose to be supported here in CAPWAP, and how does CAPWAP > support devices with no or very limited nonvolatile storage for config! > > CAPWAP does not support WTPs with no nonvolatile storage. The > protocol has the AC push configs to the WTP, which saves them at the > time they are received. I do not believe anything else is required. > > > 42) Configuration Update Response includes the Result Code message > element, which includes values that do not appear to be relevant for > this message, and there are plenty of other failure cases > > ok, but note that we are sharing a common message element. Any > suggestions on how to address your issue? > > > 43) Change State Event Report. This seems a little silly to be sent in > the "configure" state. It seems only appropriate for the "run" state. > Some might argue that even in the "run" state it shouldn't be sent after > a "config update" request that changes the operational state. However, > in the "run" state, it may take a while to have the operational state > change to follow the admin state. Thus, I think it is OK in the "run" > state after config changes." > > I believe this was addressed in -02. > > > 44) Clear Config Request. this operation has several problems, which > include: > 1) currently, the CAPWAP-01 spec says that this can only be done in > the "run" state. This is silly. It should also be possible in the > "configure" state. > I wonder why the AC would even consider clearing the WTP's state > before it even knows how it is configured. > > 2) the value of "manufacturing defaults" is not defined, and a poor > term to use, since it implies that that each manufacturer can have > different values. If so, then the AC will have no knowledge of the > config on the WTP! The problem of "default config values" has already be > mentioned above. After each config attribute has been defined with a > default value, then the proper term would be "CAPWAP config defaults". > Yes, you've raised this point already, and I agree that it does > need to be addressed. > > 3) This operation is not defined to have a response. This is broken, > since any config change can fail. Also, it is not defined what happens > next. Does this cause the WTP to reboot an start a "clean discovery"? > This was addressed in -02 > > > 45) Image Data Request. Yes, there are actually three different "Image > Data Request" messages. Which one is determined by which of the > three message elements is contained. This is completely silly! There > should be three separate operations! Additionally, how does the WTP know > which image to get? The AC should be making that decision. > > I believe the WTP is the only device that knows what it's filename > should be. Why would an AC vendor know about file naming conventions > used by the WTP vendors? I believe your other issues are discussed in > the next items. > > > 46) Image Data Response. this is silly. This operation can fail! There > needs to be message element that indicates the result. > > How so? This is only used to send firmware to the WTP. Not clear > what could fail... Reading the image from flash? > > > 47) Image Data Request. when starting over again at the WTP start state, > the WTP shouldn't use the "normal" discovery process, but instead "fast > track" a connection back to the AC that just downloaded the image. With > a little more work, we could probably figure out a way to reuse > the old DTLS session. > > To what gain? What is so expensive about the discovery, and what > happened if the AC was not longer reachable? > > > 48) opcode - if this is here, might as well also have a value that > indicates last block of the image file, instead of looking at the block > size. > > But we're just changing for the sake of changing - the protocol > works as-is. > > > 49) since this operation does not have the block number as a parameter, > the WTP must determine the block number via the CAPWAP message header > sequence number. NOTE: DTLS does not provide in-order delivery of > packets. Also, this requires the WTP to remember state. This message > element should be re-engineered to have the following subfields: > [edited] > > The control header includes a sequence number, and while we can > change the current protocol to match your recommendations, the protocol > does work. If it ain't broken... > > > 50) Image Data Response. this is silly. This operation can fail! For > example, the WTP can run out of space to store the block, or > there could be a failure in writing the block to storage. (Or as "Image > Data Request"(9.1a) is presently specified, the checksum match could > fail.) There needs to be message element that indicates the result.) > Note: don't need a block number field, since request and responses are > paired. > > We can include a result code > > > 51) Image Data Request. silly beyond belief > > Beauty is in the eye of the beholder ;-). Seriously, the protocol > does work, so what exactly are you looking for? > > > 52) Image Data Response. This is silly. This operation can fail! There > needs to be message element that indicates the result. > > See above comment. > > 53) Reset Request. ... > > The comment is irrelevant now that Clear Config has changed. > > > 54) Reset Response. this is silly. This operation can fail! There needs > to be message element that indicates the result. > > I sense a trend. I will stop including these messages from now on. > > > 55)Duplicate IPv4 Address. how often is this reported if the condition > remains? > > Only required once, I think, but we may want to include some text > covering that. > > > 56) the list of events seems understated! > > Text and conditions please > > > 57) Data Transfer Request. Nice to have - remove. > > Disagree. Providing diagnostics capabilities is required. > > > 58) Mobile Config Request. the actual details of how this works on both > splitMAC and especially localMAC are not well specified. That is, only > the figures and text in sections 11.1.1 and 11.1.2 provide any clue as > to events that would cause an AC to send this message type. Also, there > are restrictions on combinations of parameters that can be included in > the message. > > I wonder whether other folks agree that more details are required. > > > 59) it doesn't say if one message can be used to update more than one > STA. It should be able. > > No, otherwise you end up with the problem of associating specific > message elements with a given mobile. One mobile per request. > > > 60) IEEE 802.11 Mobile. shouldn't the STA MAC address be included so > this message element can be matched with a (4.4.8)Add Mobile message > element? > > I believe this is to your previous point, but the protocol assumes > one mobile per request. > > > 61) IEEE 802.11 Update Mobile QoS. s this for data traffic to the AC? If > so, then why is this an 802.11 message element > > Intended to be a way to push policies to the WTP to prioritize > mobile traffic. > > > 62) IEEE 802.11 WLAN Config Request. why is a new message type that is > 802.11 specific needed to modify 802.11 WLANs? It seems like the > existing "(8.4)Configuration Update Request" message could be used. > > To be more specific only. > > > 63) note here there are information elements to create, delete, and > modify WLANs. However, for message type "(10.1)Mobile Config Request", > there is only add and delete (and the "add" used to modify). > > Correct. The protocol requires the AC to resend a new add with a > different policy. No specific reason, but if this is deemed > inconsistent, we could change it. > > > 64) IEEE 802.11 Assigned WTP BSSID. The mapping of WLAN IDs to BSSIDs > seems like it needs a little more work > > What exactly would you like to see? > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > Sent: Thursday, June 22, 2006 4:31 PM > > To: capwap@frascone.com > > Subject: [Capwap] A commentary on CAPWAP-01 operations > > > > HI, > > > > I've attached a long file that summarizes the operations in > > CAPWAP-01. > > > > Enjoy, > > /david t. perkins > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_11227_19898693.1151680139014 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
David, Pat,
 
I created issues 150-198 to deal with the points in David's email. Happy hunting!
 
Mike

 
On 6/27/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
Going through David's lengthy document, he has raised an interesting
number of points that I believe require issues to be created. At one
point I'm paraphrasing Dave's comments in order to be brief, and
introducing my own numbering scheme.

1) Can message elements be in any order? (I believe they should be)

<PRC> Yes, and I suspect we need to include text to make it more
obvious.


2) Are all specified message elements required? (The obvious answer is
"yes", but this document doesn't discuss versioning. For example, what
if in a new version of CAPWAP an additional message element was to be
added. Would a new message type be created and the additional message
element added to it, or the existing type reused?)

<PRC> This is a great question, and one that does need to be addressed
in the spec. In the Diameter protocol we dealt with this issue by
including a "Mandatory to implement" bit. If any AVP was received, whose
bit was set, yet was not recognized, then the request had to be
rejected.

<PRC> We could consider something similar here, but I believe with the
firmware download component of the protocol it may be less of an issue -
although not guaranteed. I would hope (and expect) that as the CAPWAP
protocol extends, the AC would push new firmware to the WTP. This does
require that the initial part of the state machine be fairly static, and
this could be an area where the "Mandatory to implement" bit could be
useful as it would allow the AC to fall back to older protocol behavior.

3) CAPWAP-01 doesn't do a good job of indicating which message elements
can be repeated.

<PRC> Another good point. When we list the message elements, we should
note whether the frequently is 0-1 (meaning absent or once), 1 (only
once) or 0+ (meaning any number of them could be present.


4) Can "additional" message elements be added to a message? (I believe
so for reporting capabilities, statistics, and     events. For
configuration, there is nothing in the protocol that says what happens
when one end gets an configuration     element it doesn't know about.
Should it be ignored, and the other elements processed, or should the
complete operation     failed?)

<PRC> The "Mandatory to implement" bit above could address this issue.
If an unrecognized message element is found to have the bit set, then
the whole message needs to be rejected. If the bit is not set, the
message element may be safely ignored.


5) The config has a concept of "default value" for each configuration
attribute. However, the default values are not clearly specified. This
needs to be resolved to be able to support "default values".

<PRC> Another good point raised by David.


6) the documentation of which "binding specific" message elements are to
be included with CAPWAP messages is not consistent, and is difficult to
follow.

<PRC> Has this been addressed in the latest (-02) document?


7) There are some message elements that cause "actions". This approach
to protocol design is problematic and should be eliminated.

<PRC> Could you be more specific as well as provide guidance on what you
would like to see?


8) The message types are inconsistently named, and do not follow the
conventions of well designed protocols. Can the operations be named
consistently with the following terminology:
  1) request/response (used to get/set/perform action)
  2) report/ack (use to tell the other side something)

<PRC> Could you provide your thoughts on which messages fall within
which one of your categories?


9) Many of the configuration items, and status items are not listed in
one section with definitions. (Well make it two sections - one for
CAPWAP and the other which is "binding" specific.) For example, not all
of the time period lengths are identified and specified in section 4.5.

<PRC> Unfortunately, the document has gone back and forth a few times
and before we opt to change the structure of the document, I'd like to
ensure that we have broad agreement on what we want - with the
understanding that we will never make everyone happy.


10) each operation should have listed in which states it can be sent and
received

<PRC> I do not understand your comment.


11) All strings, such as WTP location, should be changed from US-ASCII
encoding to UTF-8 encoding.

<PRC> Agreed.

12) The term "mobile" is not really accurate when describing wireless
interfaces, since wireless does not imply      mobile. Can we just use
the techie term "STA" instead.

<PRC> I agree we should use the term Station, or STA for short.


13) The WTP Descriptor message element contains too much information,
lacks clarity on the WTP encryption field and includes version numbers,
which should be in string form.

<PRC> To the first point, I disagree. I think there is value in knowing
everything about the WTP. The AC vendors can expose whatever information
they want, but I don't believe anything is unnecessary.

<PRC> To the second point, this is one of those areas where the concept
of the technology binding creates complexity. Given that we cannot
simply discuss 802.11i at this point, the only thing we can do is punt
to another section in the technology binding section. That said, I agree
with Dave that the 802.11 binding section is too light in this area.
However, I would much prefer that instead of trying to address this
specific issue, we discuss whether we should even be supporting the mode
of operation where 802.11i is performed in the AC - especially with the
introduction of DTLS to secure the data plane. Right now, it just feels
like we have too many options and I am worried that interoperability
will be severely impacted (not to mention protocol complexity).

<PRC> To the last point, I have no issues with including text stating
that the version numbers should be in string form.


14) The WTP Descriptor information is not required at Join time.

<PRC> Well, as far as I can tell, I think there's value in knowing
whether the WTP can even be supported by the AC. So the more info is
provided by the WTP, the better the AC can determine whether it should
just ignore the WTP or not. This could be done because it knows that the
firmware running on the WTP is not compatible, and it has no new
firmware to download.


15) Are the values in the WTP Frame Encryption a capabilities bit, or an
enum?

<PRC> Looks like an enum to me. Not sure what Dave would prefer the text
to read. There are various other similar comments throughout, which I
will not repeat here.


16) The Discovery Response is broken. The AC SHOULD NOT be providing any
info to a WTP (or something that claims to be a WTP). Also, the AC
should tell the WTP what to do next, with choices: 1) Ok to try to join,
2) don't try to join, 3) try                     discover on a list of
returned ACs)

<PRC> I don't believe there is an issue with sending the AC's
information to the WTP, but would solicit input from the list. That
said, some of the information in the AC Descriptor is required, such as
the current load on the AC. No point is trying to join if he AC
indicates it's already at max capacity.
<PRC> I believe if the AC does not return the response, then it implies
(2). Otherwise, it is (1). (3) is handled during the join or configure
process, which I believe is right.


17) Is AC Name text?

<PRC> Yes, and same with WTP Name.


18) Primary Discovery are not required.

<PRC> Disagree. Required for failover.


19) The text does not make it clear that the contents of the WTP
Location is informative only, and as Dave calls it, a "scratchpad".

<PRC> Well, to be honest, I thought the example "next to the fridge"
made it clear that the information did not derive from any scientific
formula. The description also states this is a user-defined. I believe
this should be good enough.


20) Session is not required

<PRC> I believe you may be correct that with the transition to DTLS,
this is no longer required.


21) need to send "common name" as found in the WTP CERT so that the AC
can verify

<PRC> The protocol currently relies on the MAC address being the key
that binds the certificate to the WTP. I don't see a need to change
this.


22) Result code in Join Response is not sufficient, for instance WTP HW
not supported.

<PRC> Well, the protocol does not require this because the Discovery
Response would never be sent (as the protocol stands today).


23) AC IPv4/IPv6 Addr discusses clustering, which is unnecessary.

<PRC> Agreed.


24) Change Echo to Keepalive or heartbeat.

<PRC> I call it potato....


25) What if all of the message elements do not fit within a single
CAPWAP control frame.

<PRC> We should address this.


26) AC Name with Index is all messed up...

<PRC> Not really. You simply include more than one, and the index field
is clearly the priority. Don't understand the Multi-AC comment. No
inter-AC protocol implied here.


27) WTP Board Data belongs in the Join, not configure.

<PRC> Agreed, but wonder even more why we are duplicating this
information across both the WTP Descriptor and the WTP Board Data
message elements.


28) The WTP Static IPv4 Address should not have the Static bit, but
instead state that 0.0.0.0 means a static address is not to be used.

<PRC> I don't have an issue with this request, but in the end we have
the same function. The reason why I state this is that we can refine
this protocol until the cows come home, and at one point we need to draw
a line in the sand.


29) WTP Reboot Statistics belongs in the Join, and the reasons listed
are not clear enough.

<PRC> Doesn't really matter whether this is included in the
configuration or the join, but if the WG agrees to move it. We can
clarify some of the reasons, as long as it provides value.


30) The IEEE 802.11 WTP Radio Configuration message element's BSSID
field should be an array.

<PRC> Disagree.


30) The IEEE 802.11 WTP Radio Configuration message element's Country
Code is not clear enough.

<PRC> The text points to the actual MIB element in the 802.11-1999
standard, which very clearly defines the contents of the field. I don't
think there's value in replicating the format of this field in the
CAPWAP standard.


31) There seems like an awful lot of additional configuration message
elements that need to be specified here!

<PRC> Having built a protocol based on this, it's not clear to me what's
missing. I think it would be useful if you provided concrete details on
what's missing.


32) Configuration Status is just plain broken because any configuration
change operation may fail and there is no           response to the
configuration changes specified in this command.

<PRC> There certainly is - I guess I don't understand the concern.


33) Use of Change State Event should instead be Radio Admin State.

<PRC> Perhaps the two are not described properly. The first is used by
the WTP to inform the AC that something has occurred with a radio. The
second is used by the AC to enable/disable a radio.


34) Report Timer needs to be in section 4.5 or 11

<PRC> ok


35) Should Idle Timeout be per radio, or per WTP, and should the value
be defined in section 4.5 or 11.

<PRC> Per WTP, and yes. I believe it is fine as it is.


36) WTP Fallback isn't well defined, and should be removed.

<PRC> Disagree. I believe it is necessary to create enough resiliency in
the protocol/service.


37) How are the "Rate Set" and "Supported Rates" encoded.

<PRC> This was fixed in the -02


38) AC Timestamp doesn't belong in the configuration, but instead in the
join.

<PRC> Not sure this really matters....


39) Add MAC ACL Entry - this is so strange and is being managed like no
other configuration data.

<PRC> I do not understand the comment


40) Decryption Error Report Period is not defined in section 4.5 or 11

<PRC> ok, and note that the information has been moved to the IEEE
802.11 RSNA Error Report From Mobile


41) Configuration Update Response. today, there are primarily two types
of configuration models. The first is when config is changed, it is only
changed in the volatile copy (the memory or running). An explicit
command is needed to save the config to nonvolatile storage. The second
model has config both running (volatile) and saved (nonvolatile) config
changed when a config change is made. And there might be a special
command to have a config change apply to only one. In this case, there
is no need for a "save config to nonvolatile" command. It is not clear
what is suppose to be supported here in CAPWAP, and how does CAPWAP
support devices with no or very limited nonvolatile storage for config!

<PRC> CAPWAP does not support WTPs with no nonvolatile storage. The
protocol has the AC push configs to the WTP, which saves them at the
time they are received. I do not believe anything else is required.


42) Configuration Update Response includes the Result Code message
element, which includes values that do not appear to be relevant for
this message, and there are plenty of other failure cases

<PRC> ok, but note that we are sharing a common message element. Any
suggestions on how to address your issue?


43) Change State Event Report. This seems a little silly to be sent in
the "configure" state. It seems only appropriate for the "run" state.
Some might argue that even in the "run" state it shouldn't be sent after
a "config update" request that changes the operational state. However,
in the "run" state, it may take a while to have the operational state
change to follow the admin state. Thus, I think it is OK in the "run"
state after config changes."

<PRC> I believe this was addressed in -02.


44) Clear Config Request. this operation has several problems, which
include:
   1) currently, the CAPWAP-01 spec says that this can only be done in
the "run" state. This is silly. It should also be possible in the
"configure" state.
<PRC> I wonder why the AC would even consider clearing the WTP's state
before it even knows how it is configured.

   2) the value of "manufacturing defaults" is not defined, and a poor
term to use, since it implies that that each manufacturer can have
different values. If so, then the AC will have no knowledge of the
config on the WTP! The problem of "default config values" has already be
mentioned above. After each config attribute has been defined with a
default value, then the proper term would be "CAPWAP config defaults".
<PRC> Yes, you've raised this point already, and I agree that it does
need to be addressed.

   3) This operation is not defined to have a response. This is broken,
since any config change can fail. Also, it is not defined what happens
next. Does this cause the WTP to reboot an start a "clean discovery"?
<PRC> This was addressed in -02


45) Image Data Request. Yes, there are actually three different "Image
Data Request" messages. Which one is determined          by which of the
three message elements is contained. This is completely silly! There
should be three separate operations! Additionally, how does the WTP know
which image to get? The AC should be making that decision.

<PRC> I believe the WTP is the only device that knows what it's filename
should be. Why would an AC vendor know about file naming conventions
used by the WTP vendors? I believe your other issues are discussed in
the next items.


46) Image Data Response. this is silly. This operation can fail! There
needs to be message element that indicates the          result.

<PRC> How so? This is only used to send firmware to the WTP. Not clear
what could fail... Reading the image from flash?


47) Image Data Request. when starting over again at the WTP start state,
the WTP shouldn't use the "normal" discovery process, but instead "fast
track" a connection back to the AC that just downloaded the image. With
a little more          work, we could probably figure out a way to reuse
the old DTLS session.

<PRC> To what gain? What is so expensive about the discovery, and what
happened if the AC was not longer reachable?


48) opcode - if this is here, might as well also have a value that
indicates last block of the image file, instead of looking at the block
size.

<PRC> But we're just changing for the sake of changing - the protocol
works as-is.


49) since this operation does not have the block number as a parameter,
the WTP must determine the block number via the CAPWAP message header
sequence number.  NOTE: DTLS does not provide in-order delivery of
packets. Also, this requires the WTP to remember state. This message
element should be re-engineered to have the following subfields:
[edited]

<PRC> The control header includes a sequence number, and while we can
change the current protocol to match your recommendations, the protocol
does work. If it ain't broken...


50) Image Data Response. this is silly. This operation can fail!  For
example, the WTP can run out of space to store          the block, or
there could be a failure in writing the block to storage. (Or as "Image
Data Request"(9.1a) is presently specified, the checksum match could
fail.) There needs to be message element that indicates the result.)
Note: don't need a block number field, since request and responses are
paired.

<PRC> We can include a result code


51) Image Data Request. silly beyond belief

<PRC> Beauty is in the eye of the beholder ;-). Seriously, the protocol
does work, so what exactly are you looking for?


52) Image Data Response. This is silly. This operation can fail! There
needs to be message element that indicates the          result.

<PRC> See above comment.

53) Reset Request. ...

<PRC> The comment is irrelevant now that Clear Config has changed.


54) Reset Response. this is silly. This operation can fail! There needs
to be message element that indicates the          result.

<PRC> I sense a trend. I will stop including these messages from now on.


55)Duplicate IPv4 Address. how often is this reported if the condition
remains?

<PRC> Only required once, I think, but we may want to include some text
covering that.


56) the list of events seems understated!

<PRC> Text and conditions please


57) Data Transfer Request. Nice to have - remove.

<PRC> Disagree. Providing diagnostics capabilities is required.


58) Mobile Config Request. the actual details of how this works on both
splitMAC and especially localMAC are not well specified. That is, only
the figures and text in sections 11.1.1 and 11.1.2 provide any clue as
to events that would cause an AC to send this message type. Also, there
are restrictions on combinations of parameters that can be included in
the message.

<PRC> I wonder whether other folks agree that more details are required.


59) it doesn't say if one message can be used to update more than one
STA. It should be able.

<PRC> No, otherwise you end up with the problem of associating specific
message elements with a given mobile. One mobile per request.


60) IEEE 802.11 Mobile. shouldn't the STA MAC address be included so
this message element can be matched with a (4.4.8)Add Mobile message
element?

<PRC> I believe this is to your previous point, but the protocol assumes
one mobile per request.


61) IEEE 802.11 Update Mobile QoS. s this for data traffic to the AC? If
so, then why is this an 802.11 message element

<PRC> Intended to be a way to push policies to the WTP to prioritize
mobile traffic.


62) IEEE 802.11 WLAN Config Request. why is a new message type that is
802.11 specific needed to modify 802.11 WLANs? It seems like the
existing "(8.4)Configuration Update Request" message could be used.

<PRC> To be more specific only.


63) note here there are information elements to create, delete, and
modify WLANs. However, for message type "(10.1)Mobile Config Request",
there is only add and delete (and the "add" used to modify).

<PRC> Correct. The protocol requires the AC to resend a new add with a
different policy. No specific reason, but if this is deemed
inconsistent, we could change it.


64) IEEE 802.11 Assigned WTP BSSID. The mapping of WLAN IDs to BSSIDs
seems like it needs a little more work

<PRC> What exactly would you like to see?


Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems



> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
> Sent: Thursday, June 22, 2006 4:31 PM
> To: capwap@frascone.com
> Subject: [Capwap] A commentary on CAPWAP-01 operations
>
> HI,
>
> I've attached a long file that summarizes the operations in
> CAPWAP-01.
>
> Enjoy,
> /david t. perkins
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_11227_19898693.1151680139014-- --===============1687181172== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1687181172==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 30 18:56:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwRuS-0002K0-P4 for capwap-archive@lists.ietf.org; Fri, 30 Jun 2006 18:56:24 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwRuQ-0008Nb-Br for capwap-archive@lists.ietf.org; Fri, 30 Jun 2006 18:56:24 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 94AF64300FF for ; Fri, 30 Jun 2006 15:56:21 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 5EF6C430018 for ; Fri, 30 Jun 2006 15:55:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4AD301448020 for ; Fri, 30 Jun 2006 15:55:28 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by hermes.tigertech.net (Postfix) with ESMTP id 86DCB1448004 for ; Fri, 30 Jun 2006 15:55:24 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 30 Jun 2006 15:55:23 -0700 X-IronPort-AV: i="4.06,198,1149490800"; d="scan'208"; a="432449781:sNHT43194564" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5UMtN0j006210; Fri, 30 Jun 2006 15:55:23 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5UMtNke028538; Fri, 30 Jun 2006 15:55:23 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Jun 2006 15:55:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 Jun 2006 15:55:22 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2021DFA34@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Update proposal for Packet formats Thread-Index: AcaY3nL/ykSt9zxKSE2t8hT1ojgTeADkt40g From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" , X-OriginalArrivalTime: 30 Jun 2006 22:55:23.0100 (UTC) FILETIME=[44DE01C0:01C69C98] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Update proposal for Packet formats X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 71427903e4ce43cf4879c36ef9c04bc1 David, I'm not sure that I understand the justification for making all of these rather dramatic changes to the protocol, so I'm not sure what implementation and demonstration would buy us at the IETF. I think what would be useful instead is to create issues that describe the actual problem. We can change the protocol until the cows come home, but in order to maintain some level of sanity, we need to start getting a little more aggressive about rejecting feature requests. One comment on the retry number, though. Both sides have to maintain state anyways, so it's not clear to me that there is any use in this bit. For instance what do you do if you receive a message with the "Retry" bit set, but had never received the first one? The bit really doesn't provide much use in this case. So in any case you need to maintain a running counter of what's been received & processed, and we do this through the sequence number field. The reliability part of the CAPWAP protocol also ensures that packets are retransmitted if not acknowledged (where your proposal would require that the packet be re-encrypted because the Retry bit was changed). Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Sunday, June 25, 2006 10:07 PM > To: capwap@frascone.com > Subject: [Capwap] Update proposal for Packet formats > > HI, > > In the last proposal, I remove a field used for retries. In > verifying whether it could be done, I found a problem. Below > is the updated proposal, which includes examples showing how > fragmentation works, and how retries work. Please let me know > if you have any problems. This is what I plan to have > implemented and demonstrate at IETF. > > --------------------------- > Proposal for CAPWAP Packet Format > -------------------------------- > > Updates from 22-jun-2006: > 1) Cleaned up terminology definitions. > 1) Added clarification about initial values for the > "CAPWAP PDU ID" and "MSG ID" fields > 2) Added timing diagram showing no fragmentation and fragmentation > 3) Added timing diagram showing CAPWAP control message drops > and retries > 4) Put back in MSG Seq ID into the Control header, but re-labeled > as retry num, and reordered fields. > > Updates from 8-jun-2006: > 1) Made to look closer to CAPWAP-02 > 2) Added CAPWAP Fragmentation Header so that both control > and data supported fragmentation > 3) Updated descriptions of fields of packets > 4) Changed how fragmentation is indicated. > 5) Modified so that the Data (or Control) header is > on in the first fragment of a CAPWAP PDU > 6) Cleaned up Data Header, now that fragmentation > is in a separate header and made the remaining > fields match those in CAPWAP-02 > 7) Updated the Control Header so that it closely > resembles CAPWAP-02, except for 'F' field. > > > > Updates from 7-jun-2006: > 1) changed diagrams to make DTLS experts happier > 2) renamed "CAPWAP MUX Hdr" to "CAPWAP Pkt Hdr", > and made it 2 octets long instead of 1 octet > 3) made the packet types start at 1 instead of zero > 4) fixed a few typos > 5) changed the formulas for the message type value and > message element type value to multiply the IANA > enterprise number by 4096 (shift left by 12) instead > of 256 (shift left by 8). This means the the > enterprise value must be encoded in 20 bits, > and the specific type value in 12 bits. I checked > the assignment of Enterprise numbers, and there are > now approximately 16K, and also checked the OUI > assignments and there are approximately 51K. Thus, > 20 bits (1M) should be enough! > --------------------------------- > > CAPWAP Packet formats: > > > CAPWAP Unprotected Data Packet: > +------------------------------[--------]----------+ > | IP | UDP | CAPWAP | CAPWAP | CAPWAP | Wireless | > | Hdr | Hdr | Pkt | Frag | Data | Payload | > | | | Hdr | Ctrl | Hdr | Frag | > +------------------------------[--------]----------+ > only in > first fragment > > CAPWAP DTLS Protected Data Packet: > > +-------------------------------------[---------]--------------------+ > | IP | UDP | CAPWAP | DTLS | CAPWAP | CAPWAP | > Wireless | DTLS | > | Hdr | Hdr | Pkt | Hdr | Frag | Data | Payload > | Trailer | > | | | Hdr | | Ctrl | Hdr | Frag > | | > > +-------------------------------------[---------]--------------------+ > only in > first fragment > \--integrity checked-----------------/ > > \--encrypted----------------------------/ > > > CAPWAP Unprotected Control Packet: > +------------------------------[---------]----------+ > | IP | UDP | CAPWAP | CAPWAP | CAPWAP | Message | > | Hdr | Hdr | Pkt | Frag | Control | Elements | > | | | Hdr | Ctrl | Hdr | Frag | > +------------------------------[---------]----------+ > only in > first fragment > > CAPWAP DTLS Protected Control Packet: > > +------------------------------------[---------]--------------------+ > | IP | UDP | CAPWAP | DTLS | CAPWAP | CAPWAP | Message > | DTLS | > | Hdr | Hdr | Pkt | Hdr | Frag | Control | Elements > | Trailer | > | | | Hdr | | Ctrl | Hdr | Frag > | | > > +------------------------------------[---------]--------------------+ > only in > first fragment > \--integrity checked----------------/ > > \--encrypted----------------------------/ > > UDP: All CAPWAP packets are encapsulated within UDP. > > CAPWAP Pkt Header: All CAPWAP protocol packets use a > short header > that specifies the version of CAPWAP and the type of the > CAPWAP packet. > > CAPWAP PDU: CAPWAP consists of both control and data streams. > A CAPWAP PDU is either a CAPWAP control PDU or > a CAPWAP data PDU. > > CAPWAP Control PDU: A CAPWAP control PDU encapsulates a > control message, which is a control header and its > message elements. > > CAPWAP Data PDU: A CAPWAP data PDU encapsulates a data > message, which is a data header and wireless > payload. > > CAPWAP Fragmentation Control Header: Used for fragmentation > of CAPWAP PDUs. A CAPWAP PDU that will not fit in > one UDP packet will be fragmented into multiple > CAPWAP packets. > > CAPWAP Data Header: This header is used for CAPWAP data PDUs. > If a CAPWAP data PDU is fragmented, then the CAPWAP > Data Header is in only the first fragment in the > group of fragments constructing the CAPWAP data PDU. > > Wireless Payload: The actual payload from or to wireless > devices. The format may be 802.3 Ethernet II, or > native wireless transport specific encoding. > > DTLS Header: Protected CAPWAP packets use the DTLS protocol to > provide message integrity and encryption services. > > DTLS Trailer: A field used to provide protection service for > security of CAPWAP messages. > > CAPWAP Control Header: The CAPWAP protocol includes a signalling > component, known as the CAPWAP control protocol. > All CAPWAP > control PDUs include a Control Header. If a > CAPWAP control PDU > is fragmented, then the CAPWAP Control Header is in only > the first fragment in the group of fragments constructing > the CAPWAP control PDU. > > Message Elements: A CAPWAP Control PDU includes zero, one, > or more message elements, which are found immediately > following the control header. These message elements > are in a type, length, value format. > > > CAPWAP Pkt Header: > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version | Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Version - the version of the CAPWAP protocol (the first is 1) > DISCUSS: should this be split into major and minor, > and if so, what are the implications of > an increment of the major or minor part? > > Type - packet type, values are: > 1 - CAPWAP Unprotected Data Packet > 2 - CAPWAP DTLS Protected Data Packet > 3 - CAPWAP Unprotected Control Packet > 4 - CAPWAP DTLS Protected Control Packet > 0,5-15 - reserved > > > CAPWAP Fragmentation Control Header: > 0 1 2 > 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 > 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |M|Res| CAPWAP PDU ID | Fragment Offset | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > M: The More 'M' bit indicates whether there are more fragment > packets needed to be combined to reassemble a complete > CAPWAP PDU. When this bit is 1, there are more fragment > packets. When this bit is 0, there are no more fragments > and this packet completes the CAPWAP PDU. > > Res: The bits are reserved, and must be zero. > > CAPWAP PDU ID: A 16-bit field whose value is assigned to each > CAPWAP PDU. The CAPWAP PDU ID space is managed independently > for every WTP/AC pair, for each end (an AC or WTP), and for > each CAPWAP stream (data or control). For example, if AC #1 > communicates with WTP #1 and WTP #2, there will be the > following independent CAPWAP PDU IDs: > WTP #1: ID1 for control going to AC #1 > ID2 for data going to AC #1 > WTP #2: ID3 for control going to AC #1 > ID4 for data going to AC #1 > AC #1: ID5 for control going to WTP #1 > ID6 for data going to WTP #1 > ID7 for control going to WTP #2 > ID8 for data going to WTP #2 > The value for each CAPWAP PDU ID is incremented with each > new CAPWAP PDU sent whether or not the PDU is fragmented. > The value wraps to zero after the maximum value has been > used to identify a CAPWAP PDU. When a new session > is established, the initial value is a randomly generated > number. > > Fragment Offset: A 13 bit field that indicates where in > the CAPWAP > PDU will this fragment belong during re-assembly. This > field should always have a valid value. For the first > or only packet of a CAPWAP PDU, the value must be zero. > The fragment offset is measured in units of 8 octets > (64 bits). This provides a maximum size of a CAPWAP > PDU to be 16 bits (which is 65536 octets). > Note the CAPWAP protocol does not allow for overlapping > fragments. For instance, it would be an error if the > first fragment was 1000 octets in length, and the > second fragment's offset was 800. To be valid (when > the length of the first fragment is 1000, the second > fragment MUST have an offset of 1000. > (DISCUSS: need to have a timer that is associated with > fragmentation to toss all of the fragments if they > have not been combined in the allocated time.) > > > CAPWAP Data Header: > 0 1 2 > 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 > 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RID | HLEN | WBID |T|W|M| Res > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | (optional) Radio MAC Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | (optional) Wireless Specific Information > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > RID: A 5 bit field which contains the Radio ID for this CAPWAP > data PDU. WTPs with multiple radios but a single MAC Address > range (for BSSIDs) use this field to indicate which radio is > associated with the packet. > > HLEN: A 5 bit field specifying the length of the CAPWAP data > header header in 4 octet words (Similar to IP header length). > This length includes the optional headers. > > T: The Type 'T' bit indicates the format of the frame being > transported in the payload. When this bit is set to one (1), > the payload has the native frame format indicated by the > WBID field. When this bit is zero (0) the payload is an > IEEE 802.3 frame. > > W: The 'W' bit is used to specify whether the optional > "Wireless Specific Information" field is present in > the header. > A value of one (1) is used to represent the fact that the > field is present. > > M: The 'M' bit is used to specify whether the optional > "Radio MAC Address" field is present in the header. > A value of one (1) is used to represent the fact that the > field is present. > > Res: The bits are reserved and must be zero. > > Radio MAC Address: This optional field contains the BSSID > of the radio receiving the packet. This is used in packets > sent from the WTP to the AC, when the native wireless frame > format is converted to 802.3 by the WTP. This field is only > present if the 'M' bit is set. Given the HLEN field requires > the header size to be a multiple of 4 octets, this field MUST > be padded with zeroes (0x00) if it is not 4 octet aligned. > > The field has the format: > > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > | Length | MAC Address ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > Length: The number of octets in the MAC Address field. The > length field is present since new IEEE technologies > (e.g., 802.16) are now using 64 bits (8 octet) MAC > addresses. > > MAC Address: The BSSID of the receiving radio. > > Wireless Specific Information: This optional field contains > technology specific information that may be used to carry per > packet wireless information. This field is only present if > the 'W' bit is set. Given the HLEN field assumes 4 octet > alignment, this field MUST be padded with zeroes (0x00) if > it is not 4 octet aligned. > > The field has the format: > > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > | Wireless ID | Length | Data ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > Wireless ID: The wireless binding identifier. The following > values are defined: > 1 - : IEEE 802.11 > > Length: The length of the data field > > Data: Wireless specific information, whose details are > defined in the technology specific bindings sections. > > For 802.11, when sent from WTP to AC, the data > has the following format: > > IEEE 802.11 Frame Info: > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RSSI | SNR | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data Rate | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > RSSI: RSSI is a signed, 8-bit value. It is the > received signal strength indication, in dBm. > > SNR: SNR is a signed, 8-bit value. It is the signal > to noise ratio of the received IEEE > 802.11 frame, > in dB. > > Data Rate: The data rate field is a 16-bit unsigned > integer value. The contents of the > field is set > to 1/10th of the data rate of the > packet received > by the WTP. For instance, a packet > received at > 5.5Mbps would be set to 55, while 11Mbps would > be set to 110. > > For data sent from the AC to the WTP, the data > has the following format: > > Destination WLANs: > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | WLAN | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > WLAN: This bit vector indicates the WLAN ID(s) which > the WTP will transmit the associated frame on. > For instance, if a multicast packet is to be > transmitted on WLANs 1 and 3, bits 1 and 3 of > this field would be set to '1'. Note this > field is to be set to zero for unicast > packets and is unused if the WTP is not > providing encryption services. > > Wireless Payload: > The format of the wireless payload depends on the encapsulation > mode. There are two formats defined, which are: > > 802.3 Frame - this is the standard IEEE 802.3 Ethernet II frame > (DISCUSS: this needs to be confirmed) > 802.11 native frame - DISCUSS: finish this > > > CAPWAP Control Header: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Msg ID | Retry#|F| Res | Length of Msg Elements | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Message Type: This field identifies the function of the CAPWAP > control message. The Message Type field is comprised of > an IANA Enterprise Number and an enterprise > specific message > type number. The first 20 bits is the enterprise number > in network byte order, with zero being used for CAPWAP > generic message types and the IEEE 802.11 IANA assigned > enterprise number 13277 being used for IEEE > 802.11 technology > specific message types. The last 12 bits is the > enterprise > specific message type number, which has a range from 0 to > 4095. > > The value of the message type field can be expressed as: > > Message type value = IANA Enterprise Number * 4096 + > enterprise specific message > type number > > Msg ID: The message ID field is used by the CAPWAP control > application to match responses (or acknowledgements) with > requests (or reports). The value must be monotonically > incremented for each unique request (or report). After > the maximum value is reached, the value wraps > back to zero. > The paired response (or acknowledgement) returns the value > from the request (or report). Note the size is 8-bits, and > thus a maximum of 255 CAPWAP operations can be currently > outstanding. The message ID space is managed independently > for every WTP/AC pair, and for each end (an AC or WTP). > For example, if AC#1 communicates with WTP #1 and WTP #2, > there will be the following independent Message IDs: > WTP #1: MSG ID1 for requests (and reports) > going to AC #1 > WTP #2: MSG ID2 for requests (and reports) > going to AC #1 > AC #1: MSG ID3 for requests going to WTP #1 > MSG ID4 for requests going to WTP #2 > When a new session is established, the initial value is > a randomly generated number. > > Retry#: The retry number field starts at zero and is incremented > for each message with the same value of message ID. > After the maximum value is reached, the value wraps back > to zero. The paired response (or acknowledgement) returns > the value from the request (or report). Note the size > is 4-bits, and thus a maximum of 16 retries can be > be currently outstanding. > This field is used to match a request (or report) > with its paired response (or acknowledgement) so that > accurate round trip operation time can be determined. > (DISCUSS: maybe put back here the text about how this > works. The examples of operation retries should help.) > > F: The 'F' bit field indicates if the message is the first > message in a message pair. A value of "1" means > first, and "0" means second in the pair. There are > two types of message pairs, which are: > 1) a request and response > 2) a report and acknowledgement. > Thus, the first is a request or report message > (with the 'F' field set to "1"), and the second is > a response or acknowledgement (with the 'F' field > set to "0"). Note, both a request and response > (or report and acknowledgement) of a operation > type use the same value for message type. The > 'F' bit is used to indicate which is which. > This allows new message types to be added > that can be processed without knowing the > meaning of the message type. That is, when > an unknown request message type is received, > the response is the same message type with > a message element indicating that the message > type is not supported. > > Res: The bits are reserved and must be zero. > > Length of Message Elements: This field indicates in octets the > length of the message elements field, which contains zero, > one, or more message elements. The field is 16 bits wide, > and thus the maximum size that can be specified 64K. > However, the maximum size of a CAPWAP control PDU is > 64K, and thus the max length is 64K minus the size of > the CAPWAP control header, or 64K - 8, or 65528. > > Message Elements: > The "message elements" field contains, zero, one, or more message > element field, which has the following format: > > Message Element: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message Element Type > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length | Value .... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > Message Element Type: This field identifies a message element > of a CAPWAP control message. The Message Element > Type field > is comprised of an IANA Enterprise Number and an > enterprise > specific message element type number. The first 20 bits > is the enterprise number in network byte order, with zero > being used for CAPWAP generic message types and the > IEEE 802.11 IANA assigned enterprise number 13277 being > used for IEEE 802.11 technology specific message element > types. The 12 bits is the enterprise specific message > element type number, which has a range from 0 to 4095. > > The value of the message element type field can > be expressed > as: > > Message element type value = IANA Enterprise > Number * 4096 + > enterprise specific message element > type number > > > ------------------------------------------------ > Use of the CAPWAP Fragmentation Control Header > > Example of a Nonfragmented CAPWAP PDU > > For both data and control CAPWAP packets, CAPWAP Fragment Control > Header has the following content: > > first, compute next CAPWAP_PDU_ID, which is > CAPWAP_PDU_ID = (CAPWAP_PDU_ID + 1) & 0x0ffff; > 0 1 2 > 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 > 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|0 0| CAPWAP_PDU_ID | 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Example of Fragmented CAPWAP PDUs > > 1) Here is an example of a CAPWAP data PDU where the > length of the CAPWAP data header and wireless payload > will cause a single CAPWAP data packet to be greater than > the max IP packet size for the path. Assume that > the size of the CAPWAP data PDU is 1560 octets, which > needs to be fragmented into a fragments of 1400 and > 160 octets. > > The first fragment would have the following CAPWAP > fragment control header, and be followed by a > CAPWAP data header and part of the wireless payload > and would look like: > > first, compute next CAPWAP_PDU_ID, which is > CAPWAP_PDU_ID = (CAPWAP_PDU_ID + 1) & 0x0ffff; > > 0 1 2 > 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 > 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|0 0| CAPWAP_PDU_ID | 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The second fragment would have the following CAPWAP > fragment control header, and be followed by the remaining > portion of the wireless payload and would look like: > > (Use the same value of CAPWAP_PDU_ID) > 0 1 2 > 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 > 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|0 0| CAPWAP_PDU_ID | (1400/8) = 175 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 2) Here is an example of a CAPWAP control PDU where the > length of the CAPWAP control header and message elements > will cause a single CAPWAP control packet to be greater > than the max IP packet size for the path. Assume that > the size of the CAPWAP control PDU is 1560 octets, which > needs to be fragmented into a fragments of 1400 and > 160 octets. > > The first fragment would have the following CAPWAP > fragment control header, and be followed by a > CAPWAP control header and part of the message elements > and would look like: > > first, compute next CAPWAP_PDU_ID, which is > CAPWAP_PDU_ID = (CAPWAP_PDU_ID + 1) & 0x0ffff; > > 0 1 2 > 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 > 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|0 0| CAPWAP_PDU_ID | 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The second fragment would have the following CAPWAP > fragment control header, and be followed by the remaining > portion of the wireless payload and would look like: > > (Use the same value of CAPWAP_PDU_ID) > 0 1 2 > 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 > 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|0 0| CAPWAP_PDU_ID | (1400/8) = 175 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > ------------------------------------------------ > Use of the "Msg ID" and "Retry#" Fields for Retries > > Only the control path has message retries. Since control > operations are not idempotent (that is, are not guaranteed to > return the same result when redone), operation results (the > response or acknowledgement) to a request or report must be > cached and returned if a repeat of the operation occurs. A > repeat occurs when > 1) the request (or report) is not received (however, the > receiver does not know that the operation is being repeated) > 2) the response (or acknowledgement) is > not received within the expected operation round trip time. > 3) the request (or report) is duplicated by the network (this > only occurs when the control operation is not protected by DTLS) > > Here are timing diagrams for 4 cases: > > Abbreviations: > P_ID - PDU ID > M_ID - MSG ID > R - Retry number > > 0) No timeout/replay/duplication: > (P_ID=56, M_ID=23, R=0) (M_ID=23, R=0) > WTP----------------------->|----------------------->AC - process > | | and cache > (M_ID=23, R=0) | (P_ID=75,M_ID=23,R=0) | > for M_ID=23 > <------------------------|<------------------------ and R=0 > | > > NOTEs: 1) AC and WTP have different spaces for P_ID. It > is used only for CAPWAP PDU fragmentation reassembly. > 2) The P_ID is always incremented for each CAPWAP PDU, > even for retries > 3) the M_ID from a request (or report) is > echoed in a paired response (or acknowledgement) > 4) each originator of an operation has an independent > M_ID number space > > > 1) message never received, so resent: > (P_ID=56, M_ID=23, R=0) > WTP----------------------->|-->X AC > | | > |timeout | > V (P_ID=57, M_ID=23, R=1) | > retry---------------------->|----------------------->AC - process > | | and cache > (M_ID=23, R=1) | (P_ID=75,M_ID=23, R=1) | > for M_ID=23 > <------------------------|<------------------------ and R=1 > > > NOTEs: 1) the M_ID is not incremented on retries > 2) the R always starts at zero for each M_ID and > is incremented on retries > > > 2a) message response (or acknowledgement) never received, > so message resent: > (P_ID=56, M_ID=23, R=0) (M_ID=23, R=0) > WTP----------------------->|----------------------->AC - process > | | | and cache > | | (P_ID=75,M_ID=23,R=0) | > for M_ID=23 > | X<--|<------------------------ and R=0 > |timeout | > V (P_ID=57, M_ID=23, R=1) | (M_ID=23, R=1) > retry---------------------->|----------------------->AC - find in > | | cache for > (M_ID=23, R=1) | (P_ID=75,M_ID=23,R=1) | M_ID=23, > <------------------------|<------------------------ update R=1 > > NOTEs: 1) only the M_ID is search in the cache for a match > (the R is saved, but not used in search) > 2) the R from the request message is returned > in the response message > 3) the R is updated in the cache > > 2b) message response (or acknowledgement) not received within > the current computed value for round trip operation > time, so a message resent. However, original response > received before response to retry. > > (P_ID=56, M_ID=23, R=0) (M_ID=23, R=0) > WTP----------------------->|----------------------->AC - process > | | | and cache > | | (P_ID=75,M_ID=23,R=0) | > for M_ID=23 > | |/------------------------ and R=0 > |timeout || > V (P_ID=57, M_ID=23, R=1) || (M_ID=23, R=1) > retry---------------------->|+---------------------->AC - find in > || | cache for > (M_ID=23, R=0) || | M_ID=23, > <------------------------|/ | update R=1 > update RTOT(drop) | | > | | > (M_ID=23, R=1) | (P_ID=75,M_ID=23,R=1) | > <------------------------|<------------------------ > update RTOT(process) > > NOTEs: 1) without the R field, cannot determine if the > first received response was from the first > time the request was made, or from a the > retry. Without knowing which, cannot > accurately update the round trip > operational time. > 2) it is possible to process the first response > and not drop it, but if so, must remember > the time when sent each retry. If max retries > not too many, then not much of a cost. > a match (the R is not saved or searched) > > 3) message request (or report) is duplicated by the > network: > (P_ID=56, M_ID=23, R=0) (M_ID=23, R=0) > WTP----------------------->|----------------------->AC - process > \ | | and cache > (M_ID=23, R=0) \ | (P_ID=75,M_ID=23,R=0) | > for M_ID=23 > <------------------+------|<------------------------ and R=0 > \ | > \ | (M_ID=23, R=0) > Dup \-->|+---------------------->AC - find in > | cache for > | M_ID=23, > R is the > > same so drop > > NOTEs: 1) the R field in the duplicated message is used > by the AC to determine if the request is > a duplicate. > 2) if both a response drop (or delay) and > a duplicate occurs the R may be less > than the R in the cache. If so, the > message is a very delayed duplicate > and can be dropped. > > > --------------------------- > Regards, > /david t. perkins > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 30 19:16:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwSEN-0004hr-77 for capwap-archive@lists.ietf.org; Fri, 30 Jun 2006 19:16:59 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwSEL-0000qY-PV for capwap-archive@lists.ietf.org; Fri, 30 Jun 2006 19:16:59 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6C6864300A7 for ; Fri, 30 Jun 2006 16:16:57 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D3D12430018 for ; Fri, 30 Jun 2006 16:16:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9920F1448018 for ; Fri, 30 Jun 2006 16:16:36 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id F2B36144801C for ; Fri, 30 Jun 2006 16:16:32 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k5UNGW7m015816; Fri, 30 Jun 2006 16:16:32 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k5UNGVVu015809; Fri, 30 Jun 2006 16:16:32 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 30 Jun 2006 16:16:31 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2021DFA34@xmb-sjc-235.amer.cisco.com> Message-ID: MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Update proposal for Packet formats X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 HI, Pat, while I appreciate and share your concerns about changes, I believe that there are serious problems in the fragmentation and retry scheme in CAPWAP-01. (I haven't had the time to check to see if this has changed in CAPWAP-02.) I've asked repeatedly for some one to show a timing diagram of this and other issues, but have not seen this. I've only seen responses to the affect "I understand how it works and I don't need a diagram." This type of comment does not verify that all that have read the document have reached a common understanding. Of course, you are well aware of IETF requiring interoperable implementations to demonstrate common understanding for a standards track document to advance. Basic issues, such as this should have been addressed and resolved starting at the November IETF, and if needed an interim meeting that the WG didn't have. I'm disappointed. The problems still remain. Let's put a spotlight on the issues and see if they are real, imaginary, or somewhere inbetween. And on your specific question of a "retry bit", I quess I was not clear, because there is NO retry bit in my packet format proposal. On Fri, 30 Jun 2006, Pat Calhoun (pacalhou) wrote: > David, > > I'm not sure that I understand the justification for making all of these > rather dramatic changes to the protocol, so I'm not sure what > implementation and demonstration would buy us at the IETF. I think what > would be useful instead is to create issues that describe the actual > problem. We can change the protocol until the cows come home, but in > order to maintain some level of sanity, we need to start getting a > little more aggressive about rejecting feature requests. > > One comment on the retry number, though. Both sides have to maintain > state anyways, so it's not clear to me that there is any use in this > bit. For instance what do you do if you receive a message with the > "Retry" bit set, but had never received the first one? The bit really > doesn't provide much use in this case. So in any case you need to > maintain a running counter of what's been received & processed, and we > do this through the sequence number field. The reliability part of the > CAPWAP protocol also ensures that packets are retransmitted if not > acknowledged (where your proposal would require that the packet be > re-encrypted because the Retry bit was changed). > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jun 30 19:55:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwSpT-0003GY-2t for capwap-archive@lists.ietf.org; Fri, 30 Jun 2006 19:55:19 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwSpR-0002i1-J1 for capwap-archive@lists.ietf.org; Fri, 30 Jun 2006 19:55:19 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 77CC443010C for ; Fri, 30 Jun 2006 16:55:16 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 54CC9430081 for ; Fri, 30 Jun 2006 16:54:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3D94A398023 for ; Fri, 30 Jun 2006 16:54:54 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2DBEB398014 for ; Fri, 30 Jun 2006 16:54:50 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 30 Jun 2006 16:54:51 -0700 X-IronPort-AV: i="4.06,198,1149490800"; d="scan'208"; a="1834232075:sNHT34183468" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5UNso83015909; Fri, 30 Jun 2006 16:54:50 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5UNsocL009373; Fri, 30 Jun 2006 16:54:50 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Jun 2006 16:54:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 Jun 2006 16:54:49 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2021DFA6B@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Update proposal for Packet formats Thread-Index: Acacmzp7pR2duP5GR2Oc+05WfHfGhAABUUJw From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" X-OriginalArrivalTime: 30 Jun 2006 23:54:50.0351 (UTC) FILETIME=[931D4FF0:01C69CA0] Authentication-Results: sj-dkim-8.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Update proposal for Packet formats X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Now I'm confused... > And on your specific question of a "retry bit", I quess I was > not clear, because there is NO retry bit in my packet format > proposal. > Retry#: The retry number field starts at zero and is incremented > for each message with the same value of message ID. > After the maximum value is reached, the value wraps back > to zero. The paired response (or acknowledgement) returns > the value from the request (or report). Note the size > is 4-bits, and thus a maximum of 16 retries can be > be currently outstanding. > This field is used to match a request (or report) > with its paired response (or acknowledgement) so that > accurate round trip operation time can be determined. > (DISCUSS: maybe put back here the text about how this > works. The examples of operation retries should help.) Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Friday, June 30, 2006 4:17 PM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: RE: [Capwap] Update proposal for Packet formats > > HI, > > Pat, while I appreciate and share your concerns about > changes, I believe that there are serious problems in the > fragmentation and retry scheme in CAPWAP-01. (I haven't had > the time to check to see if this has changed in CAPWAP-02.) > I've asked repeatedly for some one to show a timing diagram > of this and other issues, but have not seen this. I've only > seen responses to the affect "I understand how it works and I > don't need a diagram." This type of comment does not verify > that all that have read the document have reached a common > understanding. Of course, you are well aware of IETF > requiring interoperable implementations to demonstrate common > understanding for a standards track document to advance. > > Basic issues, such as this should have been addressed and > resolved starting at the November IETF, and if needed an > interim meeting that the WG didn't have. I'm disappointed. > The problems still remain. Let's put a spotlight on the > issues and see if they are real, imaginary, or somewhere inbetween. > > > On Fri, 30 Jun 2006, Pat Calhoun (pacalhou) wrote: > > David, > > > > I'm not sure that I understand the justification for making all of > > these rather dramatic changes to the protocol, so I'm not sure what > > implementation and demonstration would buy us at the IETF. I think > > what would be useful instead is to create issues that describe the > > actual problem. We can change the protocol until the cows > come home, > > but in order to maintain some level of sanity, we need to start > > getting a little more aggressive about rejecting feature requests. > > > > One comment on the retry number, though. Both sides have to > maintain > > state anyways, so it's not clear to me that there is any > use in this > > bit. For instance what do you do if you receive a message with the > > "Retry" bit set, but had never received the first one? The > bit really > > doesn't provide much use in this case. So in any case you need to > > maintain a running counter of what's been received & > processed, and we > > do this through the sequence number field. The reliability > part of the > > CAPWAP protocol also ensures that packets are retransmitted if not > > acknowledged (where your proposal would require that the packet be > > re-encrypted because the Retry bit was changed). > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > Regards, > /david t. perkins > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap