From skitrip-bounces+capwap-archive=lists.ietf.org@frascone.com Mon May 01 08:34:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaXbL-0005gn-MC for capwap-archive@lists.ietf.org; Mon, 01 May 2006 08:34:07 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaXbK-00012A-DZ for capwap-archive@lists.ietf.org; Mon, 01 May 2006 08:34:07 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 887DA43011C for ; Mon, 1 May 2006 05:34:05 -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: Mon, 01 May 2006 05:31:24 -0700 Precedence: bulk X-BeenThere: skitrip@frascone.com X-Mailman-Version: 2.1.5 List-Id: skitrip.frascone.com 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 capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon May 01 13:58:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Facfd-0007cg-1Z for capwap-archive@lists.ietf.org; Mon, 01 May 2006 13:58:53 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Facfb-0005AG-DD for capwap-archive@lists.ietf.org; Mon, 01 May 2006 13:58:53 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CFA554300DA for ; Mon, 1 May 2006 10:58:49 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 86674430054 for ; Mon, 1 May 2006 10:58:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6D939144801E for ; Mon, 1 May 2006 10:58: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 D851A1448016 for ; Mon, 1 May 2006 10:58:26 -0700 (PDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 01 May 2006 10:58:26 -0700 X-IronPort-AV: i="4.04,169,1144047600"; d="scan'208"; a="1800265097:sNHT33448164" 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 k41HwPYk007765 for ; Mon, 1 May 2006 10:58: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); Mon, 1 May 2006 10:58:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 May 2006 10:58:25 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201CBAA7B@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 68: Update WLAN does not allow for RSN info to be sent down Thread-Index: AcZtSNeudtM0qbueTm26hiRCFQvvCw== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 01 May 2006 17:58:25.0608 (UTC) FILETIME=[D8077C80:01C66D48] 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 X-Spam-Level: Subject: [Capwap] Issue 68: Update WLAN does not allow for RSN info to be sent down X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c =20 While fixing issue 101, I had also fixed this issue. The request was to allow for the RSN info to be sent in the Update WLAN message element. Here is my proposed text: 11.8.1.3. IEEE 802.11 Update WLAN The Update WLAN message element is used by the AC to define a wireless LAN on the WTP.The inclusion of this message element MUST also include the IEEE 802.11 Information Element message element, containing the following 802.11 IEs: Capability WPA IE RSN IE EDCA Parameter Set IE QoS IE WMM IE The value contains the following format: [...] 11.8.1.4. IEEE 802.11 Information Element The IEEE 802.11 Information Element is used to communicate any IE defined in the IEEE 802.11 protocol. The contents of the data field will be an IEEE 802.11 information element as defined in clause 7.3.2 of the IEEE 802.11 (1999) standard. 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+- | Info Element +-+-+-+-+-+-+-+- Type: TBD for IEEE 802.11 Information Element Length: >=3D 1 Info Element: The IEEE 802.11 Information Element, which includes the type, length and value field. 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 May 01 14:00:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fach2-0008L3-RR for capwap-archive@lists.ietf.org; Mon, 01 May 2006 14:00:20 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fach2-0005EK-8E for capwap-archive@lists.ietf.org; Mon, 01 May 2006 14:00:20 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 768564300D1 for ; Mon, 1 May 2006 11:00:19 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4BC0F430054 for ; Mon, 1 May 2006 10:59:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3B60F1448021 for ; Mon, 1 May 2006 10:59:38 -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 B1E781448016 for ; Mon, 1 May 2006 10:59:35 -0700 (PDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 01 May 2006 10:59:35 -0700 X-IronPort-AV: i="4.04,169,1144047600"; d="scan'208"; a="1800265698:sNHT33909332" 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 k41HxTYq008903 for ; Mon, 1 May 2006 10:59:35 -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, 1 May 2006 10:59:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 May 2006 10:59:32 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201CBAA7E@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 50: Increase maximum number of BSSs Thread-Index: AcZtSP/bS6z2xyuUQwGBlDGdLM8jQA== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 01 May 2006 17:59:33.0263 (UTC) FILETIME=[005AD1F0:01C66D49] 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 X-Spam-Level: Subject: [Capwap] Issue 50: Increase maximum number of BSSs X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad =20 I would recommend that we reject this issue. 16 BSSIDs is a large number, and the overhead in generating 16 or more beacons outweighs the usefullness in advertising that many networks. 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 May 01 14:38:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FadIM-0000E2-4i for capwap-archive@lists.ietf.org; Mon, 01 May 2006 14:38:54 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FadIF-0006jc-IJ for capwap-archive@lists.ietf.org; Mon, 01 May 2006 14:38:54 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E4D44430122 for ; Mon, 1 May 2006 11:38:46 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1F882430075 for ; Mon, 1 May 2006 11:38:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0841A398021 for ; Mon, 1 May 2006 11:38:23 -0700 (PDT) Received: from smtpauth07.mail.atl.earthlink.net (smtpauth07.mail.atl.earthlink.net [209.86.89.67]) by zoidberg.tigertech.net (Postfix) with ESMTP id 06FE9398029 for ; Mon, 1 May 2006 11:38:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=OOd1D4nOdFz9UKYEFXoIPFbApu+f8k9BhsJkN8dmpaJrnJ4ccQfAmfiKTDE2hlKg; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.33] (helo=elwamui-darkeyed.atl.sa.earthlink.net) by smtpauth07.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1FadHn-0002rv-67 for capwap@frascone.com; Mon, 01 May 2006 14:38:19 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Mon, 1 May 2006 14:38:19 -0400 Message-ID: <21852423.1146508699189.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Date: Mon, 1 May 2006 11:38:19 -0700 (GMT-07:00) From: "Scott G. Kelly" To: capwap Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff71023e207b500edfb28bc736562a416363a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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: Subject: [Capwap] to mux or not to mux? X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Some time ago, I proposed that we use a single port for capwap, and insert a mux header right after the UDP header to differentiate between control and data. While there was some discussion, we did not reach a conclusion. Here's what it would look like: +---------+-------------+------------------------------- | UDP Hdr | MUX Hdr = 1 | DTLS Enc Control Packet .... +---------+-------------+---------------------- The capwap editors are currently working hard to produce the 01 version of the capwap document, and it would be best for implementers if this question could be decided prior to publication of that document. To facilitate this, I've summarized briefly below. Using separate ports for control/data has a number of drawbacks: - if firewalls are between the AC and WTP, multiple rules are required - we must be able to explicitly bind the data and control channels at the AC in order to ensure proper operation; if they use the same port (and therefore, flow), this is straightforward; if not, we must add protocol elements for detecting and accounting for NATs along the AC-WTP path, and for explicitly (and securely) creating the bindings between the two channels - there are race conditions that must be dealt with; in particular, it is possible to have the left hand (control channel) not knowing for certain what the right hand (data channel) is doing (and vice versa) - If there *are* NATs along the path, using two ports will require keepalives on both ports, and error handling for when one channel goes away but the other does not (e.g. if a middlebox deletes the NAT bindings for any reason) - there are many more error conditions to manage in the state machine, due to the channel binding and NAT issues Clearly, using two ports adds *significant* complexity to the implementation, and will likely result in operational problems in some environments. Using a mux header has one drawback (that I can think of): - it adds n bytes to the header. I'm tempted to say n will be 4 for 32-bit alignment, but it could also be only 1 or 2 bytes, if bits-on-the-wire overhead is an overriding concern. Using a mux hader has several advantages: - we get NAT traversal for free, by simply configuring the echo interval to be smaller than the NAT binding lifetime for the path in question - we only open one port through intermediate firewalls (and any intermediate NATs) - the implementation (state machine, error handling) is *much* simpler, and therefore more likely to (inter)operate according to spec We need to decide on this, preferably within the next day or two. Please speak up and make your preferences known. 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 Mon May 01 14:47:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FadQx-0006kS-Tk for capwap-archive@lists.ietf.org; Mon, 01 May 2006 14:47:47 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FadQw-0007Bo-D2 for capwap-archive@lists.ietf.org; Mon, 01 May 2006 14:47:47 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0763A4300FC for ; Mon, 1 May 2006 11:47:46 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8454B430054 for ; Mon, 1 May 2006 11:47:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 641F31448021 for ; Mon, 1 May 2006 11:47:22 -0700 (PDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by hermes.tigertech.net (Postfix) with ESMTP id 8F5551448013 for ; Mon, 1 May 2006 11:47:18 -0700 (PDT) Received: from loompa.cs.umd.edu (loompa.cs.umd.edu [128.8.128.63]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id k41IlBlt018340; Mon, 1 May 2006 14:47:15 -0400 (EDT) Date: Mon, 1 May 2006 14:47:11 -0400 (EDT) From: "T. Charles Clancy" To: "Scott G. Kelly" Subject: Re: [Capwap] to mux or not to mux? In-Reply-To: <21852423.1146508699189.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Message-ID: References: <21852423.1146508699189.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 I think another drawback of the MUX header is that stock DTLS implementations will likely already have support for running over plain UDP. Thus any CAPWAP DTLS implementation might be a little less out-of-the-box. Of course, CAPWAP will need to muck with the DTLS state machine on a low level anyway, so it's unlikely any implementation would work out-of-the-box. That being said, I'm personally in favor of the MUX header. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy On Mon, 1 May 2006, Scott G. Kelly wrote: > Some time ago, I proposed that we use a single port for capwap, and > insert a mux header right after the UDP header to differentiate between > control and data. While there was some discussion, we did not reach a > conclusion. > > Here's what it would look like: > > +---------+-------------+------------------------------- > | UDP Hdr | MUX Hdr = 1 | DTLS Enc Control Packet .... > +---------+-------------+---------------------- > > The capwap editors are currently working hard to produce the 01 version > of the capwap document, and it would be best for implementers if this > question could be decided prior to publication of that document. To > facilitate this, I've summarized briefly below. > > Using separate ports for control/data has a number of drawbacks: > > - if firewalls are between the AC and WTP, multiple rules are required > > - we must be able to explicitly bind the data and control channels at > the AC in order to ensure proper operation; if they use the same port > (and therefore, flow), this is straightforward; if not, we must add > protocol elements for detecting and accounting for NATs along the AC-WTP > path, and for explicitly (and securely) creating the bindings between > the two channels > > - there are race conditions that must be dealt with; in particular, it > is possible to have the left hand (control channel) not knowing for > certain what the right hand (data channel) is doing (and vice versa) > > - If there *are* NATs along the path, using two ports will require > keepalives on both ports, and error handling for when one channel goes > away but the other does not (e.g. if a middlebox deletes the NAT > bindings for any reason) > > - there are many more error conditions to manage in the state machine, > due to the channel binding and NAT issues > > Clearly, using two ports adds *significant* complexity to the > implementation, and will likely result in operational problems in some > environments. > > Using a mux header has one drawback (that I can think of): > > - it adds n bytes to the header. I'm tempted to say n will be 4 for > 32-bit alignment, but it could also be only 1 or 2 bytes, if > bits-on-the-wire overhead is an overriding concern. > > Using a mux hader has several advantages: > > - we get NAT traversal for free, by simply configuring the echo interval > to be smaller than the NAT binding lifetime for the path in question > > - we only open one port through intermediate firewalls (and any > intermediate NATs) > > - the implementation (state machine, error handling) is *much* simpler, > and therefore more likely > to (inter)operate according to spec > > We need to decide on this, preferably within the next day or two. Please > speak up and make your preferences known. > > 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 Mon May 01 15:01:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faddn-0007rd-Qr for capwap-archive@lists.ietf.org; Mon, 01 May 2006 15:01:03 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Faddl-0007S6-9u for capwap-archive@lists.ietf.org; Mon, 01 May 2006 15:01:03 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 996C94300F8 for ; Mon, 1 May 2006 12:00:56 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2B2C5430054 for ; Mon, 1 May 2006 12:00:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id F0CA3144803A for ; Mon, 1 May 2006 12:00:28 -0700 (PDT) Received: from smtpauth07.mail.atl.earthlink.net (smtpauth07.mail.atl.earthlink.net [209.86.89.67]) by hermes.tigertech.net (Postfix) with ESMTP id 24D3D144802D for ; Mon, 1 May 2006 12:00:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=YMzL1oGjT3oVN/BYg3YDvvGHylisq9tYuNDMR/tTEz5ncGOo2jC1kfn/7RWeNbgx; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.33] (helo=elwamui-darkeyed.atl.sa.earthlink.net) by smtpauth07.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1Fadcw-0006gv-Bk; Mon, 01 May 2006 15:00:10 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Mon, 1 May 2006 15:00:10 -0400 Message-ID: <15397353.1146510010324.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Date: Mon, 1 May 2006 12:00:10 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "T. Charles Clancy" Subject: Re: [Capwap] to mux or not to mux? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710da50f62082552b2a71d71045fa75836b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e T. Charles Clancy wrote: >I think another drawback of the MUX header is that stock DTLS >implementations will likely already have support for running over plain >UDP. Thus any CAPWAP DTLS implementation might be a little less >out-of-the-box. Of course, CAPWAP will need to muck with the DTLS state >machine on a low level anyway, so it's unlikely any implementation would >work out-of-the-box. > >That being said, I'm personally in favor of the MUX header. Actually, stock DTLS implementations (openssl in particular) can't handle multiple clients on a single socket "connection" without adding some intermediate de-muxing anyway, so as you say, it won't work out-of-the-box regardless. FWIW, I already have mux header code running with openssl. It was pretty straightforward to implement. --Scott >-- >t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > >On Mon, 1 May 2006, Scott G. Kelly wrote: > >> Some time ago, I proposed that we use a single port for capwap, and >> insert a mux header right after the UDP header to differentiate between >> control and data. While there was some discussion, we did not reach a >> conclusion. >> >> Here's what it would look like: >> >> +---------+-------------+------------------------------- >> | UDP Hdr | MUX Hdr = 1 | DTLS Enc Control Packet .... >> +---------+-------------+---------------------- >> >> The capwap editors are currently working hard to produce the 01 version >> of the capwap document, and it would be best for implementers if this >> question could be decided prior to publication of that document. To >> facilitate this, I've summarized briefly below. >> >> Using separate ports for control/data has a number of drawbacks: >> >> - if firewalls are between the AC and WTP, multiple rules are required >> >> - we must be able to explicitly bind the data and control channels at >> the AC in order to ensure proper operation; if they use the same port >> (and therefore, flow), this is straightforward; if not, we must add >> protocol elements for detecting and accounting for NATs along the AC-WTP >> path, and for explicitly (and securely) creating the bindings between >> the two channels >> >> - there are race conditions that must be dealt with; in particular, it >> is possible to have the left hand (control channel) not knowing for >> certain what the right hand (data channel) is doing (and vice versa) >> >> - If there *are* NATs along the path, using two ports will require >> keepalives on both ports, and error handling for when one channel goes >> away but the other does not (e.g. if a middlebox deletes the NAT >> bindings for any reason) >> >> - there are many more error conditions to manage in the state machine, >> due to the channel binding and NAT issues >> >> Clearly, using two ports adds *significant* complexity to the >> implementation, and will likely result in operational problems in some >> environments. >> >> Using a mux header has one drawback (that I can think of): >> >> - it adds n bytes to the header. I'm tempted to say n will be 4 for >> 32-bit alignment, but it could also be only 1 or 2 bytes, if >> bits-on-the-wire overhead is an overriding concern. >> >> Using a mux hader has several advantages: >> >> - we get NAT traversal for free, by simply configuring the echo interval >> to be smaller than the NAT binding lifetime for the path in question >> >> - we only open one port through intermediate firewalls (and any >> intermediate NATs) >> >> - the implementation (state machine, error handling) is *much* simpler, >> and therefore more likely >> to (inter)operate according to spec >> >> We need to decide on this, preferably within the next day or two. Please >> speak up and make your preferences known. >> >> 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 Mon May 01 15:04:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fadh0-0000H0-P7 for capwap-archive@lists.ietf.org; Mon, 01 May 2006 15:04:22 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fadgx-0007Zn-0E for capwap-archive@lists.ietf.org; Mon, 01 May 2006 15:04:22 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 92C64430054 for ; Mon, 1 May 2006 12:04:18 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C79BD430054 for ; Mon, 1 May 2006 12:03:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AB7A21448052 for ; Mon, 1 May 2006 12:03:48 -0700 (PDT) Received: from trpz.com (mail1.trpz.com [66.7.225.38]) by hermes.tigertech.net (Postfix) with ESMTP id A20171448001 for ; Mon, 1 May 2006 12:03:45 -0700 (PDT) Received: from [127.0.0.1] ([192.168.12.194]) by trpz.com (8.13.5/8.11.6) with ESMTP id k41I0pLw019917 for ; Mon, 1 May 2006 11:00:52 -0700 Message-ID: <44565B8E.8010103@trapezenetworks.com> Date: Mon, 01 May 2006 12:03:42 -0700 From: Jim Murphy User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: capwap@frascone.com Subject: Re: [Capwap] BSSID-WLAN mappings References: <17B8C6DE4E228348B4939BDA6B05A9DC0175B515@xmb-sjc-237.amer.cisco.com> In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC0175B515@xmb-sjc-237.amer.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed 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: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d Hi, Hasn't security already been compromised in CAPWAP by the fact that a data frame could be sent to multiple WLANs using the WLAN/Status field of the CAPWAP header? Each of these WLANs could be running a different crypto type. Thanks, Jim Bob O'Hara (boohara) wrote: > As I said, this is a proprietary extension, even if it might have been=20 > provided on some Cisco products. I hold that CAPWAP is chartered to=20 > implement a protocol to support 802.11, not the myriad proprietary=20 > extension that have been hammered onto its side over the years. > =20 > But, the more damning problem for this is the lowering of security and=20 > the violation of the security assumptions on which 802.11i is based. =20 > Crossing the boundary of a security domain, even if "only" for=20 > multicast, dramatically increases the opportunity for compromise of dat= a=20 > that communicants believe is secure. > =20 >=20 > -Bob > =20 >=20 > =20 >=20 > -----------------------------------------------------------------------= - > *From:* Jeff Joslin [mailto:jjoslin@belairnetworks.com] > *Sent:* Friday, April 28, 2006 12:47 PM > *To:* Bob O'Hara (boohara); capwap@frascone.com > *Subject:* RE: [Capwap] BSSID-WLAN mappings >=20 > Indeed, the M-SSID mechanism I described is not in the standard but has= =20 > been implemented by a number of different vendors, including, as I=20 > recall, Cisco Aironet. Now that 802.11 chip sets and drivers have bette= r=20 > support for M-BSSID, there is little reason to use the more problematic= =20 > M-SSID. Its only advantage over M-BSSID is that M-SSID uses up fewer MA= C=20 > addresses. >=20 > =20 >=20 > Jeff >=20 > =20 >=20 > -----------------------------------------------------------------------= - >=20 > *From:* Bob O'Hara (boohara) [mailto:boohara@cisco.com] > *Sent:* 28 April 2006 3:35 PM > *To:* capwap@frascone.com > *Subject:* RE: [Capwap] BSSID-WLAN mappings >=20 > =20 >=20 > The mechanism below is, of course, not compliant with the 802.11=20 > standard. It is a proprietary extension. It is not clear to me why=20 > CAPWAP should support this mechanism, or any other proprietary=20 > mechanism. As Jeff points out below, this is not compatible with all=20 > clients (most likely because the mechanism is not mentioned in the=20 > standard) and also violates the security assumptions of 802.11. >=20 > -Bob > =20 >=20 > =20 >=20 > =20 >=20 > -----------------------------------------------------------------------= - >=20 > *From:* Jeff Joslin [mailto:jjoslin@belairnetworks.com] > *Sent:* Friday, April 28, 2006 12:19 PM > *To:* capwap@frascone.com > *Subject:* RE: [Capwap] BSSID-WLAN mappings >=20 > You can implement multiple SSID with single BSSID by having only one=20 > SSID in the beacon; the others SSIDs are hidden. If a client broadcasts= =20 > a probe for one of those hidden SSIDs the AP will respond and the clien= t=20 > can then do a normal association. The AP maintains one=20 > broadcast/multicast key for each encryption type (WEP, TKIP, AES) and=20 > uses the appropriate one according to the encryption type of the frame=92= s=20 > SSID. This allows a certain amount of information leakage between SSIDs= ,=20 > but in most applications this is acceptable. >=20 > =20 >=20 > The above scheme works, after a fashion, but creates some client=20 > compatibility issues. Multiple BSSID is preferable. >=20 > =20 >=20 > One SSID =3D=3D 1 WLAN. In general we cannot assume that 1 BSSID =3D=3D= 1 WLAN. >=20 > =20 >=20 > Perhaps 1 VLAN =3D=3D 1 WLAN is more helpful? It is standard practice t= o map=20 > each SSID to a separate VLAN. >=20 > =20 >=20 > Jeff Joslin >=20 > Senior Network Architect >=20 > BelAir Networks >=20 > =20 >=20 > -----------------------------------------------------------------------= - >=20 > *From:* Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > *Sent:* 28 April 2006 2:57 PM > *To:* Puneet; Bob O'Hara (boohara) > *Cc:* capwap@frascone.com > *Subject:* RE: [Capwap] BSSID-WLAN mappings >=20 > =20 >=20 > Well, first, there is no way that I am aware of where you can have=20 > multiple SSIDs for a single BSSID. Furthermore, if one were to do this,= =20 > how would you handle broadcast packet encryption, where a station would= =20 > see packets from a BSSID, but would not be able to decrypt it -=20 > presumably because the AC would have multiple GTKs, not indexed on a=20 > BSSID, but some other non-defined mechanism. >=20 > =20 >=20 > I contend 1 BSSID =3D=3D 1 WLAN. >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 > =20 >=20 > =20 >=20 > -------------------------------------------------------------------= ----- >=20 > *From:* Puneet [mailto:pb.ietf@gmail.com] > *Sent:* Monday, April 17, 2006 10:39 AM > *To:* Bob O'Hara (boohara) > *Cc:* capwap@frascone.com > *Subject:* Re: [Capwap] BSSID-WLAN mappings >=20 > Bob, >=20 > > We should not be implementing, or requiring an CAPWAP > implementation to implement a method > > that lowers the security of the WLAN. >=20 > I am not sure I understand the argument here: supporting open or WE= P > also does the same thing, but CAPWAP supports those encryption > protocols. CAPWAP does not force everyone to support WEP, but it > *allows* it to be setup on a WLAN. Along the same lines we should > allow this mapping too. Maybe make a note that it does not allow > WLAN traffic separation into logical groups over the air (Saravanan= s > point) >=20 > Thanks, > Puneet >=20 > On 4/17/06, *Bob O'Hara (boohara)* > wrote: >=20 > There are also security issues when there is not a 1:1 mapping of > WLAN to BSSID. Without this restriction, a station will not have > any assurance that traffic it believes is encrypted and protected > according to the policy of the WLAN to which it is associated is no= t > being decrypted by an oracle (the AP) and rebroadcast to other > stations without the same requirements for abiding with the same > security policies. >=20 > =20 >=20 > We should not be implementing, or requiring an CAPWAP implementatio= n > to implement a method that lowers the security of the WLAN. >=20 > -Bob > =20 >=20 > =20 >=20 > =20 >=20 > -------------------------------------------------------------------= ----- >=20 > *From:* Puneet [mailto: pb.ietf@gmail.com ] >=20 > *Sent:* Sunday, April 16, 2006 4:47 PM > *To:* Saravanan Govindan > *Cc:* capwap@frascone.com > *Subject:* Re: [Capwap] BSSID-WLAN mappings >=20 > Hi Saravanan, >=20 > I see your point, but this seems to address a very specific > deployment scenario (service providers sharing WLAN equipment). If > nothing else in the CAPWAP messages is dependent on this, then this > should be a recommendation instead of a mandate. That way the > protocol remains inclusive, and also meets its objective. >=20 > I think it is very important that existing implementations are not > excluded just because they dont seem to meet one specific need in a > specific deployment scenario. >=20 > Thanks, > Puneet >=20 > On 4/15/06, *Saravanan Govindan* > wrote: >=20 > Hi Puneet, >=20 > My concern regarding the BSSID - WLAN mapping is based on the manda= tory > Objective "Logical Groups" (Section 5.1.1 of CAPWAP Objectives). >=20 > The Objective requires that WTP traffic be kept logically distinct > among > logical groups. This arises from the commercial need of service > providers > sharing WLAN infrastructure equipment. Service providers want their > traffic > to be distinguished both over the wireless environment (e.g. BSSIDS= ) > and > over the AC-WTP environment (e.g. WLANs). >=20 > The BSSID-WLAN mapping issue is the technical requirement coming > from this > commercial need. It allows an AC - or WTP - to decide how logical > groups are > separated over the wireless and AC-WTP segments. So by making this > mapping, > CAPWAP frames of different logical groups (WLANs) can be distinctly > exchanged. >=20 > I agree with others that this mapping should not exclude any > implementation > - my concern is that the mapping be including in the first place. >=20 > Cheers, >=20 > Saravanan >=20 >=20 >=20 >=20 > > ------------------------------ > > *From:* Puneet [mailto:pb.ietf@gmail.com ] > > *Sent:* Friday, April 14, 2006 12:29 AM > > *To:* capwap@frascone.com > > *Subject:* [Capwap] BSSID-WLAN mappings > > > > the BSSID description in Section 11.9.1 'WTP Radio Configuration= ' > notes > > that a WTP that supports 16 WLANS MUST have 16 MAC addresses > reserved for > > it. Why? ie. what part of the protocol does not work if we have > multiple > > SSIDs on a single BSSID? (whether thats good design or bad is a > different > > matter). Since the WLAN ID could be used in all such places to c= onvey > WLAN > > information back to the AC, why do we need to mandate this 1:1 > BSSID-WLAN > > mapping? > > > > Thanks, > > Puneet > > > > ________________________________________________________________= _ > > To unsubscribe or modify your subscription options, please visit= : > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > >=20 > _________________________________________________________________ > Get an advanced look at the new version of MSN Messenger. > http://messenger.msn.com.sg/Beta/Default.aspx > >=20 > =20 >=20 >=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 > >=20 > =20 >=20 >=20 > -----------------------------------------------------------------------= - >=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 _________________________________________________________________ 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 May 01 15:16:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FadsG-0000gN-Qq for capwap-archive@lists.ietf.org; Mon, 01 May 2006 15:16:00 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FadsE-0007sl-Vc for capwap-archive@lists.ietf.org; Mon, 01 May 2006 15:16:00 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 536754300CF for ; Mon, 1 May 2006 12:15:58 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E1B7F43008F for ; Mon, 1 May 2006 12:15:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id ABAD61448052 for ; Mon, 1 May 2006 12:15:16 -0700 (PDT) Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.181]) by hermes.tigertech.net (Postfix) with ESMTP id 70A871448062 for ; Mon, 1 May 2006 12:15:11 -0700 (PDT) Received: by pproxy.gmail.com with SMTP id c39so3200008pyd for ; Mon, 01 May 2006 12:15:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ceCo3j4e3WUZXwAMo0acSWWP5OMQcuKLA5+QVzMkK5kWE7Oxps4/ggw05XAmd4jjrrhGZjtfq9mT4i6pFb8AjakPN+rlj7G0uae/kHpDc4gTRGIy6MHP4mhKnI5OaxJQnjEKM/xk80ok0M5a5EaO25rsXMOAwnGFntUVU6OHJu8= Received: by 10.35.53.18 with SMTP id f18mr1329846pyk; Mon, 01 May 2006 12:15:10 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Mon, 1 May 2006 12:15:10 -0700 (PDT) Message-ID: <26140d940605011215l64ebbf16j95c221770ba84bbc@mail.gmail.com> Date: Mon, 1 May 2006 15:15:10 -0400 From: "Michael Montemurro" To: "Scott G. Kelly" Subject: Re: [Capwap] to mux or not to mux? In-Reply-To: <15397353.1146510010324.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> MIME-Version: 1.0 References: <15397353.1146510010324.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.5 tagged_above=-999.0 required=7.0 tests=HTML_20_30, HTML_MESSAGE, RCVD_BY_IP X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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="===============0322570964==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e --===============0322570964== Content-Type: multipart/alternative; boundary="----=_Part_2994_26247046.1146510910087" ------=_Part_2994_26247046.1146510910087 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Scott, Charles, For the reasons below, I'm in favor of using a MUX header to distinguish control from data traffic versus using separate ports. Cheers, Mike On 5/1/06, Scott G. Kelly wrote: > > T. Charles Clancy wrote: > > >I think another drawback of the MUX header is that stock DTLS > >implementations will likely already have support for running over plain > >UDP. Thus any CAPWAP DTLS implementation might be a little less > >out-of-the-box. Of course, CAPWAP will need to muck with the DTLS state > >machine on a low level anyway, so it's unlikely any implementation would > >work out-of-the-box. > > > >That being said, I'm personally in favor of the MUX header. > > Actually, stock DTLS implementations (openssl in particular) can't handle > multiple clients on a single socket "connection" without adding some > intermediate de-muxing anyway, so as you say, it won't work out-of-the-bo= x > regardless. > > FWIW, I already have mux header code running with openssl. It was pretty > straightforward to implement. > > --Scott > > >-- > >t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > > > > >On Mon, 1 May 2006, Scott G. Kelly wrote: > > > >> Some time ago, I proposed that we use a single port for capwap, and > >> insert a mux header right after the UDP header to differentiate betwee= n > >> control and data. While there was some discussion, we did not reach a > >> conclusion. > >> > >> Here's what it would look like: > >> > >> +---------+-------------+------------------------------- > >> | UDP Hdr | MUX Hdr =3D 1 | DTLS Enc Control Packet .... > >> +---------+-------------+---------------------- > >> > >> The capwap editors are currently working hard to produce the 01 versio= n > >> of the capwap document, and it would be best for implementers if this > >> question could be decided prior to publication of that document. To > >> facilitate this, I've summarized briefly below. > >> > >> Using separate ports for control/data has a number of drawbacks: > >> > >> - if firewalls are between the AC and WTP, multiple rules are required > >> > >> - we must be able to explicitly bind the data and control channels at > >> the AC in order to ensure proper operation; if they use the same port > >> (and therefore, flow), this is straightforward; if not, we must add > >> protocol elements for detecting and accounting for NATs along the > AC-WTP > >> path, and for explicitly (and securely) creating the bindings between > >> the two channels > >> > >> - there are race conditions that must be dealt with; in particular, it > >> is possible to have the left hand (control channel) not knowing for > >> certain what the right hand (data channel) is doing (and vice versa) > >> > >> - If there *are* NATs along the path, using two ports will require > >> keepalives on both ports, and error handling for when one channel goes > >> away but the other does not (e.g. if a middlebox deletes the NAT > >> bindings for any reason) > >> > >> - there are many more error conditions to manage in the state machine, > >> due to the channel binding and NAT issues > >> > >> Clearly, using two ports adds *significant* complexity to the > >> implementation, and will likely result in operational problems in some > >> environments. > >> > >> Using a mux header has one drawback (that I can think of): > >> > >> - it adds n bytes to the header. I'm tempted to say n will be 4 for > >> 32-bit alignment, but it could also be only 1 or 2 bytes, if > >> bits-on-the-wire overhead is an overriding concern. > >> > >> Using a mux hader has several advantages: > >> > >> - we get NAT traversal for free, by simply configuring the echo > interval > >> to be smaller than the NAT binding lifetime for the path in question > >> > >> - we only open one port through intermediate firewalls (and any > >> intermediate NATs) > >> > >> - the implementation (state machine, error handling) is *much* simpler= , > >> and therefore more likely > >> to (inter)operate according to spec > >> > >> We need to decide on this, preferably within the next day or two. > Please > >> speak up and make your preferences known. > >> > >> 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 > ------=_Part_2994_26247046.1146510910087 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Scott, Charles,
 
For the reasons below, I'm in favor of using a MUX header to distingui= sh control from data traffic versus using separate ports.
 
Cheers,
 
          Mike


 
On 5/1/06, S= cott G. Kelly <s.kelly@ix.n= etcom.com> wrote:
T. Charles Clancy wrote:

= >I think another drawback of the MUX header is that stock DTLS
>im= plementations will likely already have support for running over plain
>UDP.  Thus any CAPWAP DTLS implementation might be a litt= le less
>out-of-the-box.  Of course, CAPWAP will need to mu= ck with the DTLS state
>machine on a low level anyway, so it's unlike= ly any implementation would
>work out-of-the-box.
>
>That being said, I'm personally= in favor of the MUX header.

Actually, stock DTLS implementations (o= penssl in particular) can't handle multiple clients on a single socket &quo= t;connection" without adding some intermediate de-muxing anyway, so as= you say, it won't work out-of-the-box regardless.

FWIW, I already have mux header code running with openssl. It was p= retty straightforward to implement.

--Scott

>--
>t. = charles clancy, ph.d.  |  tcc@umd.edu  |   www.cs.umd.edu/~clancy
>= ;
>
>On Mon, 1 May 2006, Scott G. Kelly wrote:
>
>&= gt; Some time ago, I proposed that we use a single port for capwap, and
>> insert a mux header right after the UDP header to differentiate be= tween
>> control and data. While there was some discussion, we did= not reach a
>> conclusion.
>>
>> Here's what it= would look like:
>>
>> +---------+-------------+-------------------------= ------
>> | UDP Hdr | MUX Hdr =3D 1 | DTLS Enc Control Packet ....=
>> +---------+-------------+----------------------
>> >> The capwap editors are currently working hard to produce the 01 ve= rsion
>> of the capwap document, and it would be best for implemen= ters if this
>> question could be decided prior to publication of = that document. To
>> facilitate this, I've summarized briefly below.
>>>> Using separate ports for control/data has a number of drawbacks:<= br>>>
>> - if firewalls are between the AC and WTP, multiple= rules are required
>>
>> - we must be able to explicitly bind the data and = control channels at
>> the AC in order to ensure proper operation;= if they use the same port
>> (and therefore, flow), this is strai= ghtforward; if not, we must add
>> protocol elements for detecting and accounting for NATs along = the AC-WTP
>> path, and for explicitly (and securely) creating the= bindings between
>> the two channels
>>
>> - th= ere are race conditions that must be dealt with; in particular, it
>> is possible to have the left hand (control channel) not knowin= g for
>> certain what the right hand (data channel) is doing (and = vice versa)
>>
>> - If there *are* NATs along the path, u= sing two ports will require
>> keepalives on both ports, and error handling for when one chan= nel goes
>> away but the other does not (e.g. if a middlebox delet= es the NAT
>> bindings for any reason)
>>
>> - t= here are many more error conditions to manage in the state machine,
>> due to the channel binding and NAT issues
>>
>&= gt; Clearly, using two ports adds *significant* complexity to the
>&g= t; implementation, and will likely result in operational problems in some
>> environments.
>>
>> Using a mux header has o= ne drawback (that I can think of):
>>
>> - it adds n byte= s to the header. I'm tempted to say n will be 4 for
>> 32-bit alig= nment, but it could also be only 1 or 2 bytes, if
>> bits-on-the-wire overhead is an overriding concern.
>>= ;
>> Using a mux hader has several advantages:
>>
>= > - we get NAT traversal for free, by simply configuring the echo interv= al
>> to be smaller than the NAT binding lifetime for the path in qu= estion
>>
>> - we only open one port through intermediate= firewalls (and any
>> intermediate NATs)
>>
>> = - the implementation (state machine, error handling) is *much* simpler,
>> and therefore more likely
>>  to (inter)ope= rate according to spec
>>
>> We need to decide on this, p= referably within the next day or two. Please
>> speak up and make = your preferences known.
>>
>> Thanks,
>>
>> Scott
>><= br>>> _______________________________________________________________= __
>> To unsubscribe or modify your subscription options, please v= isit:
>> = http://lists.frascone.com/mailman/listinfo/capwap
>>
>&g= t; Archives: http://= lists.frascone.com/pipermail/capwap
>>

___________________________________________________= ______________
To unsubscribe or modify your subscription options, pleas= e visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.co= m/pipermail/capwap

------=_Part_2994_26247046.1146510910087-- --===============0322570964== 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 --===============0322570964==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon May 01 15:22:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fadyd-00028u-Th for capwap-archive@lists.ietf.org; Mon, 01 May 2006 15:22:35 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fadyc-0008Gi-2O for capwap-archive@lists.ietf.org; Mon, 01 May 2006 15:22:35 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A2851430111 for ; Mon, 1 May 2006 12:22:33 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 130FA430054 for ; Mon, 1 May 2006 12:22:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id F1F86144805C for ; Mon, 1 May 2006 12:22:00 -0700 (PDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by hermes.tigertech.net (Postfix) with ESMTP id 921B9144805D for ; Mon, 1 May 2006 12:21:58 -0700 (PDT) Received: from loompa.cs.umd.edu (loompa.cs.umd.edu [128.8.128.63]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id k41JLnlt019306; Mon, 1 May 2006 15:21:53 -0400 (EDT) Date: Mon, 1 May 2006 15:21:49 -0400 (EDT) From: "T. Charles Clancy" To: Jim Murphy Subject: Re: [Capwap] BSSID-WLAN mappings In-Reply-To: <44565B8E.8010103@trapezenetworks.com> Message-ID: References: <17B8C6DE4E228348B4939BDA6B05A9DC0175B515@xmb-sjc-237.amer.cisco.com> <44565B8E.8010103@trapezenetworks.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-824023566-1146511309=:13960" 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 X-Spam-Level: Cc: capwap@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-824023566-1146511309=:13960 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Sort of... As I understand the conversation, in the M-SSID case, you could send an=20 encrypted broadcast packet to other people on your WLAN. This packet=20 would be encrypted with a key that other users on other WLANs could know.= =20 For example, someone on WLAN-B could see NETBIOS broadcast packets from=20 devices associated to WLAN-A. They might even think they could=20 communicate with said NETBIOS machines, but unicast packets addressed to=20 them would fail (hopefully, assuming the WTP is properly implemented). Jim's scenario below is somewhat different, where you have someone on the= =20 wired side sending data that CAPWAP intentionally decides should be=20 transmitted to multiple WLANs. The concern here is more along the lines=20 of a chosen ciphertext attack that could leak information about keys by=20 seeing packets encrypted multiple times with different keys. Provided=20 people are using good crypto (i.e. not WEP), this shouldn't be a problem. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy On Mon, 1 May 2006, Jim Murphy wrote: > Hi, > > Hasn't security already been compromised in CAPWAP by the fact that > a data frame could be sent to multiple WLANs using the WLAN/Status field > of the CAPWAP header? Each of these WLANs could be running a different > crypto type. > > Thanks, > > Jim > > Bob O'Hara (boohara) wrote: >> As I said, this is a proprietary extension, even if it might have been= =20 >> provided on some Cisco products. I hold that CAPWAP is chartered to=20 >> implement a protocol to support 802.11, not the myriad proprietary=20 >> extension that have been hammered onto its side over the years. >> But, the more damning problem for this is the lowering of security and = the=20 >> violation of the security assumptions on which 802.11i is based. Crossi= ng=20 >> the boundary of a security domain, even if "only" for multicast,=20 >> dramatically increases the opportunity for compromise of data that=20 >> communicants believe is secure. >>=20 >> -Bob >>=20 >>=20 >> ------------------------------------------------------------------------ >> *From:* Jeff Joslin [mailto:jjoslin@belairnetworks.com] >> *Sent:* Friday, April 28, 2006 12:47 PM >> *To:* Bob O'Hara (boohara); capwap@frascone.com >> *Subject:* RE: [Capwap] BSSID-WLAN mappings >>=20 >> Indeed, the M-SSID mechanism I described is not in the standard but has= =20 >> been implemented by a number of different vendors, including, as I recal= l,=20 >> Cisco Aironet. Now that 802.11 chip sets and drivers have better support= =20 >> for M-BSSID, there is little reason to use the more problematic M-SSID. = Its=20 >> only advantage over M-BSSID is that M-SSID uses up fewer MAC addresses. >>=20 >>=20 >> Jeff >>=20 >>=20 >> ------------------------------------------------------------------------ >>=20 >> *From:* Bob O'Hara (boohara) [mailto:boohara@cisco.com] >> *Sent:* 28 April 2006 3:35 PM >> *To:* capwap@frascone.com >> *Subject:* RE: [Capwap] BSSID-WLAN mappings >>=20 >>=20 >> The mechanism below is, of course, not compliant with the 802.11 standar= d.=20 >> It is a proprietary extension. It is not clear to me why CAPWAP should= =20 >> support this mechanism, or any other proprietary mechanism. As Jeff poi= nts=20 >> out below, this is not compatible with all clients (most likely because = the=20 >> mechanism is not mentioned in the standard) and also violates the securi= ty=20 >> assumptions of 802.11. >>=20 >> -Bob >>=20 >>=20 >>=20 >> ------------------------------------------------------------------------ >>=20 >> *From:* Jeff Joslin [mailto:jjoslin@belairnetworks.com] >> *Sent:* Friday, April 28, 2006 12:19 PM >> *To:* capwap@frascone.com >> *Subject:* RE: [Capwap] BSSID-WLAN mappings >>=20 >> You can implement multiple SSID with single BSSID by having only one SSI= D=20 >> in the beacon; the others SSIDs are hidden. If a client broadcasts a pro= be=20 >> for one of those hidden SSIDs the AP will respond and the client can the= n=20 >> do a normal association. The AP maintains one broadcast/multicast key fo= r=20 >> each encryption type (WEP, TKIP, AES) and uses the appropriate one=20 >> according to the encryption type of the frame=92s SSID. This allows a ce= rtain=20 >> amount of information leakage between SSIDs, but in most applications th= is=20 >> is acceptable. >>=20 >>=20 >> The above scheme works, after a fashion, but creates some client=20 >> compatibility issues. Multiple BSSID is preferable. >>=20 >>=20 >> One SSID =3D=3D 1 WLAN. In general we cannot assume that 1 BSSID =3D=3D = 1 WLAN. >>=20 >>=20 >> Perhaps 1 VLAN =3D=3D 1 WLAN is more helpful? It is standard practice to= map=20 >> each SSID to a separate VLAN. >>=20 >>=20 >> Jeff Joslin >>=20 >> Senior Network Architect >>=20 >> BelAir Networks >>=20 >>=20 >> ------------------------------------------------------------------------ >>=20 >> *From:* Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] >> *Sent:* 28 April 2006 2:57 PM >> *To:* Puneet; Bob O'Hara (boohara) >> *Cc:* capwap@frascone.com >> *Subject:* RE: [Capwap] BSSID-WLAN mappings >>=20 >>=20 >> Well, first, there is no way that I am aware of where you can have multi= ple=20 >> SSIDs for a single BSSID. Furthermore, if one were to do this, how would= =20 >> you handle broadcast packet encryption, where a station would see packet= s=20 >> from a BSSID, but would not be able to decrypt it - presumably because t= he=20 >> AC would have multiple GTKs, not indexed on a BSSID, but some other=20 >> non-defined mechanism. >>=20 >>=20 >> I contend 1 BSSID =3D=3D 1 WLAN. >>=20 >> Pat Calhoun >> CTO, Wireless Networking Business Unit >> Cisco Systems >>=20 >>=20 >>=20 >> --------------------------------------------------------------------= ---- >>=20 >> *From:* Puneet [mailto:pb.ietf@gmail.com] >> *Sent:* Monday, April 17, 2006 10:39 AM >> *To:* Bob O'Hara (boohara) >> *Cc:* capwap@frascone.com >> *Subject:* Re: [Capwap] BSSID-WLAN mappings >>=20 >> Bob, >>=20 >> > We should not be implementing, or requiring an CAPWAP >> implementation to implement a method >> > that lowers the security of the WLAN. >>=20 >> I am not sure I understand the argument here: supporting open or WEP >> also does the same thing, but CAPWAP supports those encryption >> protocols. CAPWAP does not force everyone to support WEP, but it >> *allows* it to be setup on a WLAN. Along the same lines we should >> allow this mapping too. Maybe make a note that it does not allow >> WLAN traffic separation into logical groups over the air (Saravanans >> point) >>=20 >> Thanks, >> Puneet >>=20 >> On 4/17/06, *Bob O'Hara (boohara)* > > wrote: >>=20 >> There are also security issues when there is not a 1:1 mapping of >> WLAN to BSSID. Without this restriction, a station will not have >> any assurance that traffic it believes is encrypted and protected >> according to the policy of the WLAN to which it is associated is not >> being decrypted by an oracle (the AP) and rebroadcast to other >> stations without the same requirements for abiding with the same >> security policies. >>=20 >>=20 >> We should not be implementing, or requiring an CAPWAP implementation >> to implement a method that lowers the security of the WLAN. >>=20 >> -Bob >>=20 >>=20 >>=20 >> --------------------------------------------------------------------= ---- >>=20 >> *From:* Puneet [mailto: pb.ietf@gmail.com = ] >>=20 >> *Sent:* Sunday, April 16, 2006 4:47 PM >> *To:* Saravanan Govindan >> *Cc:* capwap@frascone.com >> *Subject:* Re: [Capwap] BSSID-WLAN mappings >>=20 >> Hi Saravanan, >>=20 >> I see your point, but this seems to address a very specific >> deployment scenario (service providers sharing WLAN equipment). If >> nothing else in the CAPWAP messages is dependent on this, then this >> should be a recommendation instead of a mandate. That way the >> protocol remains inclusive, and also meets its objective. >>=20 >> I think it is very important that existing implementations are not >> excluded just because they dont seem to meet one specific need in a >> specific deployment scenario. >>=20 >> Thanks, >> Puneet >>=20 >> On 4/15/06, *Saravanan Govindan* > > wrote: >>=20 >> Hi Puneet, >>=20 >> My concern regarding the BSSID - WLAN mapping is based on the mandat= ory >> Objective "Logical Groups" (Section 5.1.1 of CAPWAP Objectives). >>=20 >> The Objective requires that WTP traffic be kept logically distinct >> among >> logical groups. This arises from the commercial need of service >> providers >> sharing WLAN infrastructure equipment. Service providers want their >> traffic >> to be distinguished both over the wireless environment (e.g. BSSIDS) >> and >> over the AC-WTP environment (e.g. WLANs). >>=20 >> The BSSID-WLAN mapping issue is the technical requirement coming >> from this >> commercial need. It allows an AC - or WTP - to decide how logical >> groups are >> separated over the wireless and AC-WTP segments. So by making this >> mapping, >> CAPWAP frames of different logical groups (WLANs) can be distinctly >> exchanged. >>=20 >> I agree with others that this mapping should not exclude any >> implementation >> - my concern is that the mapping be including in the first place. >>=20 >> Cheers, >>=20 >> Saravanan >>=20 >>=20 >>=20 >>=20 >> > ------------------------------ >> > *From:* Puneet [mailto:pb.ietf@gmail.com ] >> > *Sent:* Friday, April 14, 2006 12:29 AM >> > *To:* capwap@frascone.com >> > *Subject:* [Capwap] BSSID-WLAN mappings >> > >> > the BSSID description in Section 11.9.1 'WTP Radio Configuration' >> notes >> > that a WTP that supports 16 WLANS MUST have 16 MAC addresses >> reserved for >> > it. Why? ie. what part of the protocol does not work if we have >> multiple >> > SSIDs on a single BSSID? (whether thats good design or bad is a >> different >> > matter). Since the WLAN ID could be used in all such places to=20 >> convey >> WLAN >> > information back to the AC, why do we need to mandate this 1:1 >> BSSID-WLAN >> > mapping? >> > >> > Thanks, >> > Puneet >> > >> > _________________________________________________________________ >> > To unsubscribe or modify your subscription options, please visit: >> > http://lists.frascone.com/mailman/listinfo/capwap >> >> > >> > Archives: http://lists.frascone.com/pipermail/capwap >> > >>=20 >> _________________________________________________________________ >> Get an advanced look at the new version of MSN Messenger. >> http://messenger.msn.com.sg/Beta/Default.aspx >> >>=20 >>=20 >>=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 >> >>=20 >>=20 >>=20 >> ------------------------------------------------------------------------ >>=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 > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ---559023410-824023566-1146511309=:13960 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 ---559023410-824023566-1146511309=:13960-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon May 01 17:47:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagEU-0008JV-KH for capwap-archive@lists.ietf.org; Mon, 01 May 2006 17:47:06 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FagES-0006YR-Sa for capwap-archive@lists.ietf.org; Mon, 01 May 2006 17:47:06 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D49A4430111 for ; Mon, 1 May 2006 14:46:59 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id BBB98430054 for ; Mon, 1 May 2006 14:46:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id AAE72398038 for ; Mon, 1 May 2006 14:46:34 -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 C71A439802A for ; Mon, 1 May 2006 14:46:31 -0700 (PDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 01 May 2006 14:46:32 -0700 X-IronPort-AV: i="4.05,77,1146466800"; d="scan'208"; a="1800329747:sNHT39669080" 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 k41LkVVI001808 for ; Mon, 1 May 2006 14:46: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); Mon, 1 May 2006 14:46:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 May 2006 14:46:30 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D24893@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 53: Add Data Rate to LWAPP Header Thread-Index: AcZtaLSr+DdqAHyvQbiP1CrPNj3XrA== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 01 May 2006 21:46:31.0036 (UTC) FILETIME=[B52E13C0:01C66D68] 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: Subject: [Capwap] Issue 53: Add Data Rate to LWAPP Header X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 All, The following is a proposed new CAPWAP header format, as a result of discussions on the list. Comments are most welcomed. 4.1. CAPWAP Transport Header =20 All CAPWAP protocol messages are encapsulated using a common header format, regardless of the CAPWAP control or CAPWAP Data transport used to carry the messages. However, certain flags are not applicable for a given transport. Refer to the specific transport section in order to determine which flags are valid. =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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VERSION| RID | HLEN |W|F|L|M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment ID | Frag Offset |Rsv-2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Radio MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Wireless Specific Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 4.1.1. VERSION Field =20 A 4 bit field which contains the version of CAPWAP used in this packet. The value for this draft is 0. =20 4.1.2. RID Field =20 A 5 bit field which contains the Radio ID number for this packet. WTPs with multiple radios but a single MAC Address use this field to indicate which radio is associated with the packet. =20 4.1.3. HLEN Length of CAPWAP tunnel header in 4 byte words. (Similar to IP header length). This length includes the optional headers. 4.1.4. W Bit =20 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 header is present. 4.1.5. F Bit =20 The Fragment 'F' bit indicates whether this packet is a fragment. When this bit is one (1), the packet is a fragment and MUST be combined with the other corresponding fragments to reassemble the complete information exchanged between the WTP and AC. =20 4.1.6. L Bit =20 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. 4.1.7. M Bit =20 The M bit is used to indicate that the Radio MAC Address optional header is present. This is used to communicate the MAC address of=20 the receiving radio when the native wireless packet. This field=20 MUST NOT be set to one in packets sent by the AC to the WTP. 4.1.8. Reserved =20 The 15-bit Reserved field is reserved and set to 0 in this version of the=20 CAPWAP protocol. =20 4.1.9. Fragment ID =20 An 16 bit 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 Fragment ID wraps to zero after the maximum value has been used to identify a set of fragments. =20 =20 4.1.10. Fragment Offset =20 A 13 bit field that indicates where in the payload will this fragment belong during re-assembly. This field is valid when the 'F' bit is set to 1. The=20 fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero.=20 =20 4.1.11. Reserved-2 =20 The 3-bit Reserved-2 field is reserved and set to 0 in this version of the=20 CAPWAP protocol. 4.1.12. Radio MAC Address This optional field contains the MAC address of the radio receiving the packet. This is useful 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. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | MAC Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: The number of bytes in the MAC Address field. The length field is present since new IEEE technologies are using 48 byte MAC addresses MAC Address: MAC Address of the receiving radio =20 4.1.13. 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. 4.1.14. Payload =20 This field contains the header for a CAPWAP Data Message or CAPWAP Control Message, followed by the data associated with that message. [...] 11.3.2. CAPWAP Wireless Specific Information The reserved CAPWAP header field (see figure Section 4.1) is only used with CAPWAP data frames, and it serves two purposes, depending upon the direction of the frame. For packets from the WTP to the AC, the field uses the format described in Section 11.3.2.1. However, for frames sent by the AC to the WTP, the format used is described in described in Section 11.3.2.2. 11.3.2.1. IEEE 802.11 Frame Info When an CAPWAP data frame is received from a station over the air, it is encapsulated and this field is used to include radio and PHY specific information associated with the frame. When used with the IEEE 802.11 binding, the field follows 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSSI | SNR | Data Rate |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 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 =20 =20 [Rest is identical to -00] 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 May 01 18:04:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagVG-0006t2-Q0 for capwap-archive@lists.ietf.org; Mon, 01 May 2006 18:04:26 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FagVE-0007Yo-9V for capwap-archive@lists.ietf.org; Mon, 01 May 2006 18:04:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 35F834300E8 for ; Mon, 1 May 2006 15:04:20 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 2292E430054 for ; Mon, 1 May 2006 15:03:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id DFA83398027 for ; Mon, 1 May 2006 15:03:35 -0700 (PDT) Received: from stlssgcorpmailfw2.anheuser-busch.com (stlssgcorpmailfw2.anheuser-busch.com [151.145.63.132]) by zoidberg.tigertech.net (Postfix) with ESMTP id 856FA398029 for ; Mon, 1 May 2006 15:03:30 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--344510-7129147-1017340393=:3379" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: Re: [Capwap] to mux or not to mux? Date: Mon, 1 May 2006 17:03:22 -0500 Message-ID: <89525CB1203D7346BBBDFCE9CECB47CF020FB41C@STLEXGUSR31.abc.corp.anheuser-busch.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] to mux or not to mux? Thread-Index: AcZtaNt3iEUueiXjQ9KSlq0iCxYmswAAY6wg From: "Kraus, Michael" To: X-OriginalArrivalTime: 01 May 2006 22:03:21.0957 (UTC) FILETIME=[0FBC6150:01C66D6B] X-MessageInspectorSig: a7fd8fad1f30c5d3867c652dde3ea600 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 8db6b1eef878f11b7d6324adee263d0c ----344510-7129147-1017340393=:3379 content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Firewalling between LAN segments (rather than just at the perimeter) does = seem to be becoming the trend. So, I too would prefer the same port number, and = utilizing a MUX header to classify control/data. 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 ---------------------------------------------------------------------- Message: 1 Date: Mon, 1 May 2006 15:15:10 -0400 From: =22Michael Montemurro=22 Subject: Re: =5BCapwap=5D to mux or not to mux? To: =22Scott G. Kelly=22 Cc: capwap Message-ID: <26140d940605011215l64ebbf16j95c221770ba84bbc=40mail.gmail.com> Content-Type: text/plain; charset=3D=22iso-8859-1=22 Scott, Charles, For the reasons below, I'm in favor of using a MUX header to distinguish con= trol from data traffic versus using separate ports. Cheers, Mike On 5/1/06, Scott G. Kelly wrote: > > T. Charles Clancy wrote: > > >I think another drawback of the MUX header is that stock DTLS > >implementations will likely already have support for running over > >plain UDP. Thus any CAPWAP DTLS implementation might be a little > >less out-of-the-box. Of course, CAPWAP will need to muck with the > >DTLS state machine on a low level anyway, so it's unlikely any > >implementation would work out-of-the-box. > > > >That being said, I'm personally in favor of the MUX header. > > Actually, stock DTLS implementations (openssl in particular) can't > handle multiple clients on a single socket =22connection=22 without adding= > some intermediate de-muxing anyway, so as you say, it won't work > out-of-the-box regardless. > > FWIW, I already have mux header code running with openssl. It was > pretty straightforward to implement. > > --Scott > > >-- > >t. charles clancy, ph.d. =7C tcc=40umd.edu =7C www.cs.umd.edu/=7Eclan= cy > > > > > >On Mon, 1 May 2006, Scott G. Kelly wrote: > > > >> Some time ago, I proposed that we use a single port for capwap, and > >> insert a mux header right after the UDP header to differentiate > >> between control and data. While there was some discussion, we did > >> not reach a conclusion. > >> > >> Here's what it would look like: > >> > >> +---------+-------------+------------------------------- > >> =7C UDP Hdr =7C MUX Hdr =3D 1 =7C DTLS Enc Control Packet .... > >> +---------+-------------+---------------------- > >> > >> The capwap editors are currently working hard to produce the 01 > >> version of the capwap document, and it would be best for > >> implementers if this question could be decided prior to publication > >> of that document. To facilitate this, I've summarized briefly below. > >> > >> Using separate ports for control/data has a number of drawbacks: > >> > >> - if firewalls are between the AC and WTP, multiple rules are > >> required > >> > >> - we must be able to explicitly bind the data and control channels > >> at the AC in order to ensure proper operation; if they use the same > >> port (and therefore, flow), this is straightforward; if not, we > >> must add protocol elements for detecting and accounting for NATs > >> along the > AC-WTP > >> path, and for explicitly (and securely) creating the bindings > >> between the two channels > >> > >> - there are race conditions that must be dealt with; in particular, > >> it is possible to have the left hand (control channel) not knowing > >> for certain what the right hand (data channel) is doing (and vice > >> versa) > >> > >> - If there *are* NATs along the path, using two ports will require > >> keepalives on both ports, and error handling for when one channel > >> goes away but the other does not (e.g. if a middlebox deletes the > >> NAT bindings for any reason) > >> > >> - there are many more error conditions to manage in the state > >> machine, due to the channel binding and NAT issues > >> > >> Clearly, using two ports adds *significant* complexity to the > >> implementation, and will likely result in operational problems in > >> some environments. > >> > >> Using a mux header has one drawback (that I can think of): > >> > >> - it adds n bytes to the header. I'm tempted to say n will be 4 for > >> 32-bit alignment, but it could also be only 1 or 2 bytes, if > >> bits-on-the-wire overhead is an overriding concern. > >> > >> Using a mux hader has several advantages: > >> > >> - we get NAT traversal for free, by simply configuring the echo > interval > >> to be smaller than the NAT binding lifetime for the path in > >> question > >> > >> - we only open one port through intermediate firewalls (and any > >> intermediate NATs) > >> > >> - the implementation (state machine, error handling) is *much* > >> simpler, and therefore more likely to (inter)operate according to > >> spec > >> > >> We need to decide on this, preferably within the next day or two. > Please > >> speak up and make your preferences known. > >> > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.tigertech.net/pipermail/capwap/attachments/20060501/d0ed34f0/at= tach ment.htm ------------------------------ Message: 2 Date: Mon, 1 May 2006 15:21:49 -0400 (EDT) From: =22T. Charles Clancy=22 Subject: Re: =5BCapwap=5D BSSID-WLAN mappings To: Jim Murphy Cc: capwap=40frascone.com Message-ID: Content-Type: text/plain; charset=3D=22windows-1252=22 Sort of... As I understand the conversation, in the M-SSID case, you could send an encrypted broadcast packet to other people on your WLAN. This packet would = be encrypted with a key that other users on other WLANs could know. For example, someone on WLAN-B could see NETBIOS broadcast packets from devi= ces associated to WLAN-A. They might even think they could communicate with sai= d NETBIOS machines, but unicast packets addressed to them would fail (hopefull= y, assuming the WTP is properly implemented). Jim's scenario below is somewhat different, where you have someone on the wi= red side sending data that CAPWAP intentionally decides should be transmitted to= multiple WLANs. The concern here is more along the lines of a chosen cipher= text attack that could leak information about keys by seeing packets encrypted multiple times with different keys. Provided people are using good crypto (= i.e. not WEP), this shouldn't be a problem. -- t. charles clancy, ph.d. =7C tcc=40umd.edu =7C www.cs.umd.edu/=7Eclancy = On Mon, 1 May 2006, Jim Murphy wrote: > Hi, > > Hasn't security already been compromised in CAPWAP by the fact that a > data frame could be sent to multiple WLANs using the WLAN/Status field > of the CAPWAP header? Each of these WLANs could be running a different > crypto type. > > Thanks, > > Jim > > Bob O'Hara (boohara) wrote: >> As I said, this is a proprietary extension, even if it might have >> been provided on some Cisco products. I hold that CAPWAP is >> chartered to implement a protocol to support 802.11, not the myriad >> proprietary extension that have been hammered onto its side over the year= s. >> But, the more damning problem for this is the lowering of security >> and the violation of the security assumptions on which 802.11i is >> based. Crossing the boundary of a security domain, even if =22only=22 >> for multicast, dramatically increases the opportunity for compromise >> of data that communicants believe is secure. >> >> -Bob >> >> >> --------------------------------------------------------------------- >> --- >> *From:* Jeff Joslin =5Bmailto:jjoslin=40belairnetworks.com=5D >> *Sent:* Friday, April 28, 2006 12:47 PM >> *To:* Bob O'Hara (boohara); capwap=40frascone.com >> *Subject:* RE: =5BCapwap=5D BSSID-WLAN mappings >> >> Indeed, the M-SSID mechanism I described is not in the standard but >> has been implemented by a number of different vendors, including, as >> I recall, Cisco Aironet. Now that 802.11 chip sets and drivers have >> better support for M-BSSID, there is little reason to use the more >> problematic M-SSID. Its only advantage over M-BSSID is that M-SSID uses u= p fewer MAC addresses. >> >> >> Jeff >> >> >> --------------------------------------------------------------------- >> --- >> >> *From:* Bob O'Hara (boohara) =5Bmailto:boohara=40cisco.com=5D >> *Sent:* 28 April 2006 3:35 PM >> *To:* capwap=40frascone.com >> *Subject:* RE: =5BCapwap=5D BSSID-WLAN mappings >> >> >> The mechanism below is, of course, not compliant with the 802.11 standard= . >> It is a proprietary extension. It is not clear to me why CAPWAP >> should support this mechanism, or any other proprietary mechanism. >> As Jeff points out below, this is not compatible with all clients >> (most likely because the mechanism is not mentioned in the standard) >> and also violates the security assumptions of 802.11. >> >> -Bob >> >> >> >> --------------------------------------------------------------------- >> --- >> >> *From:* Jeff Joslin =5Bmailto:jjoslin=40belairnetworks.com=5D >> *Sent:* Friday, April 28, 2006 12:19 PM >> *To:* capwap=40frascone.com >> *Subject:* RE: =5BCapwap=5D BSSID-WLAN mappings >> >> You can implement multiple SSID with single BSSID by having only one >> SSID in the beacon; the others SSIDs are hidden. If a client >> broadcasts a probe for one of those hidden SSIDs the AP will respond >> and the client can then do a normal association. The AP maintains one >> broadcast/multicast key for each encryption type (WEP, TKIP, AES) and >> uses the appropriate one according to the encryption type of the >> frame's SSID. This allows a certain amount of information leakage >> between SSIDs, but in most applications this is acceptable. >> >> >> The above scheme works, after a fashion, but creates some client >> compatibility issues. Multiple BSSID is preferable. >> >> >> One SSID =3D=3D 1 WLAN. In general we cannot assume that 1 BSSID =3D=3D 1= WLAN. >> >> >> Perhaps 1 VLAN =3D=3D 1 WLAN is more helpful? It is standard practice to = >> map each SSID to a separate VLAN. >> >> >> Jeff Joslin >> >> Senior Network Architect >> >> BelAir Networks >> >> >> --------------------------------------------------------------------- >> --- >> >> *From:* Pat Calhoun (pacalhou) =5Bmailto:pcalhoun=40cisco.com=5D >> *Sent:* 28 April 2006 2:57 PM >> *To:* Puneet; Bob O'Hara (boohara) >> *Cc:* capwap=40frascone.com >> *Subject:* RE: =5BCapwap=5D BSSID-WLAN mappings >> >> >> Well, first, there is no way that I am aware of where you can have >> multiple SSIDs for a single BSSID. Furthermore, if one were to do >> this, how would you handle broadcast packet encryption, where a >> station would see packets from a BSSID, but would not be able to >> decrypt it - presumably because the AC would have multiple GTKs, not >> indexed on a BSSID, but some other non-defined mechanism. >> >> >> I contend 1 BSSID =3D=3D 1 WLAN. >> >> Pat Calhoun >> CTO, Wireless Networking Business Unit Cisco Systems >> >> >> >> >> --------------------------------------------------------------------- >> --- >> >> *From:* Puneet =5Bmailto:pb.ietf=40gmail.com=5D >> *Sent:* Monday, April 17, 2006 10:39 AM >> *To:* Bob O'Hara (boohara) >> *Cc:* capwap=40frascone.com >> *Subject:* Re: =5BCapwap=5D BSSID-WLAN mappings >> >> Bob, >> >> > We should not be implementing, or requiring an CAPWAP >> implementation to implement a method >> > that lowers the security of the WLAN. >> >> I am not sure I understand the argument here: supporting open or WEP = >> also does the same thing, but CAPWAP supports those encryption >> protocols. CAPWAP does not force everyone to support WEP, but it >> *allows* it to be setup on a WLAN. Along the same lines we should >> allow this mapping too. Maybe make a note that it does not allow >> WLAN traffic separation into logical groups over the air (Saravanans = >> point) >> >> Thanks, >> Puneet >> >> On 4/17/06, *Bob O'Hara (boohara)* > > wrote: >> >> There are also security issues when there is not a 1:1 mapping of >> WLAN to BSSID. Without this restriction, a station will not have >> any assurance that traffic it believes is encrypted and protected >> according to the policy of the WLAN to which it is associated is not = >> being decrypted by an oracle (the AP) and rebroadcast to other >> stations without the same requirements for abiding with the same >> security policies. >> >> >> We should not be implementing, or requiring an CAPWAP implementation = >> to implement a method that lowers the security of the WLAN. >> >> -Bob >> >> >> >> >> --------------------------------------------------------------------- >> --- >> >> *From:* Puneet =5Bmailto: pb.ietf=40gmail.com >> =5D >> >> *Sent:* Sunday, April 16, 2006 4:47 PM >> *To:* Saravanan Govindan >> *Cc:* capwap=40frascone.com >> *Subject:* Re: =5BCapwap=5D BSSID-WLAN mappings >> >> Hi Saravanan, >> >> I see your point, but this seems to address a very specific >> deployment scenario (service providers sharing WLAN equipment). If >> nothing else in the CAPWAP messages is dependent on this, then this >> should be a recommendation instead of a mandate. That way the >> protocol remains inclusive, and also meets its objective. >> >> I think it is very important that existing implementations are not >> excluded just because they dont seem to meet one specific need in a >> specific deployment scenario. >> >> Thanks, >> Puneet >> >> On 4/15/06, *Saravanan Govindan* > > wrote: >> >> Hi Puneet, >> >> My concern regarding the BSSID - WLAN mapping is based on the mandato= ry >> Objective =22Logical Groups=22 (Section 5.1.1 of CAPWAP Objectives). = >> >> The Objective requires that WTP traffic be kept logically distinct >> among >> logical groups. This arises from the commercial need of service >> providers >> sharing WLAN infrastructure equipment. Service providers want their >> traffic >> to be distinguished both over the wireless environment (e.g. BSSIDS) = >> and >> over the AC-WTP environment (e.g. WLANs). >> >> The BSSID-WLAN mapping issue is the technical requirement coming >> from this >> commercial need. It allows an AC - or WTP - to decide how logical >> groups are >> separated over the wireless and AC-WTP segments. So by making this >> mapping, >> CAPWAP frames of different logical groups (WLANs) can be distinctly >> exchanged. >> >> I agree with others that this mapping should not exclude any >> implementation >> - my concern is that the mapping be including in the first place. >> >> Cheers, >> >> Saravanan >> >> >> >> >> > ------------------------------ >> > *From:* Puneet =5Bmailto:pb.ietf=40gmail.com =5D >> > *Sent:* Friday, April 14, 2006 12:29 AM >> > *To:* capwap=40frascone.com >> > *Subject:* =5BCapwap=5D BSSID-WLAN mappings >> > >> > the BSSID description in Section 11.9.1 'WTP Radio Configuration' = >> notes >> > that a WTP that supports 16 WLANS MUST have 16 MAC addresses >> reserved for >> > it. Why? ie. what part of the protocol does not work if we have >> multiple >> > SSIDs on a single BSSID? (whether thats good design or bad is a >> different >> > matter). Since the WLAN ID could be used in all such places to >> convey >> WLAN >> > information back to the AC, why do we need to mandate this 1:1 >> BSSID-WLAN >> > mapping? >> > >> > Thanks, >> > Puneet >> > >> > _________________________________________________________________ = >> > To unsubscribe or modify your subscription options, please visit: = >> > http://lists.frascone.com/mailman/listinfo/capwap >> >> > >> > Archives: http://lists.frascone.com/pipermail/capwap >> > >> >> _________________________________________________________________ >> Get an advanced look at the new version of MSN Messenger. >> http://messenger.msn.com.sg/Beta/Default.aspx >> >> >> >> >> _________________________________________________________________ >> 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 > ------------------------------ Message: 3 Date: Mon, 1 May 2006 14:46:30 -0700 From: =22Pat Calhoun (pacalhou)=22 Subject: =5BCapwap=5D Issue 53: Add Data Rate to LWAPP Header To: =22capwap=22 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D24893=40xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset=3D=22us-ascii=22 All, The following is a proposed new CAPWAP header format, as a result of discuss= ions on the list. Comments are most welcomed. 4.1. CAPWAP Transport Header All CAPWAP protocol messages are encapsulated using a common header format, regardless of the CAPWAP control or CAPWAP Data transport used to carry the messages. However, certain flags are not applicable for a given transport. Refer to the specific transport section in order to determine which flags are valid. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =7CVERSION=7C RID =7C HLEN =7CW=7CF=7CL=7CM=7C Reserved = =7C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =7C Fragment ID =7C Frag Offset =7CRsv-2= =7C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =7C (optional) Radio MAC Address =7C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =7C (optional) Wireless Specific Information =7C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =7C Payload .... =7C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.1. VERSION Field A 4 bit field which contains the version of CAPWAP used in this packet. The value for this draft is 0. 4.1.2. RID Field A 5 bit field which contains the Radio ID number for this packet. WTPs with multiple radios but a single MAC Address use this field to indicate which radio is associated with the packet. 4.1.3. HLEN Length of CAPWAP tunnel header in 4 byte words. (Similar to IP header length). This length includes the optional headers. 4.1.4. W Bit 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 header is present. 4.1.5. F Bit The Fragment 'F' bit indicates whether this packet is a fragment. When this bit is one (1), the packet is a fragment and MUST be combined with the other corresponding fragments to reassemble the complete information exchanged between the WTP and AC. 4.1.6. L Bit 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. 4.1.7. M Bit The M bit is used to indicate that the Radio MAC Address optional header is present. This is used to communicate the MAC address of the receiving radio when the native wireless packet. This field MUST NOT be set to one in packets sent by the AC to the WTP. 4.1.8. Reserved The 15-bit Reserved field is reserved and set to 0 in this version of the= CAPWAP protocol. 4.1.9. Fragment ID An 16 bit 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 Fragment ID wraps to zero after the maximum value has been used to identify a set of fragments. 4.1.10. Fragment Offset A 13 bit field that indicates where in the payload will this fragment bel= ong 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. 4.1.11. Reserved-2 The 3-bit Reserved-2 field is reserved and set to 0 in this version of th= e CAPWAP protocol. 4.1.12. Radio MAC Address This optional field contains the MAC address of the radio receiving the packet. This is useful 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. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =7C Length =7C MAC Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: The number of bytes in the MAC Address field. The length field is present since new IEEE technologies are using 48 byte MAC addresses= MAC Address: MAC Address of the receiving radio 4.1.13. Wireless Specific Information This optional field contains technology specific information that may be used to carry per packet wireless information. This field is only pres= ent 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =7C Wireless ID =7C Length =7C 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. 4.1.14. Payload This field contains the header for a CAPWAP Data Message or CAPWAP Control Message, followed by the data associated with that message. =5B...=5D 11.3.2. CAPWAP Wireless Specific Information The reserved CAPWAP header field (see figure Section 4.1) is only used with CAPWAP data frames, and it serves two purposes, depending upon the direction of the frame. For packets from the WTP to the AC, the field uses the format described in Section 11.3.2.1. However, for frames sent by the AC to the WTP, the format used is described in described in Section 11.3.2.2. 11.3.2.1. IEEE 802.11 Frame Info When an CAPWAP data frame is received from a station over the air, it is encapsulated and this field is used to include radio and PHY specific information associated with the frame. When used with the IEEE 802.11 binding, the field follows 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =7C RSSI =7C SNR =7C Data Rate = =7C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 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 =5BRest is identical to -00=5D 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 End of Capwap Digest, Vol 7, Issue 3 ************************************ ----344510-7129147-1017340393=:3379 Content-Type: text/plain Content-Disposition: inline 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. ----344510-7129147-1017340393=:3379 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 ----344510-7129147-1017340393=:3379-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon May 01 18:27:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fagrq-0006UR-Pa for capwap-archive@lists.ietf.org; Mon, 01 May 2006 18:27:46 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fagrp-00088K-DK for capwap-archive@lists.ietf.org; Mon, 01 May 2006 18:27:46 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C8326430103 for ; Mon, 1 May 2006 15:27:44 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 94AE143006D for ; Mon, 1 May 2006 15:27:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 84AC839802D for ; Mon, 1 May 2006 15:27:25 -0700 (PDT) Received: from trpz.com (mail1.trpz.com [66.7.225.38]) by zoidberg.tigertech.net (Postfix) with ESMTP id D99B239802A for ; Mon, 1 May 2006 15:27:20 -0700 (PDT) Received: from [127.0.0.1] ([192.168.12.194]) by trpz.com (8.13.5/8.11.6) with ESMTP id k41LOR61024731 for ; Mon, 1 May 2006 14:24:27 -0700 Message-ID: <44568B44.80302@trapezenetworks.com> Date: Mon, 01 May 2006 15:27:16 -0700 From: Jim Murphy User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: capwap Subject: Re: [Capwap] Issue 50: Increase maximum number of BSSs References: <4FF84B0BC277FF45AA27FE969DD956A201CBAA7E@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201CBAA7E@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 It seems that the limit of 16 BSSIDs is primarily motivated by this WLAN/Status field in the data header. Perhaps the WLAN/Status field should be a broadcast domain identifier (a .1q tag or VLANID). WTPs should then be told of the VLANID to BSSID/broadcast-key mapping via control plane messages and replicate packets accordingly. If a VLANID is used in place of this bitmap, the protocol will scale better. With the current proposal, I am concerned about WTPs that have many radios or offer multiple VLANs per BSSID. Thanks, Jim Pat Calhoun (pacalhou) wrote: > > I would recommend that we reject this issue. 16 BSSIDs is a large > number, and the overhead in generating 16 or more beacons outweighs the > usefullness in advertising that many networks. > > 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 May 02 02:05:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fao0x-0003k8-8O for capwap-archive@lists.ietf.org; Tue, 02 May 2006 02:05:39 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fansj-0000Tx-97 for capwap-archive@lists.ietf.org; Tue, 02 May 2006 01:57:10 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DFBAE43016A for ; Mon, 1 May 2006 22:57:08 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3CFBC43006D for ; Mon, 1 May 2006 22:55:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2D6AD144800C for ; Mon, 1 May 2006 22:55:49 -0700 (PDT) Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by hermes.tigertech.net (Postfix) with ESMTP id 96519144801E for ; Mon, 1 May 2006 22:55:45 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 01 May 2006 22:55:44 -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 k425tiRT004325 for ; Mon, 1 May 2006 22: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); Mon, 1 May 2006 22:55:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 May 2006 22:55:44 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D249BE@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 61: Change WLAN->BSSID Mapping Thread-Index: AcZtlSKlTpvg2NHqSXm/OWjSZW3e2Q== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 02 May 2006 05:55:44.0424 (UTC) FILETIME=[0D29A280:01C66DAD] 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 X-Spam-Level: Subject: [Capwap] Issue 61: Change WLAN->BSSID Mapping X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 This is the fix to allow the WTP to tell the AC what BSSID it is using for a given WLAN. Let me know if you are OK with this text before I sent it to the list - with the understanding that we have very little time left :( 11.4. BSSID to WLAN ID Mapping The CAPWAP protocol allows the WTP to assign BSSIDs upon creation of a WLAN (see Section Section 11.8.1.1). While manufacturers are free to assign BSSIDs using any arbitrary mechanism, it is advised that where possible the BSSIDs are assigned as a contiguous block. When assigned as a block, implementations can still assign any of the available BSSIDs to any WLAN. One possible method is for the WTP to assign the address using the following algorithm: base BSSID address + WLAN ID. For instance, if a WTP had a base BSSID address of 00:01:02:00:00:00, and the AC sent an Add WLAN message with a WLAN Identifier of 2 (see Section Section 11.8.1.1), the BSSID for the specific WLAN on the WTP would be 00:01:02:00:00:02. The WTP communicates the maximum number of BSSIDs that it supports during the Config Request within the IEEE 802.11 WTP WLAN Radio Configuration message element (see Section 11.9.1). [...] 11.8.2. IEEE 802.11 WLAN Config Response [...] 11.8.2.1. IEEE 802.11 Assigned WTP BSSID The IEEE 802.11 Assigned WTP BSSID is only included by the WTP when the IEEE 802.11 WLAN Config Request included the IEEE 802.11 Add WLAN message element. The value field of this message element contains the BSSID that has been assigned by the WTP, which allows the WTP to perform its own BSSID assignment. The WTP is free to assign the BSSIDs the way it sees fit, but it is highly recommended that the WTP assign the BSSID using the following algorithm: BSSID =3D {base BSSID} + WLAN 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSSID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSSID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD for IEEE 802.11 Assigned WTP BSSID Length: 6 BSSID: The BSSID assigned by the WTP for the WLAN created as a result of receiving an IEEE 802.11 Add WLAN. =20 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 May 02 02:06:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fao11-0003k8-V0 for capwap-archive@lists.ietf.org; Tue, 02 May 2006 02:05:43 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fanru-0000TI-ON for capwap-archive@lists.ietf.org; Tue, 02 May 2006 01:56:21 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2B32143010D for ; Mon, 1 May 2006 22:56:18 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3770243006D for ; Mon, 1 May 2006 22:55:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2797D1448027 for ; Mon, 1 May 2006 22:55:47 -0700 (PDT) Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by hermes.tigertech.net (Postfix) with ESMTP id 24874144800C for ; Mon, 1 May 2006 22:55:43 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-3.cisco.com with ESMTP; 01 May 2006 22:55:43 -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 k425thh0003250 for ; Mon, 1 May 2006 22:55:43 -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, 1 May 2006 22:55:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Capwap] Issues 101: 11.8.1.1 Change to re-use 802.11 Date: Mon, 1 May 2006 22:55:43 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D249BD@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issues 101: 11.8.1.1 Change to re-use 802.11 Thread-Index: AcZtlOw7y3kQxfK3SSGiJfxsywEJHg== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 02 May 2006 05:55:43.0381 (UTC) FILETIME=[0C8A7C50:01C66DAD] 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 X-Spam-Level: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd All, I've been thinking about my earlier proposed change for issue 101 and would like to change the new Information Element data structure to include flags. See below. 11.8.1.4. IEEE 802.11 Information Element The IEEE 802.11 Information Element is used to communicate any IE defined in the IEEE 802.11 protocol. The data field contains the raw IE as it would be included within an IEEE 802.11 MAC management message. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |B|P| Flags | Info Element +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: TBD for IEEE 802.11 Information Element Length: >=3D 2 B: When set, the WTP is to include the information element in beacons associated with the WLAN. P: When set, the WTP is to include the information element in probe responses associated with the WLAN. Flags: Reserved field and MUST be set to zero. Info Element: The IEEE 802.11 Information Element, which includes the type, length and value field. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Friday, April 28, 2006 11:49 AM > To: Puneet; capwap@frascone.com > Subject: [Capwap] Issues 101: 11.8.1.1 Change to re-use > 802.11 Informationelement definitions >=20 > I believe there are many issues in issue 101, some of which were=20 > introduced by Dorothy. I believe that my proposal > (below) covers all sections. Comments most welcomed! >=20 > 1. does the encryption policy refer to broadcast traffic or unicast=20 > too? If its also unicast, then there could be multiple encryption=20 > types enabled at the same type on the WLAN, in that case how is the=20 > encryption-policy field filled in? >=20 > > This is a good question as the text is obviously not clear enough. I=20 > am proposing the following text (as well as for the Update WLAN=20 > section): >=20 > Encryption Policy: A 32-bit value specifying the encryption scheme > to apply to traffic to and from the mobile station. The > applicability of the encryption policy depends upon the security > policy. For static WEP keys, which is true when the 'Shared=20 > Key' > bit is set, this encryption policy is relevant for both unicast > and multicast traffic. For encryption schemes that employ a > separate encryption key for unicast and multicast traffic, the > encryption policy defined here only applies to multicast data. =20 > In > these scenarios, the unicast encryption policy is communicated=20 > via > the Add Mobile (Section 9.1.1). > [...] > Shared Key: A 1 byte boolean that specifies whether the key=20 > included > in the Key field is a shared WEP key. When set to one, the WLAN > employs a shared WEP key, also known as a static WEP key, and=20 > uses > the encryption key for both unicast and multicast traffic for=20 > all > stations. A value of zero, with the 'Encryption Policy' field=20 > set > to any value other than 'Clear Text' means that the WLAN uses=20 > per- > station encryption keys, and therefore the key in the 'Key'=20 > field > is only used for multicast traffic. > > =09 > 2. for the encryption policies we could use the format used in the=20 > RSN IEs (OUI + encryption_type); that allows support for different=20 > vendor specific encryption types in a clean manner (CKIP for example=20 > would then use the Cisco OUI, instead of being clubbed together with=20 > the other 'standard' > encryption types; and it makes it easier for vendors to not step on=20 > each others toes). >=20 > > Based on Dorothy's e-mail and recommendation, I would propose the=20 > following new section: >=20 > 11.8.1.4. IEEE 802.11 Information Element >=20 > The IEEE 802.11 Information Element is used to communicate any IE > defined in the IEEE 802.11 protocol. The data field contains the=20 > raw > IE as it would be included within an IEEE 802.11 MAC management > message. >=20 > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+- > | Info Element > +-+-+-+-+-+-+-+- >=20 > Type: TBD for IEEE 802.11 Information Element >=20 > Length: >=3D 1 >=20 > Info Element: The IEEE 802.11 Information Element, which includes > the type, length and value field. >=20 > However, I do not believe that everything can be moved out at this=20 > point. So I would propose changing the Add WLAN to be the following: >=20 > 11.8.1.1. IEEE 802.11 Add WLAN >=20 > The Add WLAN message element is used by the AC to define a wireless > LAN on the WTP. The inclusion of this message element MUST also > include the IEEE 802.11 Information Element message element, > containing the following 802.11 IEs: > Capability > WPA IE > RSN IE > EDCA Parameter Set IE > QoS Capability IE > WMM IE >=20 > The value contains the following format: >=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 > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Radio ID | WLAN ID | Reserved =20 > | > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Encryption Policy =20 > | > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Key =20 > | > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Key =20 > | > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Key =20 > | > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Key =20 > | > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Key =20 > | > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Key =20 > | > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Key =20 > | > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Key =20 > | > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Key Index | Shared Key | QoS | =20 > Auth Type | > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MAC Mode | Tunnel Mode | Suppress SSID | SSID ... > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =09 >=20 > 3. why are the lengths of the IEs (WPA, RSN etc) fixed at 32 bytes?=20 > If each of those IEs is preceded by an element that specifies their=20 > lengths, then the IEs could be made variable length. >=20 > Thanks, that has been fixed > =09 > 4. Does the 'Suppress SSID' field also disable the use of that SSID=20 > in broadcast probe responses? If so, why do we also need the 'IEEE > 802.11 Broadcast Probe Mode' in section 11.9.12? Also, why is this IE=20 > global for the WTP? The AC might configure the WTP with 10 WLANs, but=20 > it may want probe responses generated for only four of those when a=20 > broadcast probe request comes in. >=20 > Section 11.9.12 deals with the changing of the mode of operation > after the WLAN is already operational. > =09 > 5. maybe rename WME to WMM?=20 >=20 > No longer relevant > =09 > 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 May 02 02:06:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fao0w-0003k8-7m for capwap-archive@lists.ietf.org; Tue, 02 May 2006 02:05:38 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FantB-0000Vc-C5 for capwap-archive@lists.ietf.org; Tue, 02 May 2006 01:57:38 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0635243016A for ; Mon, 1 May 2006 22:57:37 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9217A430075 for ; Mon, 1 May 2006 22:55:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id ACB18144800C for ; Mon, 1 May 2006 22:55:50 -0700 (PDT) Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by hermes.tigertech.net (Postfix) with ESMTP id BCD311448021 for ; Mon, 1 May 2006 22:55:46 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-3.cisco.com with ESMTP; 01 May 2006 22:55:46 -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 k425tkw1006237 for ; Mon, 1 May 2006 22:55: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); Mon, 1 May 2006 22:55:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 May 2006 22:55:46 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D249BF@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 40: Adapt firmware trigger state machine to allow transition from Run state Thread-Index: AcZtlWrnOXjNlCZeToee8ZjXOG6ndA== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 02 May 2006 05:55:46.0272 (UTC) FILETIME=[0E439E00:01C66DAD] 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 X-Spam-Level: Subject: [Capwap] Issue 40: Adapt firmware trigger state machine to allow transition from Run state X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 All, Here is my proposed fix for issue 40. The request was to allow for the firmware download to be able to be triggered not only at boot time, but at any time while in the Run state. The remaining issue is that the new DTLS state machine no longer includes a change I had made to support this mode of operation, so I will readd this once the DTLS state machine has stabilized. 8.1. Image Data Request The Image Data Request message is used to update firmware on the WTP. This message and its companion response message are used by the AC to ensure that the image being run on each WTP is appropriate. Image Data Request messages are exchanged between the WTP and the AC to download a new firmware image to the WTP. When a WTP or AC receives an Image Data Request message it will respond with an Image Data Response message. The message elements contained within the Image Data Request is required in order to determine the intent of the request. Note that only one message element may be present in any given Image Data Request message. The decision that new firmware is to downloaded to the WTP can occur in one of two methods: When the WTP joins the AC, and each exchange their software revision, the WTP may opt to initiate a firmware download by sending an Image Data Request, which contains an Image Filename message element. Once the WTP is in the CAPWAP state, it is possible for the AC to cause the WTP to initiate a firmware download by initiating an Image Data Request, with the Initiate Download message element. The WTP would then transmit the Image Filename message element to start the download process. Regardless of how the download was initiated, once the AC receives an Image Data Request with the Image Filename message element, it begins the transfer process by transmitting its own request with the Image Data message element. This continues until the whole firmware image has been transfered. The format of the message elements used with the Image Data Request are described in the following subsections. 8.1.1. Initiate Download The Initiate Download message element is used by the AC to inform the WTP that it should initiate a firmware upgrade. This is performed by having the WTP initiate its own Image Data Request, with the Image Download message element. This message element does not contain any Calhoun, Editor, et al. Expires August 5, 2006 [Page 61] =0C Internet-Draft CAPWAP Protocol Specification February 2006 data. Type: TBD for Initiate Download Length: 0 8.1.2. Image Filename The image filename message element is sent by the WTP to the AC and is used to initiate the firmware download process. This message element contains the image filename, which the AC subsequently transfers to the WTP via the Image Data message element. The value is a variable length byte string, which is NOT zero terminated. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Filename ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 32 for Image Filename Length: >=3D 1 Filename: A variable length string containing the filename to download. 8.1.3. Image Data The image data message element is present in the Image Data Request message sent by the AC and 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opcode | Checksum | Image Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Image Data ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 33 for Image Data Length: >=3D 4 (allows 0 length element if last data unit is 1024 bytes) Opcode: An 8-bit value representing the transfer opcode. The following values are supported: 3 - Image data is included 5 - An error occurred. Transfer is aborted Checksum: A 16-bit value containing a checksum of the image data that follows Image Data: The Image Data field contains 1024 characters, unless the payload being sent is the last one (end of file). If the last block was 1024 in length, an Image Data with a zero length payload is sent.=20 =20 =20 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 May 02 02:09:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fao4G-0005E2-Nx for capwap-archive@lists.ietf.org; Tue, 02 May 2006 02:09:04 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fao4F-00012O-AC for capwap-archive@lists.ietf.org; Tue, 02 May 2006 02:09:04 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id F0B20430141 for ; Mon, 1 May 2006 23:09:02 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7F50243006D for ; Mon, 1 May 2006 23:08:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6AA82398033 for ; Mon, 1 May 2006 23:08:43 -0700 (PDT) Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by zoidberg.tigertech.net (Postfix) with ESMTP id A6B45398029 for ; Mon, 1 May 2006 23:08:39 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 01 May 2006 23:08:39 -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 k4268dRT010625 for ; Mon, 1 May 2006 23:08:39 -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, 1 May 2006 23:08:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Issue 61: Change WLAN->BSSID Mapping Date: Mon, 1 May 2006 23:08:37 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D249CD@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 61: Change WLAN->BSSID Mapping Thread-Index: AcZtlSKlTpvg2NHqSXm/OWjSZW3e2QAGaMag From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , "capwap" X-OriginalArrivalTime: 02 May 2006 06:08:39.0153 (UTC) FILETIME=[DAEFE610:01C66DAE] 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: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Oops - I cut and paste from an e-mail to the other co-authors. Ignore my comment on sending to the list as I obviously already did :( Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Pat Calhoun (pacalhou)=20 > Sent: Monday, May 01, 2006 10:56 PM > To: capwap > Subject: [Capwap] Issue 61: Change WLAN->BSSID Mapping=20 >=20 > This is the fix to allow the WTP to tell the AC what BSSID it=20 > is using for a given WLAN. Let me know if you are OK with=20 > this text before I sent it to the list - with the=20 > understanding that we have very little time left :( >=20 _________________________________________________________________ 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 May 02 02:25:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaoK7-0000Et-5X for capwap-archive@lists.ietf.org; Tue, 02 May 2006 02:25:27 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaoK5-0001Lq-KF for capwap-archive@lists.ietf.org; Tue, 02 May 2006 02:25:27 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id F27A0430106 for ; Mon, 1 May 2006 23:25:24 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id F1D6343006D for ; Mon, 1 May 2006 23:24:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D9AF0144801E for ; Mon, 1 May 2006 23:24:57 -0700 (PDT) Received: from test-iport-2.cisco.com (test-iport-2.cisco.com [171.71.176.105]) by hermes.tigertech.net (Postfix) with ESMTP id 1B1F3144800C for ; Mon, 1 May 2006 23:24:53 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-2.cisco.com with ESMTP; 01 May 2006 23:24:53 -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 k426Orh0021435; Mon, 1 May 2006 23:24:53 -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); Mon, 1 May 2006 23:24:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] to mux or not to mux? Date: Mon, 1 May 2006 23:24:51 -0700 Message-ID: <08A9A3213527A6428774900A80DBD8D801DD1785@xmb-sjc-222.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] to mux or not to mux? Thread-Index: AcZtTn8PUwreYWAKR6eonIBaPB6VHgAYbOPQ From: "Nancy Winget (ncamwing)" To: "Scott G. Kelly" , "capwap" X-OriginalArrivalTime: 02 May 2006 06:24:53.0645 (UTC) FILETIME=[1FC793D0:01C66DB1] 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 X-Spam-Level: Cc: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 I don't believe adding a MUX is the right answer. First, the addition is a change in DTLS and also brings up other issues of concern: - distinguishing the control from data plane is a good thing as the firewall rules may be different for each plane which is already addressed by the UDP assignments.=20 - merging the control and data plane into a single UDP (dtls) tunnel forces the two planes to be synchronized from an anti-replay perspective. This effectively restricts the architecture to force them to use a centralized DTLS encapsulation/decapsulation which imho is too restrictive Nancy. -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com]=20 Sent: Monday, May 01, 2006 11:38 AM To: capwap Subject: [Capwap] to mux or not to mux? Some time ago, I proposed that we use a single port for capwap, and insert a mux header right after the UDP header to differentiate between control and data. While there was some discussion, we did not reach a conclusion. Here's what it would look like: +---------+-------------+------------------------------- | UDP Hdr | MUX Hdr =3D 1 | DTLS Enc Control Packet .... +---------+-------------+---------------------- The capwap editors are currently working hard to produce the 01 version of the capwap document, and it would be best for implementers if this question could be decided prior to publication of that document. To facilitate this, I've summarized briefly below. Using separate ports for control/data has a number of drawbacks: - if firewalls are between the AC and WTP, multiple rules are required - we must be able to explicitly bind the data and control channels at the AC in order to ensure proper operation; if they use the same port (and therefore, flow), this is straightforward; if not, we must add protocol elements for detecting and accounting for NATs along the AC-WTP path, and for explicitly (and securely) creating the bindings between the two channels - there are race conditions that must be dealt with; in particular, it is possible to have the left hand (control channel) not knowing for certain what the right hand (data channel) is doing (and vice versa) - If there *are* NATs along the path, using two ports will require keepalives on both ports, and error handling for when one channel goes away but the other does not (e.g. if a middlebox deletes the NAT bindings for any reason)=20 - there are many more error conditions to manage in the state machine, due to the channel binding and NAT issues Clearly, using two ports adds *significant* complexity to the implementation, and will likely result in operational problems in some environments. Using a mux header has one drawback (that I can think of): - it adds n bytes to the header. I'm tempted to say n will be 4 for 32-bit alignment, but it could also be only 1 or 2 bytes, if bits-on-the-wire overhead is an overriding concern. Using a mux hader has several advantages: - we get NAT traversal for free, by simply configuring the echo interval to be smaller than the NAT binding lifetime for the path in question - we only open one port through intermediate firewalls (and any intermediate NATs) - the implementation (state machine, error handling) is *much* simpler, and therefore more likely to (inter)operate according to spec We need to decide on this, preferably within the next day or two. Please speak up and make your preferences known. 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 May 02 02:31:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaoPi-0004gt-Uk for capwap-archive@lists.ietf.org; Tue, 02 May 2006 02:31:14 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaoPh-00022q-HR for capwap-archive@lists.ietf.org; Tue, 02 May 2006 02:31:14 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3178443019B for ; Mon, 1 May 2006 23:31:13 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8098943006D for ; Mon, 1 May 2006 23:30:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 68ACF1448028 for ; Mon, 1 May 2006 23:30:53 -0700 (PDT) X-Greylist-Status: Sender first seen 3 mons 7 days 14:43:07 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 A5E83144801E for ; Mon, 1 May 2006 23:30:50 -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 k426UJkq024172 for ; Tue, 2 May 2006 02:30:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 May 2006 00:30:49 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF Meeting Survey Thread-Index: AcZtM1kBiskMgMjySnqbgF8SNJnVowAflBPQ 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=X_PRIORITY_HIGH X-Spam-Level: Subject: [Capwap] FW: IETF Meeting Survey X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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: 8b30eb7682a596edff707698f4a80f7d Please do provide your feedback; even those who did not attend the sessions (but were on audios-streaming, eg) - there are a few questions and feedback points of relevance. -mani -----Original Message----- From: Ray Pelletier [mailto:rpelletier@isoc.org]=20 Sent: Monday, May 01, 2006 8:25 AM To: wgchairs@ietf.org Subject: IETF Meeting Survey All; It has been suggested that if I really wanted to get feedback on the=20 Meeting Survey (and I do) I should have it forwarded by the WG Chairs=20 to the working groups - so this is a request that you ask members of the working groups to complete a short survey that focuses primarily, but=20 not exclusively, on their meeting experience in Dallas.=20 I truly want the info to make the changes members of the community want, if possible and greatly appreciate your assistance in this regard. Those interested in taking the survey can find it at: http://www.surveymonkey.com/s.asp?u=3D649182049947 Thanks Ray Pelletier IETF Admininstrative 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 Tue May 02 10:04:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FavUh-0006FQ-Bd for capwap-archive@lists.ietf.org; Tue, 02 May 2006 10:04:51 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FavUf-0005ER-Rb for capwap-archive@lists.ietf.org; Tue, 02 May 2006 10:04:51 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id F1E70430105 for ; Tue, 2 May 2006 07:04:46 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 25192430097 for ; Tue, 2 May 2006 07:04:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0C7A1430D34 for ; Tue, 2 May 2006 07:04:24 -0700 (PDT) Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [204.127.192.84]) by hermes.tigertech.net (Postfix) with ESMTP id 50B51430D47 for ; Tue, 2 May 2006 07:04:20 -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 <20060502140419m1400rthnee>; Tue, 2 May 2006 14:04:19 +0000 Message-ID: <445766E2.704@hyperthought.com> Date: Tue, 02 May 2006 07:04:18 -0700 From: Scott G Kelly User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Nancy Winget (ncamwing)" Subject: Re: [Capwap] to mux or not to mux? References: <08A9A3213527A6428774900A80DBD8D801DD1785@xmb-sjc-222.amer.cisco.com> In-Reply-To: <08A9A3213527A6428774900A80DBD8D801DD1785@xmb-sjc-222.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Hi Nancy, Nancy Winget (ncamwing) wrote: > I don't believe adding a MUX is the right answer. First, the addition > is a change in DTLS and also brings up other issues of concern: No, this is a misconception: it is *not* a change to DTLS. It is a change to the openssl implementation of DTLS, but the fact is that you must demultiplex incoming DTLS messages prior to handing them to openssl in any event. I've said this several times before, but it must not have been clear, so let me try to get everyone to focus on this statement: You *cannot* use the stock openssl implementation without modification if you intend to support more than one WTP. You MUST modify it. This is NOT a modification of the DTLS spec, it's a modification of the OPENSSL IMPLEMENTATION. I hope that is clear. This modification is required because openssl was implemented with certain assumptions about "servers" that really depend on the tcp (connection-oriented) sockets abstraction, and these assumptions were naively carried forward into the (datagram) DTLS implementation. I have already corrected this in my implementation (and there's at least 2 ways to do it without even touching the openssl code), and it introduces absolutely no security-relevant concerns. Nothing is being changed in DTLS. Full stop. > - distinguishing the control from data plane is a good thing as the > firewall rules may be different for each plane which is already > addressed by the UDP assignments. Please explain why firewalls (which ostensibly won't understand encapsulated 802.11 traffic) need separate packet filtering rules for a data plane that is tightly bound to the associated control channel. > - merging the control and data plane into a single UDP (dtls) tunnel > forces the two planes to be synchronized from an anti-replay > perspective. Huh? Please explain this statement, as I must be missing something. LWAPP does this today, and has for, what, over 3 years now? I don't believe this has ever been a problem for LWAPP, but even if it were, it would not be for capwap. This is because the proposed mux header is outside of the capwap transport layer, and so capwap will not be aware of it. It will not interact with antireplay in specification-compliant implementation. > This effectively restricts the architecture to force them > to use a centralized DTLS encapsulation/decapsulation which imho is too > restrictive DTLS en/decapsulation is completely independent of the MUX header, so this statement makes no sense to me. Am I missing something? Scott > > Nancy. > > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > Sent: Monday, May 01, 2006 11:38 AM > To: capwap > Subject: [Capwap] to mux or not to mux? > > Some time ago, I proposed that we use a single port for capwap, and > insert a mux header right after the UDP header to differentiate between > control and data. While there was some discussion, we did not reach a > conclusion. > > Here's what it would look like: > > +---------+-------------+------------------------------- > | UDP Hdr | MUX Hdr = 1 | DTLS Enc Control Packet .... > +---------+-------------+---------------------- > > The capwap editors are currently working hard to produce the 01 version > of the capwap document, and it would be best for implementers if this > question could be decided prior to publication of that document. To > facilitate this, I've summarized briefly below. > > Using separate ports for control/data has a number of drawbacks: > > - if firewalls are between the AC and WTP, multiple rules are required > > - we must be able to explicitly bind the data and control channels at > the AC in order to ensure proper operation; if they use the same port > (and therefore, flow), this is straightforward; if not, we must add > protocol elements for detecting and accounting for NATs along the AC-WTP > path, and for explicitly (and securely) creating the bindings between > the two channels > > - there are race conditions that must be dealt with; in particular, it > is possible to have the left hand (control channel) not knowing for > certain what the right hand (data channel) is doing (and vice versa) > > - If there *are* NATs along the path, using two ports will require > keepalives on both ports, and error handling for when one channel goes > away but the other does not (e.g. if a middlebox deletes the NAT > bindings for any reason) > > - there are many more error conditions to manage in the state machine, > due to the channel binding and NAT issues > > Clearly, using two ports adds *significant* complexity to the > implementation, and will likely result in operational problems in some > environments. > > Using a mux header has one drawback (that I can think of): > > - it adds n bytes to the header. I'm tempted to say n will be 4 for > 32-bit alignment, but it could also be only 1 or 2 bytes, if > bits-on-the-wire overhead is an overriding concern. > > Using a mux hader has several advantages: > > - we get NAT traversal for free, by simply configuring the echo interval > to be smaller than the NAT binding lifetime for the path in question > > - we only open one port through intermediate firewalls (and any > intermediate NATs) > > - the implementation (state machine, error handling) is *much* simpler, > and therefore more likely > to (inter)operate according to spec > > We need to decide on this, preferably within the next day or two. Please > speak up and make your preferences known. > > 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 May 02 14:15:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FazOz-0001gn-LS for capwap-archive@lists.ietf.org; Tue, 02 May 2006 14:15:13 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FazOw-0007rr-KD for capwap-archive@lists.ietf.org; Tue, 02 May 2006 14:15:13 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 11984430122 for ; Tue, 2 May 2006 11:15:05 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C4D2E430097 for ; Tue, 2 May 2006 11:14:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D6D971448037 for ; Tue, 2 May 2006 11:14:11 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.193]) by hermes.tigertech.net (Postfix) with ESMTP id F13931448022 for ; Tue, 2 May 2006 11:14:05 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so1894007wxd for ; Tue, 02 May 2006 11:14:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=rAJ5uskNXUIHtmdVOzSnT6P6ybu8bdJIcydffmN2a/AvCkpmJFG6VTtXduJDeH+myVX1OT6cyhVM+rAsuOgi9ZGEk8AqxwE9Zsudz/Cfo7UKI+xssEEu7H/J/Di9jE1NeeYcBL2R4mpMVEzTP4h+tSv4lMU91vKMKzoH2pV/G48= Received: by 10.70.52.12 with SMTP id z12mr1258381wxz; Tue, 02 May 2006 11:14:04 -0700 (PDT) Received: by 10.70.6.8 with HTTP; Tue, 2 May 2006 11:14:04 -0700 (PDT) Message-ID: <5bfe7a820605021114w6dbf53d0w24d6b52eb60a35fb@mail.gmail.com> Date: Tue, 2 May 2006 11:14:04 -0700 From: "Dorothy Stanley" To: "Pat Calhoun (pacalhou)" Subject: Re: [Capwap] Issues 101: 11.8.1.1 Change to re-use 802.11 In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201D249BD@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A201D249BD@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.7 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_50_60, HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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="===============0707842252==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.7 (/) X-Scan-Signature: 5df1f98f3253c63b673ea560243aa58f --===============0707842252== Content-Type: multipart/alternative; boundary="----=_Part_8576_23906140.1146593644950" ------=_Part_8576_23906140.1146593644950 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Pat, . The inclusion of this message element MUST also > include the IEEE 802.11 Information Element message element, > containing the following 802.11 IEs: > Capability > WPA IE > RSN IE > EDCA Parameter Set IE > QoS Capability IE > WMM IE - should this be MUST also include IEEE 802.11 Information Element message elements, containing... Otherwise, looks good. Dorothy On 5/1/06, Pat Calhoun (pacalhou) wrote: > > All, > > I've been thinking about my earlier proposed change for issue 101 and > would like to change the new Information Element data structure to > include flags. See below. > > 11.8.1.4. IEEE 802.11 Information Element > > The IEEE 802.11 Information Element is used to communicate any IE > defined in the IEEE 802.11 protocol. The data field contains the raw > IE as it would be included within an IEEE 802.11 MAC management > message. > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > |B|P| Flags | Info Element > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > Type: TBD for IEEE 802.11 Information Element > > Length: >=3D 2 > > B: When set, the WTP is to include the information element in > beacons associated with the WLAN. > > P: When set, the WTP is to include the information element in probe > responses associated with the WLAN. > > Flags: Reserved field and MUST be set to zero. > > Info Element: The IEEE 802.11 Information Element, which includes > the type, length and value field. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) > > Sent: Friday, April 28, 2006 11:49 AM > > To: Puneet; capwap@frascone.com > > Subject: [Capwap] Issues 101: 11.8.1.1 Change to re-use > > 802.11 Informationelement definitions > > > > I believe there are many issues in issue 101, some of which were > > introduced by Dorothy. I believe that my proposal > > (below) covers all sections. Comments most welcomed! > > > > 1. does the encryption policy refer to broadcast traffic or > unicast > > too? If its also unicast, then there could be multiple encryption > > types enabled at the same type on the WLAN, in that case how is the > > encryption-policy field filled in? > > > > > > This is a good question as the text is obviously not clear enough. I > > am proposing the following text (as well as for the Update WLAN > > section): > > > > Encryption Policy: A 32-bit value specifying the encryption scheme > > to apply to traffic to and from the mobile station. The > > applicability of the encryption policy depends upon the security > > policy. For static WEP keys, which is true when the 'Shared > > Key' > > bit is set, this encryption policy is relevant for both unicast > > and multicast traffic. For encryption schemes that employ a > > separate encryption key for unicast and multicast traffic, the > > encryption policy defined here only applies to multicast data. > > In > > these scenarios, the unicast encryption policy is communicated > > via > > the Add Mobile (Section 9.1.1). > > [...] > > Shared Key: A 1 byte boolean that specifies whether the key > > included > > in the Key field is a shared WEP key. When set to one, the WLAN > > employs a shared WEP key, also known as a static WEP key, and > > uses > > the encryption key for both unicast and multicast traffic for > > all > > stations. A value of zero, with the 'Encryption Policy' field > > set > > to any value other than 'Clear Text' means that the WLAN uses > > per- > > station encryption keys, and therefore the key in the 'Key' > > field > > is only used for multicast traffic. > > > > > > 2. for the encryption policies we could use the format used in > the > > RSN IEs (OUI + encryption_type); that allows support for different > > vendor specific encryption types in a clean manner (CKIP for example > > would then use the Cisco OUI, instead of being clubbed together with > > the other 'standard' > > encryption types; and it makes it easier for vendors to not step on > > each others toes). > > > > > > Based on Dorothy's e-mail and recommendation, I would propose the > > following new section: > > > > 11.8.1.4. IEEE 802.11 Information Element > > > > The IEEE 802.11 Information Element is used to communicate any IE > > defined in the IEEE 802.11 protocol. The data field contains the > > raw > > IE as it would be included within an IEEE 802.11 MAC management > > message. > > > > 0 > > 0 1 2 3 4 5 6 7 > > +-+-+-+-+-+-+-+- > > | Info Element > > +-+-+-+-+-+-+-+- > > > > Type: TBD for IEEE 802.11 Information Element > > > > Length: >=3D 1 > > > > Info Element: The IEEE 802.11 Information Element, which includes > > the type, length and value field. > > > > However, I do not believe that everything can be moved out at this > > point. So I would propose changing the Add WLAN to be the following: > > > > 11.8.1.1. IEEE 802.11 Add WLAN > > > > The Add WLAN message element is used by the AC to define a wireless > > LAN on the WTP. The inclusion of this message element MUST also > > include the IEEE 802.11 Information Element message element, > > containing the following 802.11 IEs: > > Capability > > WPA IE > > RSN IE > > EDCA Parameter Set IE > > QoS Capability IE > > WMM IE > > > > The value contains 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 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Radio ID | WLAN ID | Reserved > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Encryption Policy > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Key > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Key > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Key > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Key > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Key > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Key > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Key > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Key > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Key Index | Shared Key | QoS | > > Auth Type | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | MAC Mode | Tunnel Mode | Suppress SSID | SSID ... > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > 3. why are the lengths of the IEs (WPA, RSN etc) fixed at 32 > bytes? > > If each of those IEs is preceded by an element that specifies their > > lengths, then the IEs could be made variable length. > > > > Thanks, that has been fixed > > > > 4. Does the 'Suppress SSID' field also disable the use of that > SSID > > in broadcast probe responses? If so, why do we also need the 'IEEE > > 802.11 Broadcast Probe Mode' in section 11.9.12? Also, why is this IE > > global for the WTP? The AC might configure the WTP with 10 WLANs, but > > it may want probe responses generated for only four of those when a > > broadcast probe request comes in. > > > > Section 11.9.12 deals with the changing of the mode of operation > > > after the WLAN is already operational. > > > > 5. maybe rename WME to WMM? > > > > No longer relevant > > > > 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_8576_23906140.1146593644950 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Pat,
 
. The inclusion of this message element MUST also
>  &= nbsp; include the IEEE 802.11 Information Element message element,
= >    containing the following 802.11 IEs:
>&nb= sp;      Capability
>    = ;   WPA IE
>       RSN IE
>  &nbs= p;    EDCA Parameter Set IE
>    &= nbsp;  QoS Capability IE
>       W= MM IE

- should this be
MUST also include IEEE 802.11 Information Element message elements, co= ntaining...
 
Otherwise, looks good.
 
Dorothy
 
On 5/1/06, P= at Calhoun (pacalhou) <pcalhou= n@cisco.com> wrote:
All,

I've been thinking a= bout my earlier proposed change for issue 101 and
would like to change t= he new Information Element data structure to
include flags. See below.

11.8.1.4.  IEEE 802.11 Information Element

  The IEEE = 802.11 Information Element is used to communicate any IE
  def= ined in the IEEE 802.11 protocol.  The data field contains the ra= w
  IE as it would be included within an IEEE 802.11 MAC manage= ment
  message.

       0&= nbsp;           &nbs= p;      1
       = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-
      |B|P|&n= bsp;  Flags   | Info Element
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
  Type:  TBD for IEEE 802.11 Information Element
  Length:  >=3D 2

  B: &= nbsp;When set, the WTP is to include the information element in
 &n= bsp;   beacons associated with the WLAN.

  P:  When set, the WTP is to include the infor= mation element in probe
     responses associated wi= th the WLAN.

  Flags:  Reserved field and MUST b= e set to zero.

  Info Element:  The IEEE 802.11 = Information Element, which includes
     the type, length and value field.


P= at Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems


> -----Original Message-----
> From: Pat Calhoun (pacalh= ou)
> Sent: Friday, April 28, 2006 11:49 AM
> To: Puneet; capwap@frascone= .com
> Subject: [Capwap] Issues 101: = 11.8.1.1 Change to re-use
> 802.11 Informationelement definitions
>
> I believe there are many issues in issue 101, some of whic= h were
> introduced by Dorothy. I believe that my proposal
> (b= elow) covers all sections. Comments most welcomed!
>
> &nb= sp;     1. does the encryption policy refer to broadcas= t traffic or
unicast
> too? If its also unicast, then there could be multiple = encryption
> types enabled at the same type on the WLAN, in that case= how is the
> encryption-policy field filled in?
>
> <= PRC>
> This is a good question as the text is obviously not clear enough.= I
> am proposing the following text (as well as for the Update WLAN<= br>> section):
>
>    Encryption Policy:=   A 32-bit value specifying the encryption scheme
>       to apply to traffic to and fro= m the mobile station.  The
>     &= nbsp; applicability of the encryption policy depends upon the security
&= gt;       policy.  For static WEP k= eys, which is true when the 'Shared
> Key'
>       bit is set, this = encryption policy is relevant for both unicast
>   &nb= sp;   and multicast traffic.  For encryption schemes th= at employ a
>       separate encryption= key for unicast and multicast traffic, the
>       encryption policy defined here= only applies to multicast data.
> In
>    =    these scenarios, the unicast encryption policy is communicated=
> via
>       the Add Mobile (Se= ction 9.1.1 ).
> [...]
>    Shared Key:  A 1 = byte boolean that specifies whether the key
> included
> &= nbsp;     in the Key field is a shared WEP key. &n= bsp;When set to one, the WLAN
>       e= mploys a shared WEP key, also known as a static WEP key, and
> uses
>       the encryption ke= y for both unicast and multicast traffic for
> all
>  = ;     stations.  A value of zero, with the 'E= ncryption Policy' field
> set
>     &n= bsp; to any value other than 'Clear Text' means that the WLAN uses
> per-
>       station encryptio= n keys, and therefore the key in the 'Key'
> field
>  = ;     is only used for multicast traffic.
> </= PRC>
>
>       2. for the encr= yption policies we could use the format used in
the
> RSN IEs (OUI + encryption_type); that allows support for di= fferent
> vendor specific encryption types in a clean manner (CKIP fo= r example
> would then use the Cisco OUI, instead of being clubbed to= gether with
> the other 'standard'
> encryption types; and it makes it eas= ier for vendors to not step on
> each others toes).
>
> &= lt;PRC>
> Based on Dorothy's e-mail and recommendation, I would pr= opose the
> following new section:
>
> 11.8.1.4.  IEEE 802.11 Information Element
>
>&n= bsp;   The IEEE 802.11 Information Element is used to commun= icate any IE
>    defined in the IEEE=20 802.11 protocol.  The data field contains the
> raw
>=     IE as it would be included within an IEEE 802.11 MA= C management
>    message.
>
> &= nbsp;     0
>      = 0 1 2 3 4 5 6 7
>      +-+-+-+-+-+-+-+= -
>      | Info Element
> &nb= sp;    +-+-+-+-+-+-+-+-
>
>  &nbs= p; Type:  TBD for IEEE 802.11 Information Element
>>    Length:  >=3D 1
>
>&n= bsp;   Info Element:  The IEEE 802.11 Information = Element, which includes
>       the type, length and value fie= ld.
>
> However, I do not believe that everything can be moved = out at this
> point. So I would propose changing the Add WLAN to be t= he following:
>
>=20 11.8.1.1.  IEEE 802.11 Add WLAN>
>    The Add WLAN message element is used = by the AC to define a wireless
>    LAN on the WT= P.  The inclusion of this message element MUST also
>    include the IEEE 802.11 Information Element= message element,
>    containing the following 8= 02.11 IEs:
>       Capability
>&n= bsp;      WPA IE
>    &n= bsp;  RSN IE
>       EDCA Paramete= r Set IE
>       QoS Capability IE
> = ;      WMM IE
>
>   &nb= sp;The value contains the following format:
>
>  &nbs= p;      0       = ;            1 =             &nb= sp;     2       &nbs= p;           3
>&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 0 1
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+
>       =  |    Radio ID   |   &nbs= p;WLAN ID    |       = ;     Reserved
>    &nbs= p;     |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |   =             &nb= sp;      Encryption Policy
>  = ;        |
>
> +-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> &nbs= p;      |      =             &nb= sp;            Key>          |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+
>        |  = ;            &n= bsp;            = ;    Key
>       &n= bsp;  |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+
>        |   =             &nb= sp;            =    Key
>        &nb= sp; |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+
>        |&= nbsp;           &nbs= p;            &= nbsp;     Key
>     &nbs= p;    |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+
>        |  = ;            &n= bsp;            = ;    Key
>       &n= bsp;  |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+
>        |   =             &nb= sp;            =    Key
>        &nb= sp; |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+
>        |&= nbsp;           &nbs= p;            &= nbsp;     Key
>     &nbs= p;    |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+
>        |  = ;            &n= bsp;            = ;    Key
>       &n= bsp;  |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+
>        |   Key I= ndex   |   Shared Key  |   &nb= sp;  QoS      |
> Auth Type&n= bsp;  |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+
>        = |   MAC Mode    |  Tunnel Mode = ; | Suppress SSID |    SSID ...
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+
> </PRC>
>
>     &= nbsp; 3. why are the lengths of the IEs (WPA, RSN etc) fixed at 32
bytes= ?
> If each of those IEs is preceded by an element that specifies the= ir
> lengths, then the IEs could be made variable length.
>
&g= t; <PRC> Thanks, that has been fixed</PRC>
>
> = ;      4. Does the 'Suppress SSID' field also disa= ble the use of that
SSID
> in broadcast probe responses? If so, why do we also need the 'IEEE=
> 802.11 Broadcast Probe Mode' in section 11.9.12? Also, why is this= IE
> global for the WTP? The AC might configure the WTP with 10 WLAN= s, but
> it may want probe responses generated for only four of those when = a
> broadcast probe request comes in.
>
> <PRC> Sec= tion 11.9.12 deals with the changing of the mode of operation

> a= fter the WLAN is already operational.</PRC>
>
>       5. maybe rename WME to= WMM?
>
> <PRC> No longer relevant </PRC>
>> Pat Calhoun
> CTO, Wireless Networking Business Unit
> C= isco Systems
___________________________________________________________= ______
To unsubscribe or modify your subscription options, please visit:
http://lists.fr= ascone.com/mailman/listinfo/capwap

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

------=_Part_8576_23906140.1146593644950-- --===============0707842252== 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 --===============0707842252==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue May 02 14:25:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FazYX-0007TW-72 for capwap-archive@lists.ietf.org; Tue, 02 May 2006 14:25:05 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FazYW-0008IS-EZ for capwap-archive@lists.ietf.org; Tue, 02 May 2006 14:25:05 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 05E534300E6 for ; Tue, 2 May 2006 11:25:04 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 0EAFB4300A2 for ; Tue, 2 May 2006 11:24:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 026DE39801B for ; Tue, 2 May 2006 11:24:29 -0700 (PDT) Received: from mail.u4eatech.com (blackhole.u4eatech.com [195.188.241.2]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9A0D0398041 for ; Tue, 2 May 2006 11:24:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.u4eatech.com (Postfix) with ESMTP id BFB4E360923; Tue, 2 May 2006 19:05:26 +0100 (BST) Received: FROM mail.u4eatech.com ([127.0.0.1]) BY localhost WITH ESMTP ; Tue, 2 May 2006 19:05:26 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.u4eatech.com (Postfix) with ESMTP id A24B636091E; Tue, 2 May 2006 19:05:26 +0100 (BST) Received: from mail.u4eatech.com ([127.0.0.1]) by localhost (mail.u4eatech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20227-02; Tue, 2 May 2006 19:05:23 +0100 (BST) Received: from [172.16.1.40] (u4ea-newvaio.u4eatechinc.com [172.16.1.40]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.u4eatech.com (Postfix) with ESMTP id 2B13336091C; Tue, 2 May 2006 19:05:20 +0100 (BST) In-Reply-To: <5bfe7a820605021114w6dbf53d0w24d6b52eb60a35fb@mail.gmail.com> References: <4FF84B0BC277FF45AA27FE969DD956A201D249BD@xmb-sjc-235.amer.cisco.com> <5bfe7a820605021114w6dbf53d0w24d6b52eb60a35fb@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v749.3) Message-Id: <43F8B082-F35C-4F92-BD12-50411397F2BE@u4eatech.com> From: Philip Rakity Subject: Re: [Capwap] Issues 101: 11.8.1.1 Change to re-use 802.11 Date: Tue, 2 May 2006 11:24:14 -0700 To: Dorothy Stanley X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: amavisd-new at u4eatech.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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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="===============1544410950==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 --===============1544410950== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-783330275; protocol="application/pkcs7-signature" --Apple-Mail-2-783330275 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed The information in the capwap messages that refer (indirectly to 802.11 mib elements) now be expressed in terms of this IE. Eg DTIM, 802.11 country codes etc. Makes things much cleaner. Philip On May 2, 2006, at 11:14 AM, Dorothy Stanley wrote: > Hi Pat, > > . The inclusion of this message element MUST also > > include the IEEE 802.11 Information Element message element, > > containing the following 802.11 IEs: > > Capability > > WPA IE > > RSN IE > > EDCA Parameter Set IE > > QoS Capability IE > > WMM IE > > - should this be > MUST also include IEEE 802.11 Information Element message elements, > containing... > > Otherwise, looks good. > > Dorothy > > On 5/1/06, Pat Calhoun (pacalhou) wrote: All, > > I've been thinking about my earlier proposed change for issue 101 and > would like to change the new Information Element data structure to > include flags. See below. > > 11.8.1.4. IEEE 802.11 Information Element > > The IEEE 802.11 Information Element is used to communicate any IE > defined in the IEEE 802.11 protocol. The data field contains the > raw > IE as it would be included within an IEEE 802.11 MAC management > message. > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > |B|P| Flags | Info Element > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > Type: TBD for IEEE 802.11 Information Element > > Length: >= 2 > > B: When set, the WTP is to include the information element in > beacons associated with the WLAN. > > P: When set, the WTP is to include the information element in probe > responses associated with the WLAN. > > Flags: Reserved field and MUST be set to zero. > > Info Element: The IEEE 802.11 Information Element, which includes > the type, length and value field. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) > > Sent: Friday, April 28, 2006 11:49 AM > > To: Puneet; capwap@frascone.com > > Subject: [Capwap] Issues 101: 11.8.1.1 Change to re-use > > 802.11 Informationelement definitions > > > > I believe there are many issues in issue 101, some of which were > > introduced by Dorothy. I believe that my proposal > > (below) covers all sections. Comments most welcomed! > > > > 1. does the encryption policy refer to broadcast traffic or > unicast > > too? If its also unicast, then there could be multiple encryption > > types enabled at the same type on the WLAN, in that case how is the > > encryption-policy field filled in? > > > > > > This is a good question as the text is obviously not clear enough. I > > am proposing the following text (as well as for the Update WLAN > > section): > > > > Encryption Policy: A 32-bit value specifying the encryption > scheme > > to apply to traffic to and from the mobile station. The > > applicability of the encryption policy depends upon the > security > > policy. For static WEP keys, which is true when the 'Shared > > Key' > > bit is set, this encryption policy is relevant for both > unicast > > and multicast traffic. For encryption schemes that employ a > > separate encryption key for unicast and multicast traffic, the > > encryption policy defined here only applies to multicast data. > > In > > these scenarios, the unicast encryption policy is communicated > > via > > the Add Mobile (Section 9.1.1 ). > > [...] > > Shared Key: A 1 byte boolean that specifies whether the key > > included > > in the Key field is a shared WEP key. When set to one, the > WLAN > > employs a shared WEP key, also known as a static WEP key, and > > uses > > the encryption key for both unicast and multicast traffic for > > all > > stations. A value of zero, with the 'Encryption Policy' field > > set > > to any value other than 'Clear Text' means that the WLAN uses > > per- > > station encryption keys, and therefore the key in the 'Key' > > field > > is only used for multicast traffic. > > > > > > 2. for the encryption policies we could use the format used in > the > > RSN IEs (OUI + encryption_type); that allows support for different > > vendor specific encryption types in a clean manner (CKIP for example > > would then use the Cisco OUI, instead of being clubbed together with > > the other 'standard' > > encryption types; and it makes it easier for vendors to not step on > > each others toes). > > > > > > Based on Dorothy's e-mail and recommendation, I would propose the > > following new section: > > > > 11.8.1.4. IEEE 802.11 Information Element > > > > The IEEE 802.11 Information Element is used to communicate any IE > > defined in the IEEE 802.11 protocol. The data field contains the > > raw > > IE as it would be included within an IEEE 802.11 MAC management > > message. > > > > 0 > > 0 1 2 3 4 5 6 7 > > +-+-+-+-+-+-+-+- > > | Info Element > > +-+-+-+-+-+-+-+- > > > > Type: TBD for IEEE 802.11 Information Element > > > > Length: >= 1 > > > > Info Element: The IEEE 802.11 Information Element, which > includes > > the type, length and value field. > > > > However, I do not believe that everything can be moved out at this > > point. So I would propose changing the Add WLAN to be the following: > > > > 11.8.1.1. IEEE 802.11 Add WLAN > > > > The Add WLAN message element is used by the AC to define a > wireless > > LAN on the WTP. The inclusion of this message element MUST also > > include the IEEE 802.11 Information Element message element, > > containing the following 802.11 IEs: > > Capability > > WPA IE > > RSN IE > > EDCA Parameter Set IE > > QoS Capability IE > > WMM IE > > > > The value contains 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 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Radio ID | WLAN ID | Reserved > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Encryption Policy > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Key > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Key > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Key > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Key > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Key > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Key > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Key > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Key > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Key Index | Shared Key | QoS | > > Auth Type | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | MAC Mode | Tunnel Mode | Suppress SSID | SSID ... > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > 3. why are the lengths of the IEs (WPA, RSN etc) fixed at 32 > bytes? > > If each of those IEs is preceded by an element that specifies their > > lengths, then the IEs could be made variable length. > > > > Thanks, that has been fixed > > > > 4. Does the 'Suppress SSID' field also disable the use of that > SSID > > in broadcast probe responses? If so, why do we also need the 'IEEE > > 802.11 Broadcast Probe Mode' in section 11.9.12? Also, why is > this IE > > global for the WTP? The AC might configure the WTP with 10 WLANs, > but > > it may want probe responses generated for only four of those when a > > broadcast probe request comes in. > > > > Section 11.9.12 deals with the changing of the mode of > operation > > > after the WLAN is already operational. > > > > 5. maybe rename WME to WMM? > > > > No longer relevant > > > > 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 Philip Rakity prakity@u4eatech.com This message is hereby marked U4EA CONFIDENTIAL, is intended only for the use of the individual or individuals to which it is addressed and shall notbe disclose or made available to any other party except with the prior written consent of the sender. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender of this E-Mail. --Apple-Mail-2-783330275 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDrjCCA6ow ggMToAMCAQICASUwDQYJKoZIhvcNAQEEBQAwfzEiMCAGA1UEAxMZZmx5aW5nbW9ua2V5LnU0ZWF0 ZWNoLmNvbTEaMBgGA1UEChMRVTRFQSBUZWNobm9sb2dpZXMxHjAcBgkqhkiG9w0BCQEWD2l0QHU0 ZWF0ZWNoLmNvbTELMAkGA1UEBhMCVUsxEDAOBgNVBAcTB0JyaXN0b2wwHhcNMDYwNDA1MDkyMjEz WhcNMDcwNDA1MDkyMjEzWjB+MQswCQYDVQQGEwJVSzEQMA4GA1UEBxMHQnJpc3RvbDEaMBgGA1UE ChMRVTRFQSBUZWNobm9sb2dpZXMxFjAUBgNVBAMTDVBoaWxpcCBSYWtpdHkxKTAnBgkqhkiG9w0B CQEWGnBoaWxpcC5yYWtpdHlAdTRlYXRlY2guY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDQqH0Lm5zoXgKWrNJPMAz+nMbEHTt2d55kT/NeZqdXZdywassH//vkdDH1CAZk+JNfG6IshRSr qDnqDAArwL8SOLpeJ2oF7YL37qwpA9c3y56Z2ZHjzGzBdX8demzNsEG3nEFTBS1ARyCQAfopCImz TrYPfa6taYdEF/Mj4CTXBwIDAQABo4IBNTCCATEwCQYDVR0TBAIwADAsBglghkgBhvhCAQ0EHxYd T3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFJCsX1sNMwH6ufp/ILfRKmb+ 6JJMMIGzBgNVHSMEgaswgaiAFPGFe7eBejo0WsmvQrqEg8SqkA3VoYGEpIGBMH8xIjAgBgNVBAMT GWZseWluZ21vbmtleS51NGVhdGVjaC5jb20xGjAYBgNVBAoTEVU0RUEgVGVjaG5vbG9naWVzMR4w HAYJKoZIhvcNAQkBFg9pdEB1NGVhdGVjaC5jb20xCzAJBgNVBAYTAlVLMRAwDgYDVQQHEwdCcmlz dG9sggkAmTQcGtijWKcwIQYDVR0RBBowGIIWYmxhY2tob2xlQHU0ZWF0ZWNoLmNvbTANBgkqhkiG 9w0BAQQFAAOBgQCUG90QVWCMOOheb3O77NopRh8Iy9FN9R81+N3MzqpaLM090eoLSUsrIhyw9/Tp ExGHM7FBBTntfO4S8+qnpC1EOQA7YCilwT7+paHXObZDoID2m9piVBdTm+16xwshUshrGya5eGUz TEoo7vpWkZJfSJ/6Kjc0K01NOqUQjM5bFDGCAr4wggK6AgEBMIGEMH8xIjAgBgNVBAMTGWZseWlu Z21vbmtleS51NGVhdGVjaC5jb20xGjAYBgNVBAoTEVU0RUEgVGVjaG5vbG9naWVzMR4wHAYJKoZI hvcNAQkBFg9pdEB1NGVhdGVjaC5jb20xCzAJBgNVBAYTAlVLMRAwDgYDVQQHEwdCcmlzdG9sAgEl MAkGBSsOAwIaBQCgggGPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA2MDUwMjE4MjQxNVowIwYJKoZIhvcNAQkEMRYEFGyOT4xvro1DtRg76N2AMwvFsd3RMIGVBgkr BgEEAYI3EAQxgYcwgYQwfzEiMCAGA1UEAxMZZmx5aW5nbW9ua2V5LnU0ZWF0ZWNoLmNvbTEaMBgG A1UEChMRVTRFQSBUZWNobm9sb2dpZXMxHjAcBgkqhkiG9w0BCQEWD2l0QHU0ZWF0ZWNoLmNvbTEL MAkGA1UEBhMCVUsxEDAOBgNVBAcTB0JyaXN0b2wCASUwgZcGCyqGSIb3DQEJEAILMYGHoIGEMH8x IjAgBgNVBAMTGWZseWluZ21vbmtleS51NGVhdGVjaC5jb20xGjAYBgNVBAoTEVU0RUEgVGVjaG5v bG9naWVzMR4wHAYJKoZIhvcNAQkBFg9pdEB1NGVhdGVjaC5jb20xCzAJBgNVBAYTAlVLMRAwDgYD VQQHEwdCcmlzdG9sAgElMA0GCSqGSIb3DQEBAQUABIGATDEyg0cdWvEMTNdOzOmKGBG9HOOrEr9V mZjZGIGWIlJ1kQZRFtzdAbR37N7KymjW2UuKt0uxKbURZEHLXPY8j79lo0o4Mi8X8mdGHoiOFt8E B/wlTubP9IOqVwH4nu35lRE7bRrezQCBwAZbd4VkM7o4imhVu/SutmuFa8jiGH4AAAAAAAA= --Apple-Mail-2-783330275-- --===============1544410950== 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 --===============1544410950==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue May 02 14:26:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FazZx-0007q2-3q for capwap-archive@lists.ietf.org; Tue, 02 May 2006 14:26:33 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FazZw-0008Rg-GB for capwap-archive@lists.ietf.org; Tue, 02 May 2006 14:26:33 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A9BD3430120 for ; Tue, 2 May 2006 11:26:31 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E81D5430097 for ; Tue, 2 May 2006 11:26:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B9DB6144802F for ; Tue, 2 May 2006 11:25:59 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.194]) by hermes.tigertech.net (Postfix) with ESMTP id 7F00A1448005 for ; Tue, 2 May 2006 11:25:56 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so1895809wxd for ; Tue, 02 May 2006 11:25:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=uQeEMcAe7RDSIE3SYK0CmTMcAdNzGahds5qwV8zrbNFbHwQqvppmP2/ipCj9FNHvAR+iq0r3JpWuWNA9FXHpKevQZswLJpJzO56QvxrDHRmy+T0Ir3O2EUSEuh2EkaK3qh17Dwh/Tv3uWJs9fNgJEe9BZZ9M8BP/aZHORkiAkn0= Received: by 10.70.18.9 with SMTP id 9mr986835wxr; Tue, 02 May 2006 11:25:54 -0700 (PDT) Received: by 10.70.6.8 with HTTP; Tue, 2 May 2006 11:25:54 -0700 (PDT) Message-ID: <5bfe7a820605021125u73011422j5357c9d51e04b3d1@mail.gmail.com> Date: Tue, 2 May 2006 11:25:54 -0700 From: "Dorothy Stanley" To: "Jim Murphy" Subject: Re: [Capwap] Issue 50: Increase maximum number of BSSs In-Reply-To: <44568B44.80302@trapezenetworks.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A201CBAA7E@xmb-sjc-235.amer.cisco.com> <44568B44.80302@trapezenetworks.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 X-Spam-Level: * Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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="===============0011558467==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.0 (+) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 --===============0011558467== Content-Type: multipart/alternative; boundary="----=_Part_8812_31962892.1146594354823" ------=_Part_8812_31962892.1146594354823 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, Looking at the original Issue 50 text: > Page 34, Section 5.1.3. LWAPP seems to assume that WLAN > radios will support > 16 BSS's per Radio. It would be better not assume that every > WTP supports 16 radios and add a field to indicate the number > of virtual networks per radio. At one point, the sheer number of beacons will saturate the air waves, so we need to pick a maximum. What number do we want? I think the issue name does not match the comment. It's not clear that the commenter is asking for more than 16 BSSIDs, but rather notes that the full 16 are assumed to be supported at the WTP. What if the WTP only supports 4= ? There is no way currently for the WTP to communicate this to the AP. Section 5.1.3 is the WTP Radio information message element. One solution would be to add a "Number of BSSIDs supported" field to that message element. Another solution would be to add a new IEEE 802.11 message element, to indicate the number of BSSIDs supported, and include that new message element in the appropriate messages. I suggest the later, to keep BSSIDs in the .11 binding definition. And, separately, keep the max at 16 BSSIDs. Dorothy On 5/1/06, Jim Murphy wrote: > > It seems that the limit of 16 BSSIDs is primarily motivated > by this WLAN/Status field in the data header. Perhaps the WLAN/Status > field should be a broadcast domain identifier (a .1q tag or VLANID). > WTPs should then be told of the VLANID to BSSID/broadcast-key mapping > via control plane messages and replicate packets accordingly. > > If a VLANID is used in place of this bitmap, the protocol will scale > better. With the current proposal, I am concerned about WTPs that have > many radios or offer multiple VLANs per BSSID. > > Thanks, > > Jim > > Pat Calhoun (pacalhou) wrote: > > > > I would recommend that we reject this issue. 16 BSSIDs is a large > > number, and the overhead in generating 16 or more beacons outweighs the > > usefullness in advertising that many networks. > > > > 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 > ------=_Part_8812_31962892.1146594354823 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
All,
 
Looking at the original Issue 50 text:
 
 
> Page 34, Section 5.1.3. LWAPP seems to assume th=
at WLAN=20
> radios will support
> 16 BSS's per Radio. It would be better not assume that every=20
> WTP supports 16 radios and add a field to indicate the number=20
> of virtual networks per radio.
At one point, the sheer number of beacons will saturate the air waves,
so we need to pick a maximum. What number do we want?
I think the issue name does not match the comment.
It's not clear that the commenter is asking for more than 16 BSSIDs, b= ut rather notes that the full
16 are assumed to be supported at the WTP.  What if the WTP only = supports 4? There is no way currently
for the WTP to communicate this to the AP. Section 5.1.3 is the WTP Ra= dio information message element.
One solution would be to add a "Number of BSSIDs supported" = field to that message element.
Another solution would be to add a new IEEE 802.11 message element, to= indicate the number of
BSSIDs supported, and include that new message element in the appropri= ate messages. I suggest the
later, to keep BSSIDs in the .11 binding definition. And, separately,&= nbsp;keep the max at 16 BSSIDs.
 
 
Dorothy

 
On 5/1/06, J= im Murphy <jmurphy@tr= apezenetworks.com> wrote:
It seems that the limit of 16 BS= SIDs is primarily motivated
by this WLAN/Status field in the data header= . Perhaps the WLAN/Status
field should be a broadcast domain identifier (a .1q tag or VLANID).WTPs should then be told of the VLANID to BSSID/broadcast-key mapping
v= ia control plane messages and replicate packets accordingly.

If a VL= ANID is used in place of this bitmap, the protocol will scale
better. With the current proposal, I am concerned about WTPs that have<= br>many radios or offer multiple VLANs per BSSID.

Thanks,

Jim=

Pat Calhoun (pacalhou) wrote:
>
> I would recommend tha= t we reject this issue. 16 BSSIDs is a large
> number, and the overhead in generating 16 or more beacons outweigh= s the
> usefullness in advertising that many networks.
>
>= ; Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco = Systems
> _________________________________________________________________<= br>> 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 o= r modify your subscription options, please visit:
http://li= sts.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/piperma= il/capwap

------=_Part_8812_31962892.1146594354823-- --===============0011558467== 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 --===============0011558467==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue May 02 16:37:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1cM-0004D5-Se for capwap-archive@lists.ietf.org; Tue, 02 May 2006 16:37:10 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb1cK-0006wH-Lp for capwap-archive@lists.ietf.org; Tue, 02 May 2006 16:37:10 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8D1854300A5 for ; Tue, 2 May 2006 13:37:07 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 06DDD430075 for ; Tue, 2 May 2006 13:36:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D9EEC39804A for ; Tue, 2 May 2006 13:36:29 -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 87DDC398041 for ; Tue, 2 May 2006 13:36:26 -0700 (PDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 02 May 2006 13:36:26 -0700 X-IronPort-AV: i="4.05,81,1146466800"; d="scan'208,217"; a="272272248:sNHT53659340" 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 k42KaMVu016245; Tue, 2 May 2006 13:36:25 -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, 2 May 2006 13:36:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] Issue 50: Increase maximum number of BSSs Date: Tue, 2 May 2006 13:36:14 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D24C84@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 50: Increase maximum number of BSSs Thread-Index: AcZuFf5pSO/hFJnmTLCpm0cDVjNWMwAEfIjA From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "Jim Murphy" X-OriginalArrivalTime: 02 May 2006 20:36:17.0121 (UTC) FILETIME=[0FE76D10:01C66E28] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.461 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_40_50, HTML_MESSAGE X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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="===============1438380478==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 This is a multi-part message in MIME format. --===============1438380478== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66E28.0FB6E5A8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66E28.0FB6E5A8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The number of BSSID supported is already in "IEEE 802.11 WTP WLAN Radio Configuration". =20 That said, you are correct that the issue name is incorrect. However, the issue raised is incorrect as the does exist a way for the WTP to provide this info to the AC. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Tuesday, May 02, 2006 11:26 AM To: Jim Murphy Cc: capwap Subject: Re: [Capwap] Issue 50: Increase maximum number of BSSs =09 =09 All, =20 Looking at the original Issue 50 text: =20 =20 > Page 34, Section 5.1.3. LWAPP seems to assume that WLAN=20 > radios will support > 16 BSS's per Radio. It would be better not assume that every=20 > WTP supports 16 radios and add a field to indicate the number=20 > of virtual networks per radio. At one point, the sheer number of beacons will saturate the air waves, so we need to pick a maximum. What number do we want? I think the issue name does not match the comment. It's not clear that the commenter is asking for more than 16 BSSIDs, but rather notes that the full 16 are assumed to be supported at the WTP. What if the WTP only supports 4? There is no way currently for the WTP to communicate this to the AP. Section 5.1.3 is the WTP Radio information message element. One solution would be to add a "Number of BSSIDs supported" field to that message element. Another solution would be to add a new IEEE 802.11 message element, to indicate the number of BSSIDs supported, and include that new message element in the appropriate messages. I suggest the=20 later, to keep BSSIDs in the .11 binding definition. And, separately, keep the max at 16 BSSIDs. =20 =20 Dorothy =09 =20 On 5/1/06, Jim Murphy wrote:=20 It seems that the limit of 16 BSSIDs is primarily motivated by this WLAN/Status field in the data header. Perhaps the WLAN/Status=20 field should be a broadcast domain identifier (a .1q tag or VLANID). WTPs should then be told of the VLANID to BSSID/broadcast-key mapping via control plane messages and replicate packets accordingly. =09 If a VLANID is used in place of this bitmap, the protocol will scale=20 better. With the current proposal, I am concerned about WTPs that have many radios or offer multiple VLANs per BSSID. =09 Thanks, =09 Jim =09 Pat Calhoun (pacalhou) wrote: > > I would recommend that we reject this issue. 16 BSSIDs is a large=20 > number, and the overhead in generating 16 or more beacons outweighs the > usefullness in advertising that many networks. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems=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 =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_01C66E28.0FB6E5A8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The=20 number of BSSID supported is already in "IEEE 802.11 WTP WLAN Radio=20 Configuration".
 
That=20 said, you are correct that the issue name is incorrect. However, the = issue=20 raised is incorrect as the does exist a way for the WTP to provide this = info to=20 the AC.
 

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

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Tuesday, May 02, 2006 = 11:26=20 AM
To: Jim Murphy
Cc: capwap
Subject: = Re:=20 [Capwap] Issue 50: Increase maximum number of = BSSs

All,
 
Looking at the original Issue 50 text:
 
 
> Page 34, Section 5.1.3. LWAPP seems to =
assume that WLAN=20
> radios will support
> 16 BSS's per Radio. It would be better not assume that every=20
> WTP supports 16 radios and add a field to indicate the number=20
> of virtual networks per radio.
At one point, the sheer number of beacons will saturate the air waves,
so we need to pick a maximum. What number do we want?
I think the issue name does not match the comment.
It's not clear that the commenter is asking for more than 16 = BSSIDs, but=20 rather notes that the full
16 are assumed to be supported at the WTP.  What if the WTP = only=20 supports 4? There is no way currently
for the WTP to communicate this to the AP. Section 5.1.3 is the = WTP Radio=20 information message element.
One solution would be to add a "Number of BSSIDs supported" field = to that=20 message element.
Another solution would be to add a new IEEE 802.11 message = element, to=20 indicate the number of
BSSIDs supported, and include that new message element in the = appropriate=20 messages. I suggest the
later, to keep BSSIDs in the .11 binding definition. And,=20 separately, keep the max at 16 BSSIDs.
 
 
Dorothy

 
On 5/1/06, Jim=20 Murphy <jmurphy@trapezenetworks.com>=20 wrote:=20
It=20 seems that the limit of 16 BSSIDs is primarily motivated
by this=20 WLAN/Status field in the data header. Perhaps the WLAN/Status =
field=20 should be a broadcast domain identifier (a .1q tag or = VLANID).
WTPs=20 should then be told of the VLANID to BSSID/broadcast-key = mapping
via=20 control plane messages and replicate packets accordingly.

If = a VLANID=20 is used in place of this bitmap, the protocol will scale
better. = With=20 the current proposal, I am concerned about WTPs that have
many = radios or=20 offer multiple VLANs per BSSID.

Thanks,

Jim

Pat = Calhoun=20 (pacalhou) wrote:
>
> I would recommend that we reject = this=20 issue. 16 BSSIDs is a large
> number, and the overhead in = generating=20 16 or more beacons outweighs the
> usefullness in advertising = that=20 many networks.
>
> Pat Calhoun
> CTO, Wireless = Networking=20 Business Unit
> Cisco Systems
>=20 = _________________________________________________________________
>= To=20 unsubscribe or modify your subscription options, please = visit:
> http://lists.f= rascone.com/mailman/listinfo/capwap=20
>
> Archives: http://lists.frascone= .com/pipermail/capwap

________________________________________= _________________________
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_01C66E28.0FB6E5A8-- --===============1438380478== 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 --===============1438380478==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue May 02 16:38:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1e7-0004jy-R1 for capwap-archive@lists.ietf.org; Tue, 02 May 2006 16:38:59 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb1e6-00074o-Ng for capwap-archive@lists.ietf.org; Tue, 02 May 2006 16:38:59 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id ED672430127 for ; Tue, 2 May 2006 13:38:57 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 55D8E430075 for ; Tue, 2 May 2006 13:38:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 41FCB144803D for ; Tue, 2 May 2006 13:38: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 53DE11448022 for ; Tue, 2 May 2006 13:38:27 -0700 (PDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 02 May 2006 13:37:53 -0700 X-IronPort-AV: i="4.05,81,1146466800"; d="scan'208"; a="1800669571:sNHT1943347826" 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 k42KbpVo017027; Tue, 2 May 2006 13:37:53 -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, 2 May 2006 13:37:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Issues 101: 11.8.1.1 Change to re-use 802.11 Date: Tue, 2 May 2006 13:37:47 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D24C88@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issues 101: 11.8.1.1 Change to re-use 802.11 Thread-Index: AcZuFbVgBPGLqqohSSOrLpTzshDPXgAEm/Bw From: "Pat Calhoun (pacalhou)" To: "Philip Rakity" , "Dorothy Stanley" X-OriginalArrivalTime: 02 May 2006 20:37:52.0495 (UTC) FILETIME=[48C057F0:01C66E28] 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 X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d These are not MIB elements, but actual information elements that are contained in the MAC management frames. Or are you raising a different point, which I believe is already captured in issue 18? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Philip Rakity [mailto:philip.rakity@u4eatech.com]=20 > Sent: Tuesday, May 02, 2006 11:24 AM > To: Dorothy Stanley > Cc: Pat Calhoun (pacalhou); capwap > Subject: Re: [Capwap] Issues 101: 11.8.1.1 Change to re-use 802.11 >=20 >=20 > The information in the capwap messages that refer (indirectly to > 802.11 mib elements) now be expressed in terms of this IE. Eg DTIM, =20 > 802.11 country codes etc. Makes things much cleaner. >=20 > Philip >=20 >=20 > On May 2, 2006, at 11:14 AM, Dorothy Stanley wrote: >=20 > > Hi Pat, > > > > . The inclusion of this message element MUST also > > > include the IEEE 802.11 Information Element message element, > > > containing the following 802.11 IEs: > > > Capability > > > WPA IE > > > RSN IE > > > EDCA Parameter Set IE > > > QoS Capability IE > > > WMM IE > > > > - should this be > > MUST also include IEEE 802.11 Information Element message elements,=20 > > containing... > > > > Otherwise, looks good. > > > > Dorothy > > > > On 5/1/06, Pat Calhoun (pacalhou) wrote: All, > > > > I've been thinking about my earlier proposed change for=20 > issue 101 and=20 > > would like to change the new Information Element data structure to=20 > > include flags. See below. > > > > 11.8.1.4. IEEE 802.11 Information Element > > > > The IEEE 802.11 Information Element is used to communicate any IE > > defined in the IEEE 802.11 protocol. The data field contains the=20 > > raw > > IE as it would be included within an IEEE 802.11 MAC management > > message. > > > > 0 1 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > |B|P| Flags | Info Element > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > > > Type: TBD for IEEE 802.11 Information Element > > > > Length: >=3D 2 > > > > B: When set, the WTP is to include the information element in > > beacons associated with the WLAN. > > > > P: When set, the WTP is to include the information=20 > element in probe > > responses associated with the WLAN. > > > > Flags: Reserved field and MUST be set to zero. > > > > Info Element: The IEEE 802.11 Information Element, which includes > > the type, length and value field. > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Pat Calhoun (pacalhou) > > > Sent: Friday, April 28, 2006 11:49 AM > > > To: Puneet; capwap@frascone.com > > > Subject: [Capwap] Issues 101: 11.8.1.1 Change to re-use > > > 802.11 Informationelement definitions > > > > > > I believe there are many issues in issue 101, some of which were > > > introduced by Dorothy. I believe that my proposal > > > (below) covers all sections. Comments most welcomed! > > > > > > 1. does the encryption policy refer to broadcast traffic or > > unicast > > > too? If its also unicast, then there could be multiple encryption > > > types enabled at the same type on the WLAN, in that case=20 > how is the > > > encryption-policy field filled in? > > > > > > > > > This is a good question as the text is obviously not=20 > clear enough. I > > > am proposing the following text (as well as for the Update WLAN > > > section): > > > > > > Encryption Policy: A 32-bit value specifying the encryption =20 > > scheme > > > to apply to traffic to and from the mobile station. The > > > applicability of the encryption policy depends upon the =20 > > security > > > policy. For static WEP keys, which is true when the 'Shared > > > Key' > > > bit is set, this encryption policy is relevant for both =20 > > unicast > > > and multicast traffic. For encryption schemes that employ a > > > separate encryption key for unicast and multicast=20 > traffic, the > > > encryption policy defined here only applies to=20 > multicast data. > > > In > > > these scenarios, the unicast encryption policy is=20 > communicated > > > via > > > the Add Mobile (Section 9.1.1 ). > > > [...] > > > Shared Key: A 1 byte boolean that specifies whether the key > > > included > > > in the Key field is a shared WEP key. When set to=20 > one, the =20 > > WLAN > > > employs a shared WEP key, also known as a static=20 > WEP key, and > > > uses > > > the encryption key for both unicast and multicast=20 > traffic for > > > all > > > stations. A value of zero, with the 'Encryption=20 > Policy' field > > > set > > > to any value other than 'Clear Text' means that the=20 > WLAN uses > > > per- > > > station encryption keys, and therefore the key in the 'Key' > > > field > > > is only used for multicast traffic. > > > > > > > > > 2. for the encryption policies we could use the=20 > format used in > > the > > > RSN IEs (OUI + encryption_type); that allows support for different > > > vendor specific encryption types in a clean manner (CKIP=20 > for example > > > would then use the Cisco OUI, instead of being clubbed=20 > together with > > > the other 'standard' > > > encryption types; and it makes it easier for vendors to=20 > not step on > > > each others toes). > > > > > > > > > Based on Dorothy's e-mail and recommendation, I would propose the > > > following new section: > > > > > > 11.8.1.4. IEEE 802.11 Information Element > > > > > > The IEEE 802.11 Information Element is used to=20 > communicate any IE > > > defined in the IEEE 802.11 protocol. The data field=20 > contains the > > > raw > > > IE as it would be included within an IEEE 802.11 MAC management > > > message. > > > > > > 0 > > > 0 1 2 3 4 5 6 7 > > > +-+-+-+-+-+-+-+- > > > | Info Element > > > +-+-+-+-+-+-+-+- > > > > > > Type: TBD for IEEE 802.11 Information Element > > > > > > Length: >=3D 1 > > > > > > Info Element: The IEEE 802.11 Information Element, which =20 > > includes > > > the type, length and value field. > > > > > > However, I do not believe that everything can be moved out at this > > > point. So I would propose changing the Add WLAN to be the=20 > following: > > > > > > 11.8.1.1. IEEE 802.11 Add WLAN > > > > > > The Add WLAN message element is used by the AC to define a =20 > > wireless > > > LAN on the WTP. The inclusion of this message element=20 > MUST also > > > include the IEEE 802.11 Information Element message element, > > > containing the following 802.11 IEs: > > > Capability > > > WPA IE > > > RSN IE > > > EDCA Parameter Set IE > > > QoS Capability IE > > > WMM IE > > > > > > The value contains the following format: > > > > > > 0 1 =20 > > 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 | WLAN ID | Reserved > > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Encryption Policy > > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Key > > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Key > > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Key > > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Key > > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Key > > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Key > > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Key > > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Key > > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Key Index | Shared Key | QoS | > > > Auth Type | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | MAC Mode | Tunnel Mode | Suppress SSID | =20 > SSID ... > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > 3. why are the lengths of the IEs (WPA, RSN etc) fixed at 32 > > bytes? > > > If each of those IEs is preceded by an element that=20 > specifies their > > > lengths, then the IEs could be made variable length. > > > > > > Thanks, that has been fixed > > > > > > 4. Does the 'Suppress SSID' field also disable the=20 > use of that > > SSID > > > in broadcast probe responses? If so, why do we also need the 'IEEE > > > 802.11 Broadcast Probe Mode' in section 11.9.12? Also, why is =20 > > this IE > > > global for the WTP? The AC might configure the WTP with=20 > 10 WLANs, =20 > > but > > > it may want probe responses generated for only four of=20 > those when a > > > broadcast probe request comes in. > > > > > > Section 11.9.12 deals with the changing of the mode of =20 > > operation > > > > > after the WLAN is already operational. > > > > > > 5. maybe rename WME to WMM? > > > > > > No longer relevant > > > > > > 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 >=20 > Philip Rakity > prakity@u4eatech.com >=20 >=20 > This message is hereby marked U4EA CONFIDENTIAL, is intended=20 > only for =20 > the use of the individual or individuals to which it is=20 > addressed and =20 > shall notbe disclose or made available to any other party=20 > except with =20 > the prior written consent of the sender. If the reader of this =20 > message is not the intended recipient, you are hereby notified that =20 > any dissemination, distribution or copying of this message is =20 > strictly prohibited. If you have received this communication in =20 > error, please notify us immediately by replying to the sender=20 > of this =20 > E-Mail. >=20 >=20 >=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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue May 02 16:40:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1fC-0004o9-Ke for capwap-archive@lists.ietf.org; Tue, 02 May 2006 16:40:06 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb1f9-00078A-Co for capwap-archive@lists.ietf.org; Tue, 02 May 2006 16:40:06 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2742B430136 for ; Tue, 2 May 2006 13:40:02 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8525C4300A5 for ; Tue, 2 May 2006 13:39:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1209D1448022 for ; Tue, 2 May 2006 13:39:25 -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 3245D1448005 for ; Tue, 2 May 2006 13:39:23 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 02 May 2006 13:39:12 -0700 X-IronPort-AV: i="4.05,81,1146466800"; d="scan'208"; a="1800670251:sNHT1336797562" 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 k42KdBh0017075; Tue, 2 May 2006 13:39:12 -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, 2 May 2006 13:39:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] to mux or not to mux? Date: Tue, 2 May 2006 13:39:07 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D24C8C@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] to mux or not to mux? Thread-Index: AcZtT8EN8V7Vt6VsRq+YF404AFWIYAA2JFkw From: "Pat Calhoun (pacalhou)" To: "T. Charles Clancy" , "Scott G. Kelly" X-OriginalArrivalTime: 02 May 2006 20:39:11.0622 (UTC) FILETIME=[77EA2A60:01C66E28] 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 X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 I am not in favor of the MUX header. I believe that we need separation at the UDP layer, to allow existing hardware to be able to identify how to treat a packet using existing ACLs.=20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: T. Charles Clancy [mailto:clancy@cs.umd.edu]=20 > Sent: Monday, May 01, 2006 11:47 AM > To: Scott G. Kelly > Cc: capwap > Subject: Re: [Capwap] to mux or not to mux? >=20 > I think another drawback of the MUX header is that stock DTLS=20 > implementations will likely already have support for running=20 > over plain UDP. Thus any CAPWAP DTLS implementation might be=20 > a little less out-of-the-box. Of course, CAPWAP will need to=20 > muck with the DTLS state machine on a low level anyway, so=20 > it's unlikely any implementation would work out-of-the-box. >=20 > That being said, I'm personally in favor of the MUX header. >=20 > -- > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy >=20 >=20 > On Mon, 1 May 2006, Scott G. Kelly wrote: >=20 > > Some time ago, I proposed that we use a single port for capwap, and=20 > > insert a mux header right after the UDP header to differentiate=20 > > between control and data. While there was some discussion,=20 > we did not=20 > > reach a conclusion. > > > > Here's what it would look like: > > > > +---------+-------------+------------------------------- > > | UDP Hdr | MUX Hdr =3D 1 | DTLS Enc Control Packet .... > > +---------+-------------+---------------------- > > > > The capwap editors are currently working hard to produce the 01=20 > > version of the capwap document, and it would be best for=20 > implementers=20 > > if this question could be decided prior to publication of that=20 > > document. To facilitate this, I've summarized briefly below. > > > > Using separate ports for control/data has a number of drawbacks: > > > > - if firewalls are between the AC and WTP, multiple rules=20 > are required > > > > - we must be able to explicitly bind the data and control=20 > channels at=20 > > the AC in order to ensure proper operation; if they use the=20 > same port=20 > > (and therefore, flow), this is straightforward; if not, we must add=20 > > protocol elements for detecting and accounting for NATs along the=20 > > AC-WTP path, and for explicitly (and securely) creating the=20 > bindings=20 > > between the two channels > > > > - there are race conditions that must be dealt with; in=20 > particular, it=20 > > is possible to have the left hand (control channel) not knowing for=20 > > certain what the right hand (data channel) is doing (and vice versa) > > > > - If there *are* NATs along the path, using two ports will require=20 > > keepalives on both ports, and error handling for when one=20 > channel goes=20 > > away but the other does not (e.g. if a middlebox deletes the NAT=20 > > bindings for any reason) > > > > - there are many more error conditions to manage in the=20 > state machine,=20 > > due to the channel binding and NAT issues > > > > Clearly, using two ports adds *significant* complexity to the=20 > > implementation, and will likely result in operational=20 > problems in some=20 > > environments. > > > > Using a mux header has one drawback (that I can think of): > > > > - it adds n bytes to the header. I'm tempted to say n will be 4 for=20 > > 32-bit alignment, but it could also be only 1 or 2 bytes, if=20 > > bits-on-the-wire overhead is an overriding concern. > > > > Using a mux hader has several advantages: > > > > - we get NAT traversal for free, by simply configuring the echo=20 > > interval to be smaller than the NAT binding lifetime for=20 > the path in=20 > > question > > > > - we only open one port through intermediate firewalls (and any=20 > > intermediate NATs) > > > > - the implementation (state machine, error handling) is *much*=20 > > simpler, and therefore more likely to (inter)operate according to=20 > > spec > > > > We need to decide on this, preferably within the next day or two.=20 > > Please speak up and make your preferences known. > > > > 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 >=20 > Archives: http://lists.frascone.com/pipermail/capwap >=20 _________________________________________________________________ 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 May 02 16:59:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1yC-0001CJ-7A for capwap-archive@lists.ietf.org; Tue, 02 May 2006 16:59:44 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb1y8-0008Cg-FL for capwap-archive@lists.ietf.org; Tue, 02 May 2006 16:59:44 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8E4E5430149 for ; Tue, 2 May 2006 13:59:39 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 13DE14300A2 for ; Tue, 2 May 2006 13:59:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5CA7A1448032 for ; Tue, 2 May 2006 13:59:16 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by hermes.tigertech.net (Postfix) with ESMTP id 10770144801A for ; Tue, 2 May 2006 13:59:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=CSqW8wNMnJE7LuQbHKfP8xS8pTBsR98ZQx42TnMvY4GwIExu5URATKUFY9egP7zA; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.42] (helo=elwamui-muscovy.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Fb1xf-0007Xg-OW; Tue, 02 May 2006 16:59:11 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Tue, 2 May 2006 16:59:11 -0400 Message-ID: <28552476.1146603551751.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Date: Tue, 2 May 2006 13:59:11 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "Pat Calhoun (pacalhou)" Subject: RE: [Capwap] to mux or not to mux? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710a013193c7f9558a52b25a8a0ed02cdd0350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Hi Pat, Pat Calhoun wrote: >I am not in favor of the MUX header. I believe that we need separation >at the UDP layer, to allow existing hardware to be able to identify how >to treat a packet using existing ACLs. In the course of this thread and related ones, we've seen quite clearly that using multiple ports rather than one is very costly in terms of the added operational complexity. There are also implicit security considerations in separating the termination points for data and control channels. What existing hardware needs to be able to distinguish between these packets based on ports, and why? What specific, valuable real-world functionality is lost by using the mux header? Scott > >Pat Calhoun >CTO, Wireless Networking Business Unit >Cisco Systems > > > >> -----Original Message----- >> From: T. Charles Clancy [mailto:clancy@cs.umd.edu] >> Sent: Monday, May 01, 2006 11:47 AM >> To: Scott G. Kelly >> Cc: capwap >> Subject: Re: [Capwap] to mux or not to mux? >> >> I think another drawback of the MUX header is that stock DTLS >> implementations will likely already have support for running >> over plain UDP. Thus any CAPWAP DTLS implementation might be >> a little less out-of-the-box. Of course, CAPWAP will need to >> muck with the DTLS state machine on a low level anyway, so >> it's unlikely any implementation would work out-of-the-box. >> >> That being said, I'm personally in favor of the MUX header. >> >> -- >> t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy >> >> >> On Mon, 1 May 2006, Scott G. Kelly wrote: >> >> > Some time ago, I proposed that we use a single port for capwap, and >> > insert a mux header right after the UDP header to differentiate >> > between control and data. While there was some discussion, >> we did not >> > reach a conclusion. >> > >> > Here's what it would look like: >> > >> > +---------+-------------+------------------------------- >> > | UDP Hdr | MUX Hdr = 1 | DTLS Enc Control Packet .... >> > +---------+-------------+---------------------- >> > >> > The capwap editors are currently working hard to produce the 01 >> > version of the capwap document, and it would be best for >> implementers >> > if this question could be decided prior to publication of that >> > document. To facilitate this, I've summarized briefly below. >> > >> > Using separate ports for control/data has a number of drawbacks: >> > >> > - if firewalls are between the AC and WTP, multiple rules >> are required >> > >> > - we must be able to explicitly bind the data and control >> channels at >> > the AC in order to ensure proper operation; if they use the >> same port >> > (and therefore, flow), this is straightforward; if not, we must add >> > protocol elements for detecting and accounting for NATs along the >> > AC-WTP path, and for explicitly (and securely) creating the >> bindings >> > between the two channels >> > >> > - there are race conditions that must be dealt with; in >> particular, it >> > is possible to have the left hand (control channel) not knowing for >> > certain what the right hand (data channel) is doing (and vice versa) >> > >> > - If there *are* NATs along the path, using two ports will require >> > keepalives on both ports, and error handling for when one >> channel goes >> > away but the other does not (e.g. if a middlebox deletes the NAT >> > bindings for any reason) >> > >> > - there are many more error conditions to manage in the >> state machine, >> > due to the channel binding and NAT issues >> > >> > Clearly, using two ports adds *significant* complexity to the >> > implementation, and will likely result in operational >> problems in some >> > environments. >> > >> > Using a mux header has one drawback (that I can think of): >> > >> > - it adds n bytes to the header. I'm tempted to say n will be 4 for >> > 32-bit alignment, but it could also be only 1 or 2 bytes, if >> > bits-on-the-wire overhead is an overriding concern. >> > >> > Using a mux hader has several advantages: >> > >> > - we get NAT traversal for free, by simply configuring the echo >> > interval to be smaller than the NAT binding lifetime for >> the path in >> > question >> > >> > - we only open one port through intermediate firewalls (and any >> > intermediate NATs) >> > >> > - the implementation (state machine, error handling) is *much* >> > simpler, and therefore more likely to (inter)operate according to >> > spec >> > >> > We need to decide on this, preferably within the next day or two. >> > Please speak up and make your preferences known. >> > >> > 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 >> _________________________________________________________________ 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 May 03 02:17:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbAgH-00078C-Jw for capwap-archive@lists.ietf.org; Wed, 03 May 2006 02:17:49 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbAgF-00061Z-Ty for capwap-archive@lists.ietf.org; Wed, 03 May 2006 02:17:49 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D3F984300D8 for ; Tue, 2 May 2006 23:17:46 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 0FF82430093 for ; Tue, 2 May 2006 23:17:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id ED74B144801B for ; Tue, 2 May 2006 23:17:20 -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 34662144801A for ; Tue, 2 May 2006 23:17:17 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 02 May 2006 23:17:18 -0700 X-IronPort-AV: i="4.05,82,1146466800"; d="scan'208"; a="321479691:sNHT43444320" 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 k436HHRT019311; Tue, 2 May 2006 23:17:17 -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); Tue, 2 May 2006 23:17:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] to mux or not to mux? Date: Tue, 2 May 2006 23:17:16 -0700 Message-ID: <08A9A3213527A6428774900A80DBD8D801DD1B86@xmb-sjc-222.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] to mux or not to mux? Thread-Index: AcZt8VTMcMBwAlsvQ8WXIdqu6fujrAAhvipA From: "Nancy Winget (ncamwing)" To: "Scott G Kelly" X-OriginalArrivalTime: 03 May 2006 06:17:17.0456 (UTC) FILETIME=[3A486900:01C66E79] 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 X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Hi Scott, =20 -----Original Message----- From: Scott G Kelly [mailto:scott@hyperthought.com]=20 Sent: Tuesday, May 02, 2006 7:04 AM To: Nancy Winget (ncamwing) Cc: capwap Subject: Re: [Capwap] to mux or not to mux? Hi Nancy, Nancy Winget (ncamwing) wrote: > I don't believe adding a MUX is the right answer. First, the addition > is a change in DTLS and also brings up other issues of concern: No, this is a misconception: it is *not* a change to DTLS. It is a change to the openssl implementation of DTLS, but the fact is that you must demultiplex incoming DTLS messages prior to handing them to openssl in any event. I've said this several times before, but it must not have been clear, so let me try to get everyone to focus on this statement: You *cannot* use the stock openssl implementation without modification if you intend to support more than one WTP. You MUST modify it. This is NOT a modification of the DTLS spec, it's a modification of the OPENSSL IMPLEMENTATION. I hope that is clear. This modification is required because openssl was implemented with certain assumptions about "servers" that really depend on the tcp (connection-oriented) sockets abstraction, and these assumptions were naively carried forward into the (datagram) DTLS implementation. I have already corrected this in my implementation (and there's at least 2 ways to do it without even touching the openssl code), and it introduces absolutely no security-relevant concerns. Nothing is being changed in DTLS. Full stop. [NCW] While it may not be a change in DTLS, you are suggesting that changes be made to compensate for openSSL. What about other implementations and instantiations? I believe that adding this MUX will force a change with other non-open implementations of DTLS that may not be warranted. =20 > - distinguishing the control from data plane is a good thing as the=20 > firewall rules may be different for each plane which is already=20 > addressed by the UDP assignments. Please explain why firewalls (which ostensibly won't understand encapsulated 802.11 traffic) need separate packet filtering rules for a data plane that is tightly bound to the associated control channel. [NCW] I am referring to the CAPWAP control vs data frames, not 802.11 traffic. > - merging the control and data plane into a single UDP (dtls) tunnel=20 > forces the two planes to be synchronized from an anti-replay=20 > perspective. Huh? Please explain this statement, as I must be missing something.=20 LWAPP does this today, and has for, what, over 3 years now? I don't believe this has ever been a problem for LWAPP, but even if it were, it would not be for capwap. This is because the proposed mux header is outside of the capwap transport layer, and so capwap will not be aware of it. It will not interact with antireplay in specification-compliant implementation. [NCW] Same comment as above. LWAPP does this today by distinguishing them with separate UDP ports and I am advocating that the UDP port distinction is preferable. > This effectively restricts the architecture to force them to use a=20 > centralized DTLS encapsulation/decapsulation which imho is too=20 > restrictive DTLS en/decapsulation is completely independent of the MUX header, so this statement makes no sense to me. Am I missing something? [NCW] My reference here is not to the MUX but to the merging of the capwap control and data plane into a single port and thus a single DTLS en/decapsulation. Scott >=20 > Nancy. >=20 > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > Sent: Monday, May 01, 2006 11:38 AM > To: capwap > Subject: [Capwap] to mux or not to mux? >=20 > Some time ago, I proposed that we use a single port for capwap, and=20 > insert a mux header right after the UDP header to differentiate=20 > between control and data. While there was some discussion, we did not=20 > reach a conclusion. >=20 > Here's what it would look like: >=20 > +---------+-------------+------------------------------- > | UDP Hdr | MUX Hdr =3D 1 | DTLS Enc Control Packet .... > +---------+-------------+---------------------- >=20 > The capwap editors are currently working hard to produce the 01=20 > version of the capwap document, and it would be best for implementers=20 > if this question could be decided prior to publication of that=20 > document. To facilitate this, I've summarized briefly below. >=20 > Using separate ports for control/data has a number of drawbacks: >=20 > - if firewalls are between the AC and WTP, multiple rules are required >=20 > - we must be able to explicitly bind the data and control channels at=20 > the AC in order to ensure proper operation; if they use the same port=20 > (and therefore, flow), this is straightforward; if not, we must add=20 > protocol elements for detecting and accounting for NATs along the=20 > AC-WTP path, and for explicitly (and securely) creating the bindings=20 > between the two channels >=20 > - there are race conditions that must be dealt with; in particular, it > is possible to have the left hand (control channel) not knowing for=20 > certain what the right hand (data channel) is doing (and vice versa) >=20 > - If there *are* NATs along the path, using two ports will require=20 > keepalives on both ports, and error handling for when one channel goes > away but the other does not (e.g. if a middlebox deletes the NAT=20 > bindings for any reason) >=20 > - there are many more error conditions to manage in the state machine, > due to the channel binding and NAT issues >=20 > Clearly, using two ports adds *significant* complexity to the=20 > implementation, and will likely result in operational problems in some > environments. >=20 > Using a mux header has one drawback (that I can think of): >=20 > - it adds n bytes to the header. I'm tempted to say n will be 4 for=20 > 32-bit alignment, but it could also be only 1 or 2 bytes, if=20 > bits-on-the-wire overhead is an overriding concern. >=20 > Using a mux hader has several advantages: >=20 > - we get NAT traversal for free, by simply configuring the echo=20 > interval to be smaller than the NAT binding lifetime for the path in=20 > question >=20 > - we only open one port through intermediate firewalls (and any=20 > intermediate NATs) >=20 > - the implementation (state machine, error handling) is *much*=20 > simpler, and therefore more likely > to (inter)operate according to spec >=20 > We need to decide on this, preferably within the next day or two.=20 > Please speak up and make your preferences known. >=20 > Thanks, >=20 > Scott >=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 >=20 _________________________________________________________________ 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 May 03 10:54:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbIkc-0003wv-CD for capwap-archive@lists.ietf.org; Wed, 03 May 2006 10:54:50 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbIka-0003qs-Aa for capwap-archive@lists.ietf.org; Wed, 03 May 2006 10:54:50 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 52D1E4300E8 for ; Wed, 3 May 2006 07:54:47 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9528643006B for ; Wed, 3 May 2006 07:54:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B919E4311D9 for ; Wed, 3 May 2006 07:54:09 -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 225034311D4 for ; Wed, 3 May 2006 07:54:05 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id h30so138259wxd for ; Wed, 03 May 2006 07:54:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=cHNPtL9aOf8sKDSzkTIlwRpepxmUskvPghkqJ/CsPHXzsbNpFINUNd5YT4iXs6CpBjCKW1VQQ6k5kx8AseHHyYpcsetevUVWY+p1gclRMLHNM5OBuo6jmLPJ04iWjn03s6+ZrpoRQky9SGmSB3lUTNtL+SZ7rtKjRgguoOP12us= Received: by 10.70.11.18 with SMTP id 18mr382575wxk; Wed, 03 May 2006 07:54:04 -0700 (PDT) Received: by 10.70.6.8 with HTTP; Wed, 3 May 2006 07:54:04 -0700 (PDT) Message-ID: <5bfe7a820605030754o716d2afbna0207c4561ec2f55@mail.gmail.com> Date: Wed, 3 May 2006 07:54:04 -0700 From: "Dorothy Stanley" To: "Michael Montemurro" Subject: Re: [Capwap] to mux or not to mux? In-Reply-To: <26140d940605011215l64ebbf16j95c221770ba84bbc@mail.gmail.com> MIME-Version: 1.0 References: <15397353.1146510010324.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> <26140d940605011215l64ebbf16j95c221770ba84bbc@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 X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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="===============0304455168==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b --===============0304455168== Content-Type: multipart/alternative; boundary="----=_Part_24042_4630034.1146668044191" ------=_Part_24042_4630034.1146668044191 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Scott, Charles, I am also in favor of using the MUX header to distinguish control and data traffic versus using separate ports, for the reasons Mike references, and for the simplicity of the solution overall. Dorothy On 5/1/06, Michael Montemurro wrote: > > Scott, Charles, > > For the reasons below, I'm in favor of using a MUX header to distinguish > control from data traffic versus using separate ports. > > Cheers, > > Mike > > > > On 5/1/06, Scott G. Kelly wrote: > > > > T. Charles Clancy wrote: > > > > >I think another drawback of the MUX header is that stock DTLS > > >implementations will likely already have support for running over plai= n > > > > >UDP. Thus any CAPWAP DTLS implementation might be a little less > > >out-of-the-box. Of course, CAPWAP will need to muck with the DTLS > > state > > >machine on a low level anyway, so it's unlikely any implementation > > would > > >work out-of-the-box. > > > > > >That being said, I'm personally in favor of the MUX header. > > > > Actually, stock DTLS implementations (openssl in particular) can't > > handle multiple clients on a single socket "connection" without adding = some > > intermediate de-muxing anyway, so as you say, it won't work out-of-the-= box > > regardless. > > > > FWIW, I already have mux header code running with openssl. It was prett= y > > straightforward to implement. > > > > --Scott > > > > >-- > > >t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > > > > > > > >On Mon, 1 May 2006, Scott G. Kelly wrote: > > > > > >> Some time ago, I proposed that we use a single port for capwap, and > > >> insert a mux header right after the UDP header to differentiate > > between > > >> control and data. While there was some discussion, we did not reach = a > > >> conclusion. > > >> > > >> Here's what it would look like: > > >> > > >> +---------+-------------+------------------------------- > > >> | UDP Hdr | MUX Hdr =3D 1 | DTLS Enc Control Packet .... > > >> +---------+-------------+---------------------- > > >> > > >> The capwap editors are currently working hard to produce the 01 > > version > > >> of the capwap document, and it would be best for implementers if thi= s > > >> question could be decided prior to publication of that document. To > > >> facilitate this, I've summarized briefly below. > > >> > > >> Using separate ports for control/data has a number of drawbacks: > > >> > > >> - if firewalls are between the AC and WTP, multiple rules are > > required > > >> > > >> - we must be able to explicitly bind the data and control channels a= t > > >> the AC in order to ensure proper operation; if they use the same por= t > > >> (and therefore, flow), this is straightforward; if not, we must add > > >> protocol elements for detecting and accounting for NATs along the > > AC-WTP > > >> path, and for explicitly (and securely) creating the bindings betwee= n > > >> the two channels > > >> > > >> - there are race conditions that must be dealt with; in particular, > > it > > >> is possible to have the left hand (control channel) not knowing for > > >> certain what the right hand (data channel) is doing (and vice versa) > > >> > > >> - If there *are* NATs along the path, using two ports will require > > >> keepalives on both ports, and error handling for when one channel > > goes > > >> away but the other does not (e.g. if a middlebox deletes the NAT > > >> bindings for any reason) > > >> > > >> - there are many more error conditions to manage in the state > > machine, > > >> due to the channel binding and NAT issues > > >> > > >> Clearly, using two ports adds *significant* complexity to the > > >> implementation, and will likely result in operational problems in > > some > > >> environments. > > >> > > >> Using a mux header has one drawback (that I can think of): > > >> > > >> - it adds n bytes to the header. I'm tempted to say n will be 4 for > > >> 32-bit alignment, but it could also be only 1 or 2 bytes, if > > >> bits-on-the-wire overhead is an overriding concern. > > >> > > >> Using a mux hader has several advantages: > > >> > > >> - we get NAT traversal for free, by simply configuring the echo > > interval > > >> to be smaller than the NAT binding lifetime for the path in question > > >> > > >> - we only open one port through intermediate firewalls (and any > > >> intermediate NATs) > > >> > > >> - the implementation (state machine, error handling) is *much* > > simpler, > > >> and therefore more likely > > >> to (inter)operate according to spec > > >> > > >> We need to decide on this, preferably within the next day or two. > > Please > > >> speak up and make your preferences known. > > >> > > >> 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 > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_24042_4630034.1146668044191 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Scott, Charles,

I am also in favor of using the MUX header to distinguish control and data = traffic
versus using separate ports, for the reasons Mike references, and for the simplicity of the solution overall.

Dorothy

On 5/1/06, Michael Montemurro <montemurro.michael@gmail.com> wrote:
Scott, Charles,
 
For the reasons below, I'm in favor of using a MUX header to distingui= sh control from data traffic versus using separate ports.
 
Cheers,
 
          Mike


 
On 5/1/06, S= cott G. Kelly <s.kelly@ix.n= etcom.com > wrote:
T. Charles Clancy= wrote:

>I think another drawback of the MUX header is that stock= DTLS
>implementations will likely already have support for running over p= lain
>UDP.  Thus any CAPWAP DTLS implementation might be a litt= le less
>out-of-the-box.  Of course, CAPWAP will need to mu= ck with the DTLS state
>machine on a low level anyway, so it's unlike= ly any implementation would
>work out-of-the-box.
>
>That being said, I'm personally= in favor of the MUX header.

Actually, stock DTLS implementations (openssl in particular) can't handle multiple clients on a single socket "connection" without adding s= ome intermediate de-muxing anyway, so as you say, it won't work out-of-the-box regardless.

FWIW, I already have mux header code running with openssl. It was p= retty straightforward to implement.

--Scott

>--
>t. = charles clancy, ph.d.  |  www.cs.umd.edu/~clancy
&= gt;
>
>On Mon, 1 May 2006, Scott G. Kelly wrote:
>
>= ;> Some time ago, I proposed that we use a single port for capwap, and
>> insert a mux header right after the UDP header to differentiate be= tween
>> control and data. While there was some discussion, we did= not reach a
>> conclusion.
>>
>> Here's what it= would look like:
>>
>> +---------+-------------+-------------------------= ------
>> | UDP Hdr | MUX Hdr =3D 1 | DTLS Enc Control Packet ....=
>> +---------+-------------+----------------------
>>
>> The capwap editors are currently working hard to produce the 01 ve= rsion
>> of the capwap document, and it would be best for implemen= ters if this
>> question could be decided prior to publication of = that document. To
>> facilitate this, I've summarized briefly below.
>>>> Using separate ports for control/data has a number of drawbacks:<= br>>>
>> - if firewalls are between the AC and WTP, multiple= rules are required
>>
>> - we must be able to explicitly bind the data and = control channels at
>> the AC in order to ensure proper operation;= if they use the same port
>> (and therefore, flow), this is strai= ghtforward; if not, we must add
>> protocol elements for detecting and accounting for NATs along = the AC-WTP
>> path, and for explicitly (and securely) creating the= bindings between
>> the two channels
>>
>> - th= ere are race conditions that must be dealt with; in particular, it
>> is possible to have the left hand (control channel) not knowin= g for
>> certain what the right hand (data channel) is doing (and = vice versa)
>>
>> - If there *are* NATs along the path, u= sing two ports will require
>> keepalives on both ports, and error handling for when one chan= nel goes
>> away but the other does not (e.g. if a middlebox delet= es the NAT
>> bindings for any reason)
>>
>> - t= here are many more error conditions to manage in the state machine,
>> due to the channel binding and NAT issues
>>
>&= gt; Clearly, using two ports adds *significant* complexity to the
>&g= t; implementation, and will likely result in operational problems in some
>> environments.
>>
>> Using a mux header has o= ne drawback (that I can think of):
>>
>> - it adds n byte= s to the header. I'm tempted to say n will be 4 for
>> 32-bit alig= nment, but it could also be only 1 or 2 bytes, if
>> bits-on-the-wire overhead is an overriding concern.
>>= ;
>> Using a mux hader has several advantages:
>>
>= > - we get NAT traversal for free, by simply configuring the echo interv= al
>> to be smaller than the NAT binding lifetime for the path in qu= estion
>>
>> - we only open one port through intermediate= firewalls (and any
>> intermediate NATs)
>>
>> = - the implementation (state machine, error handling) is *much* simpler,
>> and therefore more likely
>>  to (inter)ope= rate according to spec
>>
>> We need to decide on this, p= referably within the next day or two. Please
>> speak up and make = your preferences known.
>>
>> Thanks,
>>
>> Scott
>><= br>>> _______________________________________________________________= __
>> To unsubscribe or modify your subscription options, please v= isit:
>> = http://lists.frascone.com/mailman/listinfo/capwap
>>
>&g= t; Archives:=20 http://lists.frascon= e.com/pipermail/capwap
>>

___________________________________________________= ______________
To unsubscribe or modify your subscription options, pleas= e visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.co= m/pipermail/capwap


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

Archives: http://lists.frascone.co= m/pipermail/capwap


------=_Part_24042_4630034.1146668044191-- --===============0304455168== 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 --===============0304455168==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 03 11:41:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbJTv-0000ud-Mt for capwap-archive@lists.ietf.org; Wed, 03 May 2006 11:41:39 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbJTu-0005Gs-1q for capwap-archive@lists.ietf.org; Wed, 03 May 2006 11:41:39 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A866B4300D8 for ; Wed, 3 May 2006 08:41:36 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B2BA843006B for ; Wed, 3 May 2006 08:41:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9F8FA398029 for ; Wed, 3 May 2006 08:41:12 -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 8F07E39802B for ; Wed, 3 May 2006 08:41:09 -0700 (PDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 03 May 2006 08:41:07 -0700 X-IronPort-AV: i="4.05,85,1146466800"; d="scan'208"; a="1800963413:sNHT2834563606" 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 k43Ff6VI001058; Wed, 3 May 2006 08:41:06 -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, 3 May 2006 08:41:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] to mux or not to mux? Date: Wed, 3 May 2006 08:41:03 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D24F39@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] to mux or not to mux? Thread-Index: AcZuK0S45sXA0reRSRSrbM9zSyhK1gAA3ckw From: "Pat Calhoun (pacalhou)" To: "Scott G. Kelly" X-OriginalArrivalTime: 03 May 2006 15:41:06.0698 (UTC) FILETIME=[FE1516A0:01C66EC7] 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e > In the course of this thread and related ones, we've seen=20 > quite clearly that using multiple ports rather than one is=20 > very costly in terms of the added operational complexity.=20 I agree - but I still contend that this is an area where the added cost can be justified. > There are also implicit security considerations in separating=20 > the termination points for data and control channels. This is a separate issue, and not one that I am using in this argument > What existing hardware needs to be able to distinguish=20 > between these packets based on ports, and why? What specific,=20 > valuable real-world functionality is lost by using the mux header? The reality is that UDP port based ACLs is a known science today, and being able to use this existing mechanism to determine how to handle a packet has significant value. The alternative requires that we dig much deeper into the packet to determine whether it is control or data. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com]=20 > Sent: Tuesday, May 02, 2006 1:59 PM > To: Pat Calhoun (pacalhou) > Cc: capwap > Subject: RE: [Capwap] to mux or not to mux? >=20 > Hi Pat, >=20 > Pat Calhoun wrote: >=20 > >I am not in favor of the MUX header. I believe that we need=20 > separation=20 > >at the UDP layer, to allow existing hardware to be able to=20 > identify how=20 > >to treat a packet using existing ACLs. >=20 >=20 > Scott >=20 > > > >Pat Calhoun > >CTO, Wireless Networking Business Unit > >Cisco Systems > > > >=20 > > > >> -----Original Message----- > >> From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > >> Sent: Monday, May 01, 2006 11:47 AM > >> To: Scott G. Kelly > >> Cc: capwap > >> Subject: Re: [Capwap] to mux or not to mux? > >>=20 > >> I think another drawback of the MUX header is that stock DTLS=20 > >> implementations will likely already have support for running over=20 > >> plain UDP. Thus any CAPWAP DTLS implementation might be a little=20 > >> less out-of-the-box. Of course, CAPWAP will need to muck with the=20 > >> DTLS state machine on a low level anyway, so it's unlikely any=20 > >> implementation would work out-of-the-box. > >>=20 > >> That being said, I'm personally in favor of the MUX header. > >>=20 > >> -- > >> t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > >>=20 > >>=20 > >> On Mon, 1 May 2006, Scott G. Kelly wrote: > >>=20 > >> > Some time ago, I proposed that we use a single port for=20 > capwap, and=20 > >> > insert a mux header right after the UDP header to differentiate=20 > >> > between control and data. While there was some discussion, > >> we did not > >> > reach a conclusion. > >> > > >> > Here's what it would look like: > >> > > >> > +---------+-------------+------------------------------- > >> > | UDP Hdr | MUX Hdr =3D 1 | DTLS Enc Control Packet .... > >> > +---------+-------------+---------------------- > >> > > >> > The capwap editors are currently working hard to produce the 01=20 > >> > version of the capwap document, and it would be best for > >> implementers > >> > if this question could be decided prior to publication of that=20 > >> > document. To facilitate this, I've summarized briefly below. > >> > > >> > Using separate ports for control/data has a number of drawbacks: > >> > > >> > - if firewalls are between the AC and WTP, multiple rules > >> are required > >> > > >> > - we must be able to explicitly bind the data and control > >> channels at > >> > the AC in order to ensure proper operation; if they use the > >> same port > >> > (and therefore, flow), this is straightforward; if not,=20 > we must add=20 > >> > protocol elements for detecting and accounting for NATs=20 > along the=20 > >> > AC-WTP path, and for explicitly (and securely) creating the > >> bindings > >> > between the two channels > >> > > >> > - there are race conditions that must be dealt with; in > >> particular, it > >> > is possible to have the left hand (control channel) not=20 > knowing for=20 > >> > certain what the right hand (data channel) is doing (and vice=20 > >> > versa) > >> > > >> > - If there *are* NATs along the path, using two ports=20 > will require=20 > >> > keepalives on both ports, and error handling for when one > >> channel goes > >> > away but the other does not (e.g. if a middlebox deletes the NAT=20 > >> > bindings for any reason) > >> > > >> > - there are many more error conditions to manage in the > >> state machine, > >> > due to the channel binding and NAT issues > >> > > >> > Clearly, using two ports adds *significant* complexity to the=20 > >> > implementation, and will likely result in operational > >> problems in some > >> > environments. > >> > > >> > Using a mux header has one drawback (that I can think of): > >> > > >> > - it adds n bytes to the header. I'm tempted to say n=20 > will be 4 for=20 > >> > 32-bit alignment, but it could also be only 1 or 2 bytes, if=20 > >> > bits-on-the-wire overhead is an overriding concern. > >> > > >> > Using a mux hader has several advantages: > >> > > >> > - we get NAT traversal for free, by simply configuring the echo=20 > >> > interval to be smaller than the NAT binding lifetime for > >> the path in > >> > question > >> > > >> > - we only open one port through intermediate firewalls (and any=20 > >> > intermediate NATs) > >> > > >> > - the implementation (state machine, error handling) is *much*=20 > >> > simpler, and therefore more likely to (inter)operate=20 > according to=20 > >> > spec > >> > > >> > We need to decide on this, preferably within the next=20 > day or two.=20 > >> > Please speak up and make your preferences known. > >> > > >> > 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 > >>=20 > >> Archives: http://lists.frascone.com/pipermail/capwap > >>=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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 03 11:42:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbJUh-00015m-Jp for capwap-archive@lists.ietf.org; Wed, 03 May 2006 11:42:27 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbJUg-0005HM-64 for capwap-archive@lists.ietf.org; Wed, 03 May 2006 11:42:27 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 645F1430141 for ; Wed, 3 May 2006 08:42:24 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7D20D43006B for ; Wed, 3 May 2006 08:41:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2CE1843129C for ; Wed, 3 May 2006 08:41:46 -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 05AAB431292 for ; Wed, 3 May 2006 08:41:42 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 03 May 2006 08:41:42 -0700 X-IronPort-AV: i="4.05,85,1146466800"; d="scan'208"; a="272468882:sNHT27946136" 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 k43Fffh0007085; Wed, 3 May 2006 08:41:41 -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, 3 May 2006 08:41:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] to mux or not to mux? Date: Wed, 3 May 2006 08:41:40 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D24F3A@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] to mux or not to mux? Thread-Index: AcZt8VTMcMBwAlsvQ8WXIdqu6fujrAAhvipAABPsuaA= From: "Pat Calhoun (pacalhou)" To: "Nancy Winget (ncamwing)" , "Scott G Kelly" X-OriginalArrivalTime: 03 May 2006 15:41:41.0868 (UTC) FILETIME=[130B9AC0:01C66EC8] 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 X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 > You *cannot* use the stock openssl implementation without=20 > modification if you intend to support more than one WTP. You=20 > MUST modify it. This is NOT a modification of the DTLS spec,=20 > it's a modification of the OPENSSL IMPLEMENTATION. And I contend there is significant value in being able to use this library as-is. 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 May 03 12:06:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbJs0-0008Oy-I0 for capwap-archive@lists.ietf.org; Wed, 03 May 2006 12:06:32 -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 1FbIYH-00031u-Po for capwap-archive@lists.ietf.org; Wed, 03 May 2006 10:42:05 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FbI28-0005WW-2o for capwap-archive@lists.ietf.org; Wed, 03 May 2006 10:08:54 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6F30B43011D for ; Wed, 3 May 2006 07:08:50 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D810343006B for ; Wed, 3 May 2006 07:08:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3DA9143111F for ; Wed, 3 May 2006 07:08:16 -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 02143431122 for ; Wed, 3 May 2006 07:08:10 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id h30so129309wxd for ; Wed, 03 May 2006 07:08:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=tapZ6NnemJUMglHN+yh/A/yRPhlz8dgNOf5C3DRfXNpgdlFLqeGoFNZlftbk9XSAFAtWgUKsdLex5u8595g1SuQBLLiuFJS5YA/smk63/4kF5CBtYpCJ3quSAqLCtEWRjke0If53GkgV8d+tPyc/yXiXhipnsf6sY6tAuo1Qp3Y= Received: by 10.70.43.19 with SMTP id q19mr116140wxq; Wed, 03 May 2006 07:08:08 -0700 (PDT) Received: by 10.70.6.8 with HTTP; Wed, 3 May 2006 07:08:08 -0700 (PDT) Message-ID: <5bfe7a820605030708y3efc951cya2790bbf06cbcf44@mail.gmail.com> Date: Wed, 3 May 2006 07:08:08 -0700 From: "Dorothy Stanley" To: "Pat Calhoun (pacalhou)" Subject: Re: [Capwap] Issue 50: Increase maximum number of BSSs In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201D24C84@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A201D24C84@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 X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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="===============0616086406==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.4 (--) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 --===============0616086406== Content-Type: multipart/alternative; boundary="----=_Part_22722_13020751.1146665288611" ------=_Part_22722_13020751.1146665288611 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Agreed that The number of BSSID supported is already in "IEEE 802.11 WTP WLAN Radio Configuration". However, the IEEE 802.11 WTP WLAN Radio Configuration, as currently specified is "used by the AC to configure a radio on the WTP", though the message element bindings indicate inclusion of the message element in e.g. Config Request - coming from the WTP. Suggest that we modify the text in -00 section 11.9.1, "IEEE WTP WLAN Radio Configuration" to indicate that the message element is also used to by the WTP to notify the AC of the number of BSSIDs the radio is capable of supporting, when the message element is included in the Configure Request (now Configure Status) message. Dorothy On 5/2/06, Pat Calhoun (pacalhou) wrote: > > The number of BSSID supported is already in "IEEE 802.11 WTP WLAN Radio > Configuration". > > That said, you are correct that the issue name is incorrect. However, the > issue raised is incorrect as the does exist a way for the WTP to provide > this info to the AC. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > ------------------------------ > *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] > *Sent:* Tuesday, May 02, 2006 11:26 AM > *To:* Jim Murphy > *Cc:* capwap > *Subject:* Re: [Capwap] Issue 50: Increase maximum number of BSSs > > All, > > Looking at the original Issue 50 text: > > > > > Page 34, Section 5.1.3. LWAPP seems to assume that WLAN > > radios will support > > 16 BSS's per Radio. It would be better not assume that every > > WTP supports 16 radios and add a field to indicate the number > > of virtual networks per radio. > At one point, the sheer number of beacons will saturate the air waves, > so we need to pick a maximum. What number do we want? > > I think the issue name does not match the comment. > It's not clear that the commenter is asking for more than 16 BSSIDs, but > rather notes that the full > 16 are assumed to be supported at the WTP. What if the WTP only supports > 4? There is no way currently > for the WTP to communicate this to the AP. Section 5.1.3 is the WTP Radio > information message element. > One solution would be to add a "Number of BSSIDs supported" field to that > message element. > Another solution would be to add a new IEEE 802.11 message element, to > indicate the number of > BSSIDs supported, and include that new message element in the appropriate > messages. I suggest the > later, to keep BSSIDs in the .11 binding definition. And, > separately, keep the max at 16 BSSIDs. > > > Dorothy > > > On 5/1/06, Jim Murphy wrote: > > > > It seems that the limit of 16 BSSIDs is primarily motivated > > by this WLAN/Status field in the data header. Perhaps the WLAN/Status > > field should be a broadcast domain identifier (a .1q tag or VLANID). > > WTPs should then be told of the VLANID to BSSID/broadcast-key mapping > > via control plane messages and replicate packets accordingly. > > > > If a VLANID is used in place of this bitmap, the protocol will scale > > better. With the current proposal, I am concerned about WTPs that have > > many radios or offer multiple VLANs per BSSID. > > > > Thanks, > > > > Jim > > > > Pat Calhoun (pacalhou) wrote: > > > > > > I would recommend that we reject this issue. 16 BSSIDs is a large > > > number, and the overhead in generating 16 or more beacons outweighs > > the > > > usefullness in advertising that many networks. > > > > > > 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 > > > > ------=_Part_22722_13020751.1146665288611 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Agreed that

The=20 number of BSSID supported is already in "IEEE 802.11 WTP WLAN Radio=20 Configuration".

However, the IEEE 802.11 WTP WLAN Radio Configuration, as currently specified is "used by the AC to configure a radio on the WTP", th= ough
the message element bindings indicate inclusion of the message element in e= .g. Config Request - coming from the WTP.

Suggest that we modify the text in -00 section 11.9.1, "IEEE WTP WLAN Radio Configuration" to indicate that the message element is also used to
by the WTP to notify the AC of the number of BSSIDs the radio is capable of supporting, when the message element is included in the
Configure Request (now Configure Status) message.

Dorothy

On 5/2/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
The=20 number of BSSID supported is already in "IEEE 802.11 WTP WLAN Radio=20 Configuration".
=  
That=20 said, you are correct that the issue name is incorrect. However, the issue= =20 raised is incorrect as the does exist a way for the WTP to provide this inf= o to=20 the AC.
 

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

 

All,
 
Looking at the original Issue 50 text:
 
 
> Page 34, Section 5.1.3. LWAPP seems to assume =
that WLAN 
> radios will support
> 16 BSS's per Radio. It would=
 be better not assume that every 
> WTP supports 16 radios and add a =
field to indicate the number=20

> of virtual networks per radio.
At one point, the sheer number o=
f beacons will saturate the air waves,
so we need to pick a maximum. Wha=
t number do we want?
I think the issue name does not match the comment.
It's not clear that the commenter is asking for more than 16 BSSIDs,= but=20 rather notes that the full
16 are assumed to be supported at the WTP.  What if the WTP onl= y=20 supports 4? There is no way currently
for the WTP to communicate this to the AP. Section 5.1.3 is the WTP = Radio=20 information message element.
One solution would be to add a "Number of BSSIDs supported"= ; field to that=20 message element.
Another solution would be to add a new IEEE 802.11 message element, = to=20 indicate the number of
BSSIDs supported, and include that new message element in the approp= riate=20 messages. I suggest the
later, to keep BSSIDs in the .11 binding definition. And,=20 separately, keep the max at 16 BSSIDs.
 
 
Dorothy

 
On 5/1/06, Jim=20 Murphy <jmurphy@tra= pezenetworks.com>=20 wrote:=20
It=20 seems that the limit of 16 BSSIDs is primarily motivated
by this=20 WLAN/Status field in the data header. Perhaps the WLAN/Status
field= =20 should be a broadcast domain identifier (a .1q tag or VLANID).
WTPs= =20 should then be told of the VLANID to BSSID/broadcast-key mapping
via= =20 control plane messages and replicate packets accordingly.

If a V= LANID=20 is used in place of this bitmap, the protocol will scale
better. Wi= th=20 the current proposal, I am concerned about WTPs that have
many radio= s or=20 offer multiple VLANs per BSSID.

Thanks,

Jim

Pat Ca= lhoun=20 (pacalhou) wrote:
>
> I would recommend that we reject this= =20 issue. 16 BSSIDs is a large
> number, and the overhead in genera= ting=20 16 or more beacons outweighs the
> usefullness in advertising tha= t=20 many networks.
>
> Pat Calhoun
> CTO, Wireless Networ= king=20 Business Unit
> Cisco Systems
>=20 _________________________________________________________________
&g= t; 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

______= ___________________________________________________________
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.fras= cone.com/mailman/listinfo/capwap

Archives:=20 http://lists.fra= scone.com/pipermail/capwap=20


------=_Part_22722_13020751.1146665288611-- --===============0616086406== 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 --===============0616086406==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 03 12:49:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbKXp-0002qf-Du for capwap-archive@lists.ietf.org; Wed, 03 May 2006 12:49:45 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbKXm-00080Z-Oi for capwap-archive@lists.ietf.org; Wed, 03 May 2006 12:49:45 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C33924300B7 for ; Wed, 3 May 2006 09:49:33 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7806C4300B7 for ; Wed, 3 May 2006 09:49:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 31092431391 for ; Wed, 3 May 2006 09:49:01 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by hermes.tigertech.net (Postfix) with ESMTP id D892543139C for ; Wed, 3 May 2006 09:48:57 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id g2so163950nfe for ; Wed, 03 May 2006 09:48:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=KKjRLb8oYrhIsCucptbD+qiuMoCpZlyq1yrab+RY/kIN0/MZp1HDoz5GLJIc2GVUbMCp2UPFqe3ze0UkHeS2PRA6awwbGW1urBx0GGFYmgVxY+tArgJVGp80Wmt1o030OtosZ7uorGFmCoMqyWjCruvG7v5q7ME6TL+3+/6Mg1w= Received: by 10.48.108.2 with SMTP id g2mr61211nfc; Wed, 03 May 2006 09:48:56 -0700 (PDT) Received: by 10.49.57.12 with HTTP; Wed, 3 May 2006 09:48:56 -0700 (PDT) Message-ID: <1013407b0605030948j791fe4d9tcf9b28b3b7469656@mail.gmail.com> Date: Wed, 3 May 2006 09:48:56 -0700 From: Puneet To: "Scott G. Kelly" Subject: Re: [Capwap] to mux or not to mux? In-Reply-To: <21852423.1146508699189.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> MIME-Version: 1.0 References: <21852423.1146508699189.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.5 tagged_above=-999.0 required=7.0 tests=HTML_20_30, HTML_MESSAGE, RCVD_BY_IP X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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="===============1336957903==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff --===============1336957903== Content-Type: multipart/alternative; boundary="----=_Part_69270_29965565.1146674936002" ------=_Part_69270_29965565.1146674936002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I would vote for having the Mux header instead of using two separate UDP ports. Thanks, Puneet On 5/1/06, Scott G. Kelly wrote: > > Some time ago, I proposed that we use a single port for capwap, and inser= t > a mux header right after the UDP header to differentiate between control = and > data. While there was some discussion, we did not reach a conclusion. > > Here's what it would look like: > > +---------+-------------+------------------------------- > | UDP Hdr | MUX Hdr =3D 1 | DTLS Enc Control Packet .... > +---------+-------------+---------------------- > > The capwap editors are currently working hard to produce the 01 version o= f > the capwap document, and it would be best for implementers if this questi= on > could be decided prior to publication of that document. To facilitate thi= s, > I've summarized briefly below. > > Using separate ports for control/data has a number of drawbacks: > > - if firewalls are between the AC and WTP, multiple rules are required > > - we must be able to explicitly bind the data and control channels at the > AC in order to ensure proper operation; if they use the same port (and > therefore, flow), this is straightforward; if not, we must add protocol > elements for detecting and accounting for NATs along the AC-WTP path, and > for explicitly (and securely) creating the bindings between the two chann= els > > > - there are race conditions that must be dealt with; in particular, it is > possible to have the left hand (control channel) not knowing for certain > what the right hand (data channel) is doing (and vice versa) > > - If there *are* NATs along the path, using two ports will require > keepalives on both ports, and error handling for when one channel goes aw= ay > but the other does not (e.g. if a middlebox deletes the NAT bindings for > any reason) > > - there are many more error conditions to manage in the state machine, du= e > to the channel binding and NAT issues > > Clearly, using two ports adds *significant* complexity to the > implementation, and will likely result in operational problems in some > environments. > > Using a mux header has one drawback (that I can think of): > > - it adds n bytes to the header. I'm tempted to say n will be 4 for 32-bi= t > alignment, but it could also be only 1 or 2 bytes, if bits-on-the-wire > overhead is an overriding concern. > > Using a mux hader has several advantages: > > - we get NAT traversal for free, by simply configuring the echo interval > to be smaller than the NAT binding lifetime for the path in question > > - we only open one port through intermediate firewalls (and any > intermediate NATs) > > - the implementation (state machine, error handling) is *much* simpler, > and therefore more likely > to (inter)operate according to spec > > We need to decide on this, preferably within the next day or two. Please > speak up and make your preferences known. > > 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 > ------=_Part_69270_29965565.1146674936002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I would vote for having the Mux header instead of using two separate UDP po= rts.

Thanks,
Puneet

On 5/= 1/06, Scott G. Kelly <s.kelly@ix.netcom.com= > wrote:
Some time ago, I proposed that we use a single port for capwap, and insert = a mux header right after the UDP header to differentiate between control an= d data. While there was some discussion, we did not reach a conclusion.

Here's what it would look like:

+---------+-------------+---= ----------------------------
| UDP Hdr | MUX Hdr =3D 1 | DTLS Enc Contro= l Packet ....
+---------+-------------+----------------------

The capwap editors are currently working hard to produce the 01 version of = the capwap document, and it would be best for implementers if this question= could be decided prior to publication of that document. To facilitate this= , I've summarized briefly below.

Using separate ports for control/data has a number of drawbacks:
- if firewalls are between the AC and WTP, multiple rules are required=

- we must be able to explicitly bind the data and control channels = at the AC in order to ensure proper operation; if they use the same port (a= nd therefore, flow), this is straightforward; if not, we must add protocol = elements for detecting and accounting for NATs along the AC-WTP path, and f= or explicitly (and securely) creating the bindings between the two channels

- there are race conditions that must be dealt with; in particular,= it is possible to have the left hand (control channel) not knowing for cer= tain what the right hand (data channel) is doing (and vice versa)

- If there *are* NATs along the path, using two ports will require keepaliv= es on both ports, and error handling for when one channel goes away but the= other does not (e.g. if a middlebox deletes the NAT bindings for any reaso= n)

- there are many more error conditions to manage in the state machi= ne, due to the channel binding and NAT issues

Clearly, using two por= ts adds *significant* complexity to the implementation, and will likely res= ult in operational problems in some environments.

Using a mux header has one drawback (that I can think of):

-= it adds n bytes to the header. I'm tempted to say n will be 4 for 32-bit a= lignment, but it could also be only 1 or 2 bytes, if bits-on-the-wire overh= ead is an overriding concern.

Using a mux hader has several advantages:

- we get NAT trave= rsal for free, by simply configuring the echo interval to be smaller than t= he NAT binding lifetime for the path in question

- we only open one = port through intermediate firewalls (and any intermediate NATs)

- the implementation (state machine, error handling) is *much* simp= ler, and therefore more likely
  to (inter)operate according t= o spec

We need to decide on this, preferably within the next day or = two. Please speak up and make your preferences known.

Thanks,

Scott

_______________________________________= __________________________
To unsubscribe or modify your subscription op= tions, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.co= m/pipermail/capwap

------=_Part_69270_29965565.1146674936002-- --===============1336957903== 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 --===============1336957903==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 03 13:12:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbKth-0000qs-HB for capwap-archive@lists.ietf.org; Wed, 03 May 2006 13:12:21 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbKtg-0000lV-1Z for capwap-archive@lists.ietf.org; Wed, 03 May 2006 13:12:21 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6C4FD4300D5 for ; Wed, 3 May 2006 10:12:19 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8F66443004F for ; Wed, 3 May 2006 10:11:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7ADC34313FC for ; Wed, 3 May 2006 10:11:58 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by hermes.tigertech.net (Postfix) with ESMTP id 8A496431402 for ; Wed, 3 May 2006 10:11:55 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x37so171438nfc for ; Wed, 03 May 2006 10:11:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nAneJLgkLJhG9ML4NBsbl8Cdv0DToZ2ef1xPcueNMKeh/RIo3928kw46LywO2QDhSH0UiegJ0jIVaqdhIyq7F2q+6ymIitP5BYxoleJGh4XOHSOqhZhFsi3uWlG81jgW3HWaIkcbfy/GkMp3rkuqnrVaos/YYqbvqtQZ29oApLk= Received: by 10.49.75.4 with SMTP id c4mr852349nfl; Wed, 03 May 2006 10:11:54 -0700 (PDT) Received: by 10.49.57.12 with HTTP; Wed, 3 May 2006 10:11:54 -0700 (PDT) Message-ID: <1013407b0605031011j2fa1346aj61ea229b8f0cbcb0@mail.gmail.com> Date: Wed, 3 May 2006 10:11:54 -0700 From: Puneet To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201CBA52B@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4FF84B0BC277FF45AA27FE969DD956A201CBA52B@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=RCVD_BY_IP X-Spam-Level: Cc: capwap@frascone.com Subject: [Capwap] Re: Issues 101: 11.8.1.1 Change to re-use 802.11 Information element definitions X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 > 1. does the encryption policy refer to broadcast traffic or > unicast too? If its also unicast, then there could be multiple > encryption types enabled at the same type on the WLAN, in that case how > is the encryption-policy field filled in? > > > This is a good question as the text is obviously not clear enough. I am > proposing the following text (as well as for the Update WLAN section): > > Encryption Policy: A 32-bit value specifying the encryption scheme > to apply to traffic to and from the mobile station. this might also be a good place to note that the format of those 32 bits is the same as what the IEEE 802.11i specification mentions. That allows vendor specific encryption types, and can also be updated by IEEE for new types without having to update the CAPWAP specification. > 2. for the encryption policies we could use the format used in > the RSN IEs (OUI + encryption_type); that allows support for different > vendor specific encryption types in a clean manner (CKIP for example > would then use the Cisco OUI, instead of being clubbed together with the > other 'standard' encryption types; and it makes it easier for vendors to > not step on each others toes). > > > Based on Dorothy's e-mail and recommendation, I would propose the > following new section: > > 11.8.1.4. IEEE 802.11 Information Element > > The IEEE 802.11 Information Element is used to communicate any IE > defined in the IEEE 802.11 protocol. The data field contains the raw > IE as it would be included within an IEEE 802.11 MAC management > message. I think my request was to change the encryption-type to use the IEEE 802.11i format, but thats now what this element seems to do. Can we replace those list of numbers 1,2,3,4,5 for encryption types since in the current text they mix standard and vendor specific types, and if IEEE updates something in 802.11i, we'll need to update the capwap spec again. > 4. Does the 'Suppress SSID' field also disable the use of that > SSID in broadcast probe responses? If so, why do we also need the 'IEEE > 802.11 Broadcast Probe Mode' in section 11.9.12? Also, why is this IE > global for the WTP? The AC might configure the WTP with 10 WLANs, but it > may want probe responses generated for only four of those when a > broadcast probe request comes in. > > Section 11.9.12 deals with the changing of the mode of operation > after the WLAN is already operational. I still dont understand why this needs to be global. To quote the current d= raft: "Since broadcast NULL probes are not sent to a specific BSSID, the WTP cannot know which SSID the sending station is querying. Therefore, this behavior must be global to the WTP." However when a broadcast probe request comes in, of all the WLANs mapped to that WTP, the user should be able to configure which ones are responded to. That text seems incorrect. Thanks, Puneet _________________________________________________________________ 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 May 03 13:27:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbL8J-0007Ep-2k for capwap-archive@lists.ietf.org; Wed, 03 May 2006 13:27:27 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbL8H-0001J2-EM for capwap-archive@lists.ietf.org; Wed, 03 May 2006 13:27:27 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2E15E4300E0 for ; Wed, 3 May 2006 10:27:24 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 549E443004F for ; Wed, 3 May 2006 10:27:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 196B743142D for ; Wed, 3 May 2006 10:27:01 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by hermes.tigertech.net (Postfix) with ESMTP id 2580E431432 for ; Wed, 3 May 2006 10:26:57 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id n15so181904nfc for ; Wed, 03 May 2006 10:26:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TyyTqnCvHHjdUWJ6tUw7hAgS99/DBZpN1wV5uEIaILJLPwUeTaqJ4GQsqJHXo0mX+DplmMfklGBwAlHDMOjKIvZkc/zdewDU/8/4tu22GfygfsPg9JwhnjURAQH17FVuI9A8tP2q38a/Lq95Aq+IE5bLmAK052NT5kXoP/ZsLlM= Received: by 10.48.217.9 with SMTP id p9mr1595532nfg; Wed, 03 May 2006 10:26:56 -0700 (PDT) Received: by 10.49.57.12 with HTTP; Wed, 3 May 2006 10:26:56 -0700 (PDT) Message-ID: <1013407b0605031026m56e51969sc05b6a2170f197@mail.gmail.com> Date: Wed, 3 May 2006 10:26:56 -0700 From: Puneet To: "Pat Calhoun (pacalhou)" Subject: Re: [Capwap] Issue 70: Section 5.2.2 Minor Editioral Comment In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201CBA7B1@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4FF84B0BC277FF45AA27FE969DD956A201CBA7B1@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=RCVD_BY_IP X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Can we change the hardware and software version numbers in this message as well as the WTP model number in the board data to be of variable length? I think there is already an issue open for making all fixed-length CAPWAP IEs variable length. The fixed lengths in the current protocol specification are sometimes too short for existing implementations that now want to support CAPWAP, and there does not seem to be a reason to limit these to the numbers specified. We can either use Radius style tag-length-values for all these IEs, or keep the "tag" portion as-is (so that the order in which the elements appear is enforced), but make the data part "length-value" (ie a 1 byte length precedes the actual data) thanks, Puneet On 4/29/06, Pat Calhoun (pacalhou) wrote: > The issue stated that the following section refered to radios instead of > WTPs, > which was a bug in the text. I have made the necessary correction and am > closing > the issue. > > 5.2.2. AC Descriptor > > The AC payload message element is used by the AC to communicate it's > current state. The 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | Hardware Version ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | HW Ver | Software Version ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SW Ver | Stations | Limit | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Limit | Active WTPs | Max WTPs | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max WTPs | Security | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type: 6 for AC Descriptor > > Length: 18 > > Reserved: MUST be set to zero > > Hardware Version: The AC's hardware version number > > Software Version: The AC's Firmware version number > > Stations: The number of mobile stations currently associated with > the AC > > Limit: The maximum number of stations supported by the AC > > Active WTPs: The number of WTPs currently attached to the AC > > Max WTPs: The maximum number of WTPs supported by the AC > > Security: A 8 bit bit mask specifying the authentication credential > type supported by the AC. The following values are supported (see > Section 10): > > 1 - X.509 Certificate Based > > 2 - Pre-Shared Secret > > > > > 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 May 03 13:44:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbLON-0001Ss-F5 for capwap-archive@lists.ietf.org; Wed, 03 May 2006 13:44:03 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbLOL-0002DT-9M for capwap-archive@lists.ietf.org; Wed, 03 May 2006 13:44:03 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 54082430059 for ; Wed, 3 May 2006 10:44:00 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3FA3B43004F for ; Wed, 3 May 2006 10:43:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EB3271448003 for ; Wed, 3 May 2006 10:43:05 -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 81EA21448022 for ; Wed, 3 May 2006 10:43:02 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id 39so310323pyu for ; Wed, 03 May 2006 10:43:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=a7WZ3Jqx0vlXU3A2532OTgirYat53cl3ZKg+NjSuSWLarm56nHJ35eWcdWUDHPzyroVuq7Pyw+07fATZUI61ZshE+Pym+1UkUATgOVDX/2ZQNv1+jpexMJgzA9pdDQkomA/P2vFNjn5L5kAlwEbe5oj8GMr3yaLHjxRhunXJoHc= Received: by 10.35.98.6 with SMTP id a6mr819031pym; Wed, 03 May 2006 10:43:01 -0700 (PDT) Received: by 10.35.47.19 with HTTP; Wed, 3 May 2006 10:43:01 -0700 (PDT) Message-ID: <26140d940605031043t333877bbmf175264b948f4663@mail.gmail.com> Date: Wed, 3 May 2006 13:43:01 -0400 From: "Michael Montemurro" To: "Nancy Winget (ncamwing)" Subject: Re: [Capwap] to mux or not to mux? In-Reply-To: <08A9A3213527A6428774900A80DBD8D801DD1785@xmb-sjc-222.amer.cisco.com> MIME-Version: 1.0 References: <08A9A3213527A6428774900A80DBD8D801DD1785@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.5 tagged_above=-999.0 required=7.0 tests=HTML_20_30, HTML_MESSAGE, RCVD_BY_IP X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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="===============1285458368==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 --===============1285458368== Content-Type: multipart/alternative; boundary="----=_Part_18122_18860387.1146678181546" ------=_Part_18122_18860387.1146678181546 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Nancy brings up an interesting point here. If we go with the MUX header approach, how do we achieve key separation between the control and data channels? How do we derive the keys and how do we maintain sequence counters. Cheers, Mike On 5/2/06, Nancy Winget (ncamwing) wrote: > > > I don't believe adding a MUX is the right answer. First, the addition > is a change in DTLS and also brings up other issues of concern: > - distinguishing the control from data plane is a good thing as the > firewall rules may be different for each plane which is already > addressed by the UDP assignments. > - merging the control and data plane into a single UDP (dtls) tunnel > forces the two planes to be synchronized from an anti-replay > perspective. This effectively restricts the architecture to force them > to use a centralized DTLS encapsulation/decapsulation which imho is too > restrictive > > Nancy. > > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > Sent: Monday, May 01, 2006 11:38 AM > To: capwap > Subject: [Capwap] to mux or not to mux? > > Some time ago, I proposed that we use a single port for capwap, and > insert a mux header right after the UDP header to differentiate between > control and data. While there was some discussion, we did not reach a > conclusion. > > Here's what it would look like: > > +---------+-------------+------------------------------- > | UDP Hdr | MUX Hdr =3D 1 | DTLS Enc Control Packet .... > +---------+-------------+---------------------- > > The capwap editors are currently working hard to produce the 01 version > of the capwap document, and it would be best for implementers if this > question could be decided prior to publication of that document. To > facilitate this, I've summarized briefly below. > > Using separate ports for control/data has a number of drawbacks: > > - if firewalls are between the AC and WTP, multiple rules are required > > - we must be able to explicitly bind the data and control channels at > the AC in order to ensure proper operation; if they use the same port > (and therefore, flow), this is straightforward; if not, we must add > protocol elements for detecting and accounting for NATs along the AC-WTP > path, and for explicitly (and securely) creating the bindings between > the two channels > > - there are race conditions that must be dealt with; in particular, it > is possible to have the left hand (control channel) not knowing for > certain what the right hand (data channel) is doing (and vice versa) > > - If there *are* NATs along the path, using two ports will require > keepalives on both ports, and error handling for when one channel goes > away but the other does not (e.g. if a middlebox deletes the NAT > bindings for any reason) > > - there are many more error conditions to manage in the state machine, > due to the channel binding and NAT issues > > Clearly, using two ports adds *significant* complexity to the > implementation, and will likely result in operational problems in some > environments. > > Using a mux header has one drawback (that I can think of): > > - it adds n bytes to the header. I'm tempted to say n will be 4 for > 32-bit alignment, but it could also be only 1 or 2 bytes, if > bits-on-the-wire overhead is an overriding concern. > > Using a mux hader has several advantages: > > - we get NAT traversal for free, by simply configuring the echo interval > to be smaller than the NAT binding lifetime for the path in question > > - we only open one port through intermediate firewalls (and any > intermediate NATs) > > - the implementation (state machine, error handling) is *much* simpler, > and therefore more likely > to (inter)operate according to spec > > We need to decide on this, preferably within the next day or two. Please > speak up and make your preferences known. > > 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 > ------=_Part_18122_18860387.1146678181546 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Nancy brings up an interesting point here.
 
If we go with the MUX header approach, how do we achieve key separatio= n between the control and data channels?
 
How do we derive the keys and how do we maintain sequence counters.
 
Cheers,
 
        Mike
 


 
On 5/2/06, N= ancy Winget (ncamwing) <ncamwi= ng@cisco.com> wrote:

I don't believe adding a MUX= is the right answer.  First, the addition
is a change in DTLS= and also brings up other issues of concern:
- distinguishing the control from data plane is a good thing as the
= firewall rules may be different for each plane which is already
addresse= d by the UDP assignments.
- merging the control and data plane into a si= ngle UDP (dtls) tunnel
forces the two planes to be synchronized from an anti-replay
perspec= tive. This effectively restricts the architecture to force them
to use a= centralized DTLS encapsulation/decapsulation which imho is too
restrict= ive

       Nancy.

-----Original Me= ssage-----
From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com]
Sent: Monday, May 01, 2006 11:38 AM<= br>To: capwap
Subject: [Capwap] to mux or not to mux?

Some time ago, I proposed that we use a single port for capwap, and=
insert a mux header right after the UDP header to differentiate between=
control and data. While there was some discussion, we did not reach a
conclusion.

Here's what it would look like:

+---------+--= -----------+-------------------------------
| UDP Hdr | MUX Hdr =3D 1 | = DTLS Enc Control Packet ....
+---------+-------------+------------------= ----

The capwap editors are currently working hard to produce the 01 ver= sion
of the capwap document, and it would be best for implementers if th= is
question could be decided prior to publication of that document. To
facilitate this, I've summarized briefly below.

Using separate p= orts for control/data has a number of drawbacks:

- if firewalls are = between the AC and WTP, multiple rules are required

- we must be abl= e to explicitly bind the data and control channels at
the AC in order to ensure proper operation; if they use the same port(and therefore, flow), this is straightforward; if not, we must add
pr= otocol elements for detecting and accounting for NATs along the AC-WTP
path, and for explicitly (and securely) creating the bindings between
th= e two channels

- there are race conditions that must be dealt with; = in particular, it
is possible to have the left hand (control channel) no= t knowing for
certain what the right hand (data channel) is doing (and vice versa)
- If there *are* NATs along the path, using two ports will require
= keepalives on both ports, and error handling for when one channel goes
away but the other does not (e.g. if a middlebox deletes the NAT
binding= s for any reason)

- there are many more error conditions to manage i= n the state machine,
due to the channel binding and NAT issues

Clearly, using two ports adds *significant* complexity to the
implementa= tion, and will likely result in operational problems in some
environment= s.

Using a mux header has one drawback (that I can think of):

- it adds n bytes to the header. I'm tempted to say n will be 4 for
= 32-bit alignment, but it could also be only 1 or 2 bytes, if
bits-on-the= -wire overhead is an overriding concern.

Using a mux hader has sever= al advantages:

- we get NAT traversal for free, by simply configuring the echo int= erval
to be smaller than the NAT binding lifetime for the path in questi= on

- we only open one port through intermediate firewalls (and any
intermediate NATs)

- the implementation (state machine, error ha= ndling) is *much* simpler,
and therefore more likely
to (inter)operat= e according to spec

We need to decide on this, preferably within the= next day or two. Please
speak up and make your preferences known.

Thanks,

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

Archives: http://lists.frascone.co= m/pipermail/capwap
_________________________________________________= ________________
To unsubscribe or modify your subscription options, please visit:
http://lists.fr= ascone.com/mailman/listinfo/capwap

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

------=_Part_18122_18860387.1146678181546-- --===============1285458368== 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 --===============1285458368==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 03 14:10:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbLnc-0001vc-UB for capwap-archive@lists.ietf.org; Wed, 03 May 2006 14:10:08 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbLnb-0003WP-5B for capwap-archive@lists.ietf.org; Wed, 03 May 2006 14:10:08 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A82214300C5 for ; Wed, 3 May 2006 11:10:06 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 54C5243004F for ; Wed, 3 May 2006 11:09:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E2A2D1448022 for ; Wed, 3 May 2006 11:09:29 -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 03E4E144801C for ; Wed, 3 May 2006 11:09:26 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id h30so175051wxd for ; Wed, 03 May 2006 11:09:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=DcHaBGkjJnnpjMy77KtbD2NUMlTJ1FSUb8YDHHrk00L9df9yM5EWa9z6xZ5FJBwHrD1hvw2mYrXHJYoXaUCCWskaEQpLO59m0QxqEC4MaqCghbmcs9p1c3poxYGcHHHIBeFNOsrAIwfMRlW+/qBzpBTFPtP8h69A61qJakAz7HM= Received: by 10.70.41.5 with SMTP id o5mr1022269wxo; Wed, 03 May 2006 11:09:25 -0700 (PDT) Received: by 10.70.6.8 with HTTP; Wed, 3 May 2006 11:09:25 -0700 (PDT) Message-ID: <5bfe7a820605031109k4672acbfv88848207dc9aca1a@mail.gmail.com> Date: Wed, 3 May 2006 11:09:25 -0700 From: "Dorothy Stanley" To: Puneet Subject: Re: [Capwap] Issue 70: Section 5.2.2 Minor Editioral Comment In-Reply-To: <1013407b0605031026m56e51969sc05b6a2170f197@mail.gmail.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A201CBA7B1@xmb-sjc-235.amer.cisco.com> <1013407b0605031026m56e51969sc05b6a2170f197@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 X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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="===============0910846512==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d --===============0910846512== Content-Type: multipart/alternative; boundary="----=_Part_28213_21026382.1146679765503" ------=_Part_28213_21026382.1146679765503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Puneet, The resolution to Issue 46 should take care of your second request: WTP model number in the board data to be of variable length. The model number and serial number will be vendor specific= , of variable length. I have no objection to doing the same for hardware and software version numbers. Dorothy On 5/3/06, Puneet wrote: > > Can we change the hardware and software version numbers in this > message as well as the WTP model number in the board data to be of > variable length? I think there is already an issue open for making all > fixed-length CAPWAP IEs variable length. > > The fixed lengths in the current protocol specification are sometimes > too short for existing implementations that now want to support > CAPWAP, and there does not seem to be a reason to limit these to the > numbers specified. We can either use Radius style tag-length-values > for all these IEs, or keep the "tag" portion as-is (so that the order > in which the elements appear is enforced), but make the data part > "length-value" (ie a 1 byte length precedes the actual data) > > thanks, > Puneet > > On 4/29/06, Pat Calhoun (pacalhou) wrote: > > The issue stated that the following section refered to radios instead o= f > > WTPs, > > which was a bug in the text. I have made the necessary correction and a= m > > closing > > the issue. > > > > 5.2.2. AC Descriptor > > > > The AC payload message element is used by the AC to communicate it's > > current state. The 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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Reserved | Hardware Version ... | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | HW Ver | Software Version ... | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | SW Ver | Stations | Limit | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Limit | Active WTPs | Max WTPs | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max WTPs | Security | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Type: 6 for AC Descriptor > > > > Length: 18 > > > > Reserved: MUST be set to zero > > > > Hardware Version: The AC's hardware version number > > > > Software Version: The AC's Firmware version number > > > > Stations: The number of mobile stations currently associated with > > the AC > > > > Limit: The maximum number of stations supported by the AC > > > > Active WTPs: The number of WTPs currently attached to the AC > > > > Max WTPs: The maximum number of WTPs supported by the AC > > > > Security: A 8 bit bit mask specifying the authentication credential > > type supported by the AC. The following values are supported (se= e > > Section 10): > > > > 1 - X.509 Certificate Based > > > > 2 - Pre-Shared Secret > > > > > > > > > > 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 > ------=_Part_28213_21026382.1146679765503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Puneet,

The resolution to Issue 46 should take care of your
second request: WTP model number in the board data to be of
variable length. The model number and serial number will be vendor specific= , of
variable length.

I have no objection to doing the same for hardware and software version num= bers.

Dorothy

On 5/3/06, Puneet <pb.ietf@g= mail.com> wrote:
Can we change the hardware and software version numbers in this
message = as well as the WTP model number in the board data to be of
variable leng= th? I think there is already an issue open for making all
fixed-length C= APWAP IEs variable length.

The fixed lengths in the current protocol specification are sometim= es
too short for existing implementations that now want to support
CA= PWAP, and there does not seem to be a reason to limit these to the
numbe= rs specified. We can either use Radius style tag-length-values
for all these IEs, or keep the "tag" portion as-is (so that t= he order
in which the elements appear is enforced), but make the data pa= rt
"length-value" (ie a 1 byte length precedes the actual data= )

thanks,
Puneet

On 4/29/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
>= ; The issue stated that the following section refered to radios instead of
> WTPs,
> which was a bug in the text. I have made the necessa= ry correction and am
> closing
> the issue.
>
> 5.2= .2.  AC Descriptor
>
>    The AC = payload message element is used by the AC to communicate it's
>    current state.  The value contain= s the following fields.
>
>       0            &n= bsp;      1            &n= bsp;      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
>     &nb= sp;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= ;      |   Reserved    |       =           Hardware  Version ...         |
>  &n= bsp;   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+
>      |   =   HW Ver    |        = ;         Software  Version ...         |
>  &n= bsp;   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+
>      |   =   SW Ver    |        = ;    Stations       =     |     Limit     |
> &nbs= p;    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+
>      |  &n= bsp;  Limit     |          Active WTPs          | &nbs= p; Max WTPs    |
>     &nbs= p;+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=       |   Max WTPs    |    Security   |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
>
>    Type:  6 for AC Descri= ptor
>
>    Length:  18
>>    Reserved:  MUST be set to zero
&= gt;
>    Hardware Version:  The AC's ha= rdware version number
>
>    Software Version:  The AC= 's Firmware version number
>
>    Stations:=   The number of mobile stations currently associated with
>=        the AC
>
>  &nbs= p; Limit:  The maximum number of stations supported by the A= C
>
>    Active WTPs:  The number = of WTPs currently attached to the AC
>
>    = ;Max WTPs:  The maximum number of WTPs supported by the AC
>= ;
>    Security:  A 8 bit bit mask spec= ifying the authentication credential
>       type supported by the AC. = ; The following values are supported (see
>   &nb= sp;   Section 10):
>
>     &= nbsp; 1 - X.509 Certificate Based
>
>    &n= bsp;  2 - Pre-Shared Secret
>
>
>
>
> Pat Calhoun
> CTO, Wireless Networking Business = Unit
> Cisco Systems
> ________________________________________= _________________________
> To unsubscribe or modify your subscriptio= n options, please visit:
> http= ://lists.frascone.com/mailman/listinfo/capwap
>
> Archives:= http://lists.frasco= ne.com/pipermail/capwap
>
___________________________________________________________= ______
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_28213_21026382.1146679765503-- --===============0910846512== 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 --===============0910846512==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 03 15:04:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbMe3-0007nv-Fh for capwap-archive@lists.ietf.org; Wed, 03 May 2006 15:04:19 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbMe0-0005ud-EM for capwap-archive@lists.ietf.org; Wed, 03 May 2006 15:04:19 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A19994300DD for ; Wed, 3 May 2006 12:04:12 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C83B343004F for ; Wed, 3 May 2006 12:03:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 229171448028 for ; Wed, 3 May 2006 12:03:26 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.195]) by hermes.tigertech.net (Postfix) with ESMTP id 1592A1448034 for ; Wed, 3 May 2006 12:03:22 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id h30so184860wxd for ; Wed, 03 May 2006 12:03:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=LKliCUlfDVILZsdVhsiHun3ggwXtNXz6FImxRAR3uPITt0ACDJmtj42dLp7GItyOYAMS1JRzT9Lv+3ok9Mv/KRY4iLpx/S5D0RYvwJaHXSNv6zZGSq+dKYmkF+OlWSMZIJFte8HOh7jgz2vyp9OsTB4oD9YErkT5p0WAHlA5E6o= Received: by 10.70.40.5 with SMTP id n5mr43979wxn; Wed, 03 May 2006 12:03:22 -0700 (PDT) Received: by 10.70.6.8 with HTTP; Wed, 3 May 2006 12:03:22 -0700 (PDT) Message-ID: <5bfe7a820605031203n72fffce2i88421ad03e121d5a@mail.gmail.com> Date: Wed, 3 May 2006 12:03:22 -0700 From: "Dorothy Stanley" To: "Pat Calhoun (pacalhou)" Subject: Re: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201CBA6BA@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A201CBA6BA@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.1 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_20_30, HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP X-Spam-Level: * Cc: Saravanan Govindan , capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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="===============2003130106==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.1 (+) X-Scan-Signature: 69ad46fbd0e474a7c7f3312d9e320336 --===============2003130106== Content-Type: multipart/alternative; boundary="----=_Part_29182_25728416.1146683002092" ------=_Part_29182_25728416.1146683002092 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, After the lengthy discussion on this topic, I believe that the conclusion i= s still to reject the comment, and as Pat summarized, the echo remains, does not include any statistics, and MAY only be sent in the absence of any control packets. Changes to the text: Change text in 6.2" Echo Response" from: "If another Echo Request message is not received by the AC when the timer expires, the AC SHOULD consider the WTP to be unreachable" to "If another Echo Request or other control message is not received by the AC when the timer expires, the AC SHOULD consider the WTP to be unreachable" and from "If the NeighborDeadInterval timer expires prior to receiving an Echo Response message, message, the WTP enters the Reset State." to "If the NeighborDeadInterval timer expires prior to receiving an Echo Response message, or other control message, the WTP enters the Reset State." Thanks, Dorothy Issue 45, Issue on Combining messages currently has the following discussio= n in the issues database: Currently, the keepalive and statistics messages are separated. Separate messages for keepalive signaling and statistics can lead to high overhead. Initial analysis have shown that these overhead can be reduced significantl= y if the messages can be combined. Recommendation: To combine the keepalive and statistics message into one combined message, thus reducing overhead significantly. Discussion: The CAPWAP protocol specification currently supports the Echo Request Message and Echo Response Messages, which are used for keep-alive purposes, and do not carry message elements. There is an IEEE 802.11 Statistics measurement element(11.7.2.1), and several CAPWAP statistics related measurement elements: decryption error report, WTP descriptor, WTP radio information, WTP reboot statistics. There is no statistics message. There is no requirement on how often the statistics related measurement elements must be reported to the AC from the WTP, there is a Statistics timer, see 7.2.5, which is used by the AC to indicate the timer value to the WTP. (separate question - should the statistics timer be made general, and indicate the values for the other Section 12 CAPWAP timers too? Assume that the CAPWAP statistics timer used to determine how often to send the 802.11 specific statistics). It is not clear that there is a high overhead in keeping the echo/keep-aliv= e mechanism from the statistics reporting. There is some benefit in keeping the echo message= s simple, rather than complicating the processing of those messages. It is true that small messages (echo request, response) have high overhead. In this case, the design choice is to accept the overhead as the cost of simplicity in design and implementation. Recommended resolution: reject the comment, with the explanation in the above paragraph On 4/28/06, Pat Calhoun (pacalhou) wrote: > > I will summarize my thoughts here and not try to inject in the various > threads, but I agree that the echo remains, does not include any > statistics, and MAY only be sent in the absence of any control packets. > I say MAY because an implementation could send them if it wishes, but > the receiver must take into account control packets in addition to the > echo prior to declaring a link dead. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Scott G Kelly [mailto:scott@hyperthought.com] > > Sent: Friday, April 21, 2006 5:52 AM > > To: Saravanan Govindan > > Cc: capwap > > Subject: Re: [Capwap] Proposed Resolution to Issue 45 > > -Issueoncombiningmessages > > > > Hi Saravanan, > > > > Saravanan Govindan wrote: > > > Hi Scott, > > > > > > I think David's note does address the issue on hand. > > > > > > To formalize; > > > > > > The exchange of control messages between a WTP and AC implicitly > > > indicates that the WTP is operational. For the purpose of protocol > > > simplicity, I suggest that we focus on statistics messages > > alone for > > > this purpose, reason being that statistics are periodically > > exchanged. > > > > > > My concern is that by using "any" control message to indicate > > > keepalive (Echo), the AC processing will be complicated. This is > > > because the AC will need to process each control message > > for both its own value (e.g. > > > Configure Request) and also keepalive value. > > > > Of course, complexity is a function of many factors, but > > there is a straightforward way to implement an echo trigger > > with a flag and timer: > > when you receive a control message, unconditionally raise the flag. > > Periodically (according to your keepalive interval timer) > > check the flag; If it's up, put it down, else send a > > keepalive. There are more complicated ways to implement, but > > this works just fine. > > > > On the AC this can easily be implemented by having the > > fastpath raise the flag, and having the cp lower it and/or do > > whatever it is your AC does if a WTP doesn't report in a > > given echo interval (which may be nothing). Pretty basic stuff. > > > > On the WTP, implementation is similar, except that if the > > flag is down, you send the keepalive. Again, very simple and basic. > > > > > So I suggest keeping it simple - arrival of statistics message from > > > WTP means WTP is alive. > > > > Certainly, a statistics message qualifies as a control > > message, so I have no issues with this statement when taken > > alone. I'm concerned with the earlier suggestion that the > > echo req/reply message be discarded and replaced by the > > statistics message. > > > > In some cases, the keepalive interval must be *very* brief in > > order to facilitate rapid link loss detection and recovery. I > > know of one vendor who routinely uses a one second interval, > > and it's conceivable that in some scenarios one might choose > > to use even less. > > > > And keep in mind that WTP and AC requirements are typically > > asymmetric in this regard: the WTP needs to react quickly > > (maybe try to find another AC), whereas the AC simply needs > > to somehow report the event. > > While in some cases reporting might be considered urgent, > > this is not the typical (or average) case. > > > > The granularity requirements for reporting are typically much > > coarser than those of recovery. That is, the AC may, at it's > > option, only check every 10,20,30,... seconds for WTP > > liveness, and it may very well do that via the stats message, > > rather than the echo, since this allows echo processing to > > remain wholly in the AC fastpath. > > > > But say we eliminate the echo: what happens when, say, 500 > > WTPs send stats potentially every second or less? > > > > I think we still need the echo req/rsp. > > > > Scott > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > > > Sent: Wednesday, April 19, 2006 1:51 AM > > > To: capwap > > > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > > > -Issueoncombiningmessages > > > > > > Just trying to close the loop: I think David's point (i.e. > > that echoes > > > should only be sent in the absence of other control > > traffic) is dead > > > on, and that this effectively closes the question as to > > whether echoes > > > and stats should be combined in the same messages. > > > > > > Does anyone disagree? > > > > > > 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_29182_25728416.1146683002092 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All,

After the lengthy discussion on this topic, I believe that the conclusion i= s
still to reject the comment, and as Pat summarized, the echo remains, does = not include any
statistics, and MAY only be sent in the absence of any control packets.
Changes to the text:

Change text in 6.2" Echo Response" from:
"If another Echo Request message is not received by the AC when the ti= mer expires, the AC
SHOULD consider the WTP to be unreachable" to

"If another Echo Request or other control message is not received by t= he AC when the timer expires, the AC
SHOULD consider the WTP to be unreachable"

and from

"If the NeighborDeadInterval timer expires prior to receiving an Echo = Response message,
message, the WTP enters the Reset State."
to
"If the NeighborDeadInterval timer expires prior to receiving an Echo = Response message, or other control
message, the WTP enters the Reset State."


Thanks,

Dorothy

Issue 45, Is= sue on Combining messages currently has the following discussion in = the issues database: 

Currently, the keepalive and statistics messages are separated. Separa=
te 
messages for keepalive signaling and statistics can lead to high ove=
rhead. 
Initial analysis have shown that these overhead can be reduced s=
ignificantly=20


if the messages can be combined.

Recommendation:

To c=
ombine the keepalive and statistics message into one combined message, 
=
thus reducing overhead significantly.

Discussion:

The CAPWAP protocol specification currently supports the
Echo Request Message and Echo Response Messages, which are used for keep-al= ive
purposes, and do not carry message elements.

There is an IEEE 802.11 Statistics measurement element(11.7.2.1), and several CAPWAP statistics related
measurement elements: decryption error report, WTP descriptor, WTP radio in= formation, WTP reboot statistics.
There is no statistics message.

There is no requirement on how often the statistics related measurement ele= ments must be reported
to the AC from the WTP, there is a Statistics timer, see 7.2.5, which is us= ed by the AC to indicate the
timer value to the WTP. (separate question - should the statistics timer be= made general, and indicate the
values for the other Section 12 CAPWAP timers too?  Assume that the CA= PWAP statistics timer used
to determine how often to send the 802.11 specific statistics).

It is not clear that there is a high overhead in keeping the echo/keep-aliv= e mechanism from
the statistics reporting. There is some benefit in keeping the echo message= s simple,
rather than complicating the processing of those messages.  It is true that small messages (echo request, response) have high overhead.
In this case, the design choice is to accept the overhead as the cost of si= mplicity in design and implementation.

Recommended resolution: reject the comment, with the explanation in the abo= ve paragraph

On 4/28/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com> wrote:
I will summarize my thoughts here and not try to inj= ect in the various
threads, but I agree that the echo remains, does not include any
sta= tistics, and MAY only be sent in the absence of any control packets.
I s= ay MAY because an implementation could send them if it wishes, but
the r= eceiver must take into account control packets in addition to the
echo prior to declaring a link dead.

Pat Calhoun
CTO, Wireles= s Networking Business Unit
Cisco Systems



> -----Origin= al Message-----
> From: Scott G Kelly [mailto: scott@hyperthought.com]
> Sent: Friday, April 21, 2006 5:52 AM> To: Saravanan Govindan
> Cc: capwap
> Subject: Re: [Capwa= p] Proposed Resolution to Issue 45
> -Issueoncombiningmessages
>
> Hi Saravanan,
>
> Saravanan Govindan wrote:
>= ; > Hi Scott,
> >
> > I think David's note does addres= s the issue on hand.
> >
> > To formalize;
> >
> > The exchange of control messages between a WTP and AC implici= tly
> > indicates that the WTP is operational. For the purpose of = protocol
> > simplicity, I suggest that we focus on statistics mes= sages
> alone for
> > this purpose, reason being that statistics = are periodically
> exchanged.
> >
> > My concern is= that by using "any" control message to indicate
> > kee= palive (Echo), the AC processing will be complicated. This is
> > because the AC will need to process each control message
&= gt; for both its own value (e.g.
> > Configure Request) and also k= eepalive value.
>
> Of course, complexity is a function of many= factors, but
> there is a straightforward way to implement an echo trigger
>= ; with a flag and timer:
> when you receive a control message, uncond= itionally raise the flag.
> Periodically (according to your keepalive= interval timer)
> check the flag; If it's up, put it down, else send a
> keepa= live. There are more complicated ways to implement, but
> this works = just fine.
>
> On the AC this can easily be implemented by havi= ng the
> fastpath raise the flag, and having the cp lower it and/or do
&= gt; whatever it is your AC does if a WTP doesn't report in a
> given = echo interval (which may be nothing). Pretty basic stuff.
>
> O= n the WTP, implementation is similar, except that if the
> flag is down, you send the keepalive. Again, very simple and basic= .
>
> > So I suggest keeping it simple - arrival of statisti= cs message from
> > WTP means WTP is alive.
>
> Certai= nly, a statistics message qualifies as a control
> message, so I have no issues with this statement when taken
>= ; alone. I'm concerned with the earlier suggestion that the
> echo re= q/reply message be discarded and replaced by the
> statistics message= .
>
> In some cases, the keepalive interval must be *very* brief= in
> order to facilitate rapid link loss detection and recovery. I> know of one vendor who routinely uses a one second interval,
> and it's conceivable that in some scenarios one might choose
> t= o use even less.
>
> And keep in mind that WTP and AC requireme= nts are typically
> asymmetric in this regard: the WTP needs to react= quickly
> (maybe try to find another AC), whereas the AC simply needs
>= ; to somehow report the event.
> While in some cases reporting might = be considered urgent,
> this is not the typical (or average) case.
>
> The granularity requirements for reporting are typically m= uch
> coarser than those of recovery. That is, the AC may, at it's> option, only check every 10,20,30,... seconds for WTP
> livenes= s, and it may very well do that via the stats message,
> rather than the echo, since this allows echo processing to
>= remain wholly in the AC fastpath.
>
> But say we eliminate the= echo: what happens when, say, 500
> WTPs send stats potentially ever= y second or less?
>
> I think we still need the echo req/rsp.
>
> Sc= ott
>
> >
> > Saravanan
> >
> >> >
> >
> >
> > -----Original Message---= --
> > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com]
> > Sent: Wednesday, April 19,= 2006 1:51 AM
> > To: capwap
> > Subject: RE: [Capwap] Pr= oposed Resolution to Issue 45
> > -Issueoncombiningmessages
> >
> > Just tryi= ng to close the loop: I think David's point (i.e.
> that echoes
&g= t; > should only be sent in the absence of other control
> traffic= ) is dead
> > on, and that this effectively closes the question as to
&g= t; whether echoes
> > and stats should be combined in the same mes= sages.
> >
> > Does anyone disagree?
> >
> > Scott
> >
> >
> > ____________________= _____________________________________________
> > To unsubscribe o= r 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:<= br>> http:= //lists.frascone.com/mailman/listinfo/capwap
>
> Archives:= =20 http://lists.frascon= e.com/pipermail/capwap
>
_____________________________________= ____________________________
To unsubscribe or modify your subscription = options, please visit:
http://li= sts.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/piperma= il/capwap

------=_Part_29182_25728416.1146683002092-- --===============2003130106== 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 --===============2003130106==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 03 16:18:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbNns-0004Kj-BN for capwap-archive@lists.ietf.org; Wed, 03 May 2006 16:18:32 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbNnq-0000gC-6q for capwap-archive@lists.ietf.org; Wed, 03 May 2006 16:18:32 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2E1984300AA for ; Wed, 3 May 2006 13:18:29 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 98F2C43004F for ; Wed, 3 May 2006 13:17:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7F865144802B for ; Wed, 3 May 2006 13:17:33 -0700 (PDT) Received: from test-iport-2.cisco.com (test-iport-2.cisco.com [171.71.176.105]) by hermes.tigertech.net (Postfix) with ESMTP id DF0551448028 for ; Wed, 3 May 2006 13:17:25 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-2.cisco.com with ESMTP; 03 May 2006 13:17:24 -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 k43KHOw3012700; Wed, 3 May 2006 13:17:24 -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, 3 May 2006 13:17:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Date: Wed, 3 May 2006 13:17:22 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D25136@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Thread-Index: AcZu5EIPR4PPb9/bR4GXFgaIEusNSQAClHSQ From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" X-OriginalArrivalTime: 03 May 2006 20:17:24.0307 (UTC) FILETIME=[971B7A30:01C66EEE] 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, HTML_20_30, HTML_MESSAGE, NORMAL_HTTP_TO_IP X-Spam-Level: Cc: Saravanan Govindan , capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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="===============1796872610==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 0c3d807a9e67fb2ae2b97f891ffd2e4e This is a multi-part message in MIME format. --===============1796872610== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66EEE.96C5D952" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66EEE.96C5D952 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: Wednesday, May 03, 2006 12:03 PM To: Pat Calhoun (pacalhou) Cc: Scott G Kelly; Saravanan Govindan; capwap Subject: Re: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages =09 =09 All, =09 After the lengthy discussion on this topic, I believe that the conclusion is still to reject the comment, and as Pat summarized, the echo remains, does not include any statistics, and MAY only be sent in the absence of any control packets.=20 =09 Changes to the text: =09 Change text in 6.2" Echo Response" from: "If another Echo Request message is not received by the AC when the timer expires, the AC SHOULD consider the WTP to be unreachable" to=20 =09 "If another Echo Request or other control message is not received by the AC when the timer expires, the AC SHOULD consider the WTP to be unreachable"=20 =09 and from =09 "If the NeighborDeadInterval timer expires prior to receiving an Echo Response message,=20 message, the WTP enters the Reset State." to "If the NeighborDeadInterval timer expires prior to receiving an Echo Response message, or other control message, the WTP enters the Reset State." =09 =09 Thanks, =09 Dorothy =09 Issue 45, Issue on Combining messages currently has the following discussion in the issues database:=20 =09 =09 Currently, the keepalive and statistics messages are separated. Separate=20 messages for keepalive signaling and statistics can lead to high overhead.=20 Initial analysis have shown that these overhead can be reduced significantly=20 =09 =09 if the messages can be combined. =09 Recommendation: =09 To combine the keepalive and statistics message into one combined message,=20 thus reducing overhead significantly. Discussion: =09 The CAPWAP protocol specification currently supports the Echo Request Message and Echo Response Messages, which are used for keep-alive purposes, and do not carry message elements. =09 There is an IEEE 802.11 Statistics measurement element(11.7.2.1 ), and several CAPWAP statistics related measurement elements: decryption error report, WTP descriptor, WTP radio information, WTP reboot statistics. There is no statistics message.=20 =09 There is no requirement on how often the statistics related measurement elements must be reported to the AC from the WTP, there is a Statistics timer, see 7.2.5, which is used by the AC to indicate the timer value to the WTP. (separate question - should the statistics timer be made general, and indicate the values for the other Section 12 CAPWAP timers too? Assume that the CAPWAP statistics timer used to determine how often to send the 802.11 specific statistics). =09 It is not clear that there is a high overhead in keeping the echo/keep-alive mechanism from the statistics reporting. There is some benefit in keeping the echo messages simple, rather than complicating the processing of those messages. It is true that small messages (echo request, response) have high overhead. In this case, the design choice is to accept the overhead as the cost of simplicity in design and implementation.=20 =09 Recommended resolution: reject the comment, with the explanation in the above paragraph =09 =09 On 4/28/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com > wrote:=20 I will summarize my thoughts here and not try to inject in the various=20 threads, but I agree that the echo remains, does not include any statistics, and MAY only be sent in the absence of any control packets. I say MAY because an implementation could send them if it wishes, but the receiver must take into account control packets in addition to the=20 echo prior to declaring a link dead. =09 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =09 =09 =09 > -----Original Message----- > From: Scott G Kelly [mailto: scott@hyperthought.com ] > Sent: Friday, April 21, 2006 5:52 AM > To: Saravanan Govindan > Cc: capwap > Subject: Re: [Capwap] Proposed Resolution to Issue 45 > -Issueoncombiningmessages > > Hi Saravanan, > > Saravanan Govindan wrote: > > Hi Scott, > > > > I think David's note does address the issue on hand. > > > > To formalize; > >=20 > > The exchange of control messages between a WTP and AC implicitly > > indicates that the WTP is operational. For the purpose of protocol > > simplicity, I suggest that we focus on statistics messages=20 > alone for > > this purpose, reason being that statistics are periodically > exchanged. > > > > My concern is that by using "any" control message to indicate > > keepalive (Echo), the AC processing will be complicated. This is=20 > > because the AC will need to process each control message > for both its own value (e.g. > > Configure Request) and also keepalive value. > > Of course, complexity is a function of many factors, but=20 > there is a straightforward way to implement an echo trigger > with a flag and timer: > when you receive a control message, unconditionally raise the flag. > Periodically (according to your keepalive interval timer)=20 > check the flag; If it's up, put it down, else send a > keepalive. There are more complicated ways to implement, but > this works just fine. > > On the AC this can easily be implemented by having the > fastpath raise the flag, and having the cp lower it and/or do > whatever it is your AC does if a WTP doesn't report in a > given echo interval (which may be nothing). Pretty basic stuff. > > On the WTP, implementation is similar, except that if the=20 > flag is down, you send the keepalive. Again, very simple and basic. > > > So I suggest keeping it simple - arrival of statistics message from > > WTP means WTP is alive. > > Certainly, a statistics message qualifies as a control > message, so I have no issues with this statement when taken > alone. I'm concerned with the earlier suggestion that the > echo req/reply message be discarded and replaced by the > statistics message.=20 > > In some cases, the keepalive interval must be *very* brief in > order to facilitate rapid link loss detection and recovery. I > know of one vendor who routinely uses a one second interval, > and it's conceivable that in some scenarios one might choose > to use even less. > > And keep in mind that WTP and AC requirements are typically > asymmetric in this regard: the WTP needs to react quickly=20 > (maybe try to find another AC), whereas the AC simply needs > to somehow report the event. > While in some cases reporting might be considered urgent, > this is not the typical (or average) case.=20 > > The granularity requirements for reporting are typically much > coarser than those of recovery. That is, the AC may, at it's > option, only check every 10,20,30,... seconds for WTP > liveness, and it may very well do that via the stats message,=20 > rather than the echo, since this allows echo processing to > remain wholly in the AC fastpath. > > But say we eliminate the echo: what happens when, say, 500 > WTPs send stats potentially every second or less?=20 > > I think we still need the echo req/rsp. > > Scott > > > > > Saravanan > > > > > > > > > > > > -----Original Message-----=20 > > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > > Sent: Wednesday, April 19, 2006 1:51 AM > > To: capwap > > Subject: RE: [Capwap] Proposed Resolution to Issue 45=20 > > -Issueoncombiningmessages > > > > Just trying to close the loop: I think David's point (i.e. > that echoes > > should only be sent in the absence of other control > traffic) is dead=20 > > on, and that this effectively closes the question as to > whether echoes > > and stats should be combined in the same messages. > > > > Does anyone disagree? > > > > Scott > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > _________________________________________________________________=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 _________________________________________________________________ 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_01C66EEE.96C5D952 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: Wednesday, May 03, = 2006 12:03=20 PM
To: Pat Calhoun (pacalhou)
Cc: Scott G Kelly; = Saravanan=20 Govindan; capwap
Subject: Re: [Capwap] Proposed Resolution = to Issue=20 45 -Issueoncombiningmessages

All,

After the lengthy discussion on this topic, I = believe=20 that the conclusion is
still to reject the comment, and as Pat = summarized,=20 the echo remains, does not include any
statistics, and MAY only be = sent in=20 the absence of any control packets.

Changes to the = text:

Change=20 text in 6.2" Echo Response" from:
"If another Echo Request message = is not=20 received by the AC when the timer expires, the AC
SHOULD consider = the WTP=20 to be unreachable" to

"If another Echo Request or other = control=20 message is not received by the AC when the timer expires, the = AC
SHOULD=20 consider the WTP to be unreachable"

and from

"If the=20 NeighborDeadInterval timer expires prior to receiving an Echo Response = message,
message, the WTP enters the Reset State."
to
"If = the=20 NeighborDeadInterval timer expires prior to receiving an Echo Response = message, or other control
message, the WTP enters the Reset=20 State."


Thanks,

Dorothy

Issue 45, Issue on Combining messages = currently has the=20 following discussion in the issues database: 

Currently, =
the keepalive and statistics messages are separated. Separate =

messages for keepalive signaling and statistics can lead to high =
overhead. 
Initial analysis have shown that these overhead can be =
reduced significantly=20


if the messages can be =
combined.

Recommendation:

To combine the keepalive and =
statistics message into one combined message, 
thus reducing overhead =
significantly.

Discussion:

The=20 CAPWAP protocol specification currently supports the
Echo Request = Message=20 and Echo Response Messages, which are used for keep-alive
purposes, = and do=20 not carry message elements.

There is an IEEE 802.11 Statistics=20 measurement element(11.7.2.1), and several = CAPWAP=20 statistics related
measurement elements: decryption error report, = WTP=20 descriptor, WTP radio information, WTP reboot statistics.
There is = no=20 statistics message.

There is no requirement on how often the=20 statistics related measurement elements must be reported
to the AC = from the=20 WTP, there is a Statistics timer, see 7.2.5, which is used by the AC = to=20 indicate the
timer value to the WTP. (separate question - should = the=20 statistics timer be made general, and indicate the
values for the = other=20 Section 12 CAPWAP timers too?  Assume that the CAPWAP statistics = timer=20 used
to determine how often to send the 802.11 specific=20 statistics).

It is not clear that there is a high overhead in = keeping=20 the echo/keep-alive mechanism from
the statistics reporting. There = is some=20 benefit in keeping the echo messages simple,
rather than = complicating the=20 processing of those messages.  It is true that small messages = (echo=20 request, response) have high overhead.
In this case, the design = choice is=20 to accept the overhead as the cost of simplicity in design and = implementation.=20

Recommended resolution: reject the comment, with the = explanation in=20 the above paragraph

On 4/28/06, Pat Calhoun=20 (pacalhou) <=20 pcalhoun@cisco.com> wrote:
I=20 will summarize my thoughts here and not try to inject in the various =
threads, but I agree that the echo remains, does not include=20 any
statistics, and MAY only be sent in the absence of any = control=20 packets.
I say MAY because an implementation could send them if = it=20 wishes, but
the receiver must take into account control packets = in=20 addition to the
echo prior to declaring a link dead.

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



> -----Original Message-----
> From: = Scott G=20 Kelly [mailto:=20 scott@hyperthought.com]
> Sent: Friday, April 21, 2006 = 5:52=20 AM
> To: Saravanan Govindan
> Cc: capwap
> = Subject: Re:=20 [Capwap] Proposed Resolution to Issue 45
>=20 -Issueoncombiningmessages
>
> Hi = Saravanan,
>
>=20 Saravanan Govindan wrote:
> > Hi Scott,
> = >
> > I=20 think David's note does address the issue on hand.
> = >
> >=20 To formalize;
> >
> > The exchange of control = messages=20 between a WTP and AC implicitly
> > indicates that the WTP = is=20 operational. For the purpose of protocol
> > simplicity, I = suggest=20 that we focus on statistics messages
> alone for
> > = this=20 purpose, reason being that statistics are periodically
>=20 exchanged.
> >
> > My concern is that by using = "any"=20 control message to indicate
> > keepalive (Echo), the AC = processing=20 will be complicated. This is
> > because the AC will need = to=20 process each control message
> for both its own value = (e.g.
>=20 > Configure Request) and also keepalive value.
>
> Of = course,=20 complexity is a function of many factors, but
> there is a=20 straightforward way to implement an echo trigger
> with a flag = and=20 timer:
> when you receive a control message, unconditionally = raise the=20 flag.
> Periodically (according to your keepalive interval = timer)=20
> check the flag; If it's up, put it down, else send = a
>=20 keepalive. There are more complicated ways to implement, but
> = this=20 works just fine.
>
> On the AC this can easily be = implemented by=20 having the
> fastpath raise the flag, and having the cp lower = it=20 and/or do
> whatever it is your AC does if a WTP doesn't = report in=20 a
> given echo interval (which may be nothing). Pretty basic=20 stuff.
>
> On the WTP, implementation is similar, except = that if=20 the
> flag is down, you send the keepalive. Again, very = simple and=20 basic.
>
> > So I suggest keeping it simple - arrival = of=20 statistics message from
> > WTP means WTP is = alive.
>
>=20 Certainly, a statistics message qualifies as a control
> = message, so=20 I have no issues with this statement when taken
> alone. I'm = concerned=20 with the earlier suggestion that the
> echo req/reply message = be=20 discarded and replaced by the
> statistics message. =
>
>=20 In some cases, the keepalive interval must be *very* brief = in
> order=20 to facilitate rapid link loss detection and recovery. I
> know = of one=20 vendor who routinely uses a one second interval,
> and it's=20 conceivable that in some scenarios one might choose
> to use = even=20 less.
>
> And keep in mind that WTP and AC requirements = are=20 typically
> asymmetric in this regard: the WTP needs to react = quickly=20
> (maybe try to find another AC), whereas the AC simply = needs
>=20 to somehow report the event.
> While in some cases reporting = might be=20 considered urgent,
> this is not the typical (or average) = case.=20
>
> The granularity requirements for reporting are = typically=20 much
> coarser than those of recovery. That is, the AC may, at = it's
> option, only check every 10,20,30,... seconds for = WTP
>=20 liveness, and it may very well do that via the stats message, =
>=20 rather than the echo, since this allows echo processing to
> = remain=20 wholly in the AC fastpath.
>
> But say we eliminate the = echo:=20 what happens when, say, 500
> WTPs send stats potentially = every second=20 or less?
>
> I think we still need the echo=20 req/rsp.
>
> Scott
>
> >
> >=20 Saravanan
> >
> >
> >
> = >
>=20 >
> > -----Original Message-----
> > From: = Scott G.=20 Kelly [mailto:s.kelly@ix.netcom.com]
> = >=20 Sent: Wednesday, April 19, 2006 1:51 AM
> > To: = capwap
> >=20 Subject: RE: [Capwap] Proposed Resolution to Issue 45
> >=20 -Issueoncombiningmessages
> >
> > Just trying to = close the=20 loop: I think David's point (i.e.
> that echoes
> > = should=20 only be sent in the absence of other control
> traffic) is = dead=20
> > on, and that this effectively closes the question as=20 to
> whether echoes
> > and stats should be combined = in the=20 same messages.
> >
> > Does anyone = disagree?
>=20 >
> > Scott
> >
> >
> >=20 = _________________________________________________________________
>= =20 > To unsubscribe or modify your subscription options, please=20 visit:
> > http://lists.f= rascone.com/mailman/listinfo/capwap
>=20 >
> > Archives: http://lists.frascone= .com/pipermail/capwap
>=20 >
> >
>=20 _________________________________________________________________ =
>=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
>
____________________________________= _____________________________
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_01C66EEE.96C5D952-- --===============1796872610== 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 --===============1796872610==-- From bea@cc.ntnu.edu.tw Wed May 03 16:24:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbNtp-0003T0-Fm for capwap-archive@ietf.org; Wed, 03 May 2006 16:24:41 -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 1FbNtp-0000yD-Dh for capwap-archive@ietf.org; Wed, 03 May 2006 16:24:41 -0400 Received: from 59-115-219-42.dynamic.hinet.net ([59.115.219.42] helo=cc.ntnu.edu.tw) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FbNtk-0000M5-Lw for capwap-archive@ietf.org; Wed, 03 May 2006 16:24:37 -0400 Message-ID: <000001c66eef$7d8c8cc0$b45ba8c0@edl56> Reply-To: "Kaylin Beall" From: "Kaylin Beall" To: capwap-archive@ietf.org Subject: Re: uepoo news Date: Wed, 3 May 2006 13:23:50 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C66EB4.D12DB4C0" 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.3 (+++) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C66EB4.D12DB4C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dea e r Home O h wne s r ,=20 =20 Your cr g ed h it doesn't matter to us ! If you O s WN real e n st f at s e=20 and want IM q MED x IA l TE cas u h to s b pen q d ANY way you like, or simply wish=20 to L y OWER your monthly pa h yme n nts by a third or more, here are the de b als=20 we have T l ODA n Y :=20 =20 $ 4 z 88 , 000 at a 3 t , 67% f m ixed - rat z e=20 $ 3 s 72 , 000 at a 3 , 9 f 0% va u riab t le - rat q e=20 $ 4 h 92 , 000 at a 3 , z 21% in m tere f st - only=20 $ 2 a 48 , 000 at a 3 , h 36% f b ixed - rat v e=20 $ 1 m 98 , 000 at a 3 , t 55% v w ariable - rat f e=20 =20 Hur q ry, when these deaI f s are gone, they are gone ! =20 Don't worry about a w pprov z al, your cr p edi k t will not di i squa m lify you !=20 =20 V m isi t t our x site =20 =20 Sincerely, Kaylin Beall=20 =20 Ap g pr z oval Manager ------=_NextPart_000_0001_01C66EB4.D12DB4C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dea e r Home O h wne s r ,
 
Your cr g ed h it doesn't matter to us !=20 If you O s WN real e n st f at s e
and want IM q MED x IA l TE cas u h to s b pen q d ANY=20 way you like, or simply wish
to L y OWER your monthly pa h yme n nts=20 by a third or more, here are the de b als
we have T l ODA n Y :
 
$ 4 z 88 , 000 at a 3 t , 67% f m ixed - rat z e
$ 3 s 72 , 000 at a 3 , 9 f 0% va u riab t le - rat q e
$ 4 h 92 , 000 at a 3 , z 21% in m tere f st - only
$ 2 a 48 , 000 at a 3 , h 36% f b ixed - rat v e
$ 1 m 98 , 000 at a 3 , t 55% v w ariable - rat f e
 
Hur q ry, when these deaI f s are gone, they are gone !
 
Don't worry about a w pprov z al, your cr p edi k t will=20 not di i squa m lify you !
 
=20 V m isi t t our x site
 
Sincerely, Kaylin Beall
 
Ap g pr z oval Manager
------=_NextPart_000_0001_01C66EB4.D12DB4C0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 03 16:36:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbO56-00075M-BU for capwap-archive@lists.ietf.org; Wed, 03 May 2006 16:36:20 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbO54-0002Bj-O5 for capwap-archive@lists.ietf.org; Wed, 03 May 2006 16:36:20 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1148B4300C4 for ; Wed, 3 May 2006 13:36:18 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id CD5EE43004F for ; Wed, 3 May 2006 13:35:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4A9861448037 for ; Wed, 3 May 2006 13:35:35 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.205]) by hermes.tigertech.net (Postfix) with ESMTP id AC8CB144803C for ; Wed, 3 May 2006 13:35:31 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id h30so203752wxd for ; Wed, 03 May 2006 13:35:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=ni30scpPteAjMEpQz2g8GA/ewvtKmIAaUGYHhdKUphL5gJ03ABRCVj84ZueT9TGtLj+PtYCkuAWTxe5aIePFd26g77QF70lHzBQaMA2Efvlg1DAzcq+L2Ce05Z+MNfqsDk5i3vXHNJrmGUo7CVH2wbjp42ZDgEnK3I+NEjRdioo= Received: by 10.70.51.7 with SMTP id y7mr96168wxy; Wed, 03 May 2006 13:35:30 -0700 (PDT) Received: by 10.70.6.8 with HTTP; Wed, 3 May 2006 13:35:30 -0700 (PDT) Message-ID: <5bfe7a820605031335r55aa988ehc7a6e09e4f75007@mail.gmail.com> Date: Wed, 3 May 2006 13:35:30 -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=0.6 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_50_60, HTML_MESSAGE, RCVD_BY_IP X-Spam-Level: Subject: [Capwap] Re: Duplicate Messages - WTP Event and 802.11 WTP Event? - Issue 110 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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="===============1672160320==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f --===============1672160320== Content-Type: multipart/alternative; boundary="----=_Part_30882_12710226.1146688530095" ------=_Part_30882_12710226.1146688530095 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, Proposed resolution for issue 110, for the -01 draft: Delete the 802.11 specific WTP Event message, and indicate in the 802.11 MIC Countermeasures and WTP Radio Fail Alarm Indication message element text that these 802.11 specific message elements are sent in the WTP event message. Comments? Thanks, Dorothy On 4/25/06, Dorothy Stanley wrote: > > All, > > There are two WTP event messages defined, one CAPWAP WTPEevent message ( > 8.5), and an > 802.11 specific one (11.8.3), which carries a MIC counterneasures or radi= o > fail alarm message element. > > It's not clear that the specific 802.11 WTP event message > needed, as the CAWPAP WTP Event message is intended to carry > binding specific message elements. > > Comments? > > Thanks, > > Dorothy > ------=_Part_30882_12710226.1146688530095 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All,

Proposed resolution for issue 110, for the -01 draft:

Delete the 802.11 specific WTP Event message, and indicate in the
 802.11 MIC Countermeasures and WTP Radio Fail Alarm
Indication message element text that these
802.11 specific message elements are sent in the WTP event message.

Comments?

Thanks,

Dorothy

On 4/25/06, Dorothy Stanley <dstanley1389@gmail.com> wrote:
All,

There are two WTP event messages defined, one CAPWAP WTPEevent message (8.5), an= d an
802.11 specific one (11.8.3), which carries a MIC counterneasures or radio = fail alarm message element.

It's not clear that the specific 802.11 WTP event me= ssage
needed, as the CAWPAP WTP <= span id=3D"st" name=3D"st" class=3D"st">Event message is intended to= carry
binding specific message elements.

Comments?

Thanks,

Dorothy

------=_Part_30882_12710226.1146688530095-- --===============1672160320== 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 --===============1672160320==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 03 16:56:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbOOh-00025z-38 for capwap-archive@lists.ietf.org; Wed, 03 May 2006 16:56:35 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbOOf-0002sL-CS for capwap-archive@lists.ietf.org; Wed, 03 May 2006 16:56:35 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4FC474300C2 for ; Wed, 3 May 2006 13:56:32 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 0E41643005F for ; Wed, 3 May 2006 13:56:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D6EC7144802B for ; Wed, 3 May 2006 13:55:59 -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 349541448003 for ; Wed, 3 May 2006 13:55:56 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 03 May 2006 13:55:56 -0700 X-IronPort-AV: i="4.05,85,1146466800"; d="scan'208,217"; a="1801087099:sNHT49601208" 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 k43Ktuh0003335; Wed, 3 May 2006 13:55: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); Wed, 3 May 2006 13:55:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] Re: Duplicate Messages - WTP Event and 802.11 WTP Event? -Issue 110 Date: Wed, 3 May 2006 13:55:54 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D2517B@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Re: Duplicate Messages - WTP Event and 802.11 WTP Event? -Issue 110 Thread-Index: AcZu8UyeOga0id3ATDq+mu8iOGl1rQAAqmEA From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "capwap" X-OriginalArrivalTime: 03 May 2006 20:55:56.0024 (UTC) FILETIME=[F8FF7F80:01C66EF3] 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 X-Spam-Level: Cc: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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="===============0061999319==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 This is a multi-part message in MIME format. --===============0061999319== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66EF3.F8CB83EA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66EF3.F8CB83EA 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: Wednesday, May 03, 2006 1:36 PM To: capwap Subject: [Capwap] Re: Duplicate Messages - WTP Event and 802.11 WTP Event? -Issue 110 =09 =09 All, =09 Proposed resolution for issue 110, for the -01 draft: =09 Delete the 802.11 specific WTP Event message, and indicate in the 802.11 MIC Countermeasures and WTP Radio Fail Alarm Indication message element text that these 802.11 specific message elements are sent in the WTP event message. =09 Comments? =09 Thanks, =09 Dorothy =09 =09 On 4/25/06, Dorothy Stanley wrote:=20 All, =09 There are two WTP event messages defined, one CAPWAP WTPEevent message (8.5), and an 802.11 specific one (11.8.3), which carries a MIC counterneasures or radio fail alarm message element. =09 It's not clear that the specific 802.11 WTP event message needed, as the CAWPAP WTP Event message is intended to carry=20 binding specific message elements. =09 Comments? =09 Thanks, =09 =09 Dorothy =09 ------_=_NextPart_001_01C66EF3.F8CB83EA 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: Wednesday, May 03, = 2006 1:36=20 PM
To: capwap
Subject: [Capwap] Re: Duplicate = Messages -=20 WTP Event and 802.11 WTP Event? -Issue 110

All,

Proposed resolution for issue 110, for the -01=20 draft:

Delete the 802.11 specific WTP Event message, and = indicate in=20 the
 802.11 MIC Countermeasures and WTP Radio Fail = Alarm
Indication=20 message element text that these
802.11 specific message elements = are sent=20 in the WTP event=20 message.

Comments?

Thanks,

Dorothy

On 4/25/06, Dorothy=20 Stanley <dstanley1389@gmail.com>=20 wrote:
All,

There are two WTP event messages defined, one CAPWAP = WTPEevent=20 message (8.5), and an
802.11 specific one (11.8.3), which carries = a MIC=20 counterneasures or radio fail alarm message element.

It's not = clear=20 that the specific 802.11 WTP event message
needed, as = the CAWPAP WTP Event message is intended to carry
binding = specific=20 message elements.

Comments?

Thanks,

Dorothy

------_=_NextPart_001_01C66EF3.F8CB83EA-- --===============0061999319== 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 --===============0061999319==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 03 17:30:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbOv7-0007nP-4A for capwap-archive@lists.ietf.org; Wed, 03 May 2006 17:30:05 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbOv5-0003je-KS for capwap-archive@lists.ietf.org; Wed, 03 May 2006 17:30:05 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B9E034300EC for ; Wed, 3 May 2006 14:30:02 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8519E43005F for ; Wed, 3 May 2006 14:29:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5BE3F1448039 for ; Wed, 3 May 2006 14:29:30 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.152]) by hermes.tigertech.net (Postfix) with ESMTP id 988331448007 for ; Wed, 3 May 2006 14:29:27 -0700 (PDT) Received: from [192.168.0.2] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (rwcrmhc12) with ESMTP id <20060503212926m1200cpnkue>; Wed, 3 May 2006 21:29:26 +0000 Message-ID: <445920B6.70104@cs.umd.edu> Date: Wed, 03 May 2006 17:29:26 -0400 From: Charles Clancy User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Montemurro Subject: Re: [Capwap] to mux or not to mux? References: <08A9A3213527A6428774900A80DBD8D801DD1785@xmb-sjc-222.amer.cisco.com> <26140d940605031043t333877bbmf175264b948f4663@mail.gmail.com> In-Reply-To: <26140d940605031043t333877bbmf175264b948f4663@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Even with the MUX header, you have two independent, logical channels. If you think about it, UDP is really just one big MUX header. What we're doing is really nothing different. It should not impact anything to do with sequence numbers or key derivation. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Michael Montemurro wrote: > Nancy brings up an interesting point here. > > If we go with the MUX header approach, how do we achieve key separation > between the control and data channels? > > How do we derive the keys and how do we maintain sequence counters. > > Cheers, > > Mike > > > > > On 5/2/06, *Nancy Winget (ncamwing)* > wrote: > > > I don't believe adding a MUX is the right answer. First, the addition > is a change in DTLS and also brings up other issues of concern: > - distinguishing the control from data plane is a good thing as the > firewall rules may be different for each plane which is already > addressed by the UDP assignments. > - merging the control and data plane into a single UDP (dtls) tunnel > forces the two planes to be synchronized from an anti-replay > perspective. This effectively restricts the architecture to force them > to use a centralized DTLS encapsulation/decapsulation which imho is too > restrictive > > Nancy. > > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com > ] > Sent: Monday, May 01, 2006 11:38 AM > To: capwap > Subject: [Capwap] to mux or not to mux? > > Some time ago, I proposed that we use a single port for capwap, and > insert a mux header right after the UDP header to differentiate between > control and data. While there was some discussion, we did not reach a > conclusion. > > Here's what it would look like: > > +---------+-------------+------------------------------- > | UDP Hdr | MUX Hdr = 1 | DTLS Enc Control Packet .... > +---------+-------------+---------------------- > > The capwap editors are currently working hard to produce the 01 version > of the capwap document, and it would be best for implementers if this > question could be decided prior to publication of that document. To > facilitate this, I've summarized briefly below. > > Using separate ports for control/data has a number of drawbacks: > > - if firewalls are between the AC and WTP, multiple rules are required > > - we must be able to explicitly bind the data and control channels at > the AC in order to ensure proper operation; if they use the same port > (and therefore, flow), this is straightforward; if not, we must add > protocol elements for detecting and accounting for NATs along the AC-WTP > path, and for explicitly (and securely) creating the bindings between > the two channels > > - there are race conditions that must be dealt with; in particular, it > is possible to have the left hand (control channel) not knowing for > certain what the right hand (data channel) is doing (and vice versa) > > - If there *are* NATs along the path, using two ports will require > keepalives on both ports, and error handling for when one channel goes > away but the other does not (e.g. if a middlebox deletes the NAT > bindings for any reason) > > - there are many more error conditions to manage in the state machine, > due to the channel binding and NAT issues > > Clearly, using two ports adds *significant* complexity to the > implementation, and will likely result in operational problems in some > environments. > > Using a mux header has one drawback (that I can think of): > > - it adds n bytes to the header. I'm tempted to say n will be 4 for > 32-bit alignment, but it could also be only 1 or 2 bytes, if > bits-on-the-wire overhead is an overriding concern. > > Using a mux hader has several advantages: > > - we get NAT traversal for free, by simply configuring the echo interval > to be smaller than the NAT binding lifetime for the path in question > > - we only open one port through intermediate firewalls (and any > intermediate NATs) > > - the implementation (state machine, error handling) is *much* simpler, > and therefore more likely > to (inter)operate according to spec > > We need to decide on this, preferably within the next day or two. > Please > speak up and make your preferences known. > > 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 > > > > ------------------------------------------------------------------------ > > _________________________________________________________________ > 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 May 03 17:34:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbOzc-0000Vg-Gx for capwap-archive@lists.ietf.org; Wed, 03 May 2006 17:34:44 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbOzb-0003t1-S0 for capwap-archive@lists.ietf.org; Wed, 03 May 2006 17:34:44 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 74E6C4300F9 for ; Wed, 3 May 2006 14:34:43 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 869A343004F for ; Wed, 3 May 2006 14:34:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 75A5F398036 for ; Wed, 3 May 2006 14:34:17 -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 5A21C398043 for ; Wed, 3 May 2006 14:34:13 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 03 May 2006 14:34:13 -0700 X-IronPort-AV: i="4.05,85,1146466800"; d="scan'208"; a="272569345:sNHT44957536" 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 k43LYCh0005909; Wed, 3 May 2006 14:34:12 -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, 3 May 2006 14:34:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] to mux or not to mux? Date: Wed, 3 May 2006 14:34:11 -0700 Message-ID: <08A9A3213527A6428774900A80DBD8D801DD1DB2@xmb-sjc-222.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] to mux or not to mux? Thread-Index: AcZu+KsB0Y++DiRhS+SA1fCPDhRolwAAB9TQ From: "Nancy Winget (ncamwing)" To: "Charles Clancy" , "Michael Montemurro" X-OriginalArrivalTime: 03 May 2006 21:34:12.0405 (UTC) FILETIME=[51BF6E50:01C66EF9] 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Charles,=20 With a MUX, yes they are logical channels, but I believe the implication is that these channels are merged into a single DTLS tunnel...are you saying they are not? =20 But as you state, if UDP is a MUX header, why the need to introduce yet another one instead of just using UDP for separation? Nancy. =20 -----Original Message----- From: Charles Clancy [mailto:clancy@cs.umd.edu]=20 Sent: Wednesday, May 03, 2006 2:29 PM To: Michael Montemurro Cc: Nancy Winget (ncamwing); capwap Subject: Re: [Capwap] to mux or not to mux? Even with the MUX header, you have two independent, logical channels.=20 If you think about it, UDP is really just one big MUX header. What we're doing is really nothing different. It should not impact anything to do with sequence numbers or key derivation. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Michael Montemurro wrote: > Nancy brings up an interesting point here. > =20 > If we go with the MUX header approach, how do we achieve key=20 > separation between the control and data channels? > =20 > How do we derive the keys and how do we maintain sequence counters. > =20 > Cheers, > =20 > Mike > =20 >=20 >=20 > =20 > On 5/2/06, *Nancy Winget (ncamwing)* > wrote: >=20 >=20 > I don't believe adding a MUX is the right answer. First, the addition > is a change in DTLS and also brings up other issues of concern: > - distinguishing the control from data plane is a good thing as the > firewall rules may be different for each plane which is already > addressed by the UDP assignments. > - merging the control and data plane into a single UDP (dtls) tunnel > forces the two planes to be synchronized from an anti-replay > perspective. This effectively restricts the architecture to force them > to use a centralized DTLS encapsulation/decapsulation which imho is too > restrictive >=20 > Nancy. >=20 > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com > ] > Sent: Monday, May 01, 2006 11:38 AM > To: capwap > Subject: [Capwap] to mux or not to mux? >=20 > Some time ago, I proposed that we use a single port for capwap, and > insert a mux header right after the UDP header to differentiate between > control and data. While there was some discussion, we did not reach a > conclusion. >=20 > Here's what it would look like: >=20 > +---------+-------------+------------------------------- > | UDP Hdr | MUX Hdr =3D 1 | DTLS Enc Control Packet .... > +---------+-------------+---------------------- >=20 > The capwap editors are currently working hard to produce the 01 version > of the capwap document, and it would be best for implementers if this > question could be decided prior to publication of that document. To > facilitate this, I've summarized briefly below. >=20 > Using separate ports for control/data has a number of drawbacks: >=20 > - if firewalls are between the AC and WTP, multiple rules are=20 > required >=20 > - we must be able to explicitly bind the data and control channels at > the AC in order to ensure proper operation; if they use the same port > (and therefore, flow), this is straightforward; if not, we must add > protocol elements for detecting and accounting for NATs along the AC-WTP > path, and for explicitly (and securely) creating the bindings between > the two channels >=20 > - there are race conditions that must be dealt with; in particular, it > is possible to have the left hand (control channel) not knowing for > certain what the right hand (data channel) is doing (and vice=20 > versa) >=20 > - If there *are* NATs along the path, using two ports will require > keepalives on both ports, and error handling for when one channel goes > away but the other does not (e.g. if a middlebox deletes the NAT > bindings for any reason) >=20 > - there are many more error conditions to manage in the state machine, > due to the channel binding and NAT issues >=20 > Clearly, using two ports adds *significant* complexity to the > implementation, and will likely result in operational problems in some > environments. >=20 > Using a mux header has one drawback (that I can think of): >=20 > - it adds n bytes to the header. I'm tempted to say n will be 4 for > 32-bit alignment, but it could also be only 1 or 2 bytes, if > bits-on-the-wire overhead is an overriding concern. >=20 > Using a mux hader has several advantages: >=20 > - we get NAT traversal for free, by simply configuring the echo interval > to be smaller than the NAT binding lifetime for the path in=20 > question >=20 > - we only open one port through intermediate firewalls (and any > intermediate NATs) >=20 > - the implementation (state machine, error handling) is *much* simpler, > and therefore more likely > to (inter)operate according to spec >=20 > We need to decide on this, preferably within the next day or two. > Please > speak up and make your preferences known. >=20 > Thanks, >=20 > Scott >=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 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap >=20 > Archives: http://lists.frascone.com/pipermail/capwap >=20 >=20 >=20 > ---------------------------------------------------------------------- > -- >=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 _________________________________________________________________ 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 May 03 17:45:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbPAC-0000Vr-9H for capwap-archive@lists.ietf.org; Wed, 03 May 2006 17:45:40 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbPAA-0004Qc-LO for capwap-archive@lists.ietf.org; Wed, 03 May 2006 17:45:40 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4B20F430127 for ; Wed, 3 May 2006 14:45:38 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B932F430092 for ; Wed, 3 May 2006 14:45:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id AD27F39803F for ; Wed, 3 May 2006 14:45:14 -0700 (PDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.200.83]) by zoidberg.tigertech.net (Postfix) with ESMTP id C092A398036 for ; Wed, 3 May 2006 14:45:11 -0700 (PDT) Received: from [192.168.0.2] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (sccrmhc13) with ESMTP id <20060503214510013001bso2e>; Wed, 3 May 2006 21:45:10 +0000 Message-ID: <44592467.40800@cs.umd.edu> Date: Wed, 03 May 2006 17:45:11 -0400 From: Charles Clancy User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Nancy Winget (ncamwing)" Subject: Re: [Capwap] to mux or not to mux? References: <08A9A3213527A6428774900A80DBD8D801DD1DB2@xmb-sjc-222.amer.cisco.com> In-Reply-To: <08A9A3213527A6428774900A80DBD8D801DD1DB2@xmb-sjc-222.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f The DTLS tunnels would NOT be merged. You'd have something like: +---------+------------+------------------------ | UDP hdr | MUX = 0x01 | DTLS(CAPWAP Control) +---------+------------+----------- or +---------+------------+------------------------ | UDP hdr | MUX = 0x02 | CAPWAP Data +---------+------------+----------- UDP is indeed a MUX header, but it's a MUX header that everything already understands. So, it all comes down to whether or not we want intermediate network devices to distinguish between control and data. For NAT traversal, it's easier if the NAT treats everything the same, and doesn't have to know that the two ports are related. Same for firewall / port forwarding. I think intermediate network devices should treat everything as "CAPWAP", and we should therefore do our own MUX. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Nancy Winget (ncamwing) wrote: > Charles, > > With a MUX, yes they are logical channels, but I believe the implication > is that these channels are merged into a single DTLS tunnel...are you > saying they are not? > > But as you state, if UDP is a MUX header, why the need to introduce yet > another one instead of just using UDP for separation? > > Nancy. > > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Wednesday, May 03, 2006 2:29 PM > To: Michael Montemurro > Cc: Nancy Winget (ncamwing); capwap > Subject: Re: [Capwap] to mux or not to mux? > > Even with the MUX header, you have two independent, logical channels. > If you think about it, UDP is really just one big MUX header. What > we're doing is really nothing different. It should not impact anything > to do with sequence numbers or key derivation. > > -- > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > Michael Montemurro wrote: > >>Nancy brings up an interesting point here. >> >>If we go with the MUX header approach, how do we achieve key >>separation between the control and data channels? >> >>How do we derive the keys and how do we maintain sequence counters. >> >>Cheers, >> >> Mike >> >> >> >> >>On 5/2/06, *Nancy Winget (ncamwing)* >> wrote: >> >> >> I don't believe adding a MUX is the right answer. First, the > > addition > >> is a change in DTLS and also brings up other issues of concern: >> - distinguishing the control from data plane is a good thing as > > the > >> firewall rules may be different for each plane which is already >> addressed by the UDP assignments. >> - merging the control and data plane into a single UDP (dtls) > > tunnel > >> forces the two planes to be synchronized from an anti-replay >> perspective. This effectively restricts the architecture to force > > them > >> to use a centralized DTLS encapsulation/decapsulation which imho > > is too > >> restrictive >> >> Nancy. >> >> -----Original Message----- >> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com >> ] >> Sent: Monday, May 01, 2006 11:38 AM >> To: capwap >> Subject: [Capwap] to mux or not to mux? >> >> Some time ago, I proposed that we use a single port for capwap, > > and > >> insert a mux header right after the UDP header to differentiate > > between > >> control and data. While there was some discussion, we did not > > reach a > >> conclusion. >> >> Here's what it would look like: >> >> +---------+-------------+------------------------------- >> | UDP Hdr | MUX Hdr = 1 | DTLS Enc Control Packet .... >> +---------+-------------+---------------------- >> >> The capwap editors are currently working hard to produce the 01 > > version > >> of the capwap document, and it would be best for implementers if > > this > >> question could be decided prior to publication of that document. > > To > >> facilitate this, I've summarized briefly below. >> >> Using separate ports for control/data has a number of drawbacks: >> >> - if firewalls are between the AC and WTP, multiple rules are >>required >> >> - we must be able to explicitly bind the data and control channels > > at > >> the AC in order to ensure proper operation; if they use the same > > port > >> (and therefore, flow), this is straightforward; if not, we must > > add > >> protocol elements for detecting and accounting for NATs along the > > AC-WTP > >> path, and for explicitly (and securely) creating the bindings > > between > >> the two channels >> >> - there are race conditions that must be dealt with; in > > particular, it > >> is possible to have the left hand (control channel) not knowing > > for > >> certain what the right hand (data channel) is doing (and vice >>versa) >> >> - If there *are* NATs along the path, using two ports will require >> keepalives on both ports, and error handling for when one channel > > goes > >> away but the other does not (e.g. if a middlebox deletes the NAT >> bindings for any reason) >> >> - there are many more error conditions to manage in the state > > machine, > >> due to the channel binding and NAT issues >> >> Clearly, using two ports adds *significant* complexity to the >> implementation, and will likely result in operational problems in > > some > >> environments. >> >> Using a mux header has one drawback (that I can think of): >> >> - it adds n bytes to the header. I'm tempted to say n will be 4 > > for > >> 32-bit alignment, but it could also be only 1 or 2 bytes, if >> bits-on-the-wire overhead is an overriding concern. >> >> Using a mux hader has several advantages: >> >> - we get NAT traversal for free, by simply configuring the echo > > interval > >> to be smaller than the NAT binding lifetime for the path in >>question >> >> - we only open one port through intermediate firewalls (and any >> intermediate NATs) >> >> - the implementation (state machine, error handling) is *much* > > simpler, > >> and therefore more likely >> to (inter)operate according to spec >> >> We need to decide on this, preferably within the next day or two. >> Please >> speak up and make your preferences known. >> >> 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 >> >> >> >>---------------------------------------------------------------------- >>-- >> >>_________________________________________________________________ >>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 May 03 17:47:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbPCC-0002Bd-Ro for capwap-archive@lists.ietf.org; Wed, 03 May 2006 17:47:44 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbPCB-0004Tv-EZ for capwap-archive@lists.ietf.org; Wed, 03 May 2006 17:47:44 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 176104300FF for ; Wed, 3 May 2006 14:47:43 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D2D704300B0 for ; Wed, 3 May 2006 14:47:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id B96B139802B for ; Wed, 3 May 2006 14:47:07 -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 867F7398046 for ; Wed, 3 May 2006 14:47:03 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 03 May 2006 14:47:03 -0700 X-IronPort-AV: i="4.05,85,1146466800"; d="scan'208"; a="426174066:sNHT27268254" 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 k43Ll3RT027023; Wed, 3 May 2006 14:47:03 -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, 3 May 2006 14:47:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] to mux or not to mux? Date: Wed, 3 May 2006 14:47:01 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D251CE@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] to mux or not to mux? Thread-Index: AcZu+vEzvO2HcdttRDmN/xHFGu0U4QAABgsA From: "Pat Calhoun (pacalhou)" To: "Charles Clancy" , "Nancy Winget (ncamwing)" X-OriginalArrivalTime: 03 May 2006 21:47:03.0114 (UTC) FILETIME=[1D204AA0:01C66EFB] 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 > UDP is indeed a MUX header, but it's a MUX header that=20 > everything already understands.=20 And that's the beauty with the use of UDP. 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 May 03 17:56:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbPKn-0008Bv-Q8 for capwap-archive@lists.ietf.org; Wed, 03 May 2006 17:56:37 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbPKm-0004y4-7Q for capwap-archive@lists.ietf.org; Wed, 03 May 2006 17:56:37 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 90DE743011E for ; Wed, 3 May 2006 14:56:35 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7297243004F for ; Wed, 3 May 2006 14:56:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 61C0F398017 for ; Wed, 3 May 2006 14:56:16 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.151]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8AF5E39803A for ; Wed, 3 May 2006 14:56:13 -0700 (PDT) Received: from [192.168.0.2] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (rwcrmhc11) with ESMTP id <20060503215611m11005b43ce>; Wed, 3 May 2006 21:56:11 +0000 Message-ID: <445926FC.9030604@cs.umd.edu> Date: Wed, 03 May 2006 17:56:12 -0400 From: Charles Clancy User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charles Clancy Subject: Re: [Capwap] to mux or not to mux? References: <08A9A3213527A6428774900A80DBD8D801DD1DB2@xmb-sjc-222.amer.cisco.com> <44592467.40800@cs.umd.edu> In-Reply-To: <44592467.40800@cs.umd.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Just to clarify, MUXing or not MUXing does not affect security one way or the other. Thus my opinion is as a member of the WG, and not as a security advisor. It apparently affects deployments and implementations, which is not my expertise, and thus my comments should be weighted as such. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Charles Clancy wrote: > The DTLS tunnels would NOT be merged. You'd have something like: > > +---------+------------+------------------------ > | UDP hdr | MUX = 0x01 | DTLS(CAPWAP Control) > +---------+------------+----------- > > or > > +---------+------------+------------------------ > | UDP hdr | MUX = 0x02 | CAPWAP Data > +---------+------------+----------- > > UDP is indeed a MUX header, but it's a MUX header that everything > already understands. So, it all comes down to whether or not we want > intermediate network devices to distinguish between control and data. > For NAT traversal, it's easier if the NAT treats everything the same, > and doesn't have to know that the two ports are related. Same for > firewall / port forwarding. I think intermediate network devices should > treat everything as "CAPWAP", and we should therefore do our own MUX. > _________________________________________________________________ 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 May 03 18:17:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbPeb-0006yz-EE for capwap-archive@lists.ietf.org; Wed, 03 May 2006 18:17:05 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbPeZ-0005WT-JQ for capwap-archive@lists.ietf.org; Wed, 03 May 2006 18:17:05 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 77B134300E6 for ; Wed, 3 May 2006 15:17:00 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 61A4F43004F for ; Wed, 3 May 2006 15:16:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4F4C539803A for ; Wed, 3 May 2006 15:16:30 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 95D1639802B for ; Wed, 3 May 2006 15:16: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 k43MGLQM032012; Wed, 3 May 2006 15:16:21 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k43MGLwo032009; Wed, 3 May 2006 15:16:21 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 3 May 2006 15:16:21 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Charles Clancy Subject: Re: [Capwap] to mux or not to mux? In-Reply-To: <44592467.40800@cs.umd.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 HI, Please don't forget about the discovery message. With it, you have 3 values for MUX. See below.. Also, please note that in the prototype that I'm developing, I'm using the UNMODIFIED DTLS implementation in openSSL. That is, adding the MUX header does not require any modification of the openSSL. By the way,my two wishes are: 1) an Ethereal decode for the below 2) the addition of the NULL encryption type to the CAPWAP protocol for debugging On Wed, 3 May 2006, Charles Clancy wrote: > The DTLS tunnels would NOT be merged. You'd have something like: +---------+------------+------------------------ | UDP hdr | MUX = 0x00 | Discovery Request or Response +---------+------------+----------- > +---------+------------+------------------------ > | UDP hdr | MUX = 0x01 | DTLS(CAPWAP Control) > +---------+------------+----------- > > or > > +---------+------------+------------------------ > | UDP hdr | MUX = 0x02 | CAPWAP Data > +---------+------------+----------- > > UDP is indeed a MUX header, but it's a MUX header that everything > already understands. So, it all comes down to whether or not we want > intermediate network devices to distinguish between control and data. > For NAT traversal, it's easier if the NAT treats everything the same, > and doesn't have to know that the two ports are related. Same for > firewall / port forwarding. I think intermediate network devices should > treat everything as "CAPWAP", and we should therefore do our own MUX. > > -- > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > Nancy Winget (ncamwing) wrote: > > Charles, > > > > With a MUX, yes they are logical channels, but I believe the implication > > is that these channels are merged into a single DTLS tunnel...are you > > saying they are not? > > > > But as you state, if UDP is a MUX header, why the need to introduce yet > > another one instead of just using UDP for separation? > > > > Nancy. > > > > -----Original Message----- > > From: Charles Clancy [mailto:clancy@cs.umd.edu] > > Sent: Wednesday, May 03, 2006 2:29 PM > > To: Michael Montemurro > > Cc: Nancy Winget (ncamwing); capwap > > Subject: Re: [Capwap] to mux or not to mux? > > > > Even with the MUX header, you have two independent, logical channels. > > If you think about it, UDP is really just one big MUX header. What > > we're doing is really nothing different. It should not impact anything > > to do with sequence numbers or key derivation. > > > > -- > > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > > > Michael Montemurro wrote: > > > >>Nancy brings up an interesting point here. > >> > >>If we go with the MUX header approach, how do we achieve key > >>separation between the control and data channels? > >> > >>How do we derive the keys and how do we maintain sequence counters. > >> > >>Cheers, > >> > >> Mike > >> > >> > >> > >> > >>On 5/2/06, *Nancy Winget (ncamwing)* >>> wrote: > >> > >> > >> I don't believe adding a MUX is the right answer. First, the > > > > addition > > > >> is a change in DTLS and also brings up other issues of concern: > >> - distinguishing the control from data plane is a good thing as > > > > the > > > >> firewall rules may be different for each plane which is already > >> addressed by the UDP assignments. > >> - merging the control and data plane into a single UDP (dtls) > > > > tunnel > > > >> forces the two planes to be synchronized from an anti-replay > >> perspective. This effectively restricts the architecture to force > > > > them > > > >> to use a centralized DTLS encapsulation/decapsulation which imho > > > > is too > > > >> restrictive > >> > >> Nancy. > >> > >> -----Original Message----- > >> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com > >> ] > >> Sent: Monday, May 01, 2006 11:38 AM > >> To: capwap > >> Subject: [Capwap] to mux or not to mux? > >> > >> Some time ago, I proposed that we use a single port for capwap, > > > > and > > > >> insert a mux header right after the UDP header to differentiate > > > > between > > > >> control and data. While there was some discussion, we did not > > > > reach a > > > >> conclusion. > >> > >> Here's what it would look like: > >> > >> +---------+-------------+------------------------------- > >> | UDP Hdr | MUX Hdr = 1 | DTLS Enc Control Packet .... > >> +---------+-------------+---------------------- > >> > >> The capwap editors are currently working hard to produce the 01 > > > > version > > > >> of the capwap document, and it would be best for implementers if > > > > this > > > >> question could be decided prior to publication of that document. > > > > To > > > >> facilitate this, I've summarized briefly below. > >> > >> Using separate ports for control/data has a number of drawbacks: > >> > >> - if firewalls are between the AC and WTP, multiple rules are > >>required > >> > >> - we must be able to explicitly bind the data and control channels > > > > at > > > >> the AC in order to ensure proper operation; if they use the same > > > > port > > > >> (and therefore, flow), this is straightforward; if not, we must > > > > add > > > >> protocol elements for detecting and accounting for NATs along the > > > > AC-WTP > > > >> path, and for explicitly (and securely) creating the bindings > > > > between > > > >> the two channels > >> > >> - there are race conditions that must be dealt with; in > > > > particular, it > > > >> is possible to have the left hand (control channel) not knowing > > > > for > > > >> certain what the right hand (data channel) is doing (and vice > >>versa) > >> > >> - If there *are* NATs along the path, using two ports will require > >> keepalives on both ports, and error handling for when one channel > > > > goes > > > >> away but the other does not (e.g. if a middlebox deletes the NAT > >> bindings for any reason) > >> > >> - there are many more error conditions to manage in the state > > > > machine, > > > >> due to the channel binding and NAT issues > >> > >> Clearly, using two ports adds *significant* complexity to the > >> implementation, and will likely result in operational problems in > > > > some > > > >> environments. > >> > >> Using a mux header has one drawback (that I can think of): > >> > >> - it adds n bytes to the header. I'm tempted to say n will be 4 > > > > for > > > >> 32-bit alignment, but it could also be only 1 or 2 bytes, if > >> bits-on-the-wire overhead is an overriding concern. > >> > >> Using a mux hader has several advantages: > >> > >> - we get NAT traversal for free, by simply configuring the echo > > > > interval > > > >> to be smaller than the NAT binding lifetime for the path in > >>question > >> > >> - we only open one port through intermediate firewalls (and any > >> intermediate NATs) > >> > >> - the implementation (state machine, error handling) is *much* > > > > simpler, > > > >> and therefore more likely > >> to (inter)operate according to spec > >> > >> We need to decide on this, preferably within the next day or two. > >> Please > >> speak up and make your preferences known. > >> > >> 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 > >> > >> > >> > >>---------------------------------------------------------------------- > >>-- > >> > >>_________________________________________________________________ > >>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 May 03 18:26:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbPo2-0001Ay-O5 for capwap-archive@lists.ietf.org; Wed, 03 May 2006 18:26:50 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbPo0-0005hA-TR for capwap-archive@lists.ietf.org; Wed, 03 May 2006 18:26:50 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7A9694300AA for ; Wed, 3 May 2006 15:26:48 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3732143004F for ; Wed, 3 May 2006 15:26:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 267D7398043 for ; Wed, 3 May 2006 15:26:19 -0700 (PDT) Received: from trpz.com (mail1.trpz.com [66.7.225.38]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3288A39801D for ; Wed, 3 May 2006 15:26:14 -0700 (PDT) Received: from [127.0.0.1] ([192.168.5.174]) by trpz.com (8.13.5/8.11.6) with ESMTP id k43LNQXt031424; Wed, 3 May 2006 14:23:28 -0700 Message-ID: <44592DEC.4030204@trapezenetworks.com> Date: Wed, 03 May 2006 15:25:48 -0700 From: Jim Murphy User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "T. Charles Clancy" Subject: Re: [Capwap] BSSID-WLAN mappings References: <17B8C6DE4E228348B4939BDA6B05A9DC0175B515@xmb-sjc-237.amer.cisco.com> <44565B8E.8010103@trapezenetworks.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8 T. Charles Clancy wrote: > Sort of... >=20 > As I understand the conversation, in the M-SSID case, you could send an= =20 > encrypted broadcast packet to other people on your WLAN. This packet=20 > would be encrypted with a key that other users on other WLANs could=20 > know. For example, someone on WLAN-B could see NETBIOS broadcast packet= s=20 > from devices associated to WLAN-A. They might even think they could=20 > communicate with said NETBIOS machines, but unicast packets addressed t= o=20 > them would fail (hopefully, assuming the WTP is properly implemented). >=20 > Jim's scenario below is somewhat different, where you have someone on=20 > the wired side sending data that CAPWAP intentionally decides should be= =20 > transmitted to multiple WLANs. The concern here is more along the line= s=20 > of a chosen ciphertext attack that could leak information about keys by= =20 > seeing packets encrypted multiple times with different keys. Provided=20 > people are using good crypto (i.e. not WEP), this shouldn't be a proble= m. >=20 It doesn't matter if the packet originated on the wired side or not because all broadcast packets from stations must be retransmitted by the AP. Yes, people should be using good crypto, but we should not limit the legitimate flexibility of the protocol to enforce it. Thanks, Jim > --=20 > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy >=20 > On Mon, 1 May 2006, Jim Murphy wrote: >=20 >> Hi, >> >> Hasn't security already been compromised in CAPWAP by the fact that >> a data frame could be sent to multiple WLANs using the WLAN/Status fie= ld >> of the CAPWAP header? Each of these WLANs could be running a different >> crypto type. >> >> Thanks, >> >> Jim >> >> Bob O'Hara (boohara) wrote: >>> As I said, this is a proprietary extension, even if it might have=20 >>> been provided on some Cisco products. I hold that CAPWAP is=20 >>> chartered to implement a protocol to support 802.11, not the myriad=20 >>> proprietary extension that have been hammered onto its side over the=20 >>> years. >>> But, the more damning problem for this is the lowering of security=20 >>> and the violation of the security assumptions on which 802.11i is=20 >>> based. Crossing the boundary of a security domain, even if "only"=20 >>> for multicast, dramatically increases the opportunity for compromise=20 >>> of data that communicants believe is secure. >>> >>> -Bob >>> >>> >>> ---------------------------------------------------------------------= --- >>> *From:* Jeff Joslin [mailto:jjoslin@belairnetworks.com] >>> *Sent:* Friday, April 28, 2006 12:47 PM >>> *To:* Bob O'Hara (boohara); capwap@frascone.com >>> *Subject:* RE: [Capwap] BSSID-WLAN mappings >>> >>> Indeed, the M-SSID mechanism I described is not in the standard but=20 >>> has been implemented by a number of different vendors, including, as=20 >>> I recall, Cisco Aironet. Now that 802.11 chip sets and drivers have=20 >>> better support for M-BSSID, there is little reason to use the more=20 >>> problematic M-SSID. Its only advantage over M-BSSID is that M-SSID=20 >>> uses up fewer MAC addresses. >>> >>> >>> Jeff >>> >>> >>> ---------------------------------------------------------------------= --- >>> >>> *From:* Bob O'Hara (boohara) [mailto:boohara@cisco.com] >>> *Sent:* 28 April 2006 3:35 PM >>> *To:* capwap@frascone.com >>> *Subject:* RE: [Capwap] BSSID-WLAN mappings >>> >>> >>> The mechanism below is, of course, not compliant with the 802.11=20 >>> standard. It is a proprietary extension. It is not clear to me why=20 >>> CAPWAP should support this mechanism, or any other proprietary=20 >>> mechanism. As Jeff points out below, this is not compatible with all= =20 >>> clients (most likely because the mechanism is not mentioned in the=20 >>> standard) and also violates the security assumptions of 802.11. >>> >>> -Bob >>> >>> >>> >>> ---------------------------------------------------------------------= --- >>> >>> *From:* Jeff Joslin [mailto:jjoslin@belairnetworks.com] >>> *Sent:* Friday, April 28, 2006 12:19 PM >>> *To:* capwap@frascone.com >>> *Subject:* RE: [Capwap] BSSID-WLAN mappings >>> >>> You can implement multiple SSID with single BSSID by having only one=20 >>> SSID in the beacon; the others SSIDs are hidden. If a client=20 >>> broadcasts a probe for one of those hidden SSIDs the AP will respond=20 >>> and the client can then do a normal association. The AP maintains one= =20 >>> broadcast/multicast key for each encryption type (WEP, TKIP, AES) and= =20 >>> uses the appropriate one according to the encryption type of the=20 >>> frame=92s SSID. This allows a certain amount of information leakage=20 >>> between SSIDs, but in most applications this is acceptable. >>> >>> >>> The above scheme works, after a fashion, but creates some client=20 >>> compatibility issues. Multiple BSSID is preferable. >>> >>> >>> One SSID =3D=3D 1 WLAN. In general we cannot assume that 1 BSSID =3D=3D= 1 WLAN. >>> >>> >>> Perhaps 1 VLAN =3D=3D 1 WLAN is more helpful? It is standard practice= to=20 >>> map each SSID to a separate VLAN. >>> >>> >>> Jeff Joslin >>> >>> Senior Network Architect >>> >>> BelAir Networks >>> >>> >>> ---------------------------------------------------------------------= --- >>> >>> *From:* Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] >>> *Sent:* 28 April 2006 2:57 PM >>> *To:* Puneet; Bob O'Hara (boohara) >>> *Cc:* capwap@frascone.com >>> *Subject:* RE: [Capwap] BSSID-WLAN mappings >>> >>> >>> Well, first, there is no way that I am aware of where you can have=20 >>> multiple SSIDs for a single BSSID. Furthermore, if one were to do=20 >>> this, how would you handle broadcast packet encryption, where a=20 >>> station would see packets from a BSSID, but would not be able to=20 >>> decrypt it - presumably because the AC would have multiple GTKs, not=20 >>> indexed on a BSSID, but some other non-defined mechanism. >>> >>> >>> I contend 1 BSSID =3D=3D 1 WLAN. >>> >>> Pat Calhoun >>> CTO, Wireless Networking Business Unit >>> Cisco Systems >>> >>> >>> >>> =20 >>> ---------------------------------------------------------------------= --- >>> >>> *From:* Puneet [mailto:pb.ietf@gmail.com] >>> *Sent:* Monday, April 17, 2006 10:39 AM >>> *To:* Bob O'Hara (boohara) >>> *Cc:* capwap@frascone.com >>> *Subject:* Re: [Capwap] BSSID-WLAN mappings >>> >>> Bob, >>> >>> > We should not be implementing, or requiring an CAPWAP >>> implementation to implement a method >>> > that lowers the security of the WLAN. >>> >>> I am not sure I understand the argument here: supporting open or = WEP >>> also does the same thing, but CAPWAP supports those encryption >>> protocols. CAPWAP does not force everyone to support WEP, but it >>> *allows* it to be setup on a WLAN. Along the same lines we should >>> allow this mapping too. Maybe make a note that it does not allow >>> WLAN traffic separation into logical groups over the air (Saravan= ans >>> point) >>> >>> Thanks, >>> Puneet >>> >>> On 4/17/06, *Bob O'Hara (boohara)* >> > wrote: >>> >>> There are also security issues when there is not a 1:1 mapping of >>> WLAN to BSSID. Without this restriction, a station will not have >>> any assurance that traffic it believes is encrypted and protected >>> according to the policy of the WLAN to which it is associated is = not >>> being decrypted by an oracle (the AP) and rebroadcast to other >>> stations without the same requirements for abiding with the same >>> security policies. >>> >>> >>> We should not be implementing, or requiring an CAPWAP implementat= ion >>> to implement a method that lowers the security of the WLAN. >>> >>> -Bob >>> >>> >>> >>> =20 >>> ---------------------------------------------------------------------= --- >>> >>> *From:* Puneet [mailto: pb.ietf@gmail.com=20 >>> ] >>> >>> *Sent:* Sunday, April 16, 2006 4:47 PM >>> *To:* Saravanan Govindan >>> *Cc:* capwap@frascone.com >>> *Subject:* Re: [Capwap] BSSID-WLAN mappings >>> >>> Hi Saravanan, >>> >>> I see your point, but this seems to address a very specific >>> deployment scenario (service providers sharing WLAN equipment). I= f >>> nothing else in the CAPWAP messages is dependent on this, then th= is >>> should be a recommendation instead of a mandate. That way the >>> protocol remains inclusive, and also meets its objective. >>> >>> I think it is very important that existing implementations are no= t >>> excluded just because they dont seem to meet one specific need in= a >>> specific deployment scenario. >>> >>> Thanks, >>> Puneet >>> >>> On 4/15/06, *Saravanan Govindan* >> > wrote: >>> >>> Hi Puneet, >>> >>> My concern regarding the BSSID - WLAN mapping is based on the=20 >>> mandatory >>> Objective "Logical Groups" (Section 5.1.1 of CAPWAP Objectives). >>> >>> The Objective requires that WTP traffic be kept logically distinc= t >>> among >>> logical groups. This arises from the commercial need of service >>> providers >>> sharing WLAN infrastructure equipment. Service providers want the= ir >>> traffic >>> to be distinguished both over the wireless environment (e.g. BSSI= DS) >>> and >>> over the AC-WTP environment (e.g. WLANs). >>> >>> The BSSID-WLAN mapping issue is the technical requirement coming >>> from this >>> commercial need. It allows an AC - or WTP - to decide how logical >>> groups are >>> separated over the wireless and AC-WTP segments. So by making thi= s >>> mapping, >>> CAPWAP frames of different logical groups (WLANs) can be distinct= ly >>> exchanged. >>> >>> I agree with others that this mapping should not exclude any >>> implementation >>> - my concern is that the mapping be including in the first place. >>> >>> Cheers, >>> >>> Saravanan >>> >>> >>> >>> >>> > ------------------------------ >>> > *From:* Puneet [mailto:pb.ietf@gmail.com=20 >>> ] >>> > *Sent:* Friday, April 14, 2006 12:29 AM >>> > *To:* capwap@frascone.com >>> > *Subject:* [Capwap] BSSID-WLAN mappings >>> > >>> > the BSSID description in Section 11.9.1 'WTP Radio Configurati= on' >>> notes >>> > that a WTP that supports 16 WLANS MUST have 16 MAC addresses >>> reserved for >>> > it. Why? ie. what part of the protocol does not work if we hav= e >>> multiple >>> > SSIDs on a single BSSID? (whether thats good design or bad is = a >>> different >>> > matter). Since the WLAN ID could be used in all such places to= =20 >>> convey >>> WLAN >>> > information back to the AC, why do we need to mandate this 1:1 >>> BSSID-WLAN >>> > mapping? >>> > >>> > Thanks, >>> > Puneet >>> > >>> > ______________________________________________________________= ___ >>> > To unsubscribe or modify your subscription options, please vis= it: >>> > http://lists.frascone.com/mailman/listinfo/capwap >>> >>> > >>> > Archives: http://lists.frascone.com/pipermail/capwap >>> > >>> >>> _________________________________________________________________ >>> Get an advanced look at the new version of MSN Messenger. >>> http://messenger.msn.com.sg/Beta/Default.aspx >>> >>> >>> >>> >>> _________________________________________________________________ >>> 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 May 03 19:19:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbQdD-0004jL-IU for capwap-archive@lists.ietf.org; Wed, 03 May 2006 19:19:43 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbQdC-0008WV-PV for capwap-archive@lists.ietf.org; Wed, 03 May 2006 19:19:43 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 572BB4300D7 for ; Wed, 3 May 2006 16:19:42 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id BA0CB43004F for ; Wed, 3 May 2006 16:19:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A562543149B for ; Wed, 3 May 2006 16:19:06 -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 887ED43149A for ; Wed, 3 May 2006 16:19:04 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id h30so232046wxd for ; Wed, 03 May 2006 16:19:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=hqowZi2pu/Q1iDAykSU04RoGZZHq2sjDiTA1DLbibYtui7QqW7CojGhCbH6VUeNtFAhk7sw1/B6ZAHHNpstQ1jF5HHOiPsvrN1YOlGu6kslajZMTFZj28WRARzUhxNDxaK7bCGGkD512rjsWA3oqbOG/mEOcIwF1I7tipUpLtZI= Received: by 10.70.24.8 with SMTP id 8mr4394wxx; Wed, 03 May 2006 16:19:03 -0700 (PDT) Received: by 10.70.6.8 with HTTP; Wed, 3 May 2006 16:19:03 -0700 (PDT) Message-ID: <5bfe7a820605031619h4889f616wa3ed19737c2cf60f@mail.gmail.com> Date: Wed, 3 May 2006 16:19:03 -0700 From: "Dorothy Stanley" To: Puneet Subject: Re: [Capwap] Re: Issues 101: 11.8.1.1 Change to re-use 802.11 Information element definitions In-Reply-To: <1013407b0605031011j2fa1346aj61ea229b8f0cbcb0@mail.gmail.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A201CBA52B@xmb-sjc-235.amer.cisco.com> <1013407b0605031011j2fa1346aj61ea229b8f0cbcb0@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.1 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_20_30, HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP X-Spam-Level: * Cc: capwap@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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="===============1176936968==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.1 (+) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 --===============1176936968== Content-Type: multipart/alternative; boundary="----=_Part_33112_14208787.1146698343239" ------=_Part_33112_14208787.1146698343239 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Puneet, all, > 2. for the encryption policies we could use the format used in > the RSN IEs (OUI + encryption_type); that allows support for different > vendor specific encryption types in a clean manner (CKIP for example > would then use the Cisco OUI, instead of being clubbed together with the > other 'standard' encryption types; and it makes it easier for vendors to > not step on each others toes). Agree that this approach should be used to indicate ciphersto use. This IE is used to add a WLAN (BSS) on the WTP (also one for Update WLAN). Why is delivering the RSNIE/WPAIE not enough here - since the group key cipher is indicated in those IEs? Suggest deleting the encryption policy field in the IEEE 802.11 Add WLAN and Update WLAN message elements. Separately, the encryption policy in the IEEE Mobile Session Key message element should be updated to use the RSNIE format. Dorothy On 5/3/06, Puneet wrote: > > > 1. does the encryption policy refer to broadcast traffic or > > unicast too? If its also unicast, then there could be multiple > > encryption types enabled at the same type on the WLAN, in that case how > > is the encryption-policy field filled in? > > > > > > This is a good question as the text is obviously not clear enough. I am > > proposing the following text (as well as for the Update WLAN section): > > > > Encryption Policy: A 32-bit value specifying the encryption scheme > > to apply to traffic to and from the mobile station. > > this might also be a good place to note that the format of those 32 > bits is the same as what the IEEE 802.11i specification mentions. That > allows vendor specific encryption types, and can also be updated by > IEEE for new types without having to update the CAPWAP specification. > > > 2. for the encryption policies we could use the format used in > > the RSN IEs (OUI + encryption_type); that allows support for different > > vendor specific encryption types in a clean manner (CKIP for example > > would then use the Cisco OUI, instead of being clubbed together with th= e > > other 'standard' encryption types; and it makes it easier for vendors t= o > > not step on each others toes). > > > > > > Based on Dorothy's e-mail and recommendation, I would propose the > > following new section: > > > > 11.8.1.4. IEEE 802.11 Information Element > > > > The IEEE 802.11 Information Element is used to communicate any IE > > defined in the IEEE 802.11 protocol. The data field contains the ra= w > > IE as it would be included within an IEEE 802.11 MAC management > > message. > > > > I think my request was to change the encryption-type to use the IEEE > 802.11i format, but thats now what this element seems to do. Can we > replace those list of numbers 1,2,3,4,5 for encryption types since in > the current text they mix standard and vendor specific types, and if > IEEE updates something in 802.11i, we'll need to update the capwap > spec again. > > > 4. Does the 'Suppress SSID' field also disable the use of that > > SSID in broadcast probe responses? If so, why do we also need the 'IEEE > > 802.11 Broadcast Probe Mode' in section 11.9.12? Also, why is this IE > > global for the WTP? The AC might configure the WTP with 10 WLANs, but i= t > > may want probe responses generated for only four of those when a > > broadcast probe request comes in. > > > > Section 11.9.12 deals with the changing of the mode of operation > > after the WLAN is already operational. > > I still dont understand why this needs to be global. To quote the current > draft: > "Since broadcast NULL probes are not sent to a specific BSSID, the WTP > cannot know > which SSID the sending station is querying. Therefore, this behavior > must be global > to the WTP." > However when a broadcast probe request comes in, of all the WLANs > mapped to that WTP, the user should be able to configure which ones > are responded to. That text seems incorrect. > > Thanks, > Puneet > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_33112_14208787.1146698343239 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Puneet, all,


>         2. for the encryption po= licies we could use the format used in
> the RSN IEs (OUI + encryptio= n_type); that allows support for different
> vendor specific encrypti= on types in a clean manner (CKIP for example
> would then use the Cisco OUI, instead of being clubbed together wi= th the
> other 'standard' encryption types; and it makes it easier fo= r vendors to
> not step on each others toes).

Agree that this approach should be used to indicate ciphersto use. This IE = is used to
add a WLAN (BSS) on the WTP (also one for Update WLAN).
Why is delivering the RSNIE/WPAIE not enough here - since the
group key cipher is indicated in those IEs? Suggest deleting the encryption= policy
field in the IEEE 802.11 Add WLAN and Update WLAN message elements.

Separately, the encryption policy in the IEEE Mobile Session Key message el= ement
should be updated to use the RSNIE format.

Dorothy


On 5/3/06, Puneet <pb.ietf@gmail= .com> wrote:
>   1. does the encryption policy refer to broadcast traffic o= r
> unicast too? If its also unicast, then there could be multiple> encryption types enabled at the same type on the WLAN, in that case h= ow
> is the encryption-policy field filled in?
>
> <PRC><= br>> This is a good question as the text is obviously not clear enough. = I am
> proposing the following text (as well as for the Update WLAN s= ection):
>
>    Encryption Policy:  A 32-= bit value specifying the encryption scheme
>    &= nbsp;  to apply to traffic to and from the mobile station.

this= might also be a good place to note that the format of those 32
bits is the same as what the IEEE 802.11i specification mentions. That<= br>allows vendor specific encryption types, and can also be updated by
I= EEE for new types without having to update the CAPWAP specification.

>         2. for the encrypt= ion policies we could use the format used in
> the RSN IEs (OUI + enc= ryption_type); that allows support for different
> vendor specific en= cryption types in a clean manner (CKIP for example
> would then use the Cisco OUI, instead of being clubbed together wi= th the
> other 'standard' encryption types; and it makes it easier fo= r vendors to
> not step on each others toes).
>
> <PRC= >
> Based on Dorothy's e-mail and recommendation, I would propose the<= br>> following new section:
>
> = 11.8.1.4.  IEEE 802.11 Information Element
>
>&nb= sp;   The IEEE=20 802.11 Information Element is used to communicate any IE
>  = ;  defined in the IEEE 802.11 protocol.  The data field= contains the raw
>    IE as it would be included= within an IEEE 802.11 MAC management
>    messag= e.

<snip>

I think my request was to change the encryption= -type to use the IEEE
802.11i format, but thats now what this element se= ems to do. Can we
replace those list of numbers 1,2,3,4,5 for encryption= types since in
the current text they mix standard and vendor specific types, and ifIEEE updates something in 802.11i, we'll need to update the capwap
spec= again.

>         4. Does= the 'Suppress SSID' field also disable the use of that
> SSID in broadcast probe responses? If so, why do we also need the = 'IEEE
> 802.11 Broadcast Probe Mode' in section 11.9.12? Also, why is= this IE
> global for the WTP? The AC might configure the WTP with 10= WLANs, but it
> may want probe responses generated for only four of those when a> broadcast probe request comes in.
>
> <PRC> Sectio= n 11.9.12 deals with the changing of the mode of operation
> after th= e WLAN is already operational.</PRC>

I still dont understand why this needs to be global. To quote the c= urrent draft:
"Since broadcast NULL probes are not sent to a specif= ic BSSID, the WTP
cannot know
which SSID the sending station is query= ing.  Therefore, this behavior
must be global
to the WTP."
However when a broadcast probe r= equest comes in, of all the WLANs
mapped to that WTP, the user should be= able to configure which ones
are responded to. That text seems incorrec= t.

Thanks,
Puneet
______________________________________________= ___________________
To unsubscribe or modify your subscription options, = please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.co= m/pipermail/capwap

------=_Part_33112_14208787.1146698343239-- --===============1176936968== 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 --===============1176936968==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 03 20:18:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbRYB-0006ao-Iu for capwap-archive@lists.ietf.org; Wed, 03 May 2006 20:18:35 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbRY7-0003A8-VL for capwap-archive@lists.ietf.org; Wed, 03 May 2006 20:18:35 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5B7304300AB for ; Wed, 3 May 2006 17:18:29 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 0AD8B43004F for ; Wed, 3 May 2006 17:18:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E7495398023 for ; Wed, 3 May 2006 17:18:02 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.192.83]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5B6CC39800E for ; Wed, 3 May 2006 17:18:00 -0700 (PDT) Received: from [192.168.0.2] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (rwcrmhc13) with ESMTP id <20060504001759m13000l3rle>; Thu, 4 May 2006 00:17:59 +0000 Message-ID: <44594837.5090005@cs.umd.edu> Date: Wed, 03 May 2006 20:17:59 -0400 From: Charles Clancy User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Murphy Subject: Re: [Capwap] BSSID-WLAN mappings References: <17B8C6DE4E228348B4939BDA6B05A9DC0175B515@xmb-sjc-237.amer.cisco.com> <44565B8E.8010103@trapezenetworks.com> <44592DEC.4030204@trapezenetworks.com> In-Reply-To: <44592DEC.4030204@trapezenetworks.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Jim Murphy wrote: > > > T. Charles Clancy wrote: > >> Sort of... >> >> As I understand the conversation, in the M-SSID case, you could send >> an encrypted broadcast packet to other people on your WLAN. This >> packet would be encrypted with a key that other users on other WLANs >> could know. For example, someone on WLAN-B could see NETBIOS broadcast >> packets from devices associated to WLAN-A. They might even think they >> could communicate with said NETBIOS machines, but unicast packets >> addressed to them would fail (hopefully, assuming the WTP is properly >> implemented). >> >> Jim's scenario below is somewhat different, where you have someone on >> the wired side sending data that CAPWAP intentionally decides should >> be transmitted to multiple WLANs. The concern here is more along the >> lines of a chosen ciphertext attack that could leak information about >> keys by seeing packets encrypted multiple times with different keys. >> Provided people are using good crypto (i.e. not WEP), this shouldn't >> be a problem. > > It doesn't matter if the packet originated on the wired side or not > because all broadcast packets from stations must be retransmitted > by the AP. > > Yes, people should be using good crypto, but we should not limit the > legitimate flexibility of the protocol to enforce it. Your proposed security flaw has to do with CAPWAP data packets being marked for transmission on multiple WLANs, for each each may have a different crypto type. My point is that this could only ever happen on purpose, for example if someone configured some sort of multicast group. It could cause a theoretic crypto attack if someone is using WEP, but if they're using WEP they have bigger problems, like actual practical crypto attacks. Adding support fro M-SSID would cause all broadcast traffic on the same WTP to be visible to all devices, and this is both a security problem, and a protocol problem. It's a security problem because you have data being leaked between WLANs, and it's a problem for upper-layer protocols because they may discover each other via broadcasts, but then not be able to actually communicate via unicast. -- 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 May 03 23:20:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbUOe-0000qn-Vh for capwap-archive@lists.ietf.org; Wed, 03 May 2006 23:20:56 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbUOc-000239-Mb for capwap-archive@lists.ietf.org; Wed, 03 May 2006 23:20:56 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 22F704300C1 for ; Wed, 3 May 2006 20:20:54 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B7BE943004F for ; Wed, 3 May 2006 20:20:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 965831448041 for ; Wed, 3 May 2006 20:20: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 A22D11448042 for ; Wed, 3 May 2006 20:19:59 -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 k443JuKl004652; Thu, 4 May 2006 12:19:56 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k443Juk02736; Thu, 4 May 2006 12:19:56 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with SMTP id k443JxO15787; Thu, 4 May 2006 12:19:59 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Date: Thu, 4 May 2006 11:18:01 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDD52CC0@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Thread-Index: AcZu5AQlpREcyNxtQNSd1/efJT5EZwAP6MIg From: "Saravanan Govindan" To: "Dorothy Stanley" , "Pat Calhoun (pacalhou)" 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=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_40_50, HTML_MESSAGE, NORMAL_HTTP_TO_IP X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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="===============2074053360==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 40bdf3575eb53950a5a1f42012dfaab5 This is a multi-part message in MIME format. --===============2074053360== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66F29.59BD0BB4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66F29.59BD0BB4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dorothy, =20 I suggest that the Echo Request MAY only be send in the absence of specifically Statistics control packets as opposed to any control packets. The reason for this is that Statistics packets are the only regular exchanges, so the AC has just one type of packet to monitor for the timer.=20 =20 So I'd like to suggest the following text: =20 From: "If another Echo Request or other control message is not received by the AC when the timer expires, the AC SHOULD consider the WTP to be unreachable" =20 To: "If another Echo Request or Statistics message is not received by the AC when the timer expires, the AC SHOULD consider the WTP to be unreachable" =20 Cheers, Saravanan =20 =20 =20 =20 =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Thursday, May 04, 2006 3:03 AM To: Pat Calhoun (pacalhou) Cc: Scott G Kelly; Saravanan Govindan; capwap Subject: Re: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages =20 All, After the lengthy discussion on this topic, I believe that the conclusion is still to reject the comment, and as Pat summarized, the echo remains, does not include any statistics, and MAY only be sent in the absence of any control packets.=20 Changes to the text: Change text in 6.2" Echo Response" from: "If another Echo Request message is not received by the AC when the timer expires, the AC SHOULD consider the WTP to be unreachable" to=20 "If another Echo Request or other control message is not received by the AC when the timer expires, the AC SHOULD consider the WTP to be unreachable"=20 and from "If the NeighborDeadInterval timer expires prior to receiving an Echo Response message,=20 message, the WTP enters the Reset State." to "If the NeighborDeadInterval timer expires prior to receiving an Echo Response message, or other control message, the WTP enters the Reset State." Thanks, Dorothy Issue 45, Issue on Combining messages currently has the following discussion in the issues database:=20 Currently, the keepalive and statistics messages are separated. Separate messages for keepalive signaling and statistics can lead to high overhead.=20 Initial analysis have shown that these overhead can be reduced significantly=20 if the messages can be combined. Recommendation: To combine the keepalive and statistics message into one combined message,=20 thus reducing overhead significantly. Discussion: The CAPWAP protocol specification currently supports the Echo Request Message and Echo Response Messages, which are used for keep-alive purposes, and do not carry message elements. There is an IEEE 802.11 Statistics measurement element(11.7.2.1 ), and several CAPWAP statistics related measurement elements: decryption error report, WTP descriptor, WTP radio information, WTP reboot statistics. There is no statistics message.=20 There is no requirement on how often the statistics related measurement elements must be reported to the AC from the WTP, there is a Statistics timer, see 7.2.5, which is used by the AC to indicate the timer value to the WTP. (separate question - should the statistics timer be made general, and indicate the values for the other Section 12 CAPWAP timers too? Assume that the CAPWAP statistics timer used to determine how often to send the 802.11 specific statistics). It is not clear that there is a high overhead in keeping the echo/keep-alive mechanism from the statistics reporting. There is some benefit in keeping the echo messages simple, rather than complicating the processing of those messages. It is true that small messages (echo request, response) have high overhead. In this case, the design choice is to accept the overhead as the cost of simplicity in design and implementation.=20 Recommended resolution: reject the comment, with the explanation in the above paragraph On 4/28/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com > wrote: I will summarize my thoughts here and not try to inject in the various=20 threads, but I agree that the echo remains, does not include any statistics, and MAY only be sent in the absence of any control packets. I say MAY because an implementation could send them if it wishes, but the receiver must take into account control packets in addition to the=20 echo prior to declaring a link dead. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Scott G Kelly [mailto: scott@hyperthought.com ] > Sent: Friday, April 21, 2006 5:52 AM > To: Saravanan Govindan > Cc: capwap > Subject: Re: [Capwap] Proposed Resolution to Issue 45 > -Issueoncombiningmessages > > Hi Saravanan, > > Saravanan Govindan wrote: > > Hi Scott, > > > > I think David's note does address the issue on hand. > > > > To formalize; > >=20 > > The exchange of control messages between a WTP and AC implicitly > > indicates that the WTP is operational. For the purpose of protocol > > simplicity, I suggest that we focus on statistics messages=20 > alone for > > this purpose, reason being that statistics are periodically > exchanged. > > > > My concern is that by using "any" control message to indicate > > keepalive (Echo), the AC processing will be complicated. This is=20 > > because the AC will need to process each control message > for both its own value (e.g. > > Configure Request) and also keepalive value. > > Of course, complexity is a function of many factors, but=20 > there is a straightforward way to implement an echo trigger > with a flag and timer: > when you receive a control message, unconditionally raise the flag. > Periodically (according to your keepalive interval timer)=20 > check the flag; If it's up, put it down, else send a > keepalive. There are more complicated ways to implement, but > this works just fine. > > On the AC this can easily be implemented by having the=20 > fastpath raise the flag, and having the cp lower it and/or do > whatever it is your AC does if a WTP doesn't report in a > given echo interval (which may be nothing). Pretty basic stuff. > > On the WTP, implementation is similar, except that if the=20 > flag is down, you send the keepalive. Again, very simple and basic. > > > So I suggest keeping it simple - arrival of statistics message from > > WTP means WTP is alive. > > Certainly, a statistics message qualifies as a control=20 > message, so I have no issues with this statement when taken > alone. I'm concerned with the earlier suggestion that the > echo req/reply message be discarded and replaced by the > statistics message.=20 > > In some cases, the keepalive interval must be *very* brief in > order to facilitate rapid link loss detection and recovery. I > know of one vendor who routinely uses a one second interval, > and it's conceivable that in some scenarios one might choose > to use even less. > > And keep in mind that WTP and AC requirements are typically > asymmetric in this regard: the WTP needs to react quickly=20 > (maybe try to find another AC), whereas the AC simply needs > to somehow report the event. > While in some cases reporting might be considered urgent, > this is not the typical (or average) case.=20 > > The granularity requirements for reporting are typically much > coarser than those of recovery. That is, the AC may, at it's > option, only check every 10,20,30,... seconds for WTP > liveness, and it may very well do that via the stats message,=20 > rather than the echo, since this allows echo processing to > remain wholly in the AC fastpath. > > But say we eliminate the echo: what happens when, say, 500 > WTPs send stats potentially every second or less?=20 > > I think we still need the echo req/rsp. > > Scott > > > > > Saravanan > > > > > > > > > > > > -----Original Message-----=20 > > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > > Sent: Wednesday, April 19, 2006 1:51 AM > > To: capwap > > Subject: RE: [Capwap] Proposed Resolution to Issue 45=20 > > -Issueoncombiningmessages > > > > Just trying to close the loop: I think David's point (i.e. > that echoes > > should only be sent in the absence of other control > traffic) is dead=20 > > on, and that this effectively closes the question as to > whether echoes > > and stats should be combined in the same messages. > > > > Does anyone disagree? > > > > Scott > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > _________________________________________________________________=20 > 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:=20 http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap=20 =20 ------_=_NextPart_001_01C66F29.59BD0BB4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dorothy,

 

I suggest that the Echo Request MAY only be send in = the absence of specifically Statistics control packets as opposed to any = control packets. The reason for this is that Statistics packets are the only = regular exchanges, so the AC has just one type of packet to monitor for the = timer.

 

So I’d like to suggest the following = text:

 

From:

“If another Echo Request or other control = message is not received by the AC when the timer expires, the AC
SHOULD consider the WTP to be = unreachable"

 

To:

“If another Echo Request or Statistics message = is not received by the AC when the timer expires, the AC
SHOULD consider the WTP to be = unreachable"

 

Cheers,


Saravanan

 

 

 

 

 

From: = Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Thursday, May 04, = 2006 3:03 AM
To: Pat Calhoun = (pacalhou)
Cc: Scott G Kelly; = Saravanan Govindan; capwap
Subject: Re: [Capwap] = Proposed Resolution to Issue 45 = -Issueoncombiningmessages

 

All,

After the lengthy discussion on this topic, I believe that the = conclusion is
still to reject the comment, and as Pat summarized, the echo remains, = does not include any
statistics, and MAY only be sent in the absence of any control packets. =

Changes to the text:

Change text in 6.2" Echo Response" from:
"If another Echo Request message is not received by the AC when the = timer expires, the AC
SHOULD consider the WTP to be unreachable" to

"If another Echo Request or other control message is not received = by the AC when the timer expires, the AC
SHOULD consider the WTP to be unreachable"

and from

"If the NeighborDeadInterval timer expires prior to receiving an = Echo Response message,
message, the WTP enters the Reset State."
to
"If the NeighborDeadInterval timer expires prior to receiving an = Echo Response message, or other control
message, the WTP enters the Reset State."


Thanks,

Dorothy

Issue 45, Issue on Combining messages currently has the following discussion in the = issues database: 

Currently, the keepalive and statistics =
messages are separated. Separate 

messages for keepalive signaling and statistics can lead to high =
overhead. 

Initial analysis have shown that these overhead can be reduced =
significantly 




if the messages can be combined.



Recommendation:



To combine the keepalive and statistics message into one combined =
message, 

thus reducing overhead significantly.


Discussion:

The CAPWAP protocol specification currently supports the
Echo Request Message and Echo Response Messages, which are used for = keep-alive
purposes, and do not carry message elements.

There is an IEEE 802.11 Statistics measurement element(11.7.2.1), and several = CAPWAP statistics related
measurement elements: decryption error report, WTP descriptor, WTP radio information, WTP reboot statistics.
There is no statistics message.

There is no requirement on how often the statistics related measurement elements must be reported
to the AC from the WTP, there is a Statistics timer, see 7.2.5, which is = used by the AC to indicate the
timer value to the WTP. (separate question - should the statistics timer = be made general, and indicate the
values for the other Section 12 CAPWAP timers too?  Assume that the = CAPWAP statistics timer used
to determine how often to send the 802.11 specific statistics).

It is not clear that there is a high overhead in keeping the = echo/keep-alive mechanism from
the statistics reporting. There is some benefit in keeping the echo = messages simple,
rather than complicating the processing of those messages.  It is = true that small messages (echo request, response) have high overhead.
In this case, the design choice is to accept the overhead as the cost of simplicity in design and implementation.

Recommended resolution: reject the comment, with the explanation in the = above paragraph

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

I will summarize my thoughts here and not try to inject in the = various
threads, but I agree that the echo remains, does not include any
statistics, and MAY only be sent in the absence of any control = packets.
I say MAY because an implementation could send them if it wishes, = but
the receiver must take into account control packets in addition to the =
echo prior to declaring a link dead.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems



> -----Original Message-----
> From: Scott G Kelly [mailto: scott@hyperthought.com]
> Sent: Friday, April 21, 2006 5:52 AM
> To: Saravanan Govindan
> Cc: capwap
> Subject: Re: [Capwap] Proposed Resolution to Issue 45
> -Issueoncombiningmessages
>
> Hi Saravanan,
>
> Saravanan Govindan wrote:
> > Hi Scott,
> >
> > I think David's note does address the issue on hand.
> >
> > To formalize;
> >
> > The exchange of control messages between a WTP and AC = implicitly
> > indicates that the WTP is operational. For the purpose of = protocol
> > simplicity, I suggest that we focus on statistics messages =
> alone for
> > this purpose, reason being that statistics are = periodically
> exchanged.
> >
> > My concern is that by using "any" control message to indicate
> > keepalive (Echo), the AC processing will be complicated. This = is
> > because the AC will need to process each control message
> for both its own value (e.g.
> > Configure Request) and also keepalive value.
>
> Of course, complexity is a function of many factors, but
> there is a straightforward way to implement an echo trigger
> with a flag and timer:
> when you receive a control message, unconditionally raise the = flag.
> Periodically (according to your keepalive interval timer)
> check the flag; If it's up, put it down, else send a
> keepalive. There are more complicated ways to implement, but
> this works just fine.
>
> On the AC this can easily be implemented by having the
> fastpath raise the flag, and having the cp lower it and/or do
> whatever it is your AC does if a WTP doesn't report in a
> given echo interval (which may be nothing). Pretty basic stuff.
>
> On the WTP, implementation is similar, except that if the
> flag is down, you send the keepalive. Again, very simple and = basic.
>
> > So I suggest keeping it simple - arrival of statistics message = from
> > WTP means WTP is alive.
>
> Certainly, a statistics message qualifies as a control
> message, so I have no issues with this statement when taken
> alone. I'm concerned with the earlier suggestion that the
> echo req/reply message be discarded and replaced by the
> statistics message.
>
> In some cases, the keepalive interval must be *very* brief in
> order to facilitate rapid link loss detection and recovery. I
> know of one vendor who routinely uses a one second interval,
> and it's conceivable that in some scenarios one might choose
> to use even less.
>
> And keep in mind that WTP and AC requirements are typically
> asymmetric in this regard: the WTP needs to react quickly
> (maybe try to find another AC), whereas the AC simply needs
> to somehow report the event.
> While in some cases reporting might be considered urgent,
> this is not the typical (or average) case.
>
> The granularity requirements for reporting are typically much
> coarser than those of recovery. That is, the AC may, at it's
> option, only check every 10,20,30,... seconds for WTP
> liveness, and it may very well do that via the stats message,
> rather than the echo, since this allows echo processing to
> remain wholly in the AC fastpath.
>
> But say we eliminate the echo: what happens when, say, 500
> WTPs send stats potentially every second or less?
>
> I think we still need the echo req/rsp.
>
> Scott
>
> >
> > Saravanan
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com]
> > Sent: Wednesday, April 19, 2006 1:51 AM
> > To: capwap
> > Subject: RE: [Capwap] Proposed Resolution to Issue 45
> > -Issueoncombiningmessages
> >
> > Just trying to close the loop: I think David's point (i.e.
> that echoes
> > should only be sent in the absence of other control
> traffic) is dead
> > on, and that this effectively closes the question as to
> whether echoes
> > and stats should be combined in the same messages.
> >
> > Does anyone disagree?
> >
> > Scott
> >
> >
> > = _________________________________________________________________
> > To unsubscribe or modify your subscription options, please = visit:
> > http://lists.f= rascone.com/mailman/listinfo/capwap
> >
> > Archives: http://lists.frascone= .com/pipermail/capwap
> >
> >
> _________________________________________________________________ =
> To unsubscribe or modify your subscription options, please = visit:
> http://lists.f= rascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone= .com/pipermail/capwap
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.f= rascone.com/mailman/listinfo/capwap

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

 

------_=_NextPart_001_01C66F29.59BD0BB4-- --===============2074053360== 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 --===============2074053360==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu May 04 00:50:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbVnT-0005fj-RK for capwap-archive@lists.ietf.org; Thu, 04 May 2006 00:50:39 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbVnR-0006L0-G5 for capwap-archive@lists.ietf.org; Thu, 04 May 2006 00:50:39 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4FCDC4300E0 for ; Wed, 3 May 2006 21:50:36 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D1EC443004F for ; Wed, 3 May 2006 21:49:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id AF63A398017 for ; Wed, 3 May 2006 21:49:37 -0700 (PDT) Received: from test-iport-2.cisco.com (test-iport-2.cisco.com [171.71.176.105]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9B0F3398015 for ; Wed, 3 May 2006 21:49:33 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-2.cisco.com with ESMTP; 03 May 2006 21:49:33 -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 k444nWRT023729; Wed, 3 May 2006 21:49:32 -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, 3 May 2006 21:49:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Date: Wed, 3 May 2006 21:49:31 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D25352@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Thread-Index: AcZu5AQlpREcyNxtQNSd1/efJT5EZwAP6MIgAASTNTA= From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , "Dorothy Stanley" X-OriginalArrivalTime: 04 May 2006 04:49:32.0768 (UTC) FILETIME=[22B28600:01C66F36] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.541 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_40_50, HTML_MESSAGE, NORMAL_HTTP_TO_IP X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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="===============1073396576==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a9d8f61f7718176ef97b85bbcc64331 This is a multi-part message in MIME format. --===============1073396576== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66F36.228D0B4E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66F36.228D0B4E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The text you are proposing doesn't change the behavior of the protocol. I'm not sure that it really adds anything since we are stating that an echo is sent if no control packets are sent. You are free to send periodic Statistics messages, which with the new language would not require any Echos to be sent. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, May 03, 2006 8:18 PM To: Dorothy Stanley; Pat Calhoun (pacalhou) Cc: Scott G Kelly; capwap Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages =09 =09 Hi Dorothy, =20 I suggest that the Echo Request MAY only be send in the absence of specifically Statistics control packets as opposed to any control packets. The reason for this is that Statistics packets are the only regular exchanges, so the AC has just one type of packet to monitor for the timer.=20 =20 So I'd like to suggest the following text: =20 From: "If another Echo Request or other control message is not received by the AC when the timer expires, the AC SHOULD consider the WTP to be unreachable" =20 To: "If another Echo Request or Statistics message is not received by the AC when the timer expires, the AC SHOULD consider the WTP to be unreachable" =20 Cheers, =09 Saravanan =20 =20 =20 =20 =20 =09 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Thursday, May 04, 2006 3:03 AM To: Pat Calhoun (pacalhou) Cc: Scott G Kelly; Saravanan Govindan; capwap Subject: Re: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages =20 All, =09 After the lengthy discussion on this topic, I believe that the conclusion is still to reject the comment, and as Pat summarized, the echo remains, does not include any statistics, and MAY only be sent in the absence of any control packets.=20 =09 Changes to the text: =09 Change text in 6.2" Echo Response" from: "If another Echo Request message is not received by the AC when the timer expires, the AC SHOULD consider the WTP to be unreachable" to=20 =09 "If another Echo Request or other control message is not received by the AC when the timer expires, the AC SHOULD consider the WTP to be unreachable"=20 =09 and from =09 "If the NeighborDeadInterval timer expires prior to receiving an Echo Response message,=20 message, the WTP enters the Reset State." to "If the NeighborDeadInterval timer expires prior to receiving an Echo Response message, or other control message, the WTP enters the Reset State." =09 =09 Thanks, =09 Dorothy =09 Issue 45, Issue on Combining messages currently has the following discussion in the issues database:=20 Currently, the keepalive and statistics messages are separated. Separate=20 =09 messages for keepalive signaling and statistics can lead to high overhead.=20 =09 Initial analysis have shown that these overhead can be reduced significantly=20 =09 =09 =09 =09 if the messages can be combined. =09 =09 =09 Recommendation: =09 =09 =09 To combine the keepalive and statistics message into one combined message,=20 =09 thus reducing overhead significantly. =09 Discussion: =09 The CAPWAP protocol specification currently supports the Echo Request Message and Echo Response Messages, which are used for keep-alive purposes, and do not carry message elements. =09 There is an IEEE 802.11 Statistics measurement element(11.7.2.1 ), and several CAPWAP statistics related measurement elements: decryption error report, WTP descriptor, WTP radio information, WTP reboot statistics. There is no statistics message.=20 =09 There is no requirement on how often the statistics related measurement elements must be reported to the AC from the WTP, there is a Statistics timer, see 7.2.5, which is used by the AC to indicate the timer value to the WTP. (separate question - should the statistics timer be made general, and indicate the values for the other Section 12 CAPWAP timers too? Assume that the CAPWAP statistics timer used to determine how often to send the 802.11 specific statistics). =09 It is not clear that there is a high overhead in keeping the echo/keep-alive mechanism from the statistics reporting. There is some benefit in keeping the echo messages simple, rather than complicating the processing of those messages. It is true that small messages (echo request, response) have high overhead. In this case, the design choice is to accept the overhead as the cost of simplicity in design and implementation.=20 =09 Recommended resolution: reject the comment, with the explanation in the above paragraph On 4/28/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com > wrote: I will summarize my thoughts here and not try to inject in the various=20 threads, but I agree that the echo remains, does not include any statistics, and MAY only be sent in the absence of any control packets. I say MAY because an implementation could send them if it wishes, but the receiver must take into account control packets in addition to the=20 echo prior to declaring a link dead. =09 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =09 =09 =09 > -----Original Message----- > From: Scott G Kelly [mailto: scott@hyperthought.com ] > Sent: Friday, April 21, 2006 5:52 AM > To: Saravanan Govindan > Cc: capwap > Subject: Re: [Capwap] Proposed Resolution to Issue 45 > -Issueoncombiningmessages > > Hi Saravanan, > > Saravanan Govindan wrote: > > Hi Scott, > > > > I think David's note does address the issue on hand. > > > > To formalize; > >=20 > > The exchange of control messages between a WTP and AC implicitly > > indicates that the WTP is operational. For the purpose of protocol > > simplicity, I suggest that we focus on statistics messages=20 > alone for > > this purpose, reason being that statistics are periodically > exchanged. > > > > My concern is that by using "any" control message to indicate > > keepalive (Echo), the AC processing will be complicated. This is=20 > > because the AC will need to process each control message > for both its own value (e.g. > > Configure Request) and also keepalive value. > > Of course, complexity is a function of many factors, but=20 > there is a straightforward way to implement an echo trigger > with a flag and timer: > when you receive a control message, unconditionally raise the flag. > Periodically (according to your keepalive interval timer)=20 > check the flag; If it's up, put it down, else send a > keepalive. There are more complicated ways to implement, but > this works just fine. > > On the AC this can easily be implemented by having the=20 > fastpath raise the flag, and having the cp lower it and/or do > whatever it is your AC does if a WTP doesn't report in a > given echo interval (which may be nothing). Pretty basic stuff. > > On the WTP, implementation is similar, except that if the=20 > flag is down, you send the keepalive. Again, very simple and basic. > > > So I suggest keeping it simple - arrival of statistics message from > > WTP means WTP is alive. > > Certainly, a statistics message qualifies as a control=20 > message, so I have no issues with this statement when taken > alone. I'm concerned with the earlier suggestion that the > echo req/reply message be discarded and replaced by the > statistics message.=20 > > In some cases, the keepalive interval must be *very* brief in > order to facilitate rapid link loss detection and recovery. I > know of one vendor who routinely uses a one second interval, > and it's conceivable that in some scenarios one might choose > to use even less. > > And keep in mind that WTP and AC requirements are typically > asymmetric in this regard: the WTP needs to react quickly=20 > (maybe try to find another AC), whereas the AC simply needs > to somehow report the event. > While in some cases reporting might be considered urgent, > this is not the typical (or average) case.=20 > > The granularity requirements for reporting are typically much > coarser than those of recovery. That is, the AC may, at it's > option, only check every 10,20,30,... seconds for WTP > liveness, and it may very well do that via the stats message,=20 > rather than the echo, since this allows echo processing to > remain wholly in the AC fastpath. > > But say we eliminate the echo: what happens when, say, 500 > WTPs send stats potentially every second or less?=20 > > I think we still need the echo req/rsp. > > Scott > > > > > Saravanan > > > > > > > > > > > > -----Original Message-----=20 > > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > > Sent: Wednesday, April 19, 2006 1:51 AM > > To: capwap > > Subject: RE: [Capwap] Proposed Resolution to Issue 45=20 > > -Issueoncombiningmessages > > > > Just trying to close the loop: I think David's point (i.e. > that echoes > > should only be sent in the absence of other control > traffic) is dead=20 > > on, and that this effectively closes the question as to > whether echoes > > and stats should be combined in the same messages. > > > > Does anyone disagree? > > > > Scott > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > _________________________________________________________________=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 _________________________________________________________________ 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_01C66F36.228D0B4E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The=20 text you are proposing doesn't change the behavior of the protocol. I'm = not sure=20 that it really adds anything since we are stating that an echo is sent = if no=20 control packets are sent. You are free to send periodic Statistics = messages,=20 which with the new language would not require any Echos to be=20 sent.
 

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

 

From: Saravanan Govindan=20 [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: = Wednesday, May=20 03, 2006 8:18 PM
To: Dorothy Stanley; Pat Calhoun=20 (pacalhou)
Cc: Scott G Kelly; capwap
Subject: RE: = [Capwap]=20 Proposed Resolution to Issue 45 = -Issueoncombiningmessages

Hi=20 Dorothy,

 

I suggest that the Echo = Request=20 MAY only be send in the absence of specifically Statistics control = packets as=20 opposed to any control packets. The reason for this is that Statistics = packets=20 are the only regular exchanges, so the AC has just one type of packet = to=20 monitor for the timer.

 

So I’d like to = suggest the=20 following text:

 

From:

“If another Echo = Request or other=20 control message is not received by the AC when the timer expires, the=20 AC
SHOULD consider the WTP to be = unreachable"

 

To:

“If another Echo = Request or=20 Statistics message is not received by the AC when the timer expires, = the=20 AC
SHOULD consider the WTP to be = unreachable"

 

Cheers,


Saravanan

 

 

 

 

 

From: Dorothy=20 Stanley [mailto:dstanley1389@gmail.com]
Sent: Thursday, May 04, 2006 = 3:03=20 AM
To: Pat Calhoun=20 (pacalhou)
Cc: = Scott G Kelly;=20 Saravanan Govindan; capwap
Subject: Re: [Capwap] Proposed = Resolution=20 to Issue 45 = -Issueoncombiningmessages

 

All,

After the lengthy = discussion=20 on this topic, I believe that the conclusion is
still to reject the = comment, and as Pat summarized, the echo remains, does not include=20 any
statistics, and MAY only be sent in the absence of any control = packets.=20

Changes to the text:

Change text in 6.2" Echo Response" = from:
"If another Echo Request message is not received by the AC = when the=20 timer expires, the AC
SHOULD consider the WTP to be unreachable" to =

"If another Echo Request or other control message is not = received by=20 the AC when the timer expires, the AC
SHOULD consider the WTP to be = unreachable"

and from

"If the NeighborDeadInterval = timer=20 expires prior to receiving an Echo Response message,
message, the = WTP=20 enters the Reset=20 State."
to
"If the=20 NeighborDeadInterval timer expires prior to receiving an Echo Response = message, or other control
message, the WTP enters the Reset = State."


Thanks,
Dorothy

Issue 45, Issue on Combining messages currently has = the=20 following discussion in the issues database: = 

Currently, the keepalive and =
statistics messages are separated. Separate 

messages for keepalive signaling and statistics can lead to high =
overhead. 

Initial analysis have shown that these overhead can be reduced =
significantly 




if the messages can be combined.



Recommendation:



To combine the keepalive and statistics message into one combined =
message, 

thus reducing overhead significantly.


Discussion:

The = CAPWAP=20 protocol specification currently supports the
Echo Request Message = and Echo=20 Response Messages, which are used for keep-alive
purposes, and do = not carry=20 message elements.

There is an IEEE 802.11 Statistics = measurement=20 element(11.7.2.1), = and several=20 CAPWAP statistics related
measurement elements: decryption error = report,=20 WTP descriptor, WTP radio information, WTP reboot statistics.
There = is no=20 statistics message.

There is no requirement on how often the=20 statistics related measurement elements must be reported
to the AC = from the=20 WTP, there is a Statistics timer, see 7.2.5, which is used by the AC = to=20 indicate the
timer value to the WTP. (separate question - should = the=20 statistics timer be made general, and indicate the
values for the = other=20 Section 12 CAPWAP timers too?  Assume that the CAPWAP statistics = timer=20 used
to determine how often to send the 802.11 specific=20 statistics).

It is not clear that there is a high overhead in = keeping=20 the echo/keep-alive mechanism from
the statistics reporting. There = is some=20 benefit in keeping the echo messages simple,
rather than = complicating the=20 processing of those messages.  It is true that small messages = (echo=20 request, response) have high overhead.
In this case, the design = choice is=20 to accept the overhead as the cost of simplicity in design and = implementation.=20

Recommended resolution: reject the comment, with the = explanation in=20 the above paragraph

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

I will summarize my thoughts here and not = try to=20 inject in the various
threads, but I agree that the echo remains, = does not=20 include any
statistics, and MAY only be sent in the absence of any = control=20 packets.
I say MAY because an implementation could send them if it = wishes,=20 but
the receiver must take into account control packets in addition = to the=20
echo prior to declaring a link dead.

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



> = -----Original=20 Message-----
> From: Scott G Kelly [mailto: = scott@hyperthought.com]
>=20 Sent: Friday, April 21, 2006 5:52 AM
> To: Saravanan = Govindan
>=20 Cc: capwap
> Subject: Re: [Capwap] Proposed Resolution to Issue=20 45
> -Issueoncombiningmessages
>
> Hi=20 Saravanan,
>
> Saravanan Govindan wrote:
> > Hi=20 Scott,
> >
> > I think David's note does address the = issue=20 on hand.
> >
> > To formalize;
> >
> = >=20 The exchange of control messages between a WTP and AC = implicitly
> >=20 indicates that the WTP is operational. For the purpose of = protocol
>=20 > simplicity, I suggest that we focus on statistics messages =
> alone=20 for
> > this purpose, reason being that statistics are=20 periodically
> exchanged.
> >
> > My concern = is that=20 by using "any" control message to indicate
> > keepalive = (Echo), the=20 AC processing will be complicated. This is
> > because the = AC will=20 need to process each control message
> for both its own value=20 (e.g.
> > Configure Request) and also keepalive=20 value.
>
> Of course, complexity is a function of many = factors,=20 but
> there is a straightforward way to implement an echo=20 trigger
> with a flag and timer:
> when you receive a = control=20 message, unconditionally raise the flag.
> Periodically = (according to=20 your keepalive interval timer)
> check the flag; If it's up, = put it=20 down, else send a
> keepalive. There are more complicated ways = to=20 implement, but
> this works just fine.
>
> On the AC = this=20 can easily be implemented by having the
> fastpath raise the = flag, and=20 having the cp lower it and/or do
> whatever it is your AC does = if a WTP=20 doesn't report in a
> given echo interval (which may be = nothing). Pretty=20 basic stuff.
>
> On the WTP, implementation is similar, = except=20 that if the
> flag is down, you send the keepalive. Again, very = simple=20 and basic.
>
> > So I suggest keeping it simple - = arrival of=20 statistics message from
> > WTP means WTP is = alive.
>
>=20 Certainly, a statistics message qualifies as a control
> = message, so I=20 have no issues with this statement when taken
> alone. I'm = concerned=20 with the earlier suggestion that the
> echo req/reply message be = discarded and replaced by the
> statistics message. =
>
> In=20 some cases, the keepalive interval must be *very* brief in
> = order to=20 facilitate rapid link loss detection and recovery. I
> know of = one=20 vendor who routinely uses a one second interval,
> and it's = conceivable=20 that in some scenarios one might choose
> to use even=20 less.
>
> And keep in mind that WTP and AC requirements = are=20 typically
> asymmetric in this regard: the WTP needs to react = quickly=20
> (maybe try to find another AC), whereas the AC simply = needs
>=20 to somehow report the event.
> While in some cases reporting = might be=20 considered urgent,
> this is not the typical (or average) case.=20
>
> The granularity requirements for reporting are = typically=20 much
> coarser than those of recovery. That is, the AC may, at=20 it's
> option, only check every 10,20,30,... seconds for = WTP
>=20 liveness, and it may very well do that via the stats message,
> = rather=20 than the echo, since this allows echo processing to
> remain = wholly in=20 the AC fastpath.
>
> But say we eliminate the echo: what = happens=20 when, say, 500
> WTPs send stats potentially every second or = less?=20
>
> I think we still need the echo = req/rsp.
>
>=20 Scott
>
> >
> > Saravanan
> >
> = >
> >
> >
> >
> > -----Original = Message-----
> > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com]
> = >=20 Sent: Wednesday, April 19, 2006 1:51 AM
> > To: = capwap
> >=20 Subject: RE: [Capwap] Proposed Resolution to Issue 45
> >=20 -Issueoncombiningmessages
> >
> > Just trying to = close the=20 loop: I think David's point (i.e.
> that echoes
> > = should only=20 be sent in the absence of other control
> traffic) is dead =
> >=20 on, and that this effectively closes the question as to
> = whether=20 echoes
> > and stats should be combined in the same = messages.
>=20 >
> > Does anyone disagree?
> >
> >=20 Scott
> >
> >
> >=20 = _________________________________________________________________
>= >=20 To unsubscribe or modify your subscription options, please = visit:
> >=20 http://lists.f= rascone.com/mailman/listinfo/capwap
>=20 >
> > Archives: http://lists.frascone= .com/pipermail/capwap
>=20 >
> >
>=20 _________________________________________________________________ =
> To=20 unsubscribe or modify your subscription options, please visit:
> = http://lists.f= rascone.com/mailman/listinfo/capwap
>
>=20 Archives: http://lists.frascone= .com/pipermail/capwap
>
____________________________________= _____________________________
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_01C66F36.228D0B4E-- --===============1073396576== 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 --===============1073396576==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu May 04 05:02:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbZjO-0007yU-78 for capwap-archive@lists.ietf.org; Thu, 04 May 2006 05:02:42 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbZjL-0007Kc-Nl for capwap-archive@lists.ietf.org; Thu, 04 May 2006 05:02:42 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8ED214300B3 for ; Thu, 4 May 2006 02:02:38 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 232BF43005F for ; Thu, 4 May 2006 02:01:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0D6774308B6 for ; Thu, 4 May 2006 02:01:35 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 38FCC430674 for ; Thu, 4 May 2006 02:01:31 -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 k4490TGH003165; Thu, 4 May 2006 18:00:29 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k4490UH03446; Thu, 4 May 2006 18:00:30 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with SMTP id k4490UY09254; Thu, 4 May 2006 18:00:30 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Date: Thu, 4 May 2006 16:58:34 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDD52D77@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Thread-Index: AcZu5AQlpREcyNxtQNSd1/efJT5EZwAP6MIgAASTNTAAAUECcA== From: "Saravanan Govindan" To: "Pat Calhoun (pacalhou)" , "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.6 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_50_60, HTML_MESSAGE, NORMAL_HTTP_TO_IP X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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="===============1896861090==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: bf191ee9b6898766f466f28e49a0b8f4 This is a multi-part message in MIME format. --===============1896861090== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66F58.EC8B756F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66F58.EC8B756F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Without the text below, the specifications will require an AC to monitor the arrival of "all" control packet with respect to the EchoInterval and NeighbourDeadInterval timers. There were concerns earlier on this thread that this is not ideal.=20 =20 Furthermore, not all control packets indicate that a WTP is alive and doing well. A WTP could fail, re-start and then send Discovery Requests to an AC. This should not be construed as an indication that the WTP is well. On the other hand, by focusing only on Statistics (WTP Event Request) control messages, it is unambiguous that a WTP is operational.=20 =20 So the text in the specifications should reflect this by having Echo Requests sent in the absence of Statistics (WTP Event Request) messages. =20 Saravanan=20 =20 =20 =20 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, May 04, 2006 12:50 PM To: Saravanan Govindan; Dorothy Stanley Cc: Scott G Kelly; capwap Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages =20 The text you are proposing doesn't change the behavior of the protocol. I'm not sure that it really adds anything since we are stating that an echo is sent if no control packets are sent. You are free to send periodic Statistics messages, which with the new language would not require any Echos to be sent. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, May 03, 2006 8:18 PM To: Dorothy Stanley; Pat Calhoun (pacalhou) Cc: Scott G Kelly; capwap Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Hi Dorothy, =20 I suggest that the Echo Request MAY only be send in the absence of specifically Statistics control packets as opposed to any control packets. The reason for this is that Statistics packets are the only regular exchanges, so the AC has just one type of packet to monitor for the timer.=20 =20 So I'd like to suggest the following text: =20 From: "If another Echo Request or other control message is not received by the AC when the timer expires, the AC SHOULD consider the WTP to be unreachable" =20 To: "If another Echo Request or Statistics message is not received by the AC when the timer expires, the AC SHOULD consider the WTP to be unreachable" =20 Cheers, =09 Saravanan =20 =20 =20 =20 =20 =09 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Thursday, May 04, 2006 3:03 AM To: Pat Calhoun (pacalhou) Cc: Scott G Kelly; Saravanan Govindan; capwap Subject: Re: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages =20 All, =09 After the lengthy discussion on this topic, I believe that the conclusion is still to reject the comment, and as Pat summarized, the echo remains, does not include any statistics, and MAY only be sent in the absence of any control packets.=20 =09 Changes to the text: =09 Change text in 6.2" Echo Response" from: "If another Echo Request message is not received by the AC when the timer expires, the AC SHOULD consider the WTP to be unreachable" to=20 =09 "If another Echo Request or other control message is not received by the AC when the timer expires, the AC SHOULD consider the WTP to be unreachable"=20 =09 and from =09 "If the NeighborDeadInterval timer expires prior to receiving an Echo Response message,=20 message, the WTP enters the Reset State." to "If the NeighborDeadInterval timer expires prior to receiving an Echo Response message, or other control message, the WTP enters the Reset State." =09 =09 Thanks, =09 Dorothy =09 Issue 45, Issue on Combining messages currently has the following discussion in the issues database:=20 Currently, the keepalive and statistics messages are separated. Separate=20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =20 =20 messages for keepalive signaling and statistics can lead to high overhead.=20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =20 =20 Initial analysis have shown that these overhead can be reduced significantly=20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =20 =20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =20 =20 if the messages can be combined. =09 =09 =09 =09 =09 =09 =09 =09 =09 =20 =20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =20 =20 Recommendation: =09 =09 =09 =09 =09 =09 =09 =09 =09 =20 =20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =20 =20 To combine the keepalive and statistics message into one combined message,=20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =20 =20 thus reducing overhead significantly. =09 Discussion: =09 The CAPWAP protocol specification currently supports the Echo Request Message and Echo Response Messages, which are used for keep-alive purposes, and do not carry message elements. =09 There is an IEEE 802.11 Statistics measurement element(11.7.2.1 ), and several CAPWAP statistics related measurement elements: decryption error report, WTP descriptor, WTP radio information, WTP reboot statistics. There is no statistics message.=20 =09 There is no requirement on how often the statistics related measurement elements must be reported to the AC from the WTP, there is a Statistics timer, see 7.2.5, which is used by the AC to indicate the timer value to the WTP. (separate question - should the statistics timer be made general, and indicate the values for the other Section 12 CAPWAP timers too? Assume that the CAPWAP statistics timer used to determine how often to send the 802.11 specific statistics). =09 It is not clear that there is a high overhead in keeping the echo/keep-alive mechanism from the statistics reporting. There is some benefit in keeping the echo messages simple, rather than complicating the processing of those messages. It is true that small messages (echo request, response) have high overhead. In this case, the design choice is to accept the overhead as the cost of simplicity in design and implementation.=20 =09 Recommended resolution: reject the comment, with the explanation in the above paragraph On 4/28/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com > wrote: I will summarize my thoughts here and not try to inject in the various=20 threads, but I agree that the echo remains, does not include any statistics, and MAY only be sent in the absence of any control packets. I say MAY because an implementation could send them if it wishes, but the receiver must take into account control packets in addition to the=20 echo prior to declaring a link dead. =09 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =09 =09 =09 > -----Original Message----- > From: Scott G Kelly [mailto: scott@hyperthought.com ] > Sent: Friday, April 21, 2006 5:52 AM > To: Saravanan Govindan > Cc: capwap > Subject: Re: [Capwap] Proposed Resolution to Issue 45 > -Issueoncombiningmessages > > Hi Saravanan, > > Saravanan Govindan wrote: > > Hi Scott, > > > > I think David's note does address the issue on hand. > > > > To formalize; > >=20 > > The exchange of control messages between a WTP and AC implicitly > > indicates that the WTP is operational. For the purpose of protocol > > simplicity, I suggest that we focus on statistics messages=20 > alone for > > this purpose, reason being that statistics are periodically > exchanged. > > > > My concern is that by using "any" control message to indicate > > keepalive (Echo), the AC processing will be complicated. This is=20 > > because the AC will need to process each control message > for both its own value (e.g. > > Configure Request) and also keepalive value. > > Of course, complexity is a function of many factors, but=20 > there is a straightforward way to implement an echo trigger > with a flag and timer: > when you receive a control message, unconditionally raise the flag. > Periodically (according to your keepalive interval timer)=20 > check the flag; If it's up, put it down, else send a > keepalive. There are more complicated ways to implement, but > this works just fine. > > On the AC this can easily be implemented by having the=20 > fastpath raise the flag, and having the cp lower it and/or do > whatever it is your AC does if a WTP doesn't report in a > given echo interval (which may be nothing). Pretty basic stuff. > > On the WTP, implementation is similar, except that if the=20 > flag is down, you send the keepalive. Again, very simple and basic. > > > So I suggest keeping it simple - arrival of statistics message from > > WTP means WTP is alive. > > Certainly, a statistics message qualifies as a control=20 > message, so I have no issues with this statement when taken > alone. I'm concerned with the earlier suggestion that the > echo req/reply message be discarded and replaced by the > statistics message.=20 > > In some cases, the keepalive interval must be *very* brief in > order to facilitate rapid link loss detection and recovery. I > know of one vendor who routinely uses a one second interval, > and it's conceivable that in some scenarios one might choose > to use even less. > > And keep in mind that WTP and AC requirements are typically > asymmetric in this regard: the WTP needs to react quickly=20 > (maybe try to find another AC), whereas the AC simply needs > to somehow report the event. > While in some cases reporting might be considered urgent, > this is not the typical (or average) case.=20 > > The granularity requirements for reporting are typically much > coarser than those of recovery. That is, the AC may, at it's > option, only check every 10,20,30,... seconds for WTP > liveness, and it may very well do that via the stats message,=20 > rather than the echo, since this allows echo processing to > remain wholly in the AC fastpath. > > But say we eliminate the echo: what happens when, say, 500 > WTPs send stats potentially every second or less?=20 > > I think we still need the echo req/rsp. > > Scott > > > > > Saravanan > > > > > > > > > > > > -----Original Message-----=20 > > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > > Sent: Wednesday, April 19, 2006 1:51 AM > > To: capwap > > Subject: RE: [Capwap] Proposed Resolution to Issue 45=20 > > -Issueoncombiningmessages > > > > Just trying to close the loop: I think David's point (i.e. > that echoes > > should only be sent in the absence of other control > traffic) is dead=20 > > on, and that this effectively closes the question as to > whether echoes > > and stats should be combined in the same messages. > > > > Does anyone disagree? > > > > Scott > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > _________________________________________________________________=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 _________________________________________________________________ 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_01C66F58.EC8B756F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Without the text below, the specifications will = require an AC to monitor the arrival of “all” control packet with = respect to the EchoInterval and NeighbourDeadInterval timers. There were concerns = earlier on this thread that this is not ideal.

 

Furthermore, not all control packets indicate that a = WTP is alive and doing well. A WTP could fail, re-start and then send Discovery Requests to an AC. This should not be construed as an indication that = the WTP is well. On the other hand, by focusing only on Statistics (WTP Event = Request) control messages, it is unambiguous that a WTP is operational. =

 

So the text in the specifications should reflect this = by having Echo Requests sent in the absence of Statistics (WTP Event = Request) messages.

 

Saravanan

 

 

 

From: Pat = Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Thursday, May 04, = 2006 12:50 PM
To: Saravanan Govindan; = Dorothy Stanley
Cc: Scott G Kelly; = capwap
Subject: RE: [Capwap] = Proposed Resolution to Issue 45 = -Issueoncombiningmessages

 

The text you are proposing doesn't = change the behavior of the protocol. I'm not sure that it really adds anything = since we are stating that an echo is sent if no control packets are sent. You = are free to send periodic Statistics messages, which with the new language = would not require any Echos to be sent.

 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

 

From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: Wednesday, May 03, = 2006 8:18 PM
To: Dorothy Stanley; Pat = Calhoun (pacalhou)
Cc: Scott G Kelly; = capwap
Subject: RE: [Capwap] = Proposed Resolution to Issue 45 = -Issueoncombiningmessages

Hi Dorothy,

 

I suggest that the Echo Request MAY only be send in = the absence of specifically Statistics control packets as opposed to any = control packets. The reason for this is that Statistics packets are the only = regular exchanges, so the AC has just one type of packet to monitor for the = timer.

 

So I’d like to suggest the following = text:

 

From:

“If another Echo Request or other control = message is not received by the AC when the timer expires, the AC
SHOULD consider the WTP to be = unreachable"

 

To:

“If another Echo Request or Statistics message = is not received by the AC when the timer expires, the AC
SHOULD consider the WTP to be = unreachable"

 

Cheers,


Saravanan

 

 

 

 

 

From: = Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Thursday, May 04, = 2006 3:03 AM
To: Pat Calhoun = (pacalhou)
Cc: Scott G Kelly; = Saravanan Govindan; capwap
Subject: Re: [Capwap] = Proposed Resolution to Issue 45 = -Issueoncombiningmessages

 

All,

After the lengthy discussion on this topic, I believe that the = conclusion is
still to reject the comment, and as Pat summarized, the echo remains, = does not include any
statistics, and MAY only be sent in the absence of any control packets. =

Changes to the text:

Change text in 6.2" Echo Response" from:
"If another Echo Request message is not received by the AC when the = timer expires, the AC
SHOULD consider the WTP to be unreachable" to

"If another Echo Request or other control message is not received = by the AC when the timer expires, the AC
SHOULD consider the WTP to be unreachable"

and from

"If the NeighborDeadInterval timer expires prior to receiving an = Echo Response message,
message, the WTP enters the Reset State."
to
"If the NeighborDeadInterval timer expires prior to receiving an = Echo Response message, or other control
message, the WTP enters the Reset State."


Thanks,

Dorothy

Issue 45, Issue on Combining messages currently has the following discussion in the = issues database: 

Currently, the keepalive and statistics =
messages are separated. Separate 









 
 
messages =
for keepalive signaling and statistics can lead to high overhead. 









 
 
Initial =
analysis have shown that these overhead can be reduced significantly =











 
 










 
 
if the =
messages can be combined.









 
 










 
 
Recommendation:









 
 










 
 
To =
combine the keepalive and statistics message into one combined message, =










 
 
thus =
reducing overhead significantly.


Discussion:

The CAPWAP protocol specification currently supports the
Echo Request Message and Echo Response Messages, which are used for = keep-alive
purposes, and do not carry message elements.

There is an IEEE 802.11 Statistics measurement element(11.7.2.1), and several = CAPWAP statistics related
measurement elements: decryption error report, WTP descriptor, WTP radio information, WTP reboot statistics.
There is no statistics message.

There is no requirement on how often the statistics related measurement elements must be reported
to the AC from the WTP, there is a Statistics timer, see 7.2.5, which is = used by the AC to indicate the
timer value to the WTP. (separate question - should the statistics timer = be made general, and indicate the
values for the other Section 12 CAPWAP timers too?  Assume that the = CAPWAP statistics timer used
to determine how often to send the 802.11 specific statistics).

It is not clear that there is a high overhead in keeping the = echo/keep-alive mechanism from
the statistics reporting. There is some benefit in keeping the echo = messages simple,
rather than complicating the processing of those messages.  It is = true that small messages (echo request, response) have high overhead.
In this case, the design choice is to accept the overhead as the cost of = simplicity in design and implementation.

Recommended resolution: reject the comment, with the explanation in the = above paragraph

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

I will summarize my thoughts here and not try to inject in the = various
threads, but I agree that the echo remains, does not include any
statistics, and MAY only be sent in the absence of any control = packets.
I say MAY because an implementation could send them if it wishes, = but
the receiver must take into account control packets in addition to the =
echo prior to declaring a link dead.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems



> -----Original Message-----
> From: Scott G Kelly [mailto: scott@hyperthought.com]
> Sent: Friday, April 21, 2006 5:52 AM
> To: Saravanan Govindan
> Cc: capwap
> Subject: Re: [Capwap] Proposed Resolution to Issue 45
> -Issueoncombiningmessages
>
> Hi Saravanan,
>
> Saravanan Govindan wrote:
> > Hi Scott,
> >
> > I think David's note does address the issue on hand.
> >
> > To formalize;
> >
> > The exchange of control messages between a WTP and AC = implicitly
> > indicates that the WTP is operational. For the purpose of = protocol
> > simplicity, I suggest that we focus on statistics messages =
> alone for
> > this purpose, reason being that statistics are = periodically
> exchanged.
> >
> > My concern is that by using "any" control message to indicate
> > keepalive (Echo), the AC processing will be complicated. This = is
> > because the AC will need to process each control message
> for both its own value (e.g.
> > Configure Request) and also keepalive value.
>
> Of course, complexity is a function of many factors, but
> there is a straightforward way to implement an echo trigger
> with a flag and timer:
> when you receive a control message, unconditionally raise the = flag.
> Periodically (according to your keepalive interval timer)
> check the flag; If it's up, put it down, else send a
> keepalive. There are more complicated ways to implement, but
> this works just fine.
>
> On the AC this can easily be implemented by having the
> fastpath raise the flag, and having the cp lower it and/or do
> whatever it is your AC does if a WTP doesn't report in a
> given echo interval (which may be nothing). Pretty basic stuff.
>
> On the WTP, implementation is similar, except that if the
> flag is down, you send the keepalive. Again, very simple and = basic.
>
> > So I suggest keeping it simple - arrival of statistics message = from
> > WTP means WTP is alive.
>
> Certainly, a statistics message qualifies as a control
> message, so I have no issues with this statement when taken
> alone. I'm concerned with the earlier suggestion that the
> echo req/reply message be discarded and replaced by the
> statistics message.
>
> In some cases, the keepalive interval must be *very* brief in
> order to facilitate rapid link loss detection and recovery. I
> know of one vendor who routinely uses a one second interval,
> and it's conceivable that in some scenarios one might choose
> to use even less.
>
> And keep in mind that WTP and AC requirements are typically
> asymmetric in this regard: the WTP needs to react quickly
> (maybe try to find another AC), whereas the AC simply needs
> to somehow report the event.
> While in some cases reporting might be considered urgent,
> this is not the typical (or average) case.
>
> The granularity requirements for reporting are typically much
> coarser than those of recovery. That is, the AC may, at it's
> option, only check every 10,20,30,... seconds for WTP
> liveness, and it may very well do that via the stats message,
> rather than the echo, since this allows echo processing to
> remain wholly in the AC fastpath.
>
> But say we eliminate the echo: what happens when, say, 500
> WTPs send stats potentially every second or less?
>
> I think we still need the echo req/rsp.
>
> Scott
>
> >
> > Saravanan
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com]
> > Sent: Wednesday, April 19, 2006 1:51 AM
> > To: capwap
> > Subject: RE: [Capwap] Proposed Resolution to Issue 45
> > -Issueoncombiningmessages
> >
> > Just trying to close the loop: I think David's point (i.e.
> that echoes
> > should only be sent in the absence of other control
> traffic) is dead
> > on, and that this effectively closes the question as to
> whether echoes
> > and stats should be combined in the same messages.
> >
> > Does anyone disagree?
> >
> > Scott
> >
> >
> > = _________________________________________________________________
> > To unsubscribe or modify your subscription options, please = visit:
> > http://lists.f= rascone.com/mailman/listinfo/capwap
> >
> > Archives: http://lists.frascone= .com/pipermail/capwap
> >
> >
> _________________________________________________________________ =
> To unsubscribe or modify your subscription options, please = visit:
> http://lists.f= rascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone= .com/pipermail/capwap
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.f= rascone.com/mailman/listinfo/capwap

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

 

------_=_NextPart_001_01C66F58.EC8B756F-- --===============1896861090== 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 --===============1896861090==-- From kegoermeneg@liberal.ca Thu May 04 05:25:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fba5u-0000Gy-8M for capwap-archive@ietf.org; Thu, 04 May 2006 05:25:58 -0400 Received: from pd9503dbb.dip0.t-ipconnect.de ([217.80.61.187] helo=liberal.ca) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fba5s-0008T3-IX for capwap-archive@ietf.org; Thu, 04 May 2006 05:25:58 -0400 Message-ID: <000001c66f5c$a82eedc0$35baa8c0@gpi2> Reply-To: "Ermenegilde Kegley" From: "Ermenegilde Kegley" To: capwap-archive@ietf.org Subject: Re: tepoq news Date: Thu, 4 May 2006 02:25:17 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C66F21.FBD015C0" 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: 22bbb45ef41b733eb2d03ee71ece8243 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C66F21.FBD015C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dea m r Home O n wne n r ,=20 =20 Your c f red o it doesn't matter to us ! If you OW c N real e u st m at n e=20 and want I v MME u DIAT w E ca q sh to sp f en p d ANY way you like, or simply wish=20 to LO c WER your monthly p n ayment m s by a third or more, here are the de y als=20 we have T k OD j AY :=20 =20 $ 4 q 88 , 000 at a 3 , f 67% fi d xed - rat i e=20 $ 37 m 2 , 000 at a 3 t , 90% va l riabl x e - rat f e=20 $ 49 s 2 , 000 at a 3 v , 21% int w eres e t - only=20 $ 2 v 48 , 000 at a 3 e , 36% f s ixed - rat a e=20 $ 19 f 8 , 000 at a 3 , 5 c 5% v c ariable - rat q e=20 =20 H z urry, when these de z aIs are gone, they are gone ! =20 Don't worry about app a rova m l, your c t red z it will not dis y quali i fy you !=20 =20 V i isi s t our s m ite =20 =20 Sincerely, Ermenegilde Kegley=20 =20 Ap r pr o oval Manager ------=_NextPart_000_0001_01C66F21.FBD015C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dea m r Home O n wne n r ,
 
Your c f red o it doesn't matter to us !=20 If you OW c N real e u st m at n e
and want I v MME u DIAT w E ca q sh to sp f en p d ANY=20 way you like, or simply wish
to LO c WER your monthly p n ayment m s=20 by a third or more, here are the de y als
we have T k OD j AY :
 
$ 4 q 88 , 000 at a 3 , f 67% fi d xed - rat i e
$ 37 m 2 , 000 at a 3 t , 90% va l riabl x e - rat f e
$ 49 s 2 , 000 at a 3 v , 21% int w eres e t - only
$ 2 v 48 , 000 at a 3 e , 36% f s ixed - rat a e
$ 19 f 8 , 000 at a 3 , 5 c 5% v c ariable - rat q e
 
H z urry, when these de z aIs are gone, they are gone !
 
Don't worry about app a rova m l, your c t red z it will=20 not dis y quali i fy you !
 
=20 V i isi s t our s m ite
 
Sincerely, Ermenegilde Kegley
 
Ap r pr o oval Manager
------=_NextPart_000_0001_01C66F21.FBD015C0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu May 04 07:15:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbboB-0004Ck-4c for capwap-archive@lists.ietf.org; Thu, 04 May 2006 07:15:47 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbbo9-0005nR-Jy for capwap-archive@lists.ietf.org; Thu, 04 May 2006 07:15:47 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E4978430128 for ; Thu, 4 May 2006 04:15:44 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6C608430067 for ; Thu, 4 May 2006 04:15:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 040E63981CF for ; Thu, 4 May 2006 04:15:15 -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 971053981D2 for ; Thu, 4 May 2006 04:15:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=VYLgg3WONKL41qJR/K4aCNRlvmaSr93Hkk3bB2IHAHj/nQBbFIyvqYO3R+W9D+6L; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.48] (helo=elwamui-rustique.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FbbnL-0001mY-Rx; Thu, 04 May 2006 07:14:55 -0400 Received: from 72.114.37.62 by webmail.pas.earthlink.net with HTTP; Thu, 4 May 2006 07:14:55 -0400 Message-ID: <12525320.1146741295629.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> Date: Thu, 4 May 2006 04:14:55 -0700 (GMT-07:00) From: "Scott G. Kelly" To: Charles Clancy Subject: Re: [Capwap] to mux or not to mux? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710f2dd9398787b08e76a3029fc80d74361350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Hi Charles, I think whether this has security implications depends on a number of things, and gets tangled pretty fast, but my short answer is that for the most part, you are probably right, and I am mixing my concerns with separate IP termination points for control and data into this discussion. If you are terminating both channels on the same entity and not making middlebox decisions, UDP is very similar to the MUX header, and I think you are correct in asserting there are no additional security considerations. I think that if you use separate ports and either terminate the ports on two separate entities in the backend, or allow middleboxes to treat the traffic differently in between, you may have security issues to contend with, but I haven't spent a lot of time on analysis. In the first case, this requires coordination in the backend, and you have the potential for left-hand/right-hand problems, e.g. where data packets should no longer be flowing but they are. I think this is potentially a mini-version of the problems you have when you allow control and data to use separate IP addresses, depending on how someone chooses to implement. In the second case, you may be opening/closing the data channel at a middlebox depending on the state of the control channel, and again, you may wind up with cases where there is inconsistency. That said, this is not the overriding concern for me, and should not become a distraction. The real problems are the operational ones cited in earlier emails. Scott -----Original Message----- >From: Charles Clancy >Sent: May 3, 2006 2:56 PM >To: Charles Clancy >Cc: capwap >Subject: Re: [Capwap] to mux or not to mux? > >Just to clarify, MUXing or not MUXing does not affect security one way >or the other. Thus my opinion is as a member of the WG, and not as a >security advisor. It apparently affects deployments and >implementations, which is not my expertise, and thus my comments should >be weighted as such. > >-- >t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > >Charles Clancy wrote: >> The DTLS tunnels would NOT be merged. You'd have something like: >> >> +---------+------------+------------------------ >> | UDP hdr | MUX = 0x01 | DTLS(CAPWAP Control) >> +---------+------------+----------- >> >> or >> >> +---------+------------+------------------------ >> | UDP hdr | MUX = 0x02 | CAPWAP Data >> +---------+------------+----------- >> >> UDP is indeed a MUX header, but it's a MUX header that everything >> already understands. So, it all comes down to whether or not we want >> intermediate network devices to distinguish between control and data. >> For NAT traversal, it's easier if the NAT treats everything the same, >> and doesn't have to know that the two ports are related. Same for >> firewall / port forwarding. I think intermediate network devices should >> treat everything as "CAPWAP", and we should therefore do our own MUX. >> >_________________________________________________________________ >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 May 04 07:25:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbbxf-0001tj-At for capwap-archive@lists.ietf.org; Thu, 04 May 2006 07:25:35 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbbxe-00062w-Kn for capwap-archive@lists.ietf.org; Thu, 04 May 2006 07:25:35 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 40F54430114 for ; Thu, 4 May 2006 04:25:34 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 79C31430067 for ; Thu, 4 May 2006 04:25:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5219A1448007 for ; Thu, 4 May 2006 04:25:07 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by hermes.tigertech.net (Postfix) with ESMTP id 44A5B430B62 for ; Thu, 4 May 2006 04:25:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=eQ7uHzUyxdod0NURZOt5TrkMhvRCyGGXw20OqHC4JTYomqiQT3DTFuHpWdpxBEMT; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.48] (helo=elwamui-rustique.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Fbbx7-0006Rj-De; Thu, 04 May 2006 07:25:01 -0400 Received: from 72.114.37.62 by webmail.pas.earthlink.net with HTTP; Thu, 4 May 2006 07:25:01 -0400 Message-ID: <25044396.1146741901320.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> Date: Thu, 4 May 2006 04:25:01 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "Nancy Winget (ncamwing)" , Charles Clancy , Michael Montemurro Subject: RE: [Capwap] to mux or not to mux? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff7104bc575981cf34434f2942b9f3c37b52b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.48 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 As Charles pointed out, the two channels are not merged into one DTLS session. By current definitions, the data channel is not running over DTLS, and I suspect that if we come to agree that optional data channel security is worthwhile, the data channel may well get its own distinct DTLS session. I'm going to compress this into one response for both Nancy and Pat, since I'm on vacation, and my wife will definitely give me "the look" if she wakes up and finds me talking to you guys :-) Please go back and read the threads on this topic, in particular the messages posted during IETF65. You guys are saying you want to split this into two udp channels because you have middleboxes in between and you want to treat the streams differently. Those posts show why this will induce signficant operational complexity, much of which is outside the scope of our current charter. Nobody has given any concrete examples which demonstrate that we should incur this complexity. -----Original Message----- >From: "Nancy Winget (ncamwing)" >Sent: May 3, 2006 2:34 PM >To: Charles Clancy , Michael Montemurro >Cc: capwap >Subject: RE: [Capwap] to mux or not to mux? > >Charles, > >With a MUX, yes they are logical channels, but I believe the implication >is that these channels are merged into a single DTLS tunnel...are you >saying they are not? > >But as you state, if UDP is a MUX header, why the need to introduce yet >another one instead of just using UDP for separation? > > Nancy. > >-----Original Message----- >From: Charles Clancy [mailto:clancy@cs.umd.edu] >Sent: Wednesday, May 03, 2006 2:29 PM >To: Michael Montemurro >Cc: Nancy Winget (ncamwing); capwap >Subject: Re: [Capwap] to mux or not to mux? > >Even with the MUX header, you have two independent, logical channels. >If you think about it, UDP is really just one big MUX header. What >we're doing is really nothing different. It should not impact anything >to do with sequence numbers or key derivation. > >-- >t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > >Michael Montemurro wrote: >> Nancy brings up an interesting point here. >> >> If we go with the MUX header approach, how do we achieve key >> separation between the control and data channels? >> >> How do we derive the keys and how do we maintain sequence counters. >> >> Cheers, >> >> Mike >> >> >> >> >> On 5/2/06, *Nancy Winget (ncamwing)* > > wrote: >> >> >> I don't believe adding a MUX is the right answer. First, the >addition >> is a change in DTLS and also brings up other issues of concern: >> - distinguishing the control from data plane is a good thing as >the >> firewall rules may be different for each plane which is already >> addressed by the UDP assignments. >> - merging the control and data plane into a single UDP (dtls) >tunnel >> forces the two planes to be synchronized from an anti-replay >> perspective. This effectively restricts the architecture to force >them >> to use a centralized DTLS encapsulation/decapsulation which imho >is too >> restrictive >> >> Nancy. >> >> -----Original Message----- >> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com >> ] >> Sent: Monday, May 01, 2006 11:38 AM >> To: capwap >> Subject: [Capwap] to mux or not to mux? >> >> Some time ago, I proposed that we use a single port for capwap, >and >> insert a mux header right after the UDP header to differentiate >between >> control and data. While there was some discussion, we did not >reach a >> conclusion. >> >> Here's what it would look like: >> >> +---------+-------------+------------------------------- >> | UDP Hdr | MUX Hdr = 1 | DTLS Enc Control Packet .... >> +---------+-------------+---------------------- >> >> The capwap editors are currently working hard to produce the 01 >version >> of the capwap document, and it would be best for implementers if >this >> question could be decided prior to publication of that document. >To >> facilitate this, I've summarized briefly below. >> >> Using separate ports for control/data has a number of drawbacks: >> >> - if firewalls are between the AC and WTP, multiple rules are >> required >> >> - we must be able to explicitly bind the data and control channels >at >> the AC in order to ensure proper operation; if they use the same >port >> (and therefore, flow), this is straightforward; if not, we must >add >> protocol elements for detecting and accounting for NATs along the >AC-WTP >> path, and for explicitly (and securely) creating the bindings >between >> the two channels >> >> - there are race conditions that must be dealt with; in >particular, it >> is possible to have the left hand (control channel) not knowing >for >> certain what the right hand (data channel) is doing (and vice >> versa) >> >> - If there *are* NATs along the path, using two ports will require >> keepalives on both ports, and error handling for when one channel >goes >> away but the other does not (e.g. if a middlebox deletes the NAT >> bindings for any reason) >> >> - there are many more error conditions to manage in the state >machine, >> due to the channel binding and NAT issues >> >> Clearly, using two ports adds *significant* complexity to the >> implementation, and will likely result in operational problems in >some >> environments. >> >> Using a mux header has one drawback (that I can think of): >> >> - it adds n bytes to the header. I'm tempted to say n will be 4 >for >> 32-bit alignment, but it could also be only 1 or 2 bytes, if >> bits-on-the-wire overhead is an overriding concern. >> >> Using a mux hader has several advantages: >> >> - we get NAT traversal for free, by simply configuring the echo >interval >> to be smaller than the NAT binding lifetime for the path in >> question >> >> - we only open one port through intermediate firewalls (and any >> intermediate NATs) >> >> - the implementation (state machine, error handling) is *much* >simpler, >> and therefore more likely >> to (inter)operate according to spec >> >> We need to decide on this, preferably within the next day or two. >> Please >> speak up and make your preferences known. >> >> 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 >> >> >> >> ---------------------------------------------------------------------- >> -- >> >> _________________________________________________________________ >> 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 May 04 08:25:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbctm-000414-Gq for capwap-archive@lists.ietf.org; Thu, 04 May 2006 08:25:38 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbctk-0008I8-Mv for capwap-archive@lists.ietf.org; Thu, 04 May 2006 08:25:38 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 05B884300B7 for ; Thu, 4 May 2006 05:25:36 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A82FA430067 for ; Thu, 4 May 2006 05:25:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 938E239801F for ; Thu, 4 May 2006 05:25:04 -0700 (PDT) Received: from huawei.com (szxga01-in.huawei.com [61.144.161.53]) by zoidberg.tigertech.net (Postfix) with ESMTP id EC7C1398025 for ; Thu, 4 May 2006 05:24:58 -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 <0IYQ00FRFQI87L@szxga01-in.huawei.com> for capwap@frascone.com; Thu, 04 May 2006 20:25:20 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYQ00KCGQI7JP@szxga01-in.huawei.com> for capwap@frascone.com; Thu, 04 May 2006 20:25:20 +0800 (CST) Received: from dell60 ([10.18.7.113]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IYQ00JE5R57S5@szxml02-in.huawei.com>; Thu, 04 May 2006 20:39:08 +0800 (CST) Date: Thu, 04 May 2006 17:54:44 +0530 From: sujay Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages In-reply-to: <5F09D220B62F79418461A978CA0921BDD52D77@pslexc01.psl.local> To: 'Saravanan Govindan' , "'Pat Calhoun (pacalhou)'" , 'Dorothy Stanley' Message-id: <006501c66f75$ba182880$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 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT 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' X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 4c463dcf97e2b913ab242796279c24d2 Saravanan, A valid point, yet ALL control messages should be monitored for which are VALID in the RUN state. There is no reason for giving special treatment to statistics messages alone. Considering an implementation, I see no significant overhead in assuming say a Configure Request packet as a keepalive packet from the peer. Regds, Sujay -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Thursday, May 04, 2006 2:29 PM To: Pat Calhoun (pacalhou); Dorothy Stanley Cc: capwap Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Without the text below, the specifications will require an AC to monitor the arrival of "all" control packet with respect to the EchoInterval and NeighbourDeadInterval timers. There were concerns earlier on this thread that this is not ideal. Furthermore, not all control packets indicate that a WTP is alive and doing well. A WTP could fail, re-start and then send Discovery Requests to an AC. This should not be construed as an indication that the WTP is well. On the other hand, by focusing only on Statistics (WTP Event Request) control messages, it is unambiguous that a WTP is operational. So the text in the specifications should reflect this by having Echo Requests sent in the absence of Statistics (WTP Event Request) messages. Saravanan From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Thursday, May 04, 2006 12:50 PM To: Saravanan Govindan; Dorothy Stanley Cc: Scott G Kelly; capwap Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages The text you are proposing doesn't change the behavior of the protocol. I'm not sure that it really adds anything since we are stating that an echo is sent if no control packets are sent. You are free to send periodic Statistics messages, which with the new language would not require any Echos to be sent. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Wednesday, May 03, 2006 8:18 PM To: Dorothy Stanley; Pat Calhoun (pacalhou) Cc: Scott G Kelly; capwap Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Hi Dorothy, I suggest that the Echo Request MAY only be send in the absence of specifically Statistics control packets as opposed to any control packets. The reason for this is that Statistics packets are the only regular exchanges, so the AC has just one type of packet to monitor for the timer. So I'd like to suggest the following text: From: "If another Echo Request or other control message is not received by the AC when the timer expires, the AC SHOULD consider the WTP to be unreachable" To: "If another Echo Request or Statistics message is not received by the AC when the timer expires, the AC SHOULD consider the WTP to be unreachable" Cheers, Saravanan From: Dorothy Stanley [mailto:dstanley1389@gmail.com] Sent: Thursday, May 04, 2006 3:03 AM To: Pat Calhoun (pacalhou) Cc: Scott G Kelly; Saravanan Govindan; capwap Subject: Re: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages All, After the lengthy discussion on this topic, I believe that the conclusion is still to reject the comment, and as Pat summarized, the echo remains, does not include any statistics, and MAY only be sent in the absence of any control packets. Changes to the text: Change text in 6.2" Echo Response" from: "If another Echo Request message is not received by the AC when the timer expires, the AC SHOULD consider the WTP to be unreachable" to "If another Echo Request or other control message is not received by the AC when the timer expires, the AC SHOULD consider the WTP to be unreachable" and from "If the NeighborDeadInterval timer expires prior to receiving an Echo Response message, message, the WTP enters the Reset State." to "If the NeighborDeadInterval timer expires prior to receiving an Echo Response message, or other control message, the WTP enters the Reset State." Thanks, Dorothy Issue 45, Issue on Combining messages currently has the following discussion in the issues database: Currently, the keepalive and statistics messages are separated. Separate messages for keepalive signaling and statistics can lead to high overhead. Initial analysis have shown that these overhead can be reduced significantly if the messages can be combined. Recommendation: To combine the keepalive and statistics message into one combined message, thus reducing overhead significantly. Discussion: The CAPWAP protocol specification currently supports the Echo Request Message and Echo Response Messages, which are used for keep-alive purposes, and do not carry message elements. There is an IEEE 802.11 Statistics measurement element(11.7.2.1), and several CAPWAP statistics related measurement elements: decryption error report, WTP descriptor, WTP radio information, WTP reboot statistics. There is no statistics message. There is no requirement on how often the statistics related measurement elements must be reported to the AC from the WTP, there is a Statistics timer, see 7.2.5, which is used by the AC to indicate the timer value to the WTP. (separate question - should the statistics timer be made general, and indicate the values for the other Section 12 CAPWAP timers too? Assume that the CAPWAP statistics timer used to determine how often to send the 802.11 specific statistics). It is not clear that there is a high overhead in keeping the echo/keep-alive mechanism from the statistics reporting. There is some benefit in keeping the echo messages simple, rather than complicating the processing of those messages. It is true that small messages (echo request, response) have high overhead. In this case, the design choice is to accept the overhead as the cost of simplicity in design and implementation. Recommended resolution: reject the comment, with the explanation in the above paragraph On 4/28/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com> wrote: I will summarize my thoughts here and not try to inject in the various threads, but I agree that the echo remains, does not include any statistics, and MAY only be sent in the absence of any control packets. I say MAY because an implementation could send them if it wishes, but the receiver must take into account control packets in addition to the echo prior to declaring a link dead. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Scott G Kelly [mailto: scott@hyperthought.com] > Sent: Friday, April 21, 2006 5:52 AM > To: Saravanan Govindan > Cc: capwap > Subject: Re: [Capwap] Proposed Resolution to Issue 45 > -Issueoncombiningmessages > > Hi Saravanan, > > Saravanan Govindan wrote: > > Hi Scott, > > > > I think David's note does address the issue on hand. > > > > To formalize; > > > > The exchange of control messages between a WTP and AC implicitly > > indicates that the WTP is operational. For the purpose of protocol > > simplicity, I suggest that we focus on statistics messages > alone for > > this purpose, reason being that statistics are periodically > exchanged. > > > > My concern is that by using "any" control message to indicate > > keepalive (Echo), the AC processing will be complicated. This is > > because the AC will need to process each control message > for both its own value (e.g. > > Configure Request) and also keepalive value. > > Of course, complexity is a function of many factors, but > there is a straightforward way to implement an echo trigger > with a flag and timer: > when you receive a control message, unconditionally raise the flag. > Periodically (according to your keepalive interval timer) > check the flag; If it's up, put it down, else send a > keepalive. There are more complicated ways to implement, but > this works just fine. > > On the AC this can easily be implemented by having the > fastpath raise the flag, and having the cp lower it and/or do > whatever it is your AC does if a WTP doesn't report in a > given echo interval (which may be nothing). Pretty basic stuff. > > On the WTP, implementation is similar, except that if the > flag is down, you send the keepalive. Again, very simple and basic. > > > So I suggest keeping it simple - arrival of statistics message from > > WTP means WTP is alive. > > Certainly, a statistics message qualifies as a control > message, so I have no issues with this statement when taken > alone. I'm concerned with the earlier suggestion that the > echo req/reply message be discarded and replaced by the > statistics message. > > In some cases, the keepalive interval must be *very* brief in > order to facilitate rapid link loss detection and recovery. I > know of one vendor who routinely uses a one second interval, > and it's conceivable that in some scenarios one might choose > to use even less. > > And keep in mind that WTP and AC requirements are typically > asymmetric in this regard: the WTP needs to react quickly > (maybe try to find another AC), whereas the AC simply needs > to somehow report the event. > While in some cases reporting might be considered urgent, > this is not the typical (or average) case. > > The granularity requirements for reporting are typically much > coarser than those of recovery. That is, the AC may, at it's > option, only check every 10,20,30,... seconds for WTP > liveness, and it may very well do that via the stats message, > rather than the echo, since this allows echo processing to > remain wholly in the AC fastpath. > > But say we eliminate the echo: what happens when, say, 500 > WTPs send stats potentially every second or less? > > I think we still need the echo req/rsp. > > Scott > > > > > Saravanan > > > > > > > > > > > > -----Original Message----- > > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > > Sent: Wednesday, April 19, 2006 1:51 AM > > To: capwap > > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > > -Issueoncombiningmessages > > > > Just trying to close the loop: I think David's point (i.e. > that echoes > > should only be sent in the absence of other control > traffic) is dead > > on, and that this effectively closes the question as to > whether echoes > > and stats should be combined in the same messages. > > > > Does anyone disagree? > > > > 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 Thu May 04 10:00:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbeNc-0004VC-Cq for capwap-archive@lists.ietf.org; Thu, 04 May 2006 10:00:32 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbeNa-0004tu-Hw for capwap-archive@lists.ietf.org; Thu, 04 May 2006 10:00:32 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 87BB9430129 for ; Thu, 4 May 2006 07:00:29 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D89BB430067 for ; Thu, 4 May 2006 07:00:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C2B3139801F for ; Thu, 4 May 2006 07:00:00 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id F413A398023 for ; Thu, 4 May 2006 06:59:55 -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 k44Dxs3c024263; Thu, 4 May 2006 06:59:54 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k44DxsC7024259; Thu, 4 May 2006 06:59:54 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 4 May 2006 06:59:54 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Saravanan Govindan Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages In-Reply-To: <5F09D220B62F79418461A978CA0921BDD52D77@pslexc01.psl.local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.08 tagged_above=-999 required=7 tests=NORMAL_HTTP_TO_IP X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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: d4a1871e876bd836d4c351e861e8720d HI, I haven't yet coded the echo timers. However, I really don't see a problem with "monitoring all control traffic" for a session. Also, if a WTP reboots and sends discovery messages, these WILL NOT be on the same session that is being monitored, and thus, will not affect the echo timers of an existing session. Also note, that you really don't want a "bad guy" to be able to affect existing sessions by sending discovery messages to the AC. Have you coded up a WTP and AC prototype and had any problem with the current scheme? Regards, /david t. perkins On Thu, 4 May 2006, Saravanan Govindan wrote: > Without the text below, the specifications will require an AC to monitor > the arrival of "all" control packet with respect to the EchoInterval and > NeighbourDeadInterval timers. There were concerns earlier on this thread > that this is not ideal. > > Furthermore, not all control packets indicate that a WTP is alive and > doing well. A WTP could fail, re-start and then send Discovery Requests > to an AC. This should not be construed as an indication that the WTP is > well. On the other hand, by focusing only on Statistics (WTP Event > Request) control messages, it is unambiguous that a WTP is operational. > > So the text in the specifications should reflect this by having Echo > Requests sent in the absence of Statistics (WTP Event Request) messages. > > Saravanan > > ________________________________ > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Thursday, May 04, 2006 12:50 PM > To: Saravanan Govindan; Dorothy Stanley > Cc: Scott G Kelly; capwap > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > -Issueoncombiningmessages > > > > The text you are proposing doesn't change the behavior of the protocol. > I'm not sure that it really adds anything since we are stating that an > echo is sent if no control packets are sent. You are free to send > periodic Statistics messages, which with the new language would not > require any Echos to be sent. > > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > > > ________________________________ > > > From: Saravanan Govindan > [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Wednesday, May 03, 2006 8:18 PM > To: Dorothy Stanley; Pat Calhoun (pacalhou) > Cc: Scott G Kelly; capwap > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > -Issueoncombiningmessages > > Hi Dorothy, > > > > I suggest that the Echo Request MAY only be send in the absence > of specifically Statistics control packets as opposed to any control > packets. The reason for this is that Statistics packets are the only > regular exchanges, so the AC has just one type of packet to monitor for > the timer. > > > > So I'd like to suggest the following text: > > > > From: > > "If another Echo Request or other control message is not > received by the AC when the timer expires, the AC > SHOULD consider the WTP to be unreachable" > > > > To: > > "If another Echo Request or Statistics message is not received > by the AC when the timer expires, the AC > SHOULD consider the WTP to be unreachable" > > > > Cheers, > > > Saravanan > > > > > > > > > > > > > ________________________________ > > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > Sent: Thursday, May 04, 2006 3:03 AM > To: Pat Calhoun (pacalhou) > Cc: Scott G Kelly; Saravanan Govindan; capwap > Subject: Re: [Capwap] Proposed Resolution to Issue 45 > -Issueoncombiningmessages > > > > All, > > After the lengthy discussion on this topic, I believe that the > conclusion is > still to reject the comment, and as Pat summarized, the echo > remains, does not include any > statistics, and MAY only be sent in the absence of any control > packets. > > Changes to the text: > > Change text in 6.2" Echo Response" from: > "If another Echo Request message is not received by the AC when > the timer expires, the AC > SHOULD consider the WTP to be unreachable" to > > "If another Echo Request or other control message is not > received by the AC when the timer expires, the AC > SHOULD consider the WTP to be unreachable" > > and from > > "If the NeighborDeadInterval timer expires prior to receiving an > Echo Response message, > message, the WTP enters the Reset State." > to > "If the NeighborDeadInterval timer expires prior to receiving an > Echo Response message, or other control > message, the WTP enters the Reset State." > > > Thanks, > > Dorothy > > Issue 45, Issue on Combining messages currently has the > following discussion in the issues database: > > Currently, the keepalive and statistics messages are separated. > Separate > > > > > > > > > > > > messages for keepalive signaling and statistics can lead to high > overhead. > > > > > > > > > > > > Initial analysis have shown that these overhead can be reduced > significantly > > > > > > > > > > > > > > > > > > > > > > > > > if the messages can be combined. > > > > > > > > > > > > > > > > > > > > > > > > Recommendation: > > > > > > > > > > > > > > > > > > > > > > > > To combine the keepalive and statistics message into one > combined message, > > > > > > > > > > > > thus reducing overhead significantly. > > > Discussion: > > The CAPWAP protocol specification currently supports the > Echo Request Message and Echo Response Messages, which are used > for keep-alive > purposes, and do not carry message elements. > > There is an IEEE 802.11 Statistics measurement element(11.7.2.1 > ), and several CAPWAP statistics related > measurement elements: decryption error report, WTP descriptor, > WTP radio information, WTP reboot statistics. > There is no statistics message. > > There is no requirement on how often the statistics related > measurement elements must be reported > to the AC from the WTP, there is a Statistics timer, see 7.2.5, > which is used by the AC to indicate the > timer value to the WTP. (separate question - should the > statistics timer be made general, and indicate the > values for the other Section 12 CAPWAP timers too? Assume that > the CAPWAP statistics timer used > to determine how often to send the 802.11 specific statistics). > > It is not clear that there is a high overhead in keeping the > echo/keep-alive mechanism from > the statistics reporting. There is some benefit in keeping the > echo messages simple, > rather than complicating the processing of those messages. It > is true that small messages (echo request, response) have high overhead. > In this case, the design choice is to accept the overhead as the > cost of simplicity in design and implementation. > > Recommended resolution: reject the comment, with the explanation > in the above paragraph > > On 4/28/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com > > wrote: > > I will summarize my thoughts here and not try to inject in the > various > threads, but I agree that the echo remains, does not include any > statistics, and MAY only be sent in the absence of any control > packets. > I say MAY because an implementation could send them if it > wishes, but > the receiver must take into account control packets in addition > to the > echo prior to declaring a link dead. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Scott G Kelly [mailto: scott@hyperthought.com > ] > > Sent: Friday, April 21, 2006 5:52 AM > > To: Saravanan Govindan > > Cc: capwap > > Subject: Re: [Capwap] Proposed Resolution to Issue 45 > > -Issueoncombiningmessages > > > > Hi Saravanan, > > > > Saravanan Govindan wrote: > > > Hi Scott, > > > > > > I think David's note does address the issue on hand. > > > > > > To formalize; > > > > > > The exchange of control messages between a WTP and AC > implicitly > > > indicates that the WTP is operational. For the purpose of > protocol > > > simplicity, I suggest that we focus on statistics messages > > alone for > > > this purpose, reason being that statistics are periodically > > exchanged. > > > > > > My concern is that by using "any" control message to > indicate > > > keepalive (Echo), the AC processing will be complicated. > This is > > > because the AC will need to process each control message > > for both its own value (e.g. > > > Configure Request) and also keepalive value. > > > > Of course, complexity is a function of many factors, but > > there is a straightforward way to implement an echo trigger > > with a flag and timer: > > when you receive a control message, unconditionally raise the > flag. > > Periodically (according to your keepalive interval timer) > > check the flag; If it's up, put it down, else send a > > keepalive. There are more complicated ways to implement, but > > this works just fine. > > > > On the AC this can easily be implemented by having the > > fastpath raise the flag, and having the cp lower it and/or do > > whatever it is your AC does if a WTP doesn't report in a > > given echo interval (which may be nothing). Pretty basic > stuff. > > > > On the WTP, implementation is similar, except that if the > > flag is down, you send the keepalive. Again, very simple and > basic. > > > > > So I suggest keeping it simple - arrival of statistics > message from > > > WTP means WTP is alive. > > > > Certainly, a statistics message qualifies as a control > > message, so I have no issues with this statement when taken > > alone. I'm concerned with the earlier suggestion that the > > echo req/reply message be discarded and replaced by the > > statistics message. > > > > In some cases, the keepalive interval must be *very* brief in > > order to facilitate rapid link loss detection and recovery. I > > know of one vendor who routinely uses a one second interval, > > and it's conceivable that in some scenarios one might choose > > to use even less. > > > > And keep in mind that WTP and AC requirements are typically > > asymmetric in this regard: the WTP needs to react quickly > > (maybe try to find another AC), whereas the AC simply needs > > to somehow report the event. > > While in some cases reporting might be considered urgent, > > this is not the typical (or average) case. > > > > The granularity requirements for reporting are typically much > > coarser than those of recovery. That is, the AC may, at it's > > option, only check every 10,20,30,... seconds for WTP > > liveness, and it may very well do that via the stats message, > > rather than the echo, since this allows echo processing to > > remain wholly in the AC fastpath. > > > > But say we eliminate the echo: what happens when, say, 500 > > WTPs send stats potentially every second or less? > > > > I think we still need the echo req/rsp. > > > > Scott > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > > > Sent: Wednesday, April 19, 2006 1:51 AM > > > To: capwap > > > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > > > -Issueoncombiningmessages > > > > > > Just trying to close the loop: I think David's point (i.e. > > that echoes > > > should only be sent in the absence of other control > > traffic) is dead > > > on, and that this effectively closes the question as to > > whether echoes > > > and stats should be combined in the same messages. > > > > > > Does anyone disagree? > > > > > > 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 Thu May 04 10:02:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbePM-0007Xz-5q for capwap-archive@lists.ietf.org; Thu, 04 May 2006 10:02:20 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbePJ-0004xo-M1 for capwap-archive@lists.ietf.org; Thu, 04 May 2006 10:02:20 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 407E04300AA for ; Thu, 4 May 2006 07:02:17 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 0D8D94300A5 for ; Thu, 4 May 2006 07:01:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EDC601448038 for ; Thu, 4 May 2006 07:01:27 -0700 (PDT) Received: from stlssgcorpmailfw2.anheuser-busch.com (stlssgcorpmailfw2.anheuser-busch.com [151.145.63.132]) by hermes.tigertech.net (Postfix) with ESMTP id 95C6C144803A for ; Thu, 4 May 2006 07:01:22 -0700 (PDT) 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="--344510-7129147-1017340393=:3379" Content-Transfer-Encoding: quoted-printable Subject: Re: [Capwap] to mux or not to mux? Date: Thu, 4 May 2006 09:01:20 -0500 Message-ID: <89525CB1203D7346BBBDFCE9CECB47CF0222E882@STLEXGUSR31.abc.corp.anheuser-busch.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] to mux or not to mux? Thread-Index: AcZvCClC1qWFsf+tTE+ahymA/K4nXQAeqbpQ From: "Kraus, Michael" To: X-OriginalArrivalTime: 04 May 2006 14:01:20.0671 (UTC) FILETIME=[388B9AF0:01C66F83] X-MessageInspectorSig: 1f1413a2ae0ef41c103af0e0c2d224e5 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: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 3adba28c47054ea827843deea22a7215 ----344510-7129147-1017340393=:3379 content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One additional upside to using separate ports would be that different QoS policies can be applied against data/control data. With mux values, this wo= uld be more difficult to accomplish with current QoS tools. With 802.11n data r= ates being quoted, having the ability to do some =22control plane policing=22 for= the APs, might be advantageous. ---------------------------------------------------------------------- Message: 1 Date: Wed, 3 May 2006 15:16:21 -0700 (PDT) From: =22David T. Perkins=22 Subject: Re: =5BCapwap=5D to mux or not to mux? To: Charles Clancy Cc: capwap Message-ID: Content-Type: TEXT/PLAIN; charset=3DUS-ASCII HI, Please don't forget about the discovery message. With it, you have 3 values = for MUX. See below.. Also, please note that in the prototype that I'm developing, I'm using the UNMODIFIED DTLS implementation in openSSL. That is, adding the MUX header does not require any modification of the open= SSL. By the way,my two wishes are: 1) an Ethereal decode for the below 2) the addition of the NULL encryption type to the CAPWAP protocol for debugging On Wed, 3 May 2006, Charles Clancy wrote: > The DTLS tunnels would NOT be merged. You'd have something like: +---------+------------+------------------------ =7C UDP hdr =7C MUX =3D 0x00 =7C Discovery Request or Response +---------+------------+----------- > +---------+------------+------------------------ > =7C UDP hdr =7C MUX =3D 0x01 =7C DTLS(CAPWAP Control) > +---------+------------+----------- > > or > > +---------+------------+------------------------ > =7C UDP hdr =7C MUX =3D 0x02 =7C CAPWAP Data > +---------+------------+----------- > > UDP is indeed a MUX header, but it's a MUX header that everything > already understands. So, it all comes down to whether or not we want > intermediate network devices to distinguish between control and data. > For NAT traversal, it's easier if the NAT treats everything the same, > and doesn't have to know that the two ports are related. Same for > firewall / port forwarding. I think intermediate network devices > should treat everything as =22CAPWAP=22, and we should therefore do our ow= n MUX. > > -- > t. charles clancy, ph.d. =7C tcc=40umd.edu =7C www.cs.umd.edu/=7Eclanc= y > > Nancy Winget (ncamwing) wrote: > > Charles, > > > > With a MUX, yes they are logical channels, but I believe the > > implication is that these channels are merged into a single DTLS > > tunnel...are you saying they are not? > > > > But as you state, if UDP is a MUX header, why the need to introduce > > yet another one instead of just using UDP for separation? > > > > Nancy. > > > > -----Original Message----- > > From: Charles Clancy =5Bmailto:clancy=40cs.umd.edu=5D > > Sent: Wednesday, May 03, 2006 2:29 PM > > To: Michael Montemurro > > Cc: Nancy Winget (ncamwing); capwap > > Subject: Re: =5BCapwap=5D to mux or not to mux? > > > > Even with the MUX header, you have two independent, logical channels. > > If you think about it, UDP is really just one big MUX header. What > > we're doing is really nothing different. It should not impact > > anything to do with sequence numbers or key derivation. > > > > -- > > t. charles clancy, ph.d. =7C tcc=40umd.edu =7C www.cs.umd.edu/=7Ecla= ncy > > > > Michael Montemurro wrote: > > > >>Nancy brings up an interesting point here. > >> > >>If we go with the MUX header approach, how do we achieve key > >>separation between the control and data channels? > >> > >>How do we derive the keys and how do we maintain sequence counters. > >> > >>Cheers, > >> > >> Mike > >> > >> > >> > >> > >>On 5/2/06, *Nancy Winget (ncamwing)* >>> wrote: > >> > >> > >> I don't believe adding a MUX is the right answer. First, the > > > > addition > > > >> is a change in DTLS and also brings up other issues of concern: > >> - distinguishing the control from data plane is a good thing as > > > > the > > > >> firewall rules may be different for each plane which is already > >> addressed by the UDP assignments. > >> - merging the control and data plane into a single UDP (dtls) > > > > tunnel > > > >> forces the two planes to be synchronized from an anti-replay > >> perspective. This effectively restricts the architecture to > >> force > > > > them > > > >> to use a centralized DTLS encapsulation/decapsulation which imho > > > > is too > > > >> restrictive > >> > >> Nancy. > >> > >> -----Original Message----- > >> From: Scott G. Kelly =5Bmailto:s.kelly=40ix.netcom.com > >> =5D > >> Sent: Monday, May 01, 2006 11:38 AM > >> To: capwap > >> Subject: =5BCapwap=5D to mux or not to mux? > >> > >> Some time ago, I proposed that we use a single port for capwap, > > > > and > > > >> insert a mux header right after the UDP header to differentiate > > > > between > > > >> control and data. While there was some discussion, we did not > > > > reach a > > > >> conclusion. > >> > >> Here's what it would look like: > >> > >> +---------+-------------+------------------------------- > >> =7C UDP Hdr =7C MUX Hdr =3D 1 =7C DTLS Enc Control Packet .... > >> +---------+-------------+---------------------- > >> > >> The capwap editors are currently working hard to produce the 01 > > > > version > > > >> of the capwap document, and it would be best for implementers if > > > > this > > > >> question could be decided prior to publication of that document. > > > > To > > > >> facilitate this, I've summarized briefly below. > >> > >> Using separate ports for control/data has a number of drawbacks: > >> > >> - if firewalls are between the AC and WTP, multiple rules are > >>required > >> > >> - we must be able to explicitly bind the data and control > >> channels > > > > at > > > >> the AC in order to ensure proper operation; if they use the same > > > > port > > > >> (and therefore, flow), this is straightforward; if not, we must > > > > add > > > >> protocol elements for detecting and accounting for NATs along > >> the > > > > AC-WTP > > > >> path, and for explicitly (and securely) creating the bindings > > > > between > > > >> the two channels > >> > >> - there are race conditions that must be dealt with; in > > > > particular, it > > > >> is possible to have the left hand (control channel) not knowing > > > > for > > > >> certain what the right hand (data channel) is doing (and vice > >>versa) > >> > >> - If there *are* NATs along the path, using two ports will require > >> keepalives on both ports, and error handling for when one > >> channel > > > > goes > > > >> away but the other does not (e.g. if a middlebox deletes the NAT > >> bindings for any reason) > >> > >> - there are many more error conditions to manage in the state > > > > machine, > > > >> due to the channel binding and NAT issues > >> > >> Clearly, using two ports adds *significant* complexity to the > >> implementation, and will likely result in operational problems > >> in > > > > some > > > >> environments. > >> > >> Using a mux header has one drawback (that I can think of): > >> > >> - it adds n bytes to the header. I'm tempted to say n will be 4 > > > > for > > > >> 32-bit alignment, but it could also be only 1 or 2 bytes, if > >> bits-on-the-wire overhead is an overriding concern. > >> > >> Using a mux hader has several advantages: > >> > >> - we get NAT traversal for free, by simply configuring the echo > > > > interval > > > >> to be smaller than the NAT binding lifetime for the path in > >>question > >> > >> - we only open one port through intermediate firewalls (and any > >> intermediate NATs) > >> > >> - the implementation (state machine, error handling) is *much* > > > > simpler, > > > >> and therefore more likely > >> to (inter)operate according to spec > >> > >> We need to decide on this, preferably within the next day or two. > >> Please > >> speak up and make your preferences known. > >> > >> 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 > >> > >> > >> > >>-------------------------------------------------------------------- > >>-- > >>-- > >> > >>_________________________________________________________________ > >>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 > ------------------------------ Message: 2 Date: Wed, 03 May 2006 15:25:48 -0700 From: Jim Murphy Subject: Re: =5BCapwap=5D BSSID-WLAN mappings To: =22T. Charles Clancy=22 Cc: capwap=40frascone.com Message-ID: <44592DEC.4030204=40trapezenetworks.com> Content-Type: text/plain; charset=3Dwindows-1252; format=3Dflowed T. Charles Clancy wrote: > Sort of... > > As I understand the conversation, in the M-SSID case, you could send > an encrypted broadcast packet to other people on your WLAN. This > packet would be encrypted with a key that other users on other WLANs > could know. For example, someone on WLAN-B could see NETBIOS broadcast > packets from devices associated to WLAN-A. They might even think they > could communicate with said NETBIOS machines, but unicast packets > addressed to them would fail (hopefully, assuming the WTP is properly implemented). > > Jim's scenario below is somewhat different, where you have someone on > the wired side sending data that CAPWAP intentionally decides should > be transmitted to multiple WLANs. The concern here is more along the > lines of a chosen ciphertext attack that could leak information about > keys by seeing packets encrypted multiple times with different keys. > Provided people are using good crypto (i.e. not WEP), this shouldn't be a = problem. > It doesn't matter if the packet originated on the wired side or not because = all broadcast packets from stations must be retransmitted by the AP. Yes, people should be using good crypto, but we should not limit the legitim= ate flexibility of the protocol to enforce it. Thanks, Jim > -- > t. charles clancy, ph.d. =7C tcc=40umd.edu =7C www.cs.umd.edu/=7Eclanc= y > > On Mon, 1 May 2006, Jim Murphy wrote: > >> Hi, >> >> Hasn't security already been compromised in CAPWAP by the fact that a >> data frame could be sent to multiple WLANs using the WLAN/Status >> field of the CAPWAP header? Each of these WLANs could be running a >> different crypto type. >> >> Thanks, >> >> Jim >> >> Bob O'Hara (boohara) wrote: >>> As I said, this is a proprietary extension, even if it might have >>> been provided on some Cisco products. I hold that CAPWAP is >>> chartered to implement a protocol to support 802.11, not the myriad >>> proprietary extension that have been hammered onto its side over the >>> years. >>> But, the more damning problem for this is the lowering of security >>> and the violation of the security assumptions on which 802.11i is >>> based. Crossing the boundary of a security domain, even if =22only=22 >>> for multicast, dramatically increases the opportunity for compromise >>> of data that communicants believe is secure. >>> >>> -Bob >>> >>> >>> -------------------------------------------------------------------- >>> ---- >>> *From:* Jeff Joslin =5Bmailto:jjoslin=40belairnetworks.com=5D >>> *Sent:* Friday, April 28, 2006 12:47 PM >>> *To:* Bob O'Hara (boohara); capwap=40frascone.com >>> *Subject:* RE: =5BCapwap=5D BSSID-WLAN mappings >>> >>> Indeed, the M-SSID mechanism I described is not in the standard but >>> has been implemented by a number of different vendors, including, as >>> I recall, Cisco Aironet. Now that 802.11 chip sets and drivers have >>> better support for M-BSSID, there is little reason to use the more >>> problematic M-SSID. Its only advantage over M-BSSID is that M-SSID >>> uses up fewer MAC addresses. >>> >>> >>> Jeff >>> >>> >>> -------------------------------------------------------------------- >>> ---- >>> >>> *From:* Bob O'Hara (boohara) =5Bmailto:boohara=40cisco.com=5D >>> *Sent:* 28 April 2006 3:35 PM >>> *To:* capwap=40frascone.com >>> *Subject:* RE: =5BCapwap=5D BSSID-WLAN mappings >>> >>> >>> The mechanism below is, of course, not compliant with the 802.11 >>> standard. It is a proprietary extension. It is not clear to me why >>> CAPWAP should support this mechanism, or any other proprietary >>> mechanism. As Jeff points out below, this is not compatible with >>> all clients (most likely because the mechanism is not mentioned in >>> the >>> standard) and also violates the security assumptions of 802.11. >>> >>> -Bob >>> >>> >>> >>> -------------------------------------------------------------------- >>> ---- >>> >>> *From:* Jeff Joslin =5Bmailto:jjoslin=40belairnetworks.com=5D >>> *Sent:* Friday, April 28, 2006 12:19 PM >>> *To:* capwap=40frascone.com >>> *Subject:* RE: =5BCapwap=5D BSSID-WLAN mappings >>> >>> You can implement multiple SSID with single BSSID by having only one >>> SSID in the beacon; the others SSIDs are hidden. If a client >>> broadcasts a probe for one of those hidden SSIDs the AP will respond >>> and the client can then do a normal association. The AP maintains >>> one broadcast/multicast key for each encryption type (WEP, TKIP, >>> AES) and uses the appropriate one according to the encryption type >>> of the frame's SSID. This allows a certain amount of information >>> leakage between SSIDs, but in most applications this is acceptable. >>> >>> >>> The above scheme works, after a fashion, but creates some client >>> compatibility issues. Multiple BSSID is preferable. >>> >>> >>> One SSID =3D=3D 1 WLAN. In general we cannot assume that 1 BSSID =3D=3D = 1 WLAN. >>> >>> >>> Perhaps 1 VLAN =3D=3D 1 WLAN is more helpful? It is standard practice to= >>> map each SSID to a separate VLAN. >>> >>> >>> Jeff Joslin >>> >>> Senior Network Architect >>> >>> BelAir Networks >>> >>> >>> -------------------------------------------------------------------- >>> ---- >>> >>> *From:* Pat Calhoun (pacalhou) =5Bmailto:pcalhoun=40cisco.com=5D >>> *Sent:* 28 April 2006 2:57 PM >>> *To:* Puneet; Bob O'Hara (boohara) >>> *Cc:* capwap=40frascone.com >>> *Subject:* RE: =5BCapwap=5D BSSID-WLAN mappings >>> >>> >>> Well, first, there is no way that I am aware of where you can have >>> multiple SSIDs for a single BSSID. Furthermore, if one were to do >>> this, how would you handle broadcast packet encryption, where a >>> station would see packets from a BSSID, but would not be able to >>> decrypt it - presumably because the AC would have multiple GTKs, not >>> indexed on a BSSID, but some other non-defined mechanism. >>> >>> >>> I contend 1 BSSID =3D=3D 1 WLAN. >>> >>> Pat Calhoun >>> CTO, Wireless Networking Business Unit Cisco Systems >>> >>> >>> >>> >>> ------------------------------------------------------------------------= >>> >>> *From:* Puneet =5Bmailto:pb.ietf=40gmail.com=5D >>> *Sent:* Monday, April 17, 2006 10:39 AM >>> *To:* Bob O'Hara (boohara) >>> *Cc:* capwap=40frascone.com >>> *Subject:* Re: =5BCapwap=5D BSSID-WLAN mappings >>> >>> Bob, >>> >>> > We should not be implementing, or requiring an CAPWAP >>> implementation to implement a method >>> > that lowers the security of the WLAN. >>> >>> I am not sure I understand the argument here: supporting open or WEP= >>> also does the same thing, but CAPWAP supports those encryption >>> protocols. CAPWAP does not force everyone to support WEP, but it >>> *allows* it to be setup on a WLAN. Along the same lines we should >>> allow this mapping too. Maybe make a note that it does not allow >>> WLAN traffic separation into logical groups over the air (Saravanans= >>> point) >>> >>> Thanks, >>> Puneet >>> >>> On 4/17/06, *Bob O'Hara (boohara)* >> > wrote: >>> >>> There are also security issues when there is not a 1:1 mapping of >>> WLAN to BSSID. Without this restriction, a station will not have >>> any assurance that traffic it believes is encrypted and protected >>> according to the policy of the WLAN to which it is associated is not= >>> being decrypted by an oracle (the AP) and rebroadcast to other >>> stations without the same requirements for abiding with the same >>> security policies. >>> >>> >>> We should not be implementing, or requiring an CAPWAP implementation= >>> to implement a method that lowers the security of the WLAN. >>> >>> -Bob >>> >>> >>> >>> >>> ------------------------------------------------------------------------= >>> >>> *From:* Puneet =5Bmailto: pb.ietf=40gmail.com >>> =5D >>> >>> *Sent:* Sunday, April 16, 2006 4:47 PM >>> *To:* Saravanan Govindan >>> *Cc:* capwap=40frascone.com >>> *Subject:* Re: =5BCapwap=5D BSSID-WLAN mappings >>> >>> Hi Saravanan, >>> >>> I see your point, but this seems to address a very specific >>> deployment scenario (service providers sharing WLAN equipment). If >>> nothing else in the CAPWAP messages is dependent on this, then this = >>> should be a recommendation instead of a mandate. That way the >>> protocol remains inclusive, and also meets its objective. >>> >>> I think it is very important that existing implementations are not >>> excluded just because they dont seem to meet one specific need in a = >>> specific deployment scenario. >>> >>> Thanks, >>> Puneet >>> >>> On 4/15/06, *Saravanan Govindan* >> > wrote: >>> >>> Hi Puneet, >>> >>> My concern regarding the BSSID - WLAN mapping is based on the >>> mandatory >>> Objective =22Logical Groups=22 (Section 5.1.1 of CAPWAP Objectives).= >>> >>> The Objective requires that WTP traffic be kept logically distinct >>> among >>> logical groups. This arises from the commercial need of service >>> providers >>> sharing WLAN infrastructure equipment. Service providers want their = >>> traffic >>> to be distinguished both over the wireless environment (e.g. BSSIDS)= >>> and >>> over the AC-WTP environment (e.g. WLANs). >>> >>> The BSSID-WLAN mapping issue is the technical requirement coming >>> from this >>> commercial need. It allows an AC - or WTP - to decide how logical >>> groups are >>> separated over the wireless and AC-WTP segments. So by making this >>> mapping, >>> CAPWAP frames of different logical groups (WLANs) can be distinctly = >>> exchanged. >>> >>> I agree with others that this mapping should not exclude any >>> implementation >>> - my concern is that the mapping be including in the first place. >>> >>> Cheers, >>> >>> Saravanan >>> >>> >>> >>> >>> > ------------------------------ >>> > *From:* Puneet =5Bmailto:pb.ietf=40gmail.com >>> =5D >>> > *Sent:* Friday, April 14, 2006 12:29 AM >>> > *To:* capwap=40frascone.com >>> > *Subject:* =5BCapwap=5D BSSID-WLAN mappings >>> > >>> > the BSSID description in Section 11.9.1 'WTP Radio Configuration'= >>> notes >>> > that a WTP that supports 16 WLANS MUST have 16 MAC addresses >>> reserved for >>> > it. Why? ie. what part of the protocol does not work if we have >>> multiple >>> > SSIDs on a single BSSID? (whether thats good design or bad is a >>> different >>> > matter). Since the WLAN ID could be used in all such places to >>> convey >>> WLAN >>> > information back to the AC, why do we need to mandate this 1:1 >>> BSSID-WLAN >>> > mapping? >>> > >>> > Thanks, >>> > Puneet >>> > >>> > _________________________________________________________________= >>> > To unsubscribe or modify your subscription options, please visit:= >>> > http://lists.frascone.com/mailman/listinfo/capwap >>> >>> > >>> > Archives: http://lists.frascone.com/pipermail/capwap >>> > >>> >>> _________________________________________________________________ >>> Get an advanced look at the new version of MSN Messenger. >>> http://messenger.msn.com.sg/Beta/Default.aspx >>> >>> >>> >>> >>> _________________________________________________________________ >>> 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 >> ------------------------------ Message: 3 Date: Wed, 3 May 2006 16:19:03 -0700 From: =22Dorothy Stanley=22 Subject: Re: =5BCapwap=5D Re: Issues 101: 11.8.1.1 Change to re-use 802.11 Information element definitions To: Puneet Cc: capwap=40frascone.com Message-ID: <5bfe7a820605031619h4889f616wa3ed19737c2cf60f=40mail.gmail.com> Content-Type: text/plain; charset=3D=22iso-8859-1=22 Puneet, all, > 2. for the encryption policies we could use the format used in > the RSN IEs (OUI + encryption_type); that allows support for different > vendor specific encryption types in a clean manner (CKIP for example > would then use the Cisco OUI, instead of being clubbed together with the > other 'standard' encryption types; and it makes it easier for vendors to > not step on each others toes). Agree that this approach should be used to indicate ciphersto use. This IE is used to add a WLAN (BSS) on the WTP (also one for Update WLAN). Why is delivering the RSNIE/WPAIE not enough here - since the group key cipher is indicated in those IEs? Suggest deleting the encryption = policy field in the IEEE 802.11 Add WLAN and Update WLAN message elements. Separately, the encryption policy in the IEEE Mobile Session Key message element should be updated to use the RSNIE format. Dorothy On 5/3/06, Puneet wrote: > > > 1. does the encryption policy refer to broadcast traffic or > > unicast too? If its also unicast, then there could be multiple > > encryption types enabled at the same type on the WLAN, in that case how = > > is the encryption-policy field filled in? > > > > > > This is a good question as the text is obviously not clear enough. I am = > > proposing the following text (as well as for the Update WLAN section): > > > > Encryption Policy: A 32-bit value specifying the encryption scheme > > to apply to traffic to and from the mobile station. > > this might also be a good place to note that the format of those 32 > bits is the same as what the IEEE 802.11i specification mentions. That > allows vendor specific encryption types, and can also be updated by > IEEE for new types without having to update the CAPWAP specification. > > > 2. for the encryption policies we could use the format used in > > the RSN IEs (OUI + encryption_type); that allows support for different > > vendor specific encryption types in a clean manner (CKIP for example > > would then use the Cisco OUI, instead of being clubbed together with the= > > other 'standard' encryption types; and it makes it easier for vendors to= > > not step on each others toes). > > > > > > Based on Dorothy's e-mail and recommendation, I would propose the > > following new section: > > > > 11.8.1.4. IEEE 802.11 Information Element > > > > The IEEE 802.11 Information Element is used to communicate any IE > > defined in the IEEE 802.11 protocol. The data field contains the raw= > > IE as it would be included within an IEEE 802.11 MAC management > > message. > > > > I think my request was to change the encryption-type to use the IEEE > 802.11i format, but thats now what this element seems to do. Can we > replace those list of numbers 1,2,3,4,5 for encryption types since in > the current text they mix standard and vendor specific types, and if > IEEE updates something in 802.11i, we'll need to update the capwap > spec again. > > > 4. Does the 'Suppress SSID' field also disable the use of that > > SSID in broadcast probe responses? If so, why do we also need the 'IEEE = > > 802.11 Broadcast Probe Mode' in section 11.9.12? Also, why is this IE > > global for the WTP? The AC might configure the WTP with 10 WLANs, but it= > > may want probe responses generated for only four of those when a > > broadcast probe request comes in. > > > > Section 11.9.12 deals with the changing of the mode of operation > > after the WLAN is already operational. > > I still dont understand why this needs to be global. To quote the current = > draft: > =22Since broadcast NULL probes are not sent to a specific BSSID, the WTP > cannot know > which SSID the sending station is querying. Therefore, this behavior > must be global > to the WTP.=22 > However when a broadcast probe request comes in, of all the WLANs > mapped to that WTP, the user should be able to configure which ones > are responded to. That text seems incorrect. > > Thanks, > Puneet > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.tigertech.net/pipermail/capwap/attachments/20060503/109b5034/at= tach ment.htm ------------------------------ _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap End of Capwap Digest, Vol 7, Issue 15 ************************************* ----344510-7129147-1017340393=:3379 Content-Type: text/plain Content-Disposition: inline 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. ----344510-7129147-1017340393=:3379 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 ----344510-7129147-1017340393=:3379-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu May 04 10:08:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbeVU-0002Xm-FC for capwap-archive@lists.ietf.org; Thu, 04 May 2006 10:08:40 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbeVT-00054u-6y for capwap-archive@lists.ietf.org; Thu, 04 May 2006 10:08:40 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BD6C2430100 for ; Thu, 4 May 2006 07:08:38 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 949FC430067 for ; Thu, 4 May 2006 07:07:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7A0441448037 for ; Thu, 4 May 2006 07:07:50 -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 E04A01448003 for ; Thu, 4 May 2006 07:07:47 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id h30so333599wxd for ; Thu, 04 May 2006 07:07:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=eLdxmQvn04r0JfRBZZX1P5HhauFrQadiX15AAfFw924MAZiMHJQTMF/caS595etL0bkgaGsHmShzLWNo+sLRtdvdrepnCeTRVul8d/IrbzNlEQ7ECxK6cLd4C2mA01F8smZTKEaAv3mwNLyUQ0JdcII7tcDUv4s95XRhgNk0MFg= Received: by 10.70.18.7 with SMTP id 7mr320849wxr; Thu, 04 May 2006 07:07:47 -0700 (PDT) Received: by 10.70.6.8 with HTTP; Thu, 4 May 2006 07:07:46 -0700 (PDT) Message-ID: <5bfe7a820605040707j687f9a42w181b0272b4dc3a79@mail.gmail.com> Date: Thu, 4 May 2006 07:07:46 -0700 From: "Dorothy Stanley" To: "Saravanan Govindan" Subject: Re: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages In-Reply-To: <5F09D220B62F79418461A978CA0921BDD52CC0@pslexc01.psl.local> MIME-Version: 1.0 References: <5F09D220B62F79418461A978CA0921BDD52CC0@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.7 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_40_50, HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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="===============1726429309==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.7 (/) X-Scan-Signature: 8b46f883d051ec9bb02ad32011a213d1 --===============1726429309== Content-Type: multipart/alternative; boundary="----=_Part_43341_22733502.1146751666918" ------=_Part_43341_22733502.1146751666918 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Saravanan, There is no statistics control packet defined. There is an 802.11 Statistic= s message element, and we can add CAPWAP statistics, but these statistics message elements would be carried in the WTP Event message. So, it sounds like your proposal is to use just Echo Request and WTP Event Request messages? It seems that we are already above 1 message to consider. Dorothy On 5/3/06, Saravanan Govindan wrote: > > Hi Dorothy, > > > > I suggest that the Echo Request MAY only be send in the absence of > specifically Statistics control packets as opposed to any control packets= . > The reason for this is that Statistics packets are the only regular > exchanges, so the AC has just one type of packet to monitor for the timer= . > > > > So I'd like to suggest the following text: > > > > From: > > "If another Echo Request or other control message is not received by the > AC when the timer expires, the AC > > SHOULD consider the WTP to be unreachable" > > > > To: > > "If another Echo Request or Statistics message is not received by the AC > when the timer expires, the AC > > SHOULD consider the WTP to be unreachable" > > > > Cheers, > > > Saravanan > > > > > > > > > > > ------------------------------ > > *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] > *Sent:* Thursday, May 04, 2006 3:03 AM > > *To:* Pat Calhoun (pacalhou) > *Cc:* Scott G Kelly; Saravanan Govindan; capwap > *Subject:* Re: [Capwap] Proposed Resolution to Issue 45 > -Issueoncombiningmessages > > > > All, > > After the lengthy discussion on this topic, I believe that the conclusion > is > still to reject the comment, and as Pat summarized, the echo remains, doe= s > not include any > statistics, and MAY only be sent in the absence of any control packets. > > Changes to the text: > > Change text in 6.2" Echo Response" from: > "If another Echo Request message is not received by the AC when the timer > expires, the AC > SHOULD consider the WTP to be unreachable" to > > "If another Echo Request or other control message is not received by the > AC when the timer expires, the AC > SHOULD consider the WTP to be unreachable" > > and from > > "If the NeighborDeadInterval timer expires prior to receiving an Echo > Response message, > message, the WTP enters the Reset State." > to > "If the NeighborDeadInterval timer expires prior to receiving an Echo > Response message, or other control > message, the WTP enters the Reset State." > > > Thanks, > > Dorothy > > Issue 45, Issue on Combining messages currently has the following > discussion in the issues database: > > Currently, the keepalive and statistics messages are separated. Separate > > messages for keepalive signaling and statistics can lead to high overhead= . > > Initial analysis have shown that these overhead can be reduced significan= tly > > > > > > if the messages can be combined. > > > > Recommendation: > > > > To combine the keepalive and statistics message into one combined message= , > > thus reducing overhead significantly. > > > Discussion: > > The CAPWAP protocol specification currently supports the > Echo Request Message and Echo Response Messages, which are used for > keep-alive > purposes, and do not carry message elements. > > There is an IEEE 802.11 Statistics measurement element(11.7.2.1), and > several CAPWAP statistics related > measurement elements: decryption error report, WTP descriptor, WTP radio > information, WTP reboot statistics. > There is no statistics message. > > There is no requirement on how often the statistics related measurement > elements must be reported > to the AC from the WTP, there is a Statistics timer, see 7.2.5, which is > used by the AC to indicate the > timer value to the WTP. (separate question - should the statistics timer > be made general, and indicate the > values for the other Section 12 CAPWAP timers too? Assume that the CAPWA= P > statistics timer used > to determine how often to send the 802.11 specific statistics). > > It is not clear that there is a high overhead in keeping the > echo/keep-alive mechanism from > the statistics reporting. There is some benefit in keeping the echo > messages simple, > rather than complicating the processing of those messages. It is true > that small messages (echo request, response) have high overhead. > In this case, the design choice is to accept the overhead as the cost of > simplicity in design and implementation. > > Recommended resolution: reject the comment, with the explanation in the > above paragraph > > On 4/28/06, *Pat Calhoun (pacalhou)* < pcalhoun@cisco.com> wrote: > > I will summarize my thoughts here and not try to inject in the various > threads, but I agree that the echo remains, does not include any > statistics, and MAY only be sent in the absence of any control packets. > I say MAY because an implementation could send them if it wishes, but > the receiver must take into account control packets in addition to the > echo prior to declaring a link dead. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Scott G Kelly [mailto: scott@hyperthought.com] > > Sent: Friday, April 21, 2006 5:52 AM > > To: Saravanan Govindan > > Cc: capwap > > Subject: Re: [Capwap] Proposed Resolution to Issue 45 > > -Issueoncombiningmessages > > > > Hi Saravanan, > > > > Saravanan Govindan wrote: > > > Hi Scott, > > > > > > I think David's note does address the issue on hand. > > > > > > To formalize; > > > > > > The exchange of control messages between a WTP and AC implicitly > > > indicates that the WTP is operational. For the purpose of protocol > > > simplicity, I suggest that we focus on statistics messages > > alone for > > > this purpose, reason being that statistics are periodically > > exchanged. > > > > > > My concern is that by using "any" control message to indicate > > > keepalive (Echo), the AC processing will be complicated. This is > > > because the AC will need to process each control message > > for both its own value (e.g. > > > Configure Request) and also keepalive value. > > > > Of course, complexity is a function of many factors, but > > there is a straightforward way to implement an echo trigger > > with a flag and timer: > > when you receive a control message, unconditionally raise the flag. > > Periodically (according to your keepalive interval timer) > > check the flag; If it's up, put it down, else send a > > keepalive. There are more complicated ways to implement, but > > this works just fine. > > > > On the AC this can easily be implemented by having the > > fastpath raise the flag, and having the cp lower it and/or do > > whatever it is your AC does if a WTP doesn't report in a > > given echo interval (which may be nothing). Pretty basic stuff. > > > > On the WTP, implementation is similar, except that if the > > flag is down, you send the keepalive. Again, very simple and basic. > > > > > So I suggest keeping it simple - arrival of statistics message from > > > WTP means WTP is alive. > > > > Certainly, a statistics message qualifies as a control > > message, so I have no issues with this statement when taken > > alone. I'm concerned with the earlier suggestion that the > > echo req/reply message be discarded and replaced by the > > statistics message. > > > > In some cases, the keepalive interval must be *very* brief in > > order to facilitate rapid link loss detection and recovery. I > > know of one vendor who routinely uses a one second interval, > > and it's conceivable that in some scenarios one might choose > > to use even less. > > > > And keep in mind that WTP and AC requirements are typically > > asymmetric in this regard: the WTP needs to react quickly > > (maybe try to find another AC), whereas the AC simply needs > > to somehow report the event. > > While in some cases reporting might be considered urgent, > > this is not the typical (or average) case. > > > > The granularity requirements for reporting are typically much > > coarser than those of recovery. That is, the AC may, at it's > > option, only check every 10,20,30,... seconds for WTP > > liveness, and it may very well do that via the stats message, > > rather than the echo, since this allows echo processing to > > remain wholly in the AC fastpath. > > > > But say we eliminate the echo: what happens when, say, 500 > > WTPs send stats potentially every second or less? > > > > I think we still need the echo req/rsp. > > > > Scott > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > > > Sent: Wednesday, April 19, 2006 1:51 AM > > > To: capwap > > > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > > > -Issueoncombiningmessages > > > > > > Just trying to close the loop: I think David's point (i.e. > > that echoes > > > should only be sent in the absence of other control > > traffic) is dead > > > on, and that this effectively closes the question as to > > whether echoes > > > and stats should be combined in the same messages. > > > > > > Does anyone disagree? > > > > > > 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_43341_22733502.1146751666918 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Saravanan,

There is no statistics control packet defined. There is an 802.11 Statistic= s message element, and we can add CAPWAP
statistics, but these statistics message elements would be carried in the W= TP Event message.

So, it sounds like your proposal is to use just Echo Request and WTP Event = Request messages? It seems that
we are already above 1 message to consider.

 Dorothy

On 5/3/06, Saravanan Govindan <Saravanan.Govindan@sg.panasonic.com> wr= ote:

Hi Dorothy,

 

I suggest that the Echo Request MAY only be send in the absence of specifically Statistics control packets as opposed to any contro= l packets. The reason for this is that Statistics packets are the only regula= r exchanges, so the AC has just one type of packet to monitor for the timer. =

 

So I'd like to suggest the following text:

 

From:

"If another Echo Request or other control message is not received by the AC when the timer expires, the AC


SHOULD consider the WTP to be unreachable"

 

To:

"If another Echo Request or Statistics message is not received by the AC when the timer expires, the AC


SHOULD consider the WTP to be unreachable"

 

All,

After the lengthy discussion on this topic, I believe that the conclusion i= s
still to reject the comment, and as Pat summarized, the echo remains, does = not include any
statistics, and MAY only be sent in the absence of any control packets.
Changes to the text:

Change text in 6.2" Echo Response" from:
"If another Echo Request message is not received by the AC when the ti= mer expires, the AC
SHOULD consider the WTP to be unreachable" to

"If another Echo Request or other control message is not received by t= he AC when the timer expires, the AC
SHOULD consider the WTP to be unreachable"

and from

"If the NeighborDeadInterval timer expires prior to receiving an Echo Response message,
message, the WTP enters the Reset State."
to
"If the NeighborDeadInterval timer expires prior to receiving an Echo = Response message, or other control
message, the WTP enters the Reset State."


Thanks,

Dorothy

Issue 45, Issue on Combining messages currently has the following discussion in the issues database: 

Currently, the keepalive and statistics messages are separated. Separate <=
br>
messages for keepalive signaling and statistics can lead to high ove=
rhead.=20


Initial analysis have shown that these overhead can be reduced sign=
ificantly 




if the messages can be combi=
ned.




Recommendation:



To combine the keepalive and=
 statistics message into one combined message, 

thus reducing overhe=
ad significantly.


Discussion:

The CAPWAP protocol specification currently supports the
Echo Request Message and Echo Response Messages, which are used for keep-al= ive
purposes, and do not carry message elements.

There is an IEEE 802.11 Statistics measurement element(11.7.2.1), and several CAPWAP statistics related
measurement elements: decryption error report, WTP descriptor, WTP radio information, WTP reboot statistics.
There is no statistics message.

There is no requirement on how often the statistics related measurement elements must be reported
to the AC from the WTP, there is a Statistics timer, see 7.2.5, which is us= ed by the AC to indicate the
timer value to the WTP. (separate question - should the statistics timer be made general, and indicate the
values for the other Section 12 CAPWAP timers too?  Assume that the CA= PWAP statistics timer used
to determine how often to send the 802.11 specific statistics).

It is not clear that there is a high overhead in keeping the echo/keep-aliv= e mechanism from
the statistics reporting. There is some benefit in keeping the echo message= s simple,
rather than complicating the processing of those messages.  It is true that small messages (echo request, response) have high overhead.
In this case, the design choice is to accept the overhead as the cost of simplicity in design and implementation.

Recommended resolution: reject the comment, with the explanation in the abo= ve paragraph

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

I will summarize my thoughts here and not try to inject in the various <= br> threads, but I agree that the echo remains, does not include any
statistics, and MAY only be sent in the absence of any control packets.
I say MAY because an implementation could send them if it wishes, but
the receiver must take into account control packets in addition to the
echo prior to declaring a link dead.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems



> -----Original Message-----
> From: Scott G Kelly [mailto: scott@hyperthought.com]
> Sent: Friday, April 21, 2006 5:52 AM
> To: Saravanan Govindan
> Cc: capwap
> Subject: Re: [Capwap] Proposed Resolution to Issue 45
> -Issueoncombiningmessages
>
> Hi Saravanan,
>
> Saravanan Govindan wrote:
> > Hi Scott,
> >
> > I think David's note does address the issue on hand.
> >
> > To formalize;
> >
> > The exchange of control messages between a WTP and AC implicitly<= br> > > indicates that the WTP is operational. For the purpose of protoco= l
> > simplicity, I suggest that we focus on statistics messages
> alone for
> > this purpose, reason being that statistics are periodically
> exchanged.
> >
> > My concern is that by using "any" control message to indicate
> > keepalive (Echo), the AC processing will be complicated. This is =
> > because the AC will need to process each control message
> for both its own value (e.g.
> > Configure Request) and also keepalive value.
>
> Of course, complexity is a function of many factors, but
> there is a straightforward way to implement an echo trigger
> with a flag and timer:
> when you receive a control message, unconditionally raise the flag. > Periodically (according to your keepalive interval timer)
> check the flag; If it's up, put it down, else send a
> keepalive. There are more complicated ways to implement, but
> this works just fine.
>
> On the AC this can easily be implemented by having the
> fastpath raise the flag, and having the cp lower it and/or do
> whatever it is your AC does if a WTP doesn't report in a
> given echo interval (which may be nothing). Pretty basic stuff.
>
> On the WTP, implementation is similar, except that if the
> flag is down, you send the keepalive. Again, very simple and basic. >
> > So I suggest keeping it simple - arrival of statistics message fr= om
> > WTP means WTP is alive.
>
> Certainly, a statistics message qualifies as a control
> message, so I have no issues with this statement when taken
> alone. I'm concerned with the earlier suggestion that the
> echo req/reply message be discarded and replaced by the
> statistics message.
>
> In some cases, the keepalive interval must be *very* brief in
> order to facilitate rapid link loss detection and recovery. I
> know of one vendor who routinely uses a one second interval,
> and it's conceivable that in some scenarios one might choose
> to use even less.
>
> And keep in mind that WTP and AC requirements are typically
> asymmetric in this regard: the WTP needs to react quickly
> (maybe try to find another AC), whereas the AC simply needs
> to somehow report the event.
> While in some cases reporting might be considered urgent,
> this is not the typical (or average) case.
>
> The granularity requirements for reporting are typically much
> coarser than those of recovery. That is, the AC may, at it's
> option, only check every 10,20,30,... seconds for WTP
> liveness, and it may very well do that via the stats message,
> rather than the echo, since this allows echo processing to
> remain wholly in the AC fastpath.
>
> But say we eliminate the echo: what happens when, say, 500
> WTPs send stats potentially every second or less?
>
> I think we still need the echo req/rsp.
>
> Scott
>
> >
> > Saravanan
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com]
> > Sent: Wednesday, April 19, 2006 1:51 AM
> > To: capwap
> > Subject: RE: [Capwap] Proposed Resolution to Issue 45
> > -Issueoncombiningmessages
> >
> > Just trying to close the loop: I think David's point (i.e.
> that echoes
> > should only be sent in the absence of other control
> traffic) is dead
> > on, and that this effectively closes the question as to
> whether echoes
> > and stats should be combined in the same messages.
> >
> > Does anyone disagree?
> >
> > Scott
> >
> >
> > _________________________________________________________________=
> > To unsubscribe or modify your subscription options, please visit:=
> > htt= p://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://lis= ts.frascone.com/pipermail/capwap

 


------=_Part_43341_22733502.1146751666918-- --===============1726429309== 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 --===============1726429309==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu May 04 10:20:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbehD-00081h-3M for capwap-archive@lists.ietf.org; Thu, 04 May 2006 10:20:47 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbehA-0005Jh-PV for capwap-archive@lists.ietf.org; Thu, 04 May 2006 10:20:47 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 531AB4300A4 for ; Thu, 4 May 2006 07:20:44 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id DC80E4300A5 for ; Thu, 4 May 2006 07:19:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id CCE1739801F for ; Thu, 4 May 2006 07:19:59 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id AE93D39800E for ; Thu, 4 May 2006 07:19:56 -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 k44EJtIG029071; Thu, 4 May 2006 07:19:55 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k44EJrPI029065; Thu, 4 May 2006 07:19:53 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 4 May 2006 07:19:53 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Kraus, Michael" Subject: Re: [Capwap] to mux or not to mux? In-Reply-To: <89525CB1203D7346BBBDFCE9CECB47CF0222E882@STLEXGUSR31.abc.corp.anheuser-busch.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 8f864d073635f9dbbfb1a859082fbfac HI, Since UDP is being used, why cannot the data traffic packets be marked with a different QoS values than control traffic packets. Would you explain and provide an example of use of "current QoS tools". Regards, /david t. perkins On Thu, 4 May 2006, Kraus, Michael wrote: > One additional upside to using separate ports would be that different QoS > policies can be applied against data/control data. With mux values, this would > be more difficult to accomplish with current QoS tools. With 802.11n data rates > being quoted, having the ability to do some "control plane policing" for the > APs, might be advantageous. > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 3 May 2006 15:16:21 -0700 (PDT) > From: "David T. Perkins" > Subject: Re: [Capwap] to mux or not to mux? > To: Charles Clancy > Cc: capwap > Message-ID: > > Content-Type: TEXT/PLAIN; charset=US-ASCII > > HI, > > Please don't forget about the discovery message. With it, you have 3 values for > MUX. See below.. > > Also, please note that in the prototype that I'm developing, I'm using the > UNMODIFIED DTLS implementation in openSSL. > That is, adding the MUX header does not require any modification of the openSSL. > By the way,my two wishes are: > 1) an Ethereal decode for the below > 2) the addition of the NULL encryption type to the > CAPWAP protocol for debugging > > On Wed, 3 May 2006, Charles Clancy wrote: > > The DTLS tunnels would NOT be merged. You'd have something like: > > +---------+------------+------------------------ > | UDP hdr | MUX = 0x00 | Discovery Request or Response > +---------+------------+----------- > > > > +---------+------------+------------------------ > > | UDP hdr | MUX = 0x01 | DTLS(CAPWAP Control) > > +---------+------------+----------- > > > > or > > > > +---------+------------+------------------------ > > | UDP hdr | MUX = 0x02 | CAPWAP Data > > +---------+------------+----------- > > > > UDP is indeed a MUX header, but it's a MUX header that everything > > already understands. So, it all comes down to whether or not we want > > intermediate network devices to distinguish between control and data. > > For NAT traversal, it's easier if the NAT treats everything the same, > > and doesn't have to know that the two ports are related. Same for > > firewall / port forwarding. I think intermediate network devices > > should treat everything as "CAPWAP", and we should therefore do our own MUX. > > > > -- > > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > > > Nancy Winget (ncamwing) wrote: > > > Charles, > > > > > > With a MUX, yes they are logical channels, but I believe the > > > implication is that these channels are merged into a single DTLS > > > tunnel...are you saying they are not? > > > > > > But as you state, if UDP is a MUX header, why the need to introduce > > > yet another one instead of just using UDP for separation? > > > > > > Nancy. > > > > > > -----Original Message----- > > > From: Charles Clancy [mailto:clancy@cs.umd.edu] > > > Sent: Wednesday, May 03, 2006 2:29 PM > > > To: Michael Montemurro > > > Cc: Nancy Winget (ncamwing); capwap > > > Subject: Re: [Capwap] to mux or not to mux? > > > > > > Even with the MUX header, you have two independent, logical channels. > > > If you think about it, UDP is really just one big MUX header. What > > > we're doing is really nothing different. It should not impact > > > anything to do with sequence numbers or key derivation. > > > > > > -- > > > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > > > > > Michael Montemurro wrote: > > > > > >>Nancy brings up an interesting point here. > > >> > > >>If we go with the MUX header approach, how do we achieve key > > >>separation between the control and data channels? > > >> > > >>How do we derive the keys and how do we maintain sequence counters. > > >> > > >>Cheers, > > >> > > >> Mike > > >> > > >> > > >> > > >> > > >>On 5/2/06, *Nancy Winget (ncamwing)* > >>> wrote: > > >> > > >> > > >> I don't believe adding a MUX is the right answer. First, the > > > > > > addition > > > > > >> is a change in DTLS and also brings up other issues of concern: > > >> - distinguishing the control from data plane is a good thing as > > > > > > the > > > > > >> firewall rules may be different for each plane which is already > > >> addressed by the UDP assignments. > > >> - merging the control and data plane into a single UDP (dtls) > > > > > > tunnel > > > > > >> forces the two planes to be synchronized from an anti-replay > > >> perspective. This effectively restricts the architecture to > > >> force > > > > > > them > > > > > >> to use a centralized DTLS encapsulation/decapsulation which imho > > > > > > is too > > > > > >> restrictive > > >> > > >> Nancy. > > >> > > >> -----Original Message----- > > >> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com > > >> ] > > >> Sent: Monday, May 01, 2006 11:38 AM > > >> To: capwap > > >> Subject: [Capwap] to mux or not to mux? > > >> > > >> Some time ago, I proposed that we use a single port for capwap, > > > > > > and > > > > > >> insert a mux header right after the UDP header to differentiate > > > > > > between > > > > > >> control and data. While there was some discussion, we did not > > > > > > reach a > > > > > >> conclusion. > > >> > > >> Here's what it would look like: > > >> > > >> +---------+-------------+------------------------------- > > >> | UDP Hdr | MUX Hdr = 1 | DTLS Enc Control Packet .... > > >> +---------+-------------+---------------------- > > >> > > >> The capwap editors are currently working hard to produce the 01 > > > > > > version > > > > > >> of the capwap document, and it would be best for implementers if > > > > > > this > > > > > >> question could be decided prior to publication of that document. > > > > > > To > > > > > >> facilitate this, I've summarized briefly below. > > >> > > >> Using separate ports for control/data has a number of drawbacks: > > >> > > >> - if firewalls are between the AC and WTP, multiple rules are > > >>required > > >> > > >> - we must be able to explicitly bind the data and control > > >> channels > > > > > > at > > > > > >> the AC in order to ensure proper operation; if they use the same > > > > > > port > > > > > >> (and therefore, flow), this is straightforward; if not, we must > > > > > > add > > > > > >> protocol elements for detecting and accounting for NATs along > > >> the > > > > > > AC-WTP > > > > > >> path, and for explicitly (and securely) creating the bindings > > > > > > between > > > > > >> the two channels > > >> > > >> - there are race conditions that must be dealt with; in > > > > > > particular, it > > > > > >> is possible to have the left hand (control channel) not knowing > > > > > > for > > > > > >> certain what the right hand (data channel) is doing (and vice > > >>versa) > > >> > > >> - If there *are* NATs along the path, using two ports will require > > >> keepalives on both ports, and error handling for when one > > >> channel > > > > > > goes > > > > > >> away but the other does not (e.g. if a middlebox deletes the NAT > > >> bindings for any reason) > > >> > > >> - there are many more error conditions to manage in the state > > > > > > machine, > > > > > >> due to the channel binding and NAT issues > > >> > > >> Clearly, using two ports adds *significant* complexity to the > > >> implementation, and will likely result in operational problems > > >> in > > > > > > some > > > > > >> environments. > > >> > > >> Using a mux header has one drawback (that I can think of): > > >> > > >> - it adds n bytes to the header. I'm tempted to say n will be 4 > > > > > > for > > > > > >> 32-bit alignment, but it could also be only 1 or 2 bytes, if > > >> bits-on-the-wire overhead is an overriding concern. > > >> > > >> Using a mux hader has several advantages: > > >> > > >> - we get NAT traversal for free, by simply configuring the echo > > > > > > interval > > > > > >> to be smaller than the NAT binding lifetime for the path in > > >>question > > >> > > >> - we only open one port through intermediate firewalls (and any > > >> intermediate NATs) > > >> > > >> - the implementation (state machine, error handling) is *much* > > > > > > simpler, > > > > > >> and therefore more likely > > >> to (inter)operate according to spec > > >> > > >> We need to decide on this, preferably within the next day or two. > > >> Please > > >> speak up and make your preferences known. > > >> > > >> 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 > > >> > > >> > > >> > > >>-------------------------------------------------------------------- > > >>-- > > >>-- > > >> > > >>_________________________________________________________________ > > >>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 > > > > > > ------------------------------ > > Message: 2 > Date: Wed, 03 May 2006 15:25:48 -0700 > From: Jim Murphy > Subject: Re: [Capwap] BSSID-WLAN mappings > To: "T. Charles Clancy" > Cc: capwap@frascone.com > Message-ID: <44592DEC.4030204@trapezenetworks.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > > > T. Charles Clancy wrote: > > Sort of... > > > > As I understand the conversation, in the M-SSID case, you could send > > an encrypted broadcast packet to other people on your WLAN. This > > packet would be encrypted with a key that other users on other WLANs > > could know. For example, someone on WLAN-B could see NETBIOS broadcast > > packets from devices associated to WLAN-A. They might even think they > > could communicate with said NETBIOS machines, but unicast packets > > addressed to them would fail (hopefully, assuming the WTP is properly > implemented). > > > > Jim's scenario below is somewhat different, where you have someone on > > the wired side sending data that CAPWAP intentionally decides should > > be transmitted to multiple WLANs. The concern here is more along the > > lines of a chosen ciphertext attack that could leak information about > > keys by seeing packets encrypted multiple times with different keys. > > Provided people are using good crypto (i.e. not WEP), this shouldn't be a > > problem. > > > > It doesn't matter if the packet originated on the wired side or not because all > broadcast packets from stations must be retransmitted by the AP. > > Yes, people should be using good crypto, but we should not limit the legitimate > flexibility of the protocol to enforce it. > > Thanks, > > Jim > > > -- > > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > > > On Mon, 1 May 2006, Jim Murphy wrote: > > > >> Hi, > >> > >> Hasn't security already been compromised in CAPWAP by the fact that a > >> data frame could be sent to multiple WLANs using the WLAN/Status > >> field of the CAPWAP header? Each of these WLANs could be running a > >> different crypto type. > >> > >> Thanks, > >> > >> Jim > >> > >> Bob O'Hara (boohara) wrote: > >>> As I said, this is a proprietary extension, even if it might have > >>> been provided on some Cisco products. I hold that CAPWAP is > >>> chartered to implement a protocol to support 802.11, not the myriad > >>> proprietary extension that have been hammered onto its side over the > >>> years. > >>> But, the more damning problem for this is the lowering of security > >>> and the violation of the security assumptions on which 802.11i is > >>> based. Crossing the boundary of a security domain, even if "only" > >>> for multicast, dramatically increases the opportunity for compromise > >>> of data that communicants believe is secure. > >>> > >>> -Bob > >>> > >>> > >>> -------------------------------------------------------------------- > >>> ---- > >>> *From:* Jeff Joslin [mailto:jjoslin@belairnetworks.com] > >>> *Sent:* Friday, April 28, 2006 12:47 PM > >>> *To:* Bob O'Hara (boohara); capwap@frascone.com > >>> *Subject:* RE: [Capwap] BSSID-WLAN mappings > >>> > >>> Indeed, the M-SSID mechanism I described is not in the standard but > >>> has been implemented by a number of different vendors, including, as > >>> I recall, Cisco Aironet. Now that 802.11 chip sets and drivers have > >>> better support for M-BSSID, there is little reason to use the more > >>> problematic M-SSID. Its only advantage over M-BSSID is that M-SSID > >>> uses up fewer MAC addresses. > >>> > >>> > >>> Jeff > >>> > >>> > >>> -------------------------------------------------------------------- > >>> ---- > >>> > >>> *From:* Bob O'Hara (boohara) [mailto:boohara@cisco.com] > >>> *Sent:* 28 April 2006 3:35 PM > >>> *To:* capwap@frascone.com > >>> *Subject:* RE: [Capwap] BSSID-WLAN mappings > >>> > >>> > >>> The mechanism below is, of course, not compliant with the 802.11 > >>> standard. It is a proprietary extension. It is not clear to me why > >>> CAPWAP should support this mechanism, or any other proprietary > >>> mechanism. As Jeff points out below, this is not compatible with > >>> all clients (most likely because the mechanism is not mentioned in > >>> the > >>> standard) and also violates the security assumptions of 802.11. > >>> > >>> -Bob > >>> > >>> > >>> > >>> -------------------------------------------------------------------- > >>> ---- > >>> > >>> *From:* Jeff Joslin [mailto:jjoslin@belairnetworks.com] > >>> *Sent:* Friday, April 28, 2006 12:19 PM > >>> *To:* capwap@frascone.com > >>> *Subject:* RE: [Capwap] BSSID-WLAN mappings > >>> > >>> You can implement multiple SSID with single BSSID by having only one > >>> SSID in the beacon; the others SSIDs are hidden. If a client > >>> broadcasts a probe for one of those hidden SSIDs the AP will respond > >>> and the client can then do a normal association. The AP maintains > >>> one broadcast/multicast key for each encryption type (WEP, TKIP, > >>> AES) and uses the appropriate one according to the encryption type > >>> of the frame's SSID. This allows a certain amount of information > >>> leakage between SSIDs, but in most applications this is acceptable. > >>> > >>> > >>> The above scheme works, after a fashion, but creates some client > >>> compatibility issues. Multiple BSSID is preferable. > >>> > >>> > >>> One SSID == 1 WLAN. In general we cannot assume that 1 BSSID == 1 WLAN. > >>> > >>> > >>> Perhaps 1 VLAN == 1 WLAN is more helpful? It is standard practice to > >>> map each SSID to a separate VLAN. > >>> > >>> > >>> Jeff Joslin > >>> > >>> Senior Network Architect > >>> > >>> BelAir Networks > >>> > >>> > >>> -------------------------------------------------------------------- > >>> ---- > >>> > >>> *From:* Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > >>> *Sent:* 28 April 2006 2:57 PM > >>> *To:* Puneet; Bob O'Hara (boohara) > >>> *Cc:* capwap@frascone.com > >>> *Subject:* RE: [Capwap] BSSID-WLAN mappings > >>> > >>> > >>> Well, first, there is no way that I am aware of where you can have > >>> multiple SSIDs for a single BSSID. Furthermore, if one were to do > >>> this, how would you handle broadcast packet encryption, where a > >>> station would see packets from a BSSID, but would not be able to > >>> decrypt it - presumably because the AC would have multiple GTKs, not > >>> indexed on a BSSID, but some other non-defined mechanism. > >>> > >>> > >>> I contend 1 BSSID == 1 WLAN. > >>> > >>> Pat Calhoun > >>> CTO, Wireless Networking Business Unit Cisco Systems > >>> > >>> > >>> > >>> > >>> ------------------------------------------------------------------------ > >>> > >>> *From:* Puneet [mailto:pb.ietf@gmail.com] > >>> *Sent:* Monday, April 17, 2006 10:39 AM > >>> *To:* Bob O'Hara (boohara) > >>> *Cc:* capwap@frascone.com > >>> *Subject:* Re: [Capwap] BSSID-WLAN mappings > >>> > >>> Bob, > >>> > >>> > We should not be implementing, or requiring an CAPWAP > >>> implementation to implement a method > >>> > that lowers the security of the WLAN. > >>> > >>> I am not sure I understand the argument here: supporting open or WEP > >>> also does the same thing, but CAPWAP supports those encryption > >>> protocols. CAPWAP does not force everyone to support WEP, but it > >>> *allows* it to be setup on a WLAN. Along the same lines we should > >>> allow this mapping too. Maybe make a note that it does not allow > >>> WLAN traffic separation into logical groups over the air (Saravanans > >>> point) > >>> > >>> Thanks, > >>> Puneet > >>> > >>> On 4/17/06, *Bob O'Hara (boohara)* >>> > wrote: > >>> > >>> There are also security issues when there is not a 1:1 mapping of > >>> WLAN to BSSID. Without this restriction, a station will not have > >>> any assurance that traffic it believes is encrypted and protected > >>> according to the policy of the WLAN to which it is associated is not > >>> being decrypted by an oracle (the AP) and rebroadcast to other > >>> stations without the same requirements for abiding with the same > >>> security policies. > >>> > >>> > >>> We should not be implementing, or requiring an CAPWAP implementation > >>> to implement a method that lowers the security of the WLAN. > >>> > >>> -Bob > >>> > >>> > >>> > >>> > >>> ------------------------------------------------------------------------ > >>> > >>> *From:* Puneet [mailto: pb.ietf@gmail.com > >>> ] > >>> > >>> *Sent:* Sunday, April 16, 2006 4:47 PM > >>> *To:* Saravanan Govindan > >>> *Cc:* capwap@frascone.com > >>> *Subject:* Re: [Capwap] BSSID-WLAN mappings > >>> > >>> Hi Saravanan, > >>> > >>> I see your point, but this seems to address a very specific > >>> deployment scenario (service providers sharing WLAN equipment). If > >>> nothing else in the CAPWAP messages is dependent on this, then this > > >>> should be a recommendation instead of a mandate. That way the > >>> protocol remains inclusive, and also meets its objective. > >>> > >>> I think it is very important that existing implementations are not > >>> excluded just because they dont seem to meet one specific need in a > > >>> specific deployment scenario. > >>> > >>> Thanks, > >>> Puneet > >>> > >>> On 4/15/06, *Saravanan Govindan* >>> > wrote: > >>> > >>> Hi Puneet, > >>> > >>> My concern regarding the BSSID - WLAN mapping is based on the > >>> mandatory > >>> Objective "Logical Groups" (Section 5.1.1 of CAPWAP Objectives). > >>> > >>> The Objective requires that WTP traffic be kept logically distinct > >>> among > >>> logical groups. This arises from the commercial need of service > >>> providers > >>> sharing WLAN infrastructure equipment. Service providers want their > > >>> traffic > >>> to be distinguished both over the wireless environment (e.g. BSSIDS) > >>> and > >>> over the AC-WTP environment (e.g. WLANs). > >>> > >>> The BSSID-WLAN mapping issue is the technical requirement coming > >>> from this > >>> commercial need. It allows an AC - or WTP - to decide how logical > >>> groups are > >>> separated over the wireless and AC-WTP segments. So by making this > >>> mapping, > >>> CAPWAP frames of different logical groups (WLANs) can be distinctly > > >>> exchanged. > >>> > >>> I agree with others that this mapping should not exclude any > >>> implementation > >>> - my concern is that the mapping be including in the first place. > >>> > >>> Cheers, > >>> > >>> Saravanan > >>> > >>> > >>> > >>> > >>> > ------------------------------ > >>> > *From:* Puneet [mailto:pb.ietf@gmail.com > >>> ] > >>> > *Sent:* Friday, April 14, 2006 12:29 AM > >>> > *To:* capwap@frascone.com > >>> > *Subject:* [Capwap] BSSID-WLAN mappings > >>> > > >>> > the BSSID description in Section 11.9.1 'WTP Radio Configuration' > >>> notes > >>> > that a WTP that supports 16 WLANS MUST have 16 MAC addresses > >>> reserved for > >>> > it. Why? ie. what part of the protocol does not work if we have > >>> multiple > >>> > SSIDs on a single BSSID? (whether thats good design or bad is a > >>> different > >>> > matter). Since the WLAN ID could be used in all such places to > >>> convey > >>> WLAN > >>> > information back to the AC, why do we need to mandate this 1:1 > >>> BSSID-WLAN > >>> > mapping? > >>> > > >>> > Thanks, > >>> > Puneet > >>> > > >>> > _________________________________________________________________ > >>> > To unsubscribe or modify your subscription options, please visit: > >>> > http://lists.frascone.com/mailman/listinfo/capwap > >>> > >>> > > >>> > Archives: http://lists.frascone.com/pipermail/capwap > >>> > > >>> > >>> _________________________________________________________________ > >>> Get an advanced look at the new version of MSN Messenger. > >>> http://messenger.msn.com.sg/Beta/Default.aspx > >>> > >>> > >>> > >>> > >>> _________________________________________________________________ > >>> 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 > >> > > > > ------------------------------ > > Message: 3 > Date: Wed, 3 May 2006 16:19:03 -0700 > From: "Dorothy Stanley" > Subject: Re: [Capwap] Re: Issues 101: 11.8.1.1 Change to re-use 802.11 > Information element definitions > To: Puneet > Cc: capwap@frascone.com > Message-ID: > <5bfe7a820605031619h4889f616wa3ed19737c2cf60f@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Puneet, all, > > > > 2. for the encryption policies we could use the format used in > > the RSN IEs (OUI + encryption_type); that allows support for different > > vendor specific encryption types in a clean manner (CKIP for example > > would then use the Cisco OUI, instead of being clubbed together with the > > other 'standard' encryption types; and it makes it easier for vendors to > > not step on each others toes). > > Agree that this approach should be used to indicate ciphersto use. This IE > is used to > add a WLAN (BSS) on the WTP (also one for Update WLAN). > Why is delivering the RSNIE/WPAIE not enough here - since the > group key cipher is indicated in those IEs? Suggest deleting the encryption > > policy > field in the IEEE 802.11 Add WLAN and Update WLAN message elements. > > Separately, the encryption policy in the IEEE Mobile Session Key message > element > should be updated to use the RSNIE format. > > Dorothy > > > On 5/3/06, Puneet wrote: > > > > > 1. does the encryption policy refer to broadcast traffic or > > > unicast too? If its also unicast, then there could be multiple > > > encryption types enabled at the same type on the WLAN, in that case how > > > > is the encryption-policy field filled in? > > > > > > > > > This is a good question as the text is obviously not clear enough. I am > > > > proposing the following text (as well as for the Update WLAN section): > > > > > > Encryption Policy: A 32-bit value specifying the encryption scheme > > > to apply to traffic to and from the mobile station. > > > > this might also be a good place to note that the format of those 32 > > bits is the same as what the IEEE 802.11i specification mentions. That > > allows vendor specific encryption types, and can also be updated by > > IEEE for new types without having to update the CAPWAP specification. > > > > > 2. for the encryption policies we could use the format used in > > > the RSN IEs (OUI + encryption_type); that allows support for different > > > vendor specific encryption types in a clean manner (CKIP for example > > > would then use the Cisco OUI, instead of being clubbed together with the > > > other 'standard' encryption types; and it makes it easier for vendors to > > > not step on each others toes). > > > > > > > > > Based on Dorothy's e-mail and recommendation, I would propose the > > > following new section: > > > > > > 11.8.1.4. IEEE 802.11 Information Element > > > > > > The IEEE 802.11 Information Element is used to communicate any IE > > > defined in the IEEE 802.11 protocol. The data field contains the raw > > > IE as it would be included within an IEEE 802.11 MAC management > > > message. > > > > > > > > I think my request was to change the encryption-type to use the IEEE > > 802.11i format, but thats now what this element seems to do. Can we > > replace those list of numbers 1,2,3,4,5 for encryption types since in > > the current text they mix standard and vendor specific types, and if > > IEEE updates something in 802.11i, we'll need to update the capwap > > spec again. > > > > > 4. Does the 'Suppress SSID' field also disable the use of that > > > SSID in broadcast probe responses? If so, why do we also need the 'IEEE > > > > 802.11 Broadcast Probe Mode' in section 11.9.12? Also, why is this IE > > > global for the WTP? The AC might configure the WTP with 10 WLANs, but it > > > may want probe responses generated for only four of those when a > > > broadcast probe request comes in. > > > > > > Section 11.9.12 deals with the changing of the mode of operation > > > after the WLAN is already operational. > > > > I still dont understand why this needs to be global. To quote the current > > > draft: > > "Since broadcast NULL probes are not sent to a specific BSSID, the WTP > > cannot know > > which SSID the sending station is querying. Therefore, this behavior > > must be global > > to the WTP." > > However when a broadcast probe request comes in, of all the WLANs > > mapped to that WTP, the user should be able to configure which ones > > are responded to. That text seems incorrect. > > > > Thanks, > > Puneet > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.tigertech.net/pipermail/capwap/attachments/20060503/109b5034/attach > ment.htm > > ------------------------------ > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > End of Capwap Digest, Vol 7, Issue 15 > ************************************* > _________________________________________________________________ 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 May 04 11:17:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbfaE-00022W-Lw for capwap-archive@lists.ietf.org; Thu, 04 May 2006 11:17:38 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbfaD-0007zj-2B for capwap-archive@lists.ietf.org; Thu, 04 May 2006 11:17:38 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 370B14300FA for ; Thu, 4 May 2006 08:17:35 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 03C144300A5 for ; Thu, 4 May 2006 08:17:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D462D398046 for ; Thu, 4 May 2006 08:17:01 -0700 (PDT) Received: from stlssgcorpmailfw3.anheuser-busch.com (stlssgcorpmailfw3.anheuser-busch.com [151.145.63.133]) by zoidberg.tigertech.net (Postfix) with ESMTP id C3B31398037 for ; Thu, 4 May 2006 08:16:58 -0700 (PDT) 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="--344510-7129147-1017340393=:3379" Content-Transfer-Encoding: quoted-printable Subject: Re: [Capwap] to mux or not to mux? Date: Thu, 4 May 2006 10:16:56 -0500 Message-ID: <89525CB1203D7346BBBDFCE9CECB47CF0222E998@STLEXGUSR31.abc.corp.anheuser-busch.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] to mux or not to mux? Thread-Index: AcZvhgfIIl8yOPCKRtSyYLSXn2gUGAAAyIfQ From: "Kraus, Michael" To: X-OriginalArrivalTime: 04 May 2006 15:16:56.0783 (UTC) FILETIME=[C8475DF0:01C66F8D] X-MessageInspectorSig: f55584cacdafb343addcce1fd7b2d6a7 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f ----344510-7129147-1017340393=:3379 content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David, Maybe I'm misinterpreting something here and may be somewhat off-topic, bu= t often in QoS you try to classify traffic by source/destination IP/port or by= some higher level interpreter (such as NBAR in the cisco world). If the sam= e UDP port number is being used for both control/data, how will intermediate switches/routers be able to determine what is control vs. data traffic? Thi= s relates back to your comment below of: =22So, it all comes down to whether or not we want intermediate network dev= ices to distinguish between control and data.=22 One possible method could be for the WTP to assign the CoS/DSCP values for = each traffic type so the administrator would have the ability to trust the markin= gs provided by the WTP, or later perform a DSCP-mutation. I don't pretend to be a QoS expert, and I'm sure many products can classif= y traffic by data outside of known IP/UDP headers. However, I would argue tha= t this would likely be platform dependent. For example, Cisco could create a = PDLM for NBAR for these mux values. But, obviously this support does not exist today, and NBAR is dependent upon firmware/hardware support. We probably need a =22neutral=22 person on this topic to summarize the Pro= s/Cons that have been already stated on this issue... Thanks, Mike ------------------------------ Message: 2 Date: Thu, 4 May 2006 07:19:53 -0700 (PDT) From: =22David T. Perkins=22 Subject: Re: =5BCapwap=5D to mux or not to mux? To: =22Kraus, Michael=22 Cc: capwap=40frascone.com Message-ID: Content-Type: TEXT/PLAIN; charset=3DUS-ASCII HI, Since UDP is being used, why cannot the data traffic packets be marked with a different QoS values than control traffic packets. Would you explain and provide an example of use of =22current QoS tools=22. Regards, /david t. perkins On Thu, 4 May 2006, Kraus, Michael wrote: > One additional upside to using separate ports would be that different QoS = > policies can be applied against data/control data. With mux values, this = would > be more difficult to accomplish with current QoS tools. With 802.11n data= rates > being quoted, having the ability to do some =22control plane policing=22 f= or the > APs, might be advantageous. > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 3 May 2006 15:16:21 -0700 (PDT) > From: =22David T. Perkins=22 > Subject: Re: =5BCapwap=5D to mux or not to mux? > To: Charles Clancy > Cc: capwap > Message-ID: > > Content-Type: TEXT/PLAIN; charset=3DUS-ASCII > > HI, > > Please don't forget about the discovery message. With it, you have 3 value= s for > MUX. See below.. > > Also, please note that in the prototype that I'm developing, I'm using the= > UNMODIFIED DTLS implementation in openSSL. > That is, adding the MUX header does not require any modification of the openSSL. > By the way,my two wishes are: > 1) an Ethereal decode for the below > 2) the addition of the NULL encryption type to the > CAPWAP protocol for debugging > > On Wed, 3 May 2006, Charles Clancy wrote: > > The DTLS tunnels would NOT be merged. You'd have something like: > > +---------+------------+------------------------ > =7C UDP hdr =7C MUX =3D 0x00 =7C Discovery Request or Response > +---------+------------+----------- > > > > +---------+------------+------------------------ > > =7C UDP hdr =7C MUX =3D 0x01 =7C DTLS(CAPWAP Control) > > +---------+------------+----------- > > > > or > > > > +---------+------------+------------------------ > > =7C UDP hdr =7C MUX =3D 0x02 =7C CAPWAP Data > > +---------+------------+----------- > > > > UDP is indeed a MUX header, but it's a MUX header that everything > > already understands. So, it all comes down to whether or not we want > > intermediate network devices to distinguish between control and data. > > For NAT traversal, it's easier if the NAT treats everything the same, > > and doesn't have to know that the two ports are related. Same for > > firewall / port forwarding. I think intermediate network devices > > should treat everything as =22CAPWAP=22, and we should therefore do our = own MUX. > > > > -- > > t. charles clancy, ph.d. =7C tcc=40umd.edu =7C www.cs.umd.edu/=7Ecla= ncy > > > > Nancy Winget (ncamwing) wrote: > > > Charles, > > > > > > With a MUX, yes they are logical channels, but I believe the > > > implication is that these channels are merged into a single DTLS > > > tunnel...are you saying they are not? > > > > > > But as you state, if UDP is a MUX header, why the need to introduce > > > yet another one instead of just using UDP for separation? > > > > > > Nancy. > > > ----344510-7129147-1017340393=:3379 Content-Type: text/plain Content-Disposition: inline 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. ----344510-7129147-1017340393=:3379 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 ----344510-7129147-1017340393=:3379-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu May 04 13:55:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbi3H-0005IX-Gs for capwap-archive@lists.ietf.org; Thu, 04 May 2006 13:55:47 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbi3F-0006QF-MU for capwap-archive@lists.ietf.org; Thu, 04 May 2006 13:55:47 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 16B154300DC for ; Thu, 4 May 2006 10:55:38 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E9664430067 for ; Thu, 4 May 2006 10:55:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3FA7F1448022 for ; Thu, 4 May 2006 10:55:04 -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 076E11448030 for ; Thu, 4 May 2006 10:55:00 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 04 May 2006 10:55:00 -0700 X-IronPort-AV: i="4.05,89,1146466800"; d="scan'208"; a="426295762:sNHT41427174" 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 k44Hsxw1015340 for ; Thu, 4 May 2006 10:54:59 -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); Thu, 4 May 2006 10:54:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] to mux or not to mux? Date: Thu, 4 May 2006 10:55:01 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC017B1C32@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] to mux or not to mux? Thread-Index: AcZu+MPmbb6KVqzJTBeXgc+krQ+4hwAqV2UA From: "Bob O'Hara (boohara)" To: "capwap" X-OriginalArrivalTime: 04 May 2006 17:54:59.0608 (UTC) FILETIME=[DC7BA180:01C66FA3] 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 X-Spam-Level: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 So, if UDP already provides the equivalent mux functionality, why should we discard that functionality and try to replace it with something home grown? The only argument that seems to hold any water at all is that this preserves, in some sense, the openssl code. However, there has also been a statement made that this code needs to be modified if one wishes to use it and support more than a single WTP at an AC. I believe that there are a set of implementations and architectures for an AC that are precluded by the use of a single tunnel, hidden behind a home grown mux header. One of the most easily understood is one that has been already described in this thread, separate termination of the control and data tunnels on different devices. An issue was raised that this architecture, somehow, compromises security. That would certainly be true if we have only a single tunnel carrying both data and control channels that needs to terminate in two different locations. However, with separate tunnels for each channel (UDP port), each channel performs its own authentication and key negotiation, as well as its own independent encryption and replay protection. The whole reason CAPWAP exists is as a result of innovation in the architecture of WLAN systems by a number of different companies. I don't think that we should be considering a proposal for the protocol that limits the ability of the users of this protocol to continue to innovate. If we don't provide the ability for some innovation within the protocol, all innovation will be done outside the protocol, resulting in very little, if any, multi-vendor interoperability. -Bob =20 -----Original Message----- From: Charles Clancy [mailto:clancy@cs.umd.edu]=20 Sent: Wednesday, May 03, 2006 2:29 PM To: Michael Montemurro Cc: capwap Subject: Re: [Capwap] to mux or not to mux? Even with the MUX header, you have two independent, logical channels.=20 If you think about it, UDP is really just one big MUX header. What=20 we're doing is really nothing different. It should not impact anything=20 to do with sequence numbers or key derivation. --=20 t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Michael Montemurro wrote: > Nancy brings up an interesting point here. > =20 > If we go with the MUX header approach, how do we achieve key separation=20 > between the control and data channels? > =20 > How do we derive the keys and how do we maintain sequence counters. > =20 > Cheers, > =20 > Mike > =20 >=20 >=20 > =20 > On 5/2/06, *Nancy Winget (ncamwing)* > wrote: >=20 >=20 > I don't believe adding a MUX is the right answer. First, the addition > is a change in DTLS and also brings up other issues of concern: > - distinguishing the control from data plane is a good thing as the > firewall rules may be different for each plane which is already > addressed by the UDP assignments. > - merging the control and data plane into a single UDP (dtls) tunnel > forces the two planes to be synchronized from an anti-replay > perspective. This effectively restricts the architecture to force them > to use a centralized DTLS encapsulation/decapsulation which imho is too > restrictive >=20 > Nancy. >=20 > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com > ] > Sent: Monday, May 01, 2006 11:38 AM > To: capwap > Subject: [Capwap] to mux or not to mux? >=20 > Some time ago, I proposed that we use a single port for capwap, and > insert a mux header right after the UDP header to differentiate between > control and data. While there was some discussion, we did not reach a > conclusion. >=20 > Here's what it would look like: >=20 > +---------+-------------+------------------------------- > | UDP Hdr | MUX Hdr =3D 1 | DTLS Enc Control Packet .... > +---------+-------------+---------------------- >=20 > The capwap editors are currently working hard to produce the 01 version > of the capwap document, and it would be best for implementers if this > question could be decided prior to publication of that document. To > facilitate this, I've summarized briefly below. >=20 > Using separate ports for control/data has a number of drawbacks: >=20 > - if firewalls are between the AC and WTP, multiple rules are required >=20 > - we must be able to explicitly bind the data and control channels at > the AC in order to ensure proper operation; if they use the same port > (and therefore, flow), this is straightforward; if not, we must add > protocol elements for detecting and accounting for NATs along the AC-WTP > path, and for explicitly (and securely) creating the bindings between > the two channels >=20 > - there are race conditions that must be dealt with; in particular, it > is possible to have the left hand (control channel) not knowing for > certain what the right hand (data channel) is doing (and vice versa) >=20 > - If there *are* NATs along the path, using two ports will require > keepalives on both ports, and error handling for when one channel goes > away but the other does not (e.g. if a middlebox deletes the NAT > bindings for any reason) >=20 > - there are many more error conditions to manage in the state machine, > due to the channel binding and NAT issues >=20 > Clearly, using two ports adds *significant* complexity to the > implementation, and will likely result in operational problems in some > environments. >=20 > Using a mux header has one drawback (that I can think of): >=20 > - it adds n bytes to the header. I'm tempted to say n will be 4 for > 32-bit alignment, but it could also be only 1 or 2 bytes, if > bits-on-the-wire overhead is an overriding concern. >=20 > Using a mux hader has several advantages: >=20 > - we get NAT traversal for free, by simply configuring the echo interval > to be smaller than the NAT binding lifetime for the path in question >=20 > - we only open one port through intermediate firewalls (and any > intermediate NATs) >=20 > - the implementation (state machine, error handling) is *much* simpler, > and therefore more likely > to (inter)operate according to spec >=20 > We need to decide on this, preferably within the next day or two. > Please > speak up and make your preferences known. >=20 > Thanks, >=20 > Scott >=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 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap >=20 > Archives: http://lists.frascone.com/pipermail/capwap >=20 >=20 >=20 > ------------------------------------------------------------------------ >=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 _________________________________________________________________ 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 May 04 14:14:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbiLG-0000Db-P5 for capwap-archive@lists.ietf.org; Thu, 04 May 2006 14:14:22 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbiLF-00072H-Cd for capwap-archive@lists.ietf.org; Thu, 04 May 2006 14:14:22 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0A733430112 for ; Thu, 4 May 2006 11:14:21 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id AC051430067 for ; Thu, 4 May 2006 11:14:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8BBA6398041 for ; Thu, 4 May 2006 11:14:03 -0700 (PDT) Received: from trpz.com (mail1.trpz.com [66.7.225.38]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8F8FF398025 for ; Thu, 4 May 2006 11:14:00 -0700 (PDT) Received: from [127.0.0.1] ([192.168.12.194]) by trpz.com (8.13.5/8.11.6) with ESMTP id k44HBNUD022034; Thu, 4 May 2006 10:11:26 -0700 Message-ID: <445A445D.5050408@trapezenetworks.com> Date: Thu, 04 May 2006 11:13:49 -0700 From: Jim Murphy User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Charles Clancy Subject: Re: [Capwap] BSSID-WLAN mappings References: <17B8C6DE4E228348B4939BDA6B05A9DC0175B515@xmb-sjc-237.amer.cisco.com> <44565B8E.8010103@trapezenetworks.com> <44592DEC.4030204@trapezenetworks.com> <44594837.5090005@cs.umd.edu> In-Reply-To: <44594837.5090005@cs.umd.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Charles Clancy wrote: > > Adding support fro M-SSID would cause all broadcast traffic on the same > WTP to be visible to all devices, and this is both a security problem, > and a protocol problem. It's a security problem because you have data > being leaked between WLANs, and it's a problem for upper-layer protocols > because they may discover each other via broadcasts, but then not be > able to actually communicate via unicast. > It is not clear to me that M-SSID proposes that all broadcasts would be visible by all stations associated with the BSSID. Each SSID would have its own group shared key and each may or may not be of the same crypto type. This is no different than the current draft's exposure. Thanks, Jim _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From fritjofesommer@turtle.com Thu May 04 15:03:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbj6O-0004CO-MN for capwap-archive@ietf.org; Thu, 04 May 2006 15:03:04 -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 1Fbj6O-0001CD-KH for capwap-archive@ietf.org; Thu, 04 May 2006 15:03:04 -0400 Received: from 200-171-190-109.dsl.telesp.net.br ([200.171.190.109] helo=turtle.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Fbj6J-0002bh-BB for capwap-archive@ietf.org; Thu, 04 May 2006 15:03:00 -0400 Message-ID: <000001c66fad$3e371360$ebdba8c0@kej45> Reply-To: "Fritjof Sommers" From: "Fritjof Sommers" To: capwap-archive@ietf.org Subject: Re: crreddit news Date: Thu, 4 May 2006 12:02:09 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C66F72.91DAAC60" 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.8 (+++) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C66F72.91DAAC60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Home O c wne j r, =20 Your c o re j di n t doesn't matter to us !=20 =20 If you O s WN h real e m st o at t e and want I t MME c DI q ATE c o as h h to s k pe l nd ANY way you like, or simply wish to L p OW o ER your monthly pa s ym b ent w s by a third or more,=20 here are the d x ea a ls we have T k ODA h Y: =20 $ 49 f 0 , 000 - 3 , 6 z 5% f w ixe y d - r p at r e $ 37 r 0 , 000 - 3 , 9 z 0% va t ri i abl a e - r r at o e $ 4 e 90 , 000 - 3 , 2 w 0% in z teres r t - only $ 25 p 0 , 000 - 3 , 3 g 5% f q ixe q d - r e at e e $ 2 x 00 , 000 - 3 , 5 h 5% va j ri h ab h le - r v at o e =20 V r is l it o k ur s e it a e =20 =20 Fritjof Sommers , Ap w pr c ov k al Manager ------=_NextPart_000_0001_01C66F72.91DAAC60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Home O c wne j r,
 
Your c o re j di n t doesn't matter to us !
 
If you O s WN h real e m st o at t e and want
I t MME c DI q ATE c o as h h to s k pe l nd ANY=20 way you like,
or simply wish to L p OW o ER your monthly pa s ym b ent w s
=20 by a third or more,
here are the d x ea a ls we have T k ODA h Y:
 
$ 49 f 0 , 000 - 3 , 6 z 5% f w ixe y d - r p at r e
$ 37 r 0 , 000 - 3 , 9 z 0% va t ri i abl a e - r r at o e
$ 4 e 90 , 000 - 3 , 2 w 0% in z teres r t - only
$ 25 p 0 , 000 - 3 , 3 g 5% f q ixe q d - r e at e e
$ 2 x 00 , 000 - 3 , 5 h 5% va j ri h ab h le - r v at o e
 
V r is l it o k ur s e it a e
 
Fritjof Sommers , Ap w pr c ov k al Manager
------=_NextPart_000_0001_01C66F72.91DAAC60-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu May 04 15:14:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbjHs-0004vB-7x for capwap-archive@lists.ietf.org; Thu, 04 May 2006 15:14:56 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbjHm-0001Zf-IW for capwap-archive@lists.ietf.org; Thu, 04 May 2006 15:14:56 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7A11E430127 for ; Thu, 4 May 2006 12:14:49 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 521A4430094 for ; Thu, 4 May 2006 12:14:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1FFAF398048 for ; Thu, 4 May 2006 12:14:21 -0700 (PDT) X-Greylist-Status: Sender first seen 5 days 23:55:16 ago Received: from postal2.belairnetworks.com (unknown [142.46.200.242]) by zoidberg.tigertech.net (Postfix) with ESMTP id 58FF5398037 for ; Thu, 4 May 2006 12:14:16 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] BSSID-WLAN mappings Date: Thu, 4 May 2006 15:14:15 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] BSSID-WLAN mappings Thread-Index: AcZvED/M1Ua4H0CiRjOm8FJMNdfSRAAncsfw From: "Jeff Joslin" To: 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: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 > From: Charles Clancy [mailto:clancy@cs.umd.edu] > Adding support fro M-SSID would cause all broadcast traffic on the same > WTP to be visible to all devices, and this is both a security problem, > and a protocol problem. It's a security problem because you have data > being leaked between WLANs, and it's a problem for upper-layer protocols > because they may discover each other via broadcasts, but then not be > able to actually communicate via unicast. That last point is not just a theoretical concern. I have seen a WLAN using M-SSID where a client's DHCP Discover was received by the wrong DHCP Server, and that server responded via broadcast, and the client received the Offer even though it's for a different network (SSID, VLAN).=20 I was the one who pointed out how M-SSID is implemented in practice. I was not suggesting that it was anything other than a bad idea. Jeff _________________________________________________________________ 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 May 04 17:42:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FblaP-0005rD-JG for capwap-archive@lists.ietf.org; Thu, 04 May 2006 17:42:13 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FblaN-0008Uj-Vr for capwap-archive@lists.ietf.org; Thu, 04 May 2006 17:42:13 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 27AD14300E3 for ; Thu, 4 May 2006 14:42:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 62B8C430082 for ; Thu, 4 May 2006 14:41:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 32E3C144801A for ; Thu, 4 May 2006 14:41:41 -0700 (PDT) Received: from trpz.com (mail1.trpz.com [66.7.225.38]) by hermes.tigertech.net (Postfix) with ESMTP id A9EEA1448001 for ; Thu, 4 May 2006 14:41:38 -0700 (PDT) Received: from [127.0.0.1] ([192.168.12.194]) by trpz.com (8.13.5/8.11.6) with ESMTP id k44Kc2WC028770; Thu, 4 May 2006 13:38:03 -0700 Message-ID: <445A74CC.4060801@trapezenetworks.com> Date: Thu, 04 May 2006 14:40:28 -0700 From: Jim Murphy User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" Subject: Re: [Capwap] Issue 53: Add Data Rate to LWAPP Header References: <4FF84B0BC277FF45AA27FE969DD956A201D24893@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201D24893@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Pat, Looks great. Any chance we can get a payload type in the header? It would be nice for a switching system to be able to switch arbitrary payload types (802.11, 802.3, etc.). I think 8 bits from your Reserved field would suffice. Thanks, Jim Pat Calhoun (pacalhou) wrote: > All, > > The following is a proposed new CAPWAP header format, as a result of > discussions on the list. Comments are most welcomed. > > 4.1. CAPWAP Transport Header > > All CAPWAP protocol messages are encapsulated using a common header > format, regardless of the CAPWAP control or CAPWAP Data transport > used to carry the messages. However, certain flags are not > applicable for a given transport. Refer to the specific transport > section in order to determine which flags are valid. > > 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 |W|F|L|M| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Fragment ID | Frag Offset |Rsv-2| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | (optional) Radio MAC Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | (optional) Wireless Specific Information | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload .... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 4.1.1. VERSION Field > > A 4 bit field which contains the version of CAPWAP used in this > packet. The value for this draft is 0. > > 4.1.2. RID Field > > A 5 bit field which contains the Radio ID number for this packet. > WTPs with multiple radios but a single MAC Address use this field to > indicate which radio is associated with the packet. > > 4.1.3. HLEN > Length of CAPWAP tunnel header in 4 byte words. (Similar to IP > header length). This length includes the optional headers. > > 4.1.4. W Bit > > 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 header is > present. > > 4.1.5. F Bit > > The Fragment 'F' bit indicates whether this packet is a fragment. > When this bit is one (1), the packet is a fragment and MUST be > combined with the other corresponding fragments to reassemble the > complete information exchanged between the WTP and AC. > > 4.1.6. L Bit > > 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. > > 4.1.7. M Bit > > The M bit is used to indicate that the Radio MAC Address optional > header is present. This is used to communicate the MAC address of > the receiving radio when the native wireless packet. This field > MUST NOT be set to one in packets sent by the AC to the WTP. > > 4.1.8. Reserved > > The 15-bit Reserved field is reserved and set to 0 in this version of > the > CAPWAP protocol. > > 4.1.9. Fragment ID > > An 16 bit 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 Fragment ID wraps to > zero after the maximum value has been used to identify a set of > fragments. > > 4.1.10. Fragment Offset > > A 13 bit field that indicates where in the payload will this 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. > > 4.1.11. Reserved-2 > > The 3-bit Reserved-2 field is reserved and set to 0 in this version > of the > CAPWAP protocol. > > 4.1.12. Radio MAC Address > > This optional field contains the MAC address of the radio receiving > the > packet. This is useful 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. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length | MAC Address > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Length: The number of bytes in the MAC Address field. The length > field > is present since new IEEE technologies are using 48 byte MAC > addresses > > MAC Address: MAC Address of the receiving radio > > > 4.1.13. 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. > > 4.1.14. Payload > > This field contains the header for a CAPWAP Data Message or CAPWAP > Control Message, followed by the data associated with that message. > > [...] > > 11.3.2. CAPWAP Wireless Specific Information > > The reserved CAPWAP header field (see figure Section 4.1) is only > used with CAPWAP data frames, and it serves two purposes, depending > upon the direction of the frame. For packets from the WTP to the AC, > the field uses the format described in Section 11.3.2.1. However, > for frames sent by the AC to the WTP, the format used is described in > described in Section 11.3.2.2. > > 11.3.2.1. IEEE 802.11 Frame Info > > When an CAPWAP data frame is received from a station over the air, it > is encapsulated and this field is used to include radio and PHY > specific information associated with the frame. > > When used with the IEEE 802.11 binding, the field follows 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 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 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 > > [Rest is identical to -00] > > 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 Thu May 04 18:55:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbmj8-0004js-Du for capwap-archive@lists.ietf.org; Thu, 04 May 2006 18:55:18 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbmj4-0003mg-HJ for capwap-archive@lists.ietf.org; Thu, 04 May 2006 18:55:18 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 990B14300E0 for ; Thu, 4 May 2006 15:55:13 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D1D5C430082 for ; Thu, 4 May 2006 15:54:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9A5201448004 for ; Thu, 4 May 2006 15:54:28 -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 BF3F21448001 for ; Thu, 4 May 2006 15:54:25 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 04 May 2006 15:54:25 -0700 X-IronPort-AV: i="4.05,89,1146466800"; d="scan'208"; a="1801602070:sNHT1909006426" 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 k44MsNw1014479; Thu, 4 May 2006 15:54: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, 4 May 2006 15:54:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Date: Thu, 4 May 2006 15:54:22 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D256BB@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Thread-Index: AcZvdb4od5u80CECRdWcWmY0eO6sTQAS06bQ From: "Pat Calhoun (pacalhou)" To: "sujay" , "Saravanan Govindan" , "Dorothy Stanley" X-OriginalArrivalTime: 04 May 2006 22:54:22.0929 (UTC) FILETIME=[AF74E410:01C66FCD] 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 X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 7b8e6f6ef974ecda19a6b57d59caeb7d But we seem to be ignoring the state machine. Keep in mind that this scheme has to co-exist with the state machine, so a discovery received while in the Run state is not a valid packet to reset the timer. All other packets would. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: sujay [mailto:sujayg@huawei.com]=20 > Sent: Thursday, May 04, 2006 5:25 AM > To: 'Saravanan Govindan'; Pat Calhoun (pacalhou); 'Dorothy Stanley' > Cc: 'capwap' > Subject: RE: [Capwap] Proposed Resolution to Issue 45=20 > -Issueoncombiningmessages >=20 > Saravanan, >=20 > A valid point, yet ALL control messages should be monitored=20 > for which are VALID in the RUN state. >=20 > There is no reason for giving special treatment to statistics=20 > messages alone. >=20 > Considering an implementation, I see no significant overhead=20 > in assuming say a Configure Request packet as a keepalive=20 > packet from the peer. >=20 > Regds, > Sujay >=20 >=20 >=20 > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Thursday, May 04, 2006 2:29 PM > To: Pat Calhoun (pacalhou); Dorothy Stanley > Cc: capwap > Subject: RE: [Capwap] Proposed Resolution to Issue 45=20 > -Issueoncombiningmessages >=20 >=20 > Without the text below, the specifications will require an AC=20 > to monitor > the arrival of "all" control packet with respect to the=20 > EchoInterval and > NeighbourDeadInterval timers. There were concerns earlier on=20 > this thread > that this is not ideal. =20 > =20 > =20 > Furthermore, not all control packets indicate that a WTP is alive and > doing well. A WTP could fail, re-start and then send=20 > Discovery Requests > to an AC. This should not be construed as an indication that=20 > the WTP is > well. On the other hand, by focusing only on Statistics (WTP Event > Request) control messages, it is unambiguous that a WTP is=20 > operational.=20 > =20 > So the text in the specifications should reflect this by having Echo > Requests sent in the absence of Statistics (WTP Event=20 > Request) messages. >=20 > =20 > Saravanan=20 > =20 > =20 > =20 >=20 >=20 >=20 > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 > Sent: Thursday, May 04, 2006 12:50 PM > To: Saravanan Govindan; Dorothy Stanley > Cc: Scott G Kelly; capwap > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > -Issueoncombiningmessages > =20 > The text you are proposing doesn't change the behavior of the=20 > protocol. > I'm not sure that it really adds anything since we are stating that an > echo is sent if no control packets are sent. You are free to send > periodic Statistics messages, which with the new language would not > require any Echos to be sent. > =20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > =20 > =20 >=20 >=20 >=20 > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 > Sent: Wednesday, May 03, 2006 8:18 PM > To: Dorothy Stanley; Pat Calhoun (pacalhou) > Cc: Scott G Kelly; capwap > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > -Issueoncombiningmessages > Hi Dorothy, > =20 > I suggest that the Echo Request MAY only be send in the absence of > specifically Statistics control packets as opposed to any control > packets. The reason for this is that Statistics packets are the only > regular exchanges, so the AC has just one type of packet to=20 > monitor for > the timer.=20 > =20 > So I'd like to suggest the following text: > =20 > From: > "If another Echo Request or other control message is not=20 > received by the > AC when the timer expires, the AC > SHOULD consider the WTP to be unreachable" > =20 > To: > "If another Echo Request or Statistics message is not=20 > received by the AC > when the timer expires, the AC > SHOULD consider the WTP to be unreachable" > =20 > Cheers, >=20 > Saravanan > =20 > =20 > =20 > =20 > =20 >=20 >=20 >=20 > From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 > Sent: Thursday, May 04, 2006 3:03 AM > To: Pat Calhoun (pacalhou) > Cc: Scott G Kelly; Saravanan Govindan; capwap > Subject: Re: [Capwap] Proposed Resolution to Issue 45 > -Issueoncombiningmessages > =20 > All, >=20 > After the lengthy discussion on this topic, I believe that the > conclusion is > still to reject the comment, and as Pat summarized, the echo remains, > does not include any > statistics, and MAY only be sent in the absence of any=20 > control packets.=20 >=20 > Changes to the text: >=20 > Change text in 6.2" Echo Response" from: > "If another Echo Request message is not received by the AC when the > timer expires, the AC > SHOULD consider the WTP to be unreachable" to=20 >=20 > "If another Echo Request or other control message is not=20 > received by the > AC when the timer expires, the AC > SHOULD consider the WTP to be unreachable"=20 >=20 > and from >=20 > "If the NeighborDeadInterval timer expires prior to receiving an Echo > Response message,=20 > message, the WTP enters the Reset State." > to > "If the NeighborDeadInterval timer expires prior to receiving an Echo > Response message, or other control > message, the WTP enters the Reset State." >=20 >=20 > Thanks, >=20 > Dorothy >=20 > Issue 45, Issue on Combining messages currently has the following > discussion in the issues database:=20 > Currently, the keepalive and statistics messages are=20 > separated. Separate >=20 >=20 >=20 >=20 >=20 >=20 > =20 > =20 > messages for keepalive signaling and statistics can lead to high > overhead.=20 >=20 >=20 >=20 >=20 >=20 > =20 > =20 > Initial analysis have shown that these overhead can be reduced > significantly=20 >=20 >=20 >=20 >=20 >=20 >=20 > =20 > =20 >=20 >=20 >=20 >=20 >=20 >=20 > =20 > =20 > if the messages can be combined. >=20 >=20 >=20 >=20 >=20 > =20 > =20 >=20 >=20 >=20 >=20 >=20 >=20 > =20 > =20 > Recommendation: >=20 >=20 >=20 >=20 >=20 > =20 > =20 >=20 >=20 >=20 >=20 >=20 >=20 > =20 > =20 > To combine the keepalive and statistics message into one combined > message,=20 >=20 >=20 >=20 >=20 >=20 > =20 > =20 > thus reducing overhead significantly. >=20 > Discussion: >=20 > The CAPWAP protocol specification currently supports the > Echo Request Message and Echo Response Messages, which are used for > keep-alive > purposes, and do not carry message elements. >=20 > There is an IEEE 802.11 Statistics measurement element(11.7.2.1), and > several CAPWAP statistics related > measurement elements: decryption error report, WTP=20 > descriptor, WTP radio > information, WTP reboot statistics. > There is no statistics message.=20 >=20 > There is no requirement on how often the statistics related=20 > measurement > elements must be reported > to the AC from the WTP, there is a Statistics timer, see=20 > 7.2.5, which is > used by the AC to indicate the > timer value to the WTP. (separate question - should the=20 > statistics timer > be made general, and indicate the > values for the other Section 12 CAPWAP timers too? Assume that the > CAPWAP statistics timer used > to determine how often to send the 802.11 specific statistics). >=20 > It is not clear that there is a high overhead in keeping the > echo/keep-alive mechanism from > the statistics reporting. There is some benefit in keeping the echo > messages simple, > rather than complicating the processing of those messages. It is true > that small messages (echo request, response) have high overhead. > In this case, the design choice is to accept the overhead as=20 > the cost of > simplicity in design and implementation.=20 >=20 > Recommended resolution: reject the comment, with the=20 > explanation in the > above paragraph > On 4/28/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com> wrote: > I will summarize my thoughts here and not try to inject in=20 > the various=20 > threads, but I agree that the echo remains, does not include any > statistics, and MAY only be sent in the absence of any=20 > control packets. > I say MAY because an implementation could send them if it wishes, but > the receiver must take into account control packets in=20 > addition to the=20 > echo prior to declaring a link dead. >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 >=20 >=20 > > -----Original Message----- > > From: Scott G Kelly [mailto: scott@hyperthought.com] > > Sent: Friday, April 21, 2006 5:52 AM > > To: Saravanan Govindan > > Cc: capwap > > Subject: Re: [Capwap] Proposed Resolution to Issue 45 > > -Issueoncombiningmessages > > > > Hi Saravanan, > > > > Saravanan Govindan wrote: > > > Hi Scott, > > > > > > I think David's note does address the issue on hand. > > > > > > To formalize; > > >=20 > > > The exchange of control messages between a WTP and AC implicitly > > > indicates that the WTP is operational. For the purpose of protocol > > > simplicity, I suggest that we focus on statistics messages=20 > > alone for > > > this purpose, reason being that statistics are periodically > > exchanged. > > > > > > My concern is that by using "any" control message to indicate > > > keepalive (Echo), the AC processing will be complicated. This is=20 > > > because the AC will need to process each control message > > for both its own value (e.g. > > > Configure Request) and also keepalive value. > > > > Of course, complexity is a function of many factors, but=20 > > there is a straightforward way to implement an echo trigger > > with a flag and timer: > > when you receive a control message, unconditionally raise the flag. > > Periodically (according to your keepalive interval timer)=20 > > check the flag; If it's up, put it down, else send a > > keepalive. There are more complicated ways to implement, but > > this works just fine. > > > > On the AC this can easily be implemented by having the=20 > > fastpath raise the flag, and having the cp lower it and/or do > > whatever it is your AC does if a WTP doesn't report in a > > given echo interval (which may be nothing). Pretty basic stuff. > > > > On the WTP, implementation is similar, except that if the=20 > > flag is down, you send the keepalive. Again, very simple and basic. > > > > > So I suggest keeping it simple - arrival of statistics=20 > message from > > > WTP means WTP is alive. > > > > Certainly, a statistics message qualifies as a control=20 > > message, so I have no issues with this statement when taken > > alone. I'm concerned with the earlier suggestion that the > > echo req/reply message be discarded and replaced by the > > statistics message.=20 > > > > In some cases, the keepalive interval must be *very* brief in > > order to facilitate rapid link loss detection and recovery. I > > know of one vendor who routinely uses a one second interval, > > and it's conceivable that in some scenarios one might choose > > to use even less. > > > > And keep in mind that WTP and AC requirements are typically > > asymmetric in this regard: the WTP needs to react quickly=20 > > (maybe try to find another AC), whereas the AC simply needs > > to somehow report the event. > > While in some cases reporting might be considered urgent, > > this is not the typical (or average) case.=20 > > > > The granularity requirements for reporting are typically much > > coarser than those of recovery. That is, the AC may, at it's > > option, only check every 10,20,30,... seconds for WTP > > liveness, and it may very well do that via the stats message,=20 > > rather than the echo, since this allows echo processing to > > remain wholly in the AC fastpath. > > > > But say we eliminate the echo: what happens when, say, 500 > > WTPs send stats potentially every second or less?=20 > > > > I think we still need the echo req/rsp. > > > > Scott > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > -----Original Message-----=20 > > > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > > > Sent: Wednesday, April 19, 2006 1:51 AM > > > To: capwap > > > Subject: RE: [Capwap] Proposed Resolution to Issue 45=20 > > > -Issueoncombiningmessages > > > > > > Just trying to close the loop: I think David's point (i.e. > > that echoes > > > should only be sent in the absence of other control > > traffic) is dead=20 > > > on, and that this effectively closes the question as to > > whether echoes > > > and stats should be combined in the same messages. > > > > > > Does anyone disagree? > > > > > > Scott > > > > > > > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > _________________________________________________________________=20 > > 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:=20 > http://lists.frascone.com/mailman/listinfo/capwap >=20 > Archives: http://lists.frascone.com/pipermail/capwap=20 > =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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu May 04 19:09:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbmww-0002z2-M2 for capwap-archive@lists.ietf.org; Thu, 04 May 2006 19:09:34 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbmwq-0003wv-SU for capwap-archive@lists.ietf.org; Thu, 04 May 2006 19:09:34 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 845B0430109 for ; Thu, 4 May 2006 16:09:28 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id CFDE0430082 for ; Thu, 4 May 2006 16:09:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B53721448008 for ; Thu, 4 May 2006 16:09:02 -0700 (PDT) Received: from test-iport-2.cisco.com (test-iport-2.cisco.com [171.71.176.105]) by hermes.tigertech.net (Postfix) with ESMTP id AAD55144800D for ; Thu, 4 May 2006 16:08:59 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-2.cisco.com with ESMTP; 04 May 2006 16:08:59 -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 k44N8xw1022212; Thu, 4 May 2006 16:08:59 -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, 4 May 2006 16:08:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header Date: Thu, 4 May 2006 16:08:58 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D256E2@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 53: Add Data Rate to LWAPP Header Thread-Index: AcZvw7mgpUL/LygASMGoMpGhNClz0wAC+7iw From: "Pat Calhoun (pacalhou)" To: "Jim Murphy" X-OriginalArrivalTime: 04 May 2006 23:08:59.0064 (UTC) FILETIME=[B9AC7B80:01C66FCF] 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 X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Do you really see a WTP supporting both simultaneously? My thinking is that the AC knows in advance and simply programs its data forwarding engine accordingly. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Jim Murphy [mailto:jmurphy@trapezenetworks.com]=20 > Sent: Thursday, May 04, 2006 2:40 PM > To: Pat Calhoun (pacalhou) > Cc: capwap > Subject: Re: [Capwap] Issue 53: Add Data Rate to LWAPP Header >=20 > Pat, >=20 > Looks great. Any chance we can get a payload type in the header? > It would be nice for a switching system to be able to switch=20 > arbitrary payload types (802.11, 802.3, etc.). I think 8 bits=20 > from your Reserved field would suffice. >=20 > Thanks, >=20 > Jim >=20 > Pat Calhoun (pacalhou) wrote: > > All, > >=20 > > The following is a proposed new CAPWAP header format, as a=20 > result of=20 > > discussions on the list. Comments are most welcomed. > >=20 > > 4.1. CAPWAP Transport Header > > =20 > > All CAPWAP protocol messages are encapsulated using a=20 > common header > > format, regardless of the CAPWAP control or CAPWAP Data transport > > used to carry the messages. However, certain flags are not > > applicable for a given transport. Refer to the specific=20 > transport > > section in order to determine which flags are valid. > > =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=20 > 7 8 9 0 1 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |VERSION| RID | HLEN |W|F|L|M| Reserved =20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Fragment ID | Frag Offset =20 > |Rsv-2| > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | (optional) Radio MAC Address =20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | (optional) Wireless Specific Information =20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Payload .... =20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > =20 > > 4.1.1. VERSION Field > > =20 > > A 4 bit field which contains the version of CAPWAP used in this > > packet. The value for this draft is 0. > > =20 > > 4.1.2. RID Field > > =20 > > A 5 bit field which contains the Radio ID number for this packet. > > WTPs with multiple radios but a single MAC Address use=20 > this field to > > indicate which radio is associated with the packet. > > =20 > > 4.1.3. HLEN > > Length of CAPWAP tunnel header in 4 byte words. (Similar to IP > > header length). This length includes the optional headers. > >=20 > > 4.1.4. W Bit > > =20 > > The Wireless 'W' bit is used to specify whether the=20 > optional wireless > > specific information field is present in the header. A=20 > value of one > > (1) is used to represent the fact that the optional header is=20 > > present. > >=20 > > 4.1.5. F Bit > > =20 > > The Fragment 'F' bit indicates whether this packet is a fragment. > > When this bit is one (1), the packet is a fragment and MUST be > > combined with the other corresponding fragments to reassemble the > > complete information exchanged between the WTP and AC. > > =20 > > 4.1.6. L Bit > > =20 > > 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,=20 > the packet is > > the last fragment. > >=20 > > 4.1.7. M Bit > > =20 > > The M bit is used to indicate that the Radio MAC Address optional > > header is present. This is used to communicate the MAC=20 > address of=20 > > the receiving radio when the native wireless packet. This field=20 > > MUST NOT be set to one in packets sent by the AC to the WTP. > >=20 > > 4.1.8. Reserved > > =20 > > The 15-bit Reserved field is reserved and set to 0 in=20 > this version=20 > > of the > > CAPWAP protocol. > > =20 > > 4.1.9. Fragment ID > > =20 > > An 16 bit field whose value is assigned to each group of=20 > 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=20 > Fragment ID wraps to > > zero after the maximum value has been used to identify a set of > > fragments. =20 > > =20 > > 4.1.10. Fragment Offset > > =20 > > A 13 bit field that indicates where in the payload will this=20 > > fragment belong > > during re-assembly. This field is valid when the 'F' bit=20 > is set to 1. > > The=20 > > fragment offset is measured in units of 8 octets (64 bits). The=20 > > first > >=20 > > fragment has offset zero.=20 > > =20 > > 4.1.11. Reserved-2 > > =20 > > The 3-bit Reserved-2 field is reserved and set to 0 in=20 > this version=20 > > of the > > CAPWAP protocol. > >=20 > > 4.1.12. Radio MAC Address > >=20 > > This optional field contains the MAC address of the=20 > radio receiving=20 > > the > > packet. This is useful in packets sent from the WTP to=20 > the AC, when=20 > > the > > native wireless frame format is converted to 802.3 by=20 > the WTP. This=20 > > field > > is only present if the 'M' bit is set. > >=20 > > 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=20 > 7 8 9 0 1 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Length | MAC Address > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > Length: The number of bytes in the MAC Address field.=20 > The length=20 > > field > > is present since new IEEE technologies are using 48 byte MAC=20 > > addresses > >=20 > > MAC Address: MAC Address of the receiving radio > >=20 > > =20 > > 4.1.13. Wireless Specific Information > >=20 > > This optional field contains technology specific=20 > information that may > > be used to carry per packet wireless information. This field is=20 > > only present > > if the 'W' bit is set. > >=20 > > 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=20 > 7 8 9 0 1 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Wireless ID | Length | Data > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > Wireless ID: The wireless binding identifier. The=20 > following values=20 > > are > > defined: > >=20 > > 1 - IEEE 802.11 > >=20 > > Length: The length of the data field > >=20 > > Data: Wireless specific information, whose details are=20 > defined in=20 > > the > > technology specific binding section. > >=20 > > 4.1.14. Payload > > =20 > > This field contains the header for a CAPWAP Data Message=20 > or CAPWAP > > Control Message, followed by the data associated with=20 > that message. > >=20 > > [...] > >=20 > > 11.3.2. CAPWAP Wireless Specific Information > >=20 > > The reserved CAPWAP header field (see figure Section 4.1) is only > > used with CAPWAP data frames, and it serves two=20 > purposes, depending > > upon the direction of the frame. For packets from the=20 > WTP to the AC, > > the field uses the format described in Section 11.3.2.1.=20 > However, > > for frames sent by the AC to the WTP, the format used is=20 > described in > > described in Section 11.3.2.2. > >=20 > > 11.3.2.1. IEEE 802.11 Frame Info > >=20 > > When an CAPWAP data frame is received from a station=20 > over the air, it > > is encapsulated and this field is used to include radio and PHY > > specific information associated with the frame. > >=20 > > When used with the IEEE 802.11 binding, the field follows the > > following format: > >=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=20 > 6 7 8 9 0 1 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | RSSI | SNR | Data Rate=20 > |=20 > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > RSSI: RSSI is a signed, 8-bit value. It is the received signal > > strength indication, in dBm. > >=20 > > SNR: SNR is a signed, 8-bit value. It is the signal to=20 > noise ratio > > of the received IEEE 802.11 frame, in dB. > >=20 > > Data Rate: The data rate field is a 16 bit unsigned 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=20 > received at > > =20 > > [Rest is identical to -00] > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems=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 >=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 >=20 _________________________________________________________________ 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 May 04 19:11:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbmyu-0003Av-9l for capwap-archive@lists.ietf.org; Thu, 04 May 2006 19:11:36 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbmys-0003yy-L5 for capwap-archive@lists.ietf.org; Thu, 04 May 2006 19:11:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4EADD4300D4 for ; Thu, 4 May 2006 16:11:34 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 822CB430082 for ; Thu, 4 May 2006 16:11:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 698B9398029 for ; Thu, 4 May 2006 16:11:10 -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 904FB398020 for ; Thu, 4 May 2006 16:11:07 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 04 May 2006 16:11:08 -0700 X-IronPort-AV: i="4.05,90,1146466800"; d="scan'208"; a="426382224:sNHT49104954" 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 k44NB5w5023580; Thu, 4 May 2006 16:11:06 -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, 4 May 2006 16:11:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] to mux or not to mux? Date: Thu, 4 May 2006 16:11:05 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D256E5@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] to mux or not to mux? Thread-Index: AcZvhgfIIl8yOPCKRtSyYLSXn2gUGAAAyIfQAA4T/yA= From: "Pat Calhoun (pacalhou)" To: "Kraus, Michael" , X-OriginalArrivalTime: 04 May 2006 23:11:05.0457 (UTC) FILETIME=[05028610:01C66FD0] 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 The point Michael makes here is the same one I was making. Nearly every enterprise class system, router or switch, is capable of providing QoS enforcement using simple ACLs, which rely on IP addresses and ports. QoS is just one of many features that can be (and are) implemented through ACLs that would be very useful to CAPWAP. The use of the MUX makes all of the deployed equipment out there no longer capable of applying QoS based on control/data plane. I think this is a serious issue, and justifies the need for two ports.=20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Kraus, Michael [mailto:Michael.Kraus@anheuser-busch.com]=20 > Sent: Thursday, May 04, 2006 8:17 AM > To: dperkins@dsperkins.com > Cc: capwap@frascone.com > Subject: Re: [Capwap] to mux or not to mux? >=20 > David,=20 > =20 > Maybe I'm misinterpreting something here and may be=20 > somewhat off-topic, but often in QoS you try to classify=20 > traffic by source/destination IP/port or by some higher level=20 > interpreter (such as NBAR in the cisco world). If the same=20 > UDP port number is being used for both control/data, how will=20 > intermediate switches/routers be able to determine what is=20 > control vs. data traffic? This relates back to your comment below of: >=20 > "So, it all comes down to whether or not we want=20 > intermediate network devices to distinguish between control and data." >=20 > One possible method could be for the WTP to assign the=20 > CoS/DSCP values for each traffic type so the administrator=20 > would have the ability to trust the markings provided by the=20 > WTP, or later perform a DSCP-mutation. >=20 > I don't pretend to be a QoS expert, and I'm sure many=20 > products can classify traffic by data outside of known IP/UDP=20 > headers. However, I would argue that this would likely be=20 > platform dependent. For example, Cisco could create a PDLM=20 > for NBAR for these mux values. But, obviously this support=20 > does not exist today, and NBAR is dependent upon=20 > firmware/hardware support. >=20 > We probably need a "neutral" person on this topic to=20 > summarize the Pros/Cons that have been already stated on this issue... >=20 >=20 > Thanks, > Mike >=20 > ------------------------------ >=20 > Message: 2 > Date: Thu, 4 May 2006 07:19:53 -0700 (PDT) > From: "David T. Perkins" > Subject: Re: [Capwap] to mux or not to mux? > To: "Kraus, Michael" > Cc: capwap@frascone.com > Message-ID: > > Content-Type: TEXT/PLAIN; charset=3DUS-ASCII >=20 > HI, >=20 > Since UDP is being used, why cannot the data traffic packets=20 > be marked with a different QoS values than control traffic packets. >=20 > Would you explain and provide an example of use of "current=20 > QoS tools". >=20 > Regards, > /david t. perkins >=20 > On Thu, 4 May 2006, Kraus, Michael wrote: > > One additional upside to using separate ports would be that=20 > different=20 > > QoS >=20 > > policies can be applied against data/control data. With=20 > mux values,=20 > > this >=20 > would > > be more difficult to accomplish with current QoS tools. =20 > With 802.11n=20 > > data > rates > > being quoted, having the ability to do some "control plane=20 > policing"=20 > > for the APs, might be advantageous. > >=20 > >=20 > ---------------------------------------------------------------------- > >=20 > > Message: 1 > > Date: Wed, 3 May 2006 15:16:21 -0700 (PDT) > > From: "David T. Perkins" > > Subject: Re: [Capwap] to mux or not to mux? > > To: Charles Clancy > > Cc: capwap > > Message-ID: > > > > Content-Type: TEXT/PLAIN; charset=3DUS-ASCII > >=20 > > HI, > >=20 > > Please don't forget about the discovery message. With it,=20 > you have 3=20 > > values > for > > MUX. See below.. > >=20 > > Also, please note that in the prototype that I'm=20 > developing, I'm using=20 > > the UNMODIFIED DTLS implementation in openSSL. > > That is, adding the MUX header does not require any modification of=20 > > the > openSSL. > > By the way,my two wishes are: > > 1) an Ethereal decode for the below > > 2) the addition of the NULL encryption type to the > > CAPWAP protocol for debugging > >=20 > > On Wed, 3 May 2006, Charles Clancy wrote: > > > The DTLS tunnels would NOT be merged. You'd have something like: > >=20 > > +---------+------------+------------------------ > > | UDP hdr | MUX =3D 0x00 | Discovery Request or Response > > +---------+------------+----------- > >=20 > >=20 > > > +---------+------------+------------------------ > > > | UDP hdr | MUX =3D 0x01 | DTLS(CAPWAP Control) > > > +---------+------------+----------- > > > > > > or > > > > > > +---------+------------+------------------------ > > > | UDP hdr | MUX =3D 0x02 | CAPWAP Data > > > +---------+------------+----------- > > > > > > UDP is indeed a MUX header, but it's a MUX header that everything=20 > > > already understands. So, it all comes down to whether or not we=20 > > > want intermediate network devices to distinguish between=20 > control and data. > > > For NAT traversal, it's easier if the NAT treats everything the=20 > > > same, and doesn't have to know that the two ports are=20 > related. Same=20 > > > for firewall / port forwarding. I think intermediate network=20 > > > devices should treat everything as "CAPWAP", and we=20 > should therefore do our own MUX. > > > > > > -- > > > t. charles clancy, ph.d. | tcc@umd.edu | =20 > www.cs.umd.edu/~clancy > > > > > > Nancy Winget (ncamwing) wrote: > > > > Charles, > > > > > > > > With a MUX, yes they are logical channels, but I believe the=20 > > > > implication is that these channels are merged into a=20 > single DTLS=20 > > > > tunnel...are you saying they are not? > > > > > > > > But as you state, if UDP is a MUX header, why the need to=20 > > > > introduce yet another one instead of just using UDP for=20 > separation? > > > > > > > > Nancy. > > > > >=20 _________________________________________________________________ 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 May 04 19:34:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbnLR-0004iU-Mg for capwap-archive@lists.ietf.org; Thu, 04 May 2006 19:34:53 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbnLP-0004qT-UN for capwap-archive@lists.ietf.org; Thu, 04 May 2006 19:34:53 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 332754300CE for ; Thu, 4 May 2006 16:34:51 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 8FDBF430082 for ; Thu, 4 May 2006 16:34:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7BDD8398011 for ; Thu, 4 May 2006 16:34:24 -0700 (PDT) X-Greylist-Status: Sender first seen 1 mon 13 days 06:00:23 ago Received: from sinett.com (63-197-255-151.ded.pacbell.net [63.197.255.151]) by zoidberg.tigertech.net (Postfix) with ESMTP id 73551398014 for ; Thu, 4 May 2006 16:34:22 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header Date: Thu, 4 May 2006 16:34:22 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 53: Add Data Rate to LWAPP Header Thread-Index: AcZvw7mgpUL/LygASMGoMpGhNClz0wAC+7iwAAC8t6A= From: "Abhijit Choudhury" To: "Pat Calhoun (pacalhou)" , "Jim Murphy" 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: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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: 913ee11e7c554f7d4da75d500826397e Pat, I agree with Jim. It's easier if the packet header conveys this information, i.e., what kind of payload it is carrying. On a related note, shouldn't RadioId be part of the Wireless Specific Information field ? Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, May 04, 2006 4:09 PM To: Jim Murphy Cc: capwap Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header Do you really see a WTP supporting both simultaneously? My thinking is that the AC knows in advance and simply programs its data forwarding engine accordingly. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Jim Murphy [mailto:jmurphy@trapezenetworks.com] > Sent: Thursday, May 04, 2006 2:40 PM > To: Pat Calhoun (pacalhou) > Cc: capwap > Subject: Re: [Capwap] Issue 53: Add Data Rate to LWAPP Header >=20 > Pat, >=20 > Looks great. Any chance we can get a payload type in the header? It=20 > would be nice for a switching system to be able to switch arbitrary=20 > payload types (802.11, 802.3, etc.). I think 8 bits from your Reserved > field would suffice. >=20 > Thanks, >=20 > Jim >=20 > Pat Calhoun (pacalhou) wrote: > > All, > >=20 > > The following is a proposed new CAPWAP header format, as a > result of > > discussions on the list. Comments are most welcomed. > >=20 > > 4.1. CAPWAP Transport Header > > =20 > > All CAPWAP protocol messages are encapsulated using a > common header > > format, regardless of the CAPWAP control or CAPWAP Data transport > > used to carry the messages. However, certain flags are not > > applicable for a given transport. Refer to the specific > transport > > section in order to determine which flags are valid. > > =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 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |VERSION| RID | HLEN |W|F|L|M| Reserved =20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Fragment ID | Frag Offset =20 > |Rsv-2| > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | (optional) Radio MAC Address =20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | (optional) Wireless Specific Information =20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Payload .... =20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > =20 > > 4.1.1. VERSION Field > > =20 > > A 4 bit field which contains the version of CAPWAP used in this > > packet. The value for this draft is 0. > > =20 > > 4.1.2. RID Field > > =20 > > A 5 bit field which contains the Radio ID number for this packet. > > WTPs with multiple radios but a single MAC Address use > this field to > > indicate which radio is associated with the packet. > > =20 > > 4.1.3. HLEN > > Length of CAPWAP tunnel header in 4 byte words. (Similar to IP > > header length). This length includes the optional headers. > >=20 > > 4.1.4. W Bit > > =20 > > 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 header is > > present. > >=20 > > 4.1.5. F Bit > > =20 > > The Fragment 'F' bit indicates whether this packet is a fragment. > > When this bit is one (1), the packet is a fragment and MUST be > > combined with the other corresponding fragments to reassemble the > > complete information exchanged between the WTP and AC. > > =20 > > 4.1.6. L Bit > > =20 > > 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. > >=20 > > 4.1.7. M Bit > > =20 > > The M bit is used to indicate that the Radio MAC Address optional > > header is present. This is used to communicate the MAC > address of > > the receiving radio when the native wireless packet. This field=20 > > MUST NOT be set to one in packets sent by the AC to the WTP. > >=20 > > 4.1.8. Reserved > > =20 > > The 15-bit Reserved field is reserved and set to 0 in > this version > > of the > > CAPWAP protocol. > > =20 > > 4.1.9. Fragment ID > > =20 > > An 16 bit 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 > Fragment ID wraps to > > zero after the maximum value has been used to identify a set of > > fragments. > > =20 > > 4.1.10. Fragment Offset > > =20 > > A 13 bit field that indicates where in the payload will this > > fragment belong > > during re-assembly. This field is valid when the 'F' bit=20 > is set to 1. > > The=20 > > fragment offset is measured in units of 8 octets (64 bits). The > > first > >=20 > > fragment has offset zero. > > =20 > > 4.1.11. Reserved-2 > > =20 > > The 3-bit Reserved-2 field is reserved and set to 0 in > this version > > of the > > CAPWAP protocol. > >=20 > > 4.1.12. Radio MAC Address > >=20 > > This optional field contains the MAC address of the > radio receiving > > the > > packet. This is useful 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. > >=20 > > 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 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Length | MAC Address > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > Length: The number of bytes in the MAC Address field. > The length > > field > > is present since new IEEE technologies are using 48 byte MAC > > addresses > >=20 > > MAC Address: MAC Address of the receiving radio > >=20 > > =20 > > 4.1.13. Wireless Specific Information > >=20 > > 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. > >=20 > > 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 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Wireless ID | Length | Data > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > Wireless ID: The wireless binding identifier. The > following values > > are > > defined: > >=20 > > 1 - IEEE 802.11 > >=20 > > Length: The length of the data field > >=20 > > Data: Wireless specific information, whose details are > defined in > > the > > technology specific binding section. > >=20 > > 4.1.14. Payload > > =20 > > This field contains the header for a CAPWAP Data Message > or CAPWAP > > Control Message, followed by the data associated with > that message. > >=20 > > [...] > >=20 > > 11.3.2. CAPWAP Wireless Specific Information > >=20 > > The reserved CAPWAP header field (see figure Section 4.1) is only > > used with CAPWAP data frames, and it serves two > purposes, depending > > upon the direction of the frame. For packets from the > WTP to the AC, > > the field uses the format described in Section 11.3.2.1. > However, > > for frames sent by the AC to the WTP, the format used is > described in > > described in Section 11.3.2.2. > >=20 > > 11.3.2.1. IEEE 802.11 Frame Info > >=20 > > When an CAPWAP data frame is received from a station > over the air, it > > is encapsulated and this field is used to include radio and PHY > > specific information associated with the frame. > >=20 > > When used with the IEEE 802.11 binding, the field follows the > > following format: > >=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 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | RSSI | SNR | Data Rate=20 > | > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > RSSI: RSSI is a signed, 8-bit value. It is the received signal > > strength indication, in dBm. > >=20 > > SNR: SNR is a signed, 8-bit value. It is the signal to > noise ratio > > of the received IEEE 802.11 frame, in dB. > >=20 > > Data Rate: The data rate field is a 16 bit unsigned 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 > > =20 > > [Rest is identical to -00] > >=20 > > 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 > >=20 > > Archives: http://lists.frascone.com/pipermail/capwap >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit:=20 > http://lists.frascone.com/mailman/listinfo/capwap >=20 > Archives: http://lists.frascone.com/pipermail/capwap >=20 _________________________________________________________________ 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 May 04 20:09:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbnse-0001PE-6s for capwap-archive@lists.ietf.org; Thu, 04 May 2006 20:09:12 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbnsc-00064J-Cz for capwap-archive@lists.ietf.org; Thu, 04 May 2006 20:09:12 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 73C484300D4 for ; Thu, 4 May 2006 17:09:09 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 44168430082 for ; Thu, 4 May 2006 17:08:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1E618398020 for ; Thu, 4 May 2006 17:08:41 -0700 (PDT) Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0F0DB398014 for ; Thu, 4 May 2006 17:08:37 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-3.cisco.com with ESMTP; 04 May 2006 17:08:37 -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 k4508bh0027079; Thu, 4 May 2006 17:08:37 -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, 4 May 2006 17:08:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header Date: Thu, 4 May 2006 17:08:37 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D2572D@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 53: Add Data Rate to LWAPP Header Thread-Index: AcZvw7mgpUL/LygASMGoMpGhNClz0wAC+7iwAAC8t6AAAVqYUA== From: "Pat Calhoun (pacalhou)" To: "Abhijit Choudhury" , "Jim Murphy" X-OriginalArrivalTime: 05 May 2006 00:08:37.0319 (UTC) FILETIME=[0E7ADD70:01C66FD8] 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae But do you believe that WTPs would send both simultaneously? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Abhijit Choudhury [mailto:Abhijit@sinett.com]=20 > Sent: Thursday, May 04, 2006 4:34 PM > To: Pat Calhoun (pacalhou); Jim Murphy > Cc: capwap > Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header >=20 > Pat, > I agree with Jim. It's easier if the packet header conveys=20 > this information, i.e., what kind of payload it is carrying. >=20 > On a related note, shouldn't RadioId be part of the Wireless=20 > Specific Information field ? >=20 > Thanks, > Abhijit >=20 >=20 >=20 >=20 > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Thursday, May 04, 2006 4:09 PM > To: Jim Murphy > Cc: capwap > Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header >=20 >=20 > Do you really see a WTP supporting both simultaneously? My thinking is > that the AC knows in advance and simply programs its data forwarding > engine accordingly. >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 > =20 >=20 > > -----Original Message----- > > From: Jim Murphy [mailto:jmurphy@trapezenetworks.com] > > Sent: Thursday, May 04, 2006 2:40 PM > > To: Pat Calhoun (pacalhou) > > Cc: capwap > > Subject: Re: [Capwap] Issue 53: Add Data Rate to LWAPP Header > >=20 > > Pat, > >=20 > > Looks great. Any chance we can get a payload type in the header? It=20 > > would be nice for a switching system to be able to switch arbitrary=20 > > payload types (802.11, 802.3, etc.). I think 8 bits from=20 > your Reserved >=20 > > field would suffice. > >=20 > > Thanks, > >=20 > > Jim > >=20 > > Pat Calhoun (pacalhou) wrote: > > > All, > > >=20 > > > The following is a proposed new CAPWAP header format, as a > > result of > > > discussions on the list. Comments are most welcomed. > > >=20 > > > 4.1. CAPWAP Transport Header > > > =20 > > > All CAPWAP protocol messages are encapsulated using a > > common header > > > format, regardless of the CAPWAP control or CAPWAP=20 > Data transport > > > used to carry the messages. However, certain flags are not > > > applicable for a given transport. Refer to the specific > > transport > > > section in order to determine which flags are valid. > > > =20 > > > 0 1 2 =20 > 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 > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |VERSION| RID | HLEN |W|F|L|M| Reserved =20 > > | > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Fragment ID | Frag Offset =20 > > |Rsv-2| > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | (optional) Radio MAC Address =20 > > | > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | (optional) Wireless Specific Information =20 > > | > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Payload .... =20 > > | > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > =20 > > > 4.1.1. VERSION Field > > > =20 > > > A 4 bit field which contains the version of CAPWAP used in this > > > packet. The value for this draft is 0. > > > =20 > > > 4.1.2. RID Field > > > =20 > > > A 5 bit field which contains the Radio ID number for=20 > this packet. > > > WTPs with multiple radios but a single MAC Address use > > this field to > > > indicate which radio is associated with the packet. > > > =20 > > > 4.1.3. HLEN > > > Length of CAPWAP tunnel header in 4 byte words. (Similar to IP > > > header length). This length includes the optional headers. > > >=20 > > > 4.1.4. W Bit > > > =20 > > > 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 header is > > > present. > > >=20 > > > 4.1.5. F Bit > > > =20 > > > The Fragment 'F' bit indicates whether this packet is=20 > a fragment. > > > When this bit is one (1), the packet is a fragment and MUST be > > > combined with the other corresponding fragments to=20 > reassemble the > > > complete information exchanged between the WTP and AC. > > > =20 > > > 4.1.6. L Bit > > > =20 > > > 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=20 > is 1, the > > > packet is not the last fragment. When this bit is 0, > > the packet is > > > the last fragment. > > >=20 > > > 4.1.7. M Bit > > > =20 > > > The M bit is used to indicate that the Radio MAC=20 > Address optional > > > header is present. This is used to communicate the MAC > > address of > > > the receiving radio when the native wireless packet.=20 > This field=20 > > > MUST NOT be set to one in packets sent by the AC to the WTP. > > >=20 > > > 4.1.8. Reserved > > > =20 > > > The 15-bit Reserved field is reserved and set to 0 in > > this version > > > of the > > > CAPWAP protocol. > > > =20 > > > 4.1.9. Fragment ID > > > =20 > > > An 16 bit 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=20 > Fragment ID is > > > incremented with each new set of fragments. The > > Fragment ID wraps to > > > zero after the maximum value has been used to identify a set of > > > fragments. > > > =20 > > > 4.1.10. Fragment Offset > > > =20 > > > A 13 bit field that indicates where in the payload will this > > > fragment belong > > > during re-assembly. This field is valid when the 'F' bit=20 > > is set to 1. > > > The=20 > > > fragment offset is measured in units of 8 octets (64 bits). The > > > first > > >=20 > > > fragment has offset zero. > > > =20 > > > 4.1.11. Reserved-2 > > > =20 > > > The 3-bit Reserved-2 field is reserved and set to 0 in > > this version > > > of the > > > CAPWAP protocol. > > >=20 > > > 4.1.12. Radio MAC Address > > >=20 > > > This optional field contains the MAC address of the > > radio receiving > > > the > > > packet. This is useful 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. > > >=20 > > > The field contains the basic format: > > > 0 1 2 =20 > 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 > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Length | MAC Address > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >=20 > > > Length: The number of bytes in the MAC Address field. > > The length > > > field > > > is present since new IEEE technologies are using 48 byte MAC > > > addresses > > >=20 > > > MAC Address: MAC Address of the receiving radio > > >=20 > > > =20 > > > 4.1.13. Wireless Specific Information > > >=20 > > > 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. > > >=20 > > > The field contains the basic format: > > > 0 1 2 =20 > 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 > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Wireless ID | Length | Data > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >=20 > > > Wireless ID: The wireless binding identifier. The > > following values > > > are > > > defined: > > >=20 > > > 1 - IEEE 802.11 > > >=20 > > > Length: The length of the data field > > >=20 > > > Data: Wireless specific information, whose details are > > defined in > > > the > > > technology specific binding section. > > >=20 > > > 4.1.14. Payload > > > =20 > > > This field contains the header for a CAPWAP Data Message > > or CAPWAP > > > Control Message, followed by the data associated with > > that message. > > >=20 > > > [...] > > >=20 > > > 11.3.2. CAPWAP Wireless Specific Information > > >=20 > > > The reserved CAPWAP header field (see figure Section=20 > 4.1) is only > > > used with CAPWAP data frames, and it serves two > > purposes, depending > > > upon the direction of the frame. For packets from the > > WTP to the AC, > > > the field uses the format described in Section 11.3.2.1. > > However, > > > for frames sent by the AC to the WTP, the format used is > > described in > > > described in Section 11.3.2.2. > > >=20 > > > 11.3.2.1. IEEE 802.11 Frame Info > > >=20 > > > When an CAPWAP data frame is received from a station > > over the air, it > > > is encapsulated and this field is used to include radio and PHY > > > specific information associated with the frame. > > >=20 > > > When used with the IEEE 802.11 binding, the field follows the > > > following format: > > >=20 > > > 0 1 2 =20 > 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 > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | RSSI | SNR | Data Rate=20 > > | > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >=20 > > > RSSI: RSSI is a signed, 8-bit value. It is the=20 > received signal > > > strength indication, in dBm. > > >=20 > > > SNR: SNR is a signed, 8-bit value. It is the signal to > > noise ratio > > > of the received IEEE 802.11 frame, in dB. > > >=20 > > > Data Rate: The data rate field is a 16 bit unsigned=20 > value. The > > > contents of the field is set to 1/10th of the data=20 > rate of the > > > packet received by the WTP. For instance, a packet > > received at > > > =20 > > > [Rest is identical to -00] > > >=20 > > > 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 > > >=20 > > > Archives: http://lists.frascone.com/pipermail/capwap > >=20 > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit:=20 > > http://lists.frascone.com/mailman/listinfo/capwap > >=20 > > Archives: http://lists.frascone.com/pipermail/capwap > >=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 >=20 _________________________________________________________________ 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 May 04 20:12:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbnvQ-0006RM-1M for capwap-archive@lists.ietf.org; Thu, 04 May 2006 20:12:04 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbnvP-000660-8O for capwap-archive@lists.ietf.org; Thu, 04 May 2006 20:12:04 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D91364300D4 for ; Thu, 4 May 2006 17:12:02 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 45C14430082 for ; Thu, 4 May 2006 17:11:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 31F181448019 for ; Thu, 4 May 2006 17:11:34 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by hermes.tigertech.net (Postfix) with ESMTP id 15A341448004 for ; Thu, 4 May 2006 17:11:31 -0700 (PDT) Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Thu, 04 May 2006 17:11:20 -0700 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id C02422B0; Thu, 4 May 2006 17:11:19 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 8FF2C2AE; Thu, 4 May 2006 17:11:19 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5-GA) with ESMTP id DLH20515; Thu, 4 May 2006 17:11:18 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id ACED720501; Thu, 4 May 2006 17:11:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header Date: Thu, 4 May 2006 17:11:18 -0700 Message-ID: <8954613CA6BB3242A1531D916A527A41BDADA0@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [Capwap] Issue 53: Add Data Rate to LWAPP Header Thread-Index: AcZvw7mgpUL/LygASMGoMpGhNClz0wAC+7iwAAD4CCA= From: "Puneet Agarwal" To: "Pat Calhoun (pacalhou)" , "Jim Murphy" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006050409; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230352E34343541393635312E303031462D412D; ENG=IBF; TS=20060505001124; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006050409_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 684447AD4I85997927-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 Hi Pat, You are right that the payload type would typically be known by the AC - however this configuration information is typically not known by other systems (eg you are doing packet mirroring to an remote port analyzer from a device between AC and WTP - the port analyzer would be unable to parse the payload effectively as it wouldn't know the payload type). Hence it is important that the CAPWAP header define the payload (802.3, 802.11 etc) so other network devices can parse the packet if they want to. Other comments/questions: (1) Section 4.1.6: I think intuitively, it would be better if we re-define the bit as follows "The 'L' (Last) 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. Specifically: 1: Last fragment 0: Not last fragment" (2) Section 4.1.12: I assume you meant 48 bits (not bytes). (3) General: Are each of the optional headers required to be a multiple of 4 bytes (since the HLEN is required to be a multiple of 4 bytes)? If not, then do we need to define padding headers? (4) General: Is there any requirement on the ordering of the optional headers? (5) Section 4.1.10: Since you have introduced the notion of fragment offset, do we then allow for overlapping fragments (eg fragment 0 has {offset 0, payload length 1000} and fragment 1 has {offset 900, payload length 600})? My preference would be to disallow this behavior. (6) General: I assume that there would be a capability mechanism (for the AC to indicate to the WTP(s)) to specify which optional header the AC supports. Thanks. -Puneet -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, May 04, 2006 4:09 PM To: Jim Murphy Cc: capwap Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header Do you really see a WTP supporting both simultaneously? My thinking is that the AC knows in advance and simply programs its data forwarding engine accordingly. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Jim Murphy [mailto:jmurphy@trapezenetworks.com] > Sent: Thursday, May 04, 2006 2:40 PM > To: Pat Calhoun (pacalhou) > Cc: capwap > Subject: Re: [Capwap] Issue 53: Add Data Rate to LWAPP Header >=20 > Pat, >=20 > Looks great. Any chance we can get a payload type in the header? > It would be nice for a switching system to be able to switch arbitrary > payload types (802.11, 802.3, etc.). I think 8 bits from your Reserved > field would suffice. >=20 > Thanks, >=20 > Jim >=20 > Pat Calhoun (pacalhou) wrote: > > All, > >=20 > > The following is a proposed new CAPWAP header format, as a > result of > > discussions on the list. Comments are most welcomed. > >=20 > > 4.1. CAPWAP Transport Header > > =20 > > All CAPWAP protocol messages are encapsulated using a > common header > > format, regardless of the CAPWAP control or CAPWAP Data transport > > used to carry the messages. However, certain flags are not > > applicable for a given transport. Refer to the specific > transport > > section in order to determine which flags are valid. > > =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 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |VERSION| RID | HLEN |W|F|L|M| Reserved =20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Fragment ID | Frag Offset =20 > |Rsv-2| > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | (optional) Radio MAC Address =20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | (optional) Wireless Specific Information =20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Payload .... =20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > =20 > > 4.1.1. VERSION Field > > =20 > > A 4 bit field which contains the version of CAPWAP used in this > > packet. The value for this draft is 0. > > =20 > > 4.1.2. RID Field > > =20 > > A 5 bit field which contains the Radio ID number for this packet. > > WTPs with multiple radios but a single MAC Address use > this field to > > indicate which radio is associated with the packet. > > =20 > > 4.1.3. HLEN > > Length of CAPWAP tunnel header in 4 byte words. (Similar to IP > > header length). This length includes the optional headers. > >=20 > > 4.1.4. W Bit > > =20 > > 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 header is=20 > > present. > >=20 > > 4.1.5. F Bit > > =20 > > The Fragment 'F' bit indicates whether this packet is a fragment. > > When this bit is one (1), the packet is a fragment and MUST be > > combined with the other corresponding fragments to reassemble the > > complete information exchanged between the WTP and AC. > > =20 > > 4.1.6. L Bit > > =20 > > 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. > >=20 > > 4.1.7. M Bit > > =20 > > The M bit is used to indicate that the Radio MAC Address optional > > header is present. This is used to communicate the MAC > address of > > the receiving radio when the native wireless packet. This field=20 > > MUST NOT be set to one in packets sent by the AC to the WTP. > >=20 > > 4.1.8. Reserved > > =20 > > The 15-bit Reserved field is reserved and set to 0 in > this version > > of the > > CAPWAP protocol. > > =20 > > 4.1.9. Fragment ID > > =20 > > An 16 bit 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 > Fragment ID wraps to > > zero after the maximum value has been used to identify a set of > > fragments. =20 > > =20 > > 4.1.10. Fragment Offset > > =20 > > A 13 bit field that indicates where in the payload will this=20 > > fragment belong > > during re-assembly. This field is valid when the 'F' bit > is set to 1. > > The=20 > > fragment offset is measured in units of 8 octets (64 bits). The=20 > > first > >=20 > > fragment has offset zero.=20 > > =20 > > 4.1.11. Reserved-2 > > =20 > > The 3-bit Reserved-2 field is reserved and set to 0 in > this version > > of the > > CAPWAP protocol. > >=20 > > 4.1.12. Radio MAC Address > >=20 > > This optional field contains the MAC address of the > radio receiving > > the > > packet. This is useful 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. > >=20 > > 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 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Length | MAC Address > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > Length: The number of bytes in the MAC Address field.=20 > The length > > field > > is present since new IEEE technologies are using 48 byte MAC=20 > > addresses > >=20 > > MAC Address: MAC Address of the receiving radio > >=20 > > =20 > > 4.1.13. Wireless Specific Information > >=20 > > This optional field contains technology specific > information that may > > be used to carry per packet wireless information. This field is=20 > > only present > > if the 'W' bit is set. > >=20 > > 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 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Wireless ID | Length | Data > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > Wireless ID: The wireless binding identifier. The > following values > > are > > defined: > >=20 > > 1 - IEEE 802.11 > >=20 > > Length: The length of the data field > >=20 > > Data: Wireless specific information, whose details are > defined in > > the > > technology specific binding section. > >=20 > > 4.1.14. Payload > > =20 > > This field contains the header for a CAPWAP Data Message > or CAPWAP > > Control Message, followed by the data associated with > that message. > >=20 > > [...] > >=20 > > 11.3.2. CAPWAP Wireless Specific Information > >=20 > > The reserved CAPWAP header field (see figure Section 4.1) is only > > used with CAPWAP data frames, and it serves two > purposes, depending > > upon the direction of the frame. For packets from the > WTP to the AC, > > the field uses the format described in Section 11.3.2.1.=20 > However, > > for frames sent by the AC to the WTP, the format used is > described in > > described in Section 11.3.2.2. > >=20 > > 11.3.2.1. IEEE 802.11 Frame Info > >=20 > > When an CAPWAP data frame is received from a station > over the air, it > > is encapsulated and this field is used to include radio and PHY > > specific information associated with the frame. > >=20 > > When used with the IEEE 802.11 binding, the field follows the > > following format: > >=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 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | RSSI | SNR | Data Rate=20 > | > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > RSSI: RSSI is a signed, 8-bit value. It is the received signal > > strength indication, in dBm. > >=20 > > SNR: SNR is a signed, 8-bit value. It is the signal to > noise ratio > > of the received IEEE 802.11 frame, in dB. > >=20 > > Data Rate: The data rate field is a 16 bit unsigned 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 > > =20 > > [Rest is identical to -00] > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems=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 >=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 >=20 _________________________________________________________________ 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 May 04 21:42:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbpKc-0006Sp-Az for capwap-archive@lists.ietf.org; Thu, 04 May 2006 21:42:10 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbpKa-0001IZ-Qr for capwap-archive@lists.ietf.org; Thu, 04 May 2006 21:42:10 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 85DE64300D6 for ; Thu, 4 May 2006 18:42:07 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6DE33430059 for ; Thu, 4 May 2006 18:41:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6054439801D for ; Thu, 4 May 2006 18:41:49 -0700 (PDT) Received: from trpz.com (mail1.trpz.com [66.7.225.38]) by zoidberg.tigertech.net (Postfix) with ESMTP id 41252398016 for ; Thu, 4 May 2006 18:41:44 -0700 (PDT) Received: from [127.0.0.1] ([192.168.12.194]) by trpz.com (8.13.5/8.11.6) with ESMTP id k450dBXw001715; Thu, 4 May 2006 17:39:12 -0700 Message-ID: <445AAD51.1060109@trapezenetworks.com> Date: Thu, 04 May 2006 18:41:37 -0700 From: Jim Murphy User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" Subject: Re: [Capwap] Issue 53: Add Data Rate to LWAPP Header References: <4FF84B0BC277FF45AA27FE969DD956A201D2572D@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201D2572D@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 , Abhijit Choudhury X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b If the WTP supported both 802.11 and 802.16. 802.16 encapsulates 802.3 frames. Thanks, Jim Pat Calhoun (pacalhou) wrote: > But do you believe that WTPs would send both simultaneously? > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > >> -----Original Message----- >> From: Abhijit Choudhury [mailto:Abhijit@sinett.com] >> Sent: Thursday, May 04, 2006 4:34 PM >> To: Pat Calhoun (pacalhou); Jim Murphy >> Cc: capwap >> Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header >> >> Pat, >> I agree with Jim. It's easier if the packet header conveys >> this information, i.e., what kind of payload it is carrying. >> >> On a related note, shouldn't RadioId be part of the Wireless >> Specific Information field ? >> >> Thanks, >> 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 Thu May 04 22:04:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbpfx-0008IO-9h for capwap-archive@lists.ietf.org; Thu, 04 May 2006 22:04:13 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbpfv-0001sp-FO for capwap-archive@lists.ietf.org; Thu, 04 May 2006 22:04:13 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id EF82A4300DC for ; Thu, 4 May 2006 19:04:10 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 126BE430059 for ; Thu, 4 May 2006 19:03:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E665839801D for ; Thu, 4 May 2006 19:03:45 -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 495FD398014 for ; Thu, 4 May 2006 19:03:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=QD7Fs7ShTXFToho6oiJavbtI/dzJhJy/uZW5+cFoQ3nzxmAcUFuDYgqV525KiVd7; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.53] (helo=elwamui-wigeon.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FbpfQ-0003P0-8a; Thu, 04 May 2006 22:03:40 -0400 Received: from 72.114.175.125 by webmail.pas.earthlink.net with HTTP; Thu, 4 May 2006 22:03:40 -0400 Message-ID: <9946222.1146794620209.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Date: Thu, 4 May 2006 19:03:40 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "Pat Calhoun (pacalhou)" , "Kraus,Michael" , dperkins@dsperkins.com Subject: RE: [Capwap] to mux or not to mux? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710475b5ccd32ee34f7287b8c1a24431e06350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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: Cc: capwap@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Please explain what problem is encountered if the same QoS policy is applied to both control and data traffic. Also explain why any such problems cannot be solved by having the WTP and/or AC apply appropriate DSCP or 802.1q marking. -----Original Message----- >From: "Pat Calhoun (pacalhou)" >Sent: May 4, 2006 4:11 PM >To: "Kraus, Michael" , dperkins@dsperkins.com >Cc: capwap@frascone.com >Subject: RE: [Capwap] to mux or not to mux? > >The point Michael makes here is the same one I was making. Nearly every >enterprise class system, router or switch, is capable of providing QoS >enforcement using simple ACLs, which rely on IP addresses and ports. QoS >is just one of many features that can be (and are) implemented through >ACLs that would be very useful to CAPWAP. > >The use of the MUX makes all of the deployed equipment out there no >longer capable of applying QoS based on control/data plane. I think this >is a serious issue, and justifies the need for two ports. > >Pat Calhoun >CTO, Wireless Networking Business Unit >Cisco Systems > > > >> -----Original Message----- >> From: Kraus, Michael [mailto:Michael.Kraus@anheuser-busch.com] >> Sent: Thursday, May 04, 2006 8:17 AM >> To: dperkins@dsperkins.com >> Cc: capwap@frascone.com >> Subject: Re: [Capwap] to mux or not to mux? >> >> David, >> >> Maybe I'm misinterpreting something here and may be >> somewhat off-topic, but often in QoS you try to classify >> traffic by source/destination IP/port or by some higher level >> interpreter (such as NBAR in the cisco world). If the same >> UDP port number is being used for both control/data, how will >> intermediate switches/routers be able to determine what is >> control vs. data traffic? This relates back to your comment below of: >> >> "So, it all comes down to whether or not we want >> intermediate network devices to distinguish between control and data." >> >> One possible method could be for the WTP to assign the >> CoS/DSCP values for each traffic type so the administrator >> would have the ability to trust the markings provided by the >> WTP, or later perform a DSCP-mutation. >> >> I don't pretend to be a QoS expert, and I'm sure many >> products can classify traffic by data outside of known IP/UDP >> headers. However, I would argue that this would likely be >> platform dependent. For example, Cisco could create a PDLM >> for NBAR for these mux values. But, obviously this support >> does not exist today, and NBAR is dependent upon >> firmware/hardware support. >> >> We probably need a "neutral" person on this topic to >> summarize the Pros/Cons that have been already stated on this issue... >> >> >> Thanks, >> Mike >> >> ------------------------------ >> >> Message: 2 >> Date: Thu, 4 May 2006 07:19:53 -0700 (PDT) >> From: "David T. Perkins" >> Subject: Re: [Capwap] to mux or not to mux? >> To: "Kraus, Michael" >> Cc: capwap@frascone.com >> Message-ID: >> >> Content-Type: TEXT/PLAIN; charset=US-ASCII >> >> HI, >> >> Since UDP is being used, why cannot the data traffic packets >> be marked with a different QoS values than control traffic packets. >> >> Would you explain and provide an example of use of "current >> QoS tools". >> >> Regards, >> /david t. perkins >> >> On Thu, 4 May 2006, Kraus, Michael wrote: >> > One additional upside to using separate ports would be that >> different >> > QoS >> >> > policies can be applied against data/control data. With >> mux values, >> > this >> >> would >> > be more difficult to accomplish with current QoS tools. >> With 802.11n >> > data >> rates >> > being quoted, having the ability to do some "control plane >> policing" >> > for the APs, might be advantageous. >> > >> > >> ---------------------------------------------------------------------- >> > >> > Message: 1 >> > Date: Wed, 3 May 2006 15:16:21 -0700 (PDT) >> > From: "David T. Perkins" >> > Subject: Re: [Capwap] to mux or not to mux? >> > To: Charles Clancy >> > Cc: capwap >> > Message-ID: >> > >> > Content-Type: TEXT/PLAIN; charset=US-ASCII >> > >> > HI, >> > >> > Please don't forget about the discovery message. With it, >> you have 3 >> > values >> for >> > MUX. See below.. >> > >> > Also, please note that in the prototype that I'm >> developing, I'm using >> > the UNMODIFIED DTLS implementation in openSSL. >> > That is, adding the MUX header does not require any modification of >> > the >> openSSL. >> > By the way,my two wishes are: >> > 1) an Ethereal decode for the below >> > 2) the addition of the NULL encryption type to the >> > CAPWAP protocol for debugging >> > >> > On Wed, 3 May 2006, Charles Clancy wrote: >> > > The DTLS tunnels would NOT be merged. You'd have something like: >> > >> > +---------+------------+------------------------ >> > | UDP hdr | MUX = 0x00 | Discovery Request or Response >> > +---------+------------+----------- >> > >> > >> > > +---------+------------+------------------------ >> > > | UDP hdr | MUX = 0x01 | DTLS(CAPWAP Control) >> > > +---------+------------+----------- >> > > >> > > or >> > > >> > > +---------+------------+------------------------ >> > > | UDP hdr | MUX = 0x02 | CAPWAP Data >> > > +---------+------------+----------- >> > > >> > > UDP is indeed a MUX header, but it's a MUX header that everything >> > > already understands. So, it all comes down to whether or not we >> > > want intermediate network devices to distinguish between >> control and data. >> > > For NAT traversal, it's easier if the NAT treats everything the >> > > same, and doesn't have to know that the two ports are >> related. Same >> > > for firewall / port forwarding. I think intermediate network >> > > devices should treat everything as "CAPWAP", and we >> should therefore do our own MUX. >> > > >> > > -- >> > > t. charles clancy, ph.d. | tcc@umd.edu | >> www.cs.umd.edu/~clancy >> > > >> > > Nancy Winget (ncamwing) wrote: >> > > > Charles, >> > > > >> > > > With a MUX, yes they are logical channels, but I believe the >> > > > implication is that these channels are merged into a >> single DTLS >> > > > tunnel...are you saying they are not? >> > > > >> > > > But as you state, if UDP is a MUX header, why the need to >> > > > introduce yet another one instead of just using UDP for >> separation? >> > > > >> > > > Nancy. >> > > > >> >_________________________________________________________________ >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 May 04 22:34:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbq94-00069y-Kg for capwap-archive@lists.ietf.org; Thu, 04 May 2006 22:34:18 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbq8f-0002js-5J for capwap-archive@lists.ietf.org; Thu, 04 May 2006 22:33:54 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 67FB143010B for ; Thu, 4 May 2006 19:33:52 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 13FFD430059 for ; Thu, 4 May 2006 19:33:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E80E11448008 for ; Thu, 4 May 2006 19:33:26 -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 2E79F1448001 for ; Thu, 4 May 2006 19:33:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=MppJxC/MwuUojTFs0Yp9JWl3vDxFPorOS7HRsY9Xu3+I4kM+ofqNWqmMM9kB5lzT; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.53] (helo=elwamui-wigeon.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Fbq8C-0003Wp-6I; Thu, 04 May 2006 22:33:24 -0400 Received: from 72.114.175.125 by webmail.pas.earthlink.net with HTTP; Thu, 4 May 2006 22:33:24 -0400 Message-ID: <29736562.1146796404141.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Date: Thu, 4 May 2006 19:33:24 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "Bob O'Hara (boohara)" , capwap Subject: RE: [Capwap] to mux or not to mux? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710b57ddec74cf92dd2a6040929766343ac350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.53 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: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 >So, if UDP already provides the equivalent mux functionality, why should >we discard that functionality and try to replace it with something home >grown? The only argument that seems to hold any water at all is that >this preserves, in some sense, the openssl code. This has been clearly articulated in earlier threads on this topic. If defining our own mux header is "homegrown" and we should interpret that pejoratively (which does seem to be the general intent), then defining our own capwap transport header should be viewed similarly. This is misdirection, intentional or not. The reasons why it makes sense to combine data and control into one layer 4 channel have been discussed again and again here. In particular, see the NAT-T thread from the end of March. Splitting these channels raises significiant operational issues. Quoting from the NAT-T thread: "The basic function of the mux header is that it allows you to combine the two channels over one UDP transport session. That accomplishes three things for us: implicit channel binding, elimination of a second keepalive timer and associated processing, and simplification of the state machine, both with respect to normal processing and error states. It's easier to implement and operate." 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; - 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. - 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. And all of this for what? I've heard some nebulous concerns about QoS, but nobody is offering a detailed and persuasive explanation of why all this added complexity is warranted. Please explain exactly what architectures are being precluded, and why this represents a loss that justifies the added effort the dual-port (actually, tri-port, as discover will require it's own port too) path requires. Many of us have been through protocol spec development here before, and we all know how hard this sort of complexity makes interoperability, and this ignores how hard it makes it just to get your *own* implementations working together. >The whole reason CAPWAP exists is as a result of innovation in the >architecture of WLAN systems by a number of different companies. I >don't think that we should be considering a proposal for the protocol >that limits the ability of the users of this protocol to continue to >innovate. If we don't provide the ability for some innovation within >the protocol, all innovation will be done outside the protocol, >resulting in very little, if any, multi-vendor interoperability. To be very clear, agreeing on a minimal interoperable spec that we can actually bring to market in no way prevents anyone from innovating. Nobody is bound by this spec - you are always free to implement your own value-add extensions. Also there is nothing to prevent us from adding functionality to the base spec once it is complete. What I'd like to know is, exactly *what* precluded architecture is so important? What are we losing? 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 May 05 02:39:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbty3-0005hl-45 for capwap-archive@lists.ietf.org; Fri, 05 May 2006 02:39:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbty1-0003T8-8z for capwap-archive@lists.ietf.org; Fri, 05 May 2006 02:39:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9C3E24300F0 for ; Thu, 4 May 2006 23:39:08 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7643E430059 for ; Thu, 4 May 2006 23:38:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 565CB144800D for ; Thu, 4 May 2006 23:38:36 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [12.129.211.51]) by hermes.tigertech.net (Postfix) with ESMTP id 6761F1448001 for ; Thu, 4 May 2006 23:38:33 -0700 (PDT) Received: from huawei.com ([172.24.2.9]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYS00EOB47RHE@usaga01-in.huawei.com> for capwap@frascone.com; Thu, 04 May 2006 23:19:03 -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 <0IYS006HW4QXCE@szxga03-in.huawei.com> for capwap@frascone.com; Fri, 05 May 2006 14:30:33 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYS006H74QW9A@szxga03-in.huawei.com> for capwap@frascone.com; Fri, 05 May 2006 14:30:33 +0800 (CST) Received: from dell60 ([10.18.7.113]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IYS00KND577MT@szxml01-in.huawei.com>; Fri, 05 May 2006 14:40:20 +0800 (CST) Date: Fri, 05 May 2006 11:52:09 +0530 From: sujay Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages In-reply-to: <4FF84B0BC277FF45AA27FE969DD956A201D256BB@xmb-sjc-235.amer.cisco.com> To: "'Pat Calhoun (pacalhou)'" , 'Saravanan Govindan' , 'Dorothy Stanley' Message-id: <009201c6700c$3dbc0ad0$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 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT 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' X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 089da5e32269fece1072c9ff54523f20 Nevertheless, a discovery recvd in the run state should ideally indicate the peer has gone down, Probably a reboot. It may turn out to be a faster way of detecting Nbr Down than waiting for Nbr dead interval. (Of course subject to the packet being authentic) In general, perhaps the draft should specify about "treatment of messages when recvd in the incorrect state". i.e should it be dropped or any action is to be taken. Comments? Regds, Sujay -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Friday, May 05, 2006 4:24 AM To: sujay; Saravanan Govindan; Dorothy Stanley Cc: capwap Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages But we seem to be ignoring the state machine. Keep in mind that this scheme has to co-exist with the state machine, so a discovery received while in the Run state is not a valid packet to reset the timer. All other packets would. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: sujay [mailto:sujayg@huawei.com] > Sent: Thursday, May 04, 2006 5:25 AM > To: 'Saravanan Govindan'; Pat Calhoun (pacalhou); 'Dorothy Stanley' > Cc: 'capwap' > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > -Issueoncombiningmessages > > Saravanan, > > A valid point, yet ALL control messages should be monitored > for which are VALID in the RUN state. > > There is no reason for giving special treatment to statistics > messages alone. > > Considering an implementation, I see no significant overhead > in assuming say a Configure Request packet as a keepalive > packet from the peer. > > Regds, > Sujay > > > > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Thursday, May 04, 2006 2:29 PM > To: Pat Calhoun (pacalhou); Dorothy Stanley > Cc: capwap > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > -Issueoncombiningmessages > > > Without the text below, the specifications will require an AC > to monitor > the arrival of "all" control packet with respect to the > EchoInterval and > NeighbourDeadInterval timers. There were concerns earlier on > this thread > that this is not ideal. > > > Furthermore, not all control packets indicate that a WTP is alive and > doing well. A WTP could fail, re-start and then send Discovery > Requests to an AC. This should not be construed as an indication that > the WTP is > well. On the other hand, by focusing only on Statistics (WTP Event > Request) control messages, it is unambiguous that a WTP is > operational. > > So the text in the specifications should reflect this by having Echo > Requests sent in the absence of Statistics (WTP Event > Request) messages. > > > Saravanan > > > > > > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Thursday, May 04, 2006 12:50 PM > To: Saravanan Govindan; Dorothy Stanley > Cc: Scott G Kelly; capwap > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > -Issueoncombiningmessages > > The text you are proposing doesn't change the behavior of the > protocol. > I'm not sure that it really adds anything since we are stating that an > echo is sent if no control packets are sent. You are free to send > periodic Statistics messages, which with the new language would not > require any Echos to be sent. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Wednesday, May 03, 2006 8:18 PM > To: Dorothy Stanley; Pat Calhoun (pacalhou) > Cc: Scott G Kelly; capwap > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > -Issueoncombiningmessages > Hi Dorothy, > > I suggest that the Echo Request MAY only be send in the absence of > specifically Statistics control packets as opposed to any control > packets. The reason for this is that Statistics packets are the only > regular exchanges, so the AC has just one type of packet to monitor > for the timer. > > So I'd like to suggest the following text: > > From: > "If another Echo Request or other control message is not > received by the > AC when the timer expires, the AC > SHOULD consider the WTP to be unreachable" > > To: > "If another Echo Request or Statistics message is not > received by the AC > when the timer expires, the AC > SHOULD consider the WTP to be unreachable" > > Cheers, > > Saravanan > > > > > > > > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > Sent: Thursday, May 04, 2006 3:03 AM > To: Pat Calhoun (pacalhou) > Cc: Scott G Kelly; Saravanan Govindan; capwap > Subject: Re: [Capwap] Proposed Resolution to Issue 45 > -Issueoncombiningmessages > > All, > > After the lengthy discussion on this topic, I believe that the > conclusion is still to reject the comment, and as Pat summarized, the > echo remains, does not include any > statistics, and MAY only be sent in the absence of any > control packets. > > Changes to the text: > > Change text in 6.2" Echo Response" from: > "If another Echo Request message is not received by the AC when the > timer expires, the AC SHOULD consider the WTP to be unreachable" to > > "If another Echo Request or other control message is not > received by the > AC when the timer expires, the AC > SHOULD consider the WTP to be unreachable" > > and from > > "If the NeighborDeadInterval timer expires prior to receiving an Echo > Response message, message, the WTP enters the Reset State." > to > "If the NeighborDeadInterval timer expires prior to receiving an Echo > Response message, or other control > message, the WTP enters the Reset State." > > > Thanks, > > Dorothy > > Issue 45, Issue on Combining messages currently has the following > discussion in the issues database: Currently, the keepalive and > statistics messages are separated. Separate > > > > > > > > > messages for keepalive signaling and statistics can lead to high > overhead. > > > > > > > > Initial analysis have shown that these overhead can be reduced > significantly > > > > > > > > > > > > > > > > > if the messages can be combined. > > > > > > > > > > > > > > > > Recommendation: > > > > > > > > > > > > > > > > To combine the keepalive and statistics message into one combined > message, > > > > > > > > thus reducing overhead significantly. > > Discussion: > > The CAPWAP protocol specification currently supports the > Echo Request Message and Echo Response Messages, which are used for > keep-alive purposes, and do not carry message elements. > > There is an IEEE 802.11 Statistics measurement element(11.7.2.1), and > several CAPWAP statistics related measurement elements: decryption > error report, WTP descriptor, WTP radio > information, WTP reboot statistics. > There is no statistics message. > > There is no requirement on how often the statistics related > measurement > elements must be reported > to the AC from the WTP, there is a Statistics timer, see > 7.2.5, which is > used by the AC to indicate the > timer value to the WTP. (separate question - should the > statistics timer > be made general, and indicate the > values for the other Section 12 CAPWAP timers too? Assume that the > CAPWAP statistics timer used > to determine how often to send the 802.11 specific statistics). > > It is not clear that there is a high overhead in keeping the > echo/keep-alive mechanism from the statistics reporting. There is some > benefit in keeping the echo messages simple, > rather than complicating the processing of those messages. It is true > that small messages (echo request, response) have high overhead. > In this case, the design choice is to accept the overhead as > the cost of > simplicity in design and implementation. > > Recommended resolution: reject the comment, with the > explanation in the > above paragraph > On 4/28/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com> wrote: > I will summarize my thoughts here and not try to inject in > the various > threads, but I agree that the echo remains, does not include any > statistics, and MAY only be sent in the absence of any > control packets. > I say MAY because an implementation could send them if it wishes, but > the receiver must take into account control packets in > addition to the > echo prior to declaring a link dead. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Scott G Kelly [mailto: scott@hyperthought.com] > > Sent: Friday, April 21, 2006 5:52 AM > > To: Saravanan Govindan > > Cc: capwap > > Subject: Re: [Capwap] Proposed Resolution to Issue 45 > > -Issueoncombiningmessages > > > > Hi Saravanan, > > > > Saravanan Govindan wrote: > > > Hi Scott, > > > > > > I think David's note does address the issue on hand. > > > > > > To formalize; > > > > > > The exchange of control messages between a WTP and AC implicitly > > > indicates that the WTP is operational. For the purpose of protocol > > > simplicity, I suggest that we focus on statistics messages > > alone for > > > this purpose, reason being that statistics are periodically > > exchanged. > > > > > > My concern is that by using "any" control message to indicate > > > keepalive (Echo), the AC processing will be complicated. This is > > > because the AC will need to process each control message > > for both its own value (e.g. > > > Configure Request) and also keepalive value. > > > > Of course, complexity is a function of many factors, but > > there is a straightforward way to implement an echo trigger > > with a flag and timer: > > when you receive a control message, unconditionally raise the flag. > > Periodically (according to your keepalive interval timer) > > check the flag; If it's up, put it down, else send a > > keepalive. There are more complicated ways to implement, but > > this works just fine. > > > > On the AC this can easily be implemented by having the > > fastpath raise the flag, and having the cp lower it and/or do > > whatever it is your AC does if a WTP doesn't report in a > > given echo interval (which may be nothing). Pretty basic stuff. > > > > On the WTP, implementation is similar, except that if the > > flag is down, you send the keepalive. Again, very simple and basic. > > > > > So I suggest keeping it simple - arrival of statistics > message from > > > WTP means WTP is alive. > > > > Certainly, a statistics message qualifies as a control > > message, so I have no issues with this statement when taken > > alone. I'm concerned with the earlier suggestion that the > > echo req/reply message be discarded and replaced by the > > statistics message. > > > > In some cases, the keepalive interval must be *very* brief in order > > to facilitate rapid link loss detection and recovery. I know of one > > vendor who routinely uses a one second interval, and it's > > conceivable that in some scenarios one might choose to use even > > less. > > > > And keep in mind that WTP and AC requirements are typically > > asymmetric in this regard: the WTP needs to react quickly (maybe try > > to find another AC), whereas the AC simply needs to somehow report > > the event. While in some cases reporting might be considered urgent, > > this is not the typical (or average) case. > > > > The granularity requirements for reporting are typically much > > coarser than those of recovery. That is, the AC may, at it's option, > > only check every 10,20,30,... seconds for WTP liveness, and it may > > very well do that via the stats message, rather than the echo, since > > this allows echo processing to remain wholly in the AC fastpath. > > > > But say we eliminate the echo: what happens when, say, 500 WTPs send > > stats potentially every second or less? > > > > I think we still need the echo req/rsp. > > > > Scott > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > > > Sent: Wednesday, April 19, 2006 1:51 AM > > > To: capwap > > > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > > > -Issueoncombiningmessages > > > > > > Just trying to close the loop: I think David's point (i.e. > > that echoes > > > should only be sent in the absence of other control > > traffic) is dead > > > on, and that this effectively closes the question as to > > whether echoes > > > and stats should be combined in the same messages. > > > > > > Does anyone disagree? > > > > > > 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 Fri May 05 07:43:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbyii-00047c-VO for capwap-archive@lists.ietf.org; Fri, 05 May 2006 07:43:40 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbyig-0008H2-G6 for capwap-archive@lists.ietf.org; Fri, 05 May 2006 07:43:40 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 440BD430112 for ; Fri, 5 May 2006 04:43:34 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 339E0430059 for ; Fri, 5 May 2006 04:43:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1CC52430CB3 for ; Fri, 5 May 2006 04:43:10 -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 82A06430CAE for ; Fri, 5 May 2006 04:43:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=S0DtwGLz5bzfXVaPLMg5qOZ9ZM8cjdduVaV5PsbDo1/I2DurKzU1hc7+5OTJFMHS; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.31] (helo=elwamui-chisos.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FbyiA-0003QC-Kj; Fri, 05 May 2006 07:43:06 -0400 Received: from 72.114.67.145 by webmail.pas.earthlink.net with HTTP; Fri, 5 May 2006 07:43:06 -0400 Message-ID: <14351565.1146829386605.JavaMail.root@elwamui-chisos.atl.sa.earthlink.net> Date: Fri, 5 May 2006 04:43:06 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "Bob O'Hara (boohara)" , capwap Subject: RE: [Capwap] to mux or not to mux? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff7108c927555030dca9945ea301ccc555ac1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.31 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: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad One point I forgot to mention: >The only argument that seems to hold any water at all is that >this preserves, in some sense, the openssl code. Openssl has zero to do with this discussion, and is only adding confusion. I've discussed it along with everyone else, to please don't take this as being aimed just at the above post, but I think we're being distracted. The fact is, openssl is obvlivious to whether we use two ports or one. It is an implementation, and the standard we want to be discussing is dtls. Let's not waste any more time discussing it, as it is irrelevant to the issues at hand. 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 michawade@coates.com Fri May 05 08:00:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbyyt-0008B7-Eh for capwap-archive@ietf.org; Fri, 05 May 2006 08:00:23 -0400 Received: from [221.237.211.133] (helo=coates.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fbyyr-0000V3-1e for capwap-archive@ietf.org; Fri, 05 May 2006 08:00:23 -0400 Message-ID: <000001c6703b$5abd3ad0$cf4ca8c0@mkf78> Reply-To: "Wade Michaels" From: "Wade Michaels" To: capwap-archive@ietf.org Subject: Re: good credddit Date: Fri, 5 May 2006 04:59:25 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C67000.AE5E62D0" 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.4 (+++) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C67000.AE5E62D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0002_01C67000.AE5E62D0" ------=_NextPart_001_0002_01C67000.AE5E62D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable the web site =20 =20 =20 =20 =20 It was Bilbo who found that out. Poor Mr. Baggins =13 it was a weary long time that he lived in that place all alone, and always in hiding, never daring to take off his ring, hardly daring to sleep, even tucked away in the darkest and remotest comers he could find. For something to do he took to wandering about the Elven-kings palace. Magic shut the gates, but be could sometimes get out, if he was quick. Companies of the Wood-elves, sometimes with the king at their head, would from time to time ride out to hunt, or to other business in the woods and in the lands to the East. Then if Bilbo was very nimble, he could slip out just behind them; though it was a dangerous thing to do. More than once he was nearly caught in the doors, as they clashed together when the last elf passed, yet he did not dare to march among them because of his shadow (altogether thin and wobbly as it was in torch-light), or for fear of being bumped into and discovered. And when he did go out, which was not very often, he did no good. He did not wish to desert the dwarves, and ------=_NextPart_001_0002_01C67000.AE5E62D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
 
 
 
It was Bilbo who found that out.
Poor Mr. Baggins =80=93 it was a weary long time that he lived in = that
place all alone, and always in hiding, never daring to take off his
ring, hardly daring to sleep, even tucked away in the darkest and
remotest comers he could find. For something to do he took to = wandering
about the Elven-kings palace. Magic shut the gates, but be could
sometimes get out, if he was quick. Companies of the Wood-elves,
sometimes with the king at their head, would from time to time ride = out
to hunt, or to other business in the woods and in the lands to the = East.
Then if Bilbo was very nimble, he could slip out just behind them;
though it was a dangerous thing to do. More than once he was nearly
caught in the doors, as they clashed together when the last elf = passed,
yet he did not dare to march among them because of his shadow
(altogether thin and wobbly as it was in torch-light), or for fear = of
being bumped into and discovered. And when he did go out, which was = not
very often, he did no good. He did not wish to desert the dwarves, = and
------=_NextPart_001_0002_01C67000.AE5E62D0-- ------=_NextPart_000_0001_01C67000.AE5E62D0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <000101c6703b$5ab889a4$cf4ca8c0@mkf78> R0lGODdhMAE/AcIAAAAAAAAAAP///wAA//8AALXgugAAAAAAACwAAAAAMAE/AQAD/ii63P4wSldm nfDizbv/YCiOpFBpZapy6Nq0bgzCIy3Xn32TutT3OxEwSCxihsbkDqlsOovMp9QTvVWnlpziuuAe seCweJz0lszktHrNbrvd6E2c8q7b7/i8Hj/fT/t+gVQdgFmCfzGFh4eKi0qNjHYFAZSVQQEPmE+V mo6enwqdC6IupKFnHZQMpi8yJysaP06QX12GJaysuJl0JjwOpqa0ecOgEbqdlqucowKqDaIXosqn ypOk1MCZmNOrzs7Py93hIcU4GbbovXqTEJrJo8nSyLyn9uCh4fD30O7f+fD0ebtHjog5Y5f8YeP3 Txc4TsoW/uP3rp82X96eccs3/nGiRIcIQ4qgJ1Ecw4EWP6JsaLFlymr2ujGsKLJmhAtASEJMZolm vZcDZcbc+fOlqqMU40E8abNpKoX+gh6rp7KZ1WhRoVUMmJRpxwIHDT4B0gJFWKtAr6a9uJYlWrfN YARTSrfjPrVOjZxNMRctz3heO/od/PYuyGl/AZsQ6hHtXlRkougIuzNYQWY+2a7MhrVwwW2fSzJ+ uDKwjzGNCg1Dc+Wxp72u38TOqwakOi20HZmZHAZn7tu/gwv/NBv18OM3kaspvkX5IuZSoD+AXc6V 8+vYZ2VnEWm7EO+JwCuXLh4j5OUzApEHXr55+/e3BK1/Db++zdjF5tsvI1J//kj/xsXHHXgAilXf K/sl2N1p0VWn4INyQChhENSFl1eBE2aIHIa55SKJT7a9ZWFM32UV4gQnkpBiK3eUlIZcmkkQYh+Z rYBJBSu6J2IKLeSonYqJ2dEXBj6OpCODHNxlZC0hFLmHkgBt1sxnUVbDk2UbNZSNSYhhqZVAnD00 V0TkLCUmM3VZ+eWVU3lWpgp90JIlSvBIo1g6jeFDGEEgtqlnY3YSFBSU7WxTpZaKQWkYPXv2E6hd O4o050xdCVZapSRK5VVVeF0F446MdsXpaDXS6dIWQoXqFFac5kmBhyLW2GdRzuDY1jtDWqrqaKTl aaumP7lY2J2X1pQrXK7G/kgRUd+AlamllAqGq5liDnuqtXwilWxlgSlaVJcoOOnHsZlBWSyv0Zqb bltR8borsM9q8quyjUKLbrJNHSuNs/ieW5qsOqqK7MCwupsVpNIKGitT8wqLqan8YQGrqwL5CXCl GkXKZ6OGwfupZjLpM+ueDqVqopKdsVEIMpdpK1i41Hj5JVxb0tUlMC1XfFLNjF2ZZU9lvumOyPKC ZleYurnAoYZML40I01Bj4XSJbUwddYJWZ2dD1lTDtx5vKgvHtRUPjk2cfFenDad3YcUBdh1mj3fg cHEb2LTaePe3hF55wxJx3zy2V/fegJ9jHn2FXx1L4ow3DofiESo4OAOT/hdeueOQg3J52A1Oh/nn j+CZ+FmIOYEmqBeFdoO4xdJbBOtJSqrxDkLPdBlH1/KlO5FSwL6B72yoy+LuUk5pqsPEj3Ai8KL7 mZDUqwNUdMJpIpy7zt+YjA2MRK8p/KHVhn+m9NXjHHOvXLoU8uncEM38gLRHKhrHtJLcPmHo1h5k xiZ2BXOiEMNZolBGLI+AKTE668TmFMYWbxXKHuHqHwM7xhRSQfBZp5oUtuJ1vbV4axkwwUervreO ADVQgtTL38FmZbIK/st8m3LP/XLXqw8eg38M3FkIZRZB01AuD8KrUwr99UNILaRnLlQK+3qyKWax b000Y5b5fhZAHR5l/k6YwRh6cFOvjLzQeucaRz8syIoexqhUPkTWqH7nwVj1qDEXayFCvjepEUZF A9jI2QsnNkR4fRFeayRip/Alsxq2MY3jQtUN57exFUaDSrUrYLQMCEAJhgyEuJOjViqJMctg8k84 7JcnSBgaPR6mZkkEFR/BVy00Vm+JPtMSmxZJxeYx8YziqGW2/sPGzvkSdGSrDSmks8DnBE5s7+tb MQkBTNlgxGyS4dzwpNnMap6wXW2qjEakCK2jcetMp4vB8p7Wy8PtbEz1k0Q5IYkrQzXrYDks35EQ aaNymrB16MOdH5O5Bq6YJHsz62YSPbRKgUaPd0KayhFTEiTZhdB4/gD1okFJwouC5ogz4Twdjqgk PlQq0U48e1NINShRiJJshYOqxLzoqTRBLTSiED0MVFpyLIPSVJ+qeCCiYthFURGwkdbj6E+RWLI0 zbBW1JvCPpbKQVlSi6I3vZY2W7FKNI7mUcir6rrqVcafbkugGWunAmn2NKZmioWmgWoVdWhPo/1p g2vNxTBbpcaF/cSMNsRmqSIyuyR0zKwwdWUM80gttiJ0igbEXqiQ11GGmkmTlroGJa5hrWGiCB/t iOXIlDoYwGIxrTO1K+raOklAznOs+BzkwLCV1aia1CsgjelN+QmCRXm2YjJNXQalGjtc6lZjeS0i wbYaT61SirFG/g0lHCN3UDCWy4+8fZh0V7RUBJr2W8D1BmW1uNJU1XS1t9NB0O7UvbFU8ZKVnSo4 kQiyKUq2Mxm9ZWOBW96hua+QYCTNXN6I1E+m0UVZBMzUvnZPiZWHttYckfOyw9EttnQPAErRMm+Y YL4NosJ1oGAamJfM3F7WA7bRaE2n5cRvKqegoEAwPLOChJJBdkuC1dV1UIwk4ZKBdVUYJ4gX/NVu rJReKhan+hSLQhdT94Cg+es2AyI0YQmlULG0Esvq6zq5JgWyHYRCjeFJwXtp2LUyugoy8NhIlQ4F f7s9FE3Wl92edpNR8gBlpAJlRiFhdYyt+7JouQzWYBUvkLra/komU/nmPbf5txRT4hNpqOUP6LmO 7rizXepMK5JK0qvDTfQPb6TLdqoPhYTOc6eeS0uPuuHR+R2MrYJW2EpP9HyYelRT7SXCz5JPug3L cpVfC9OJSrJFOn3pKT6Gx832gswl/TCm45jsktr6kNeU34rlLGxf//pvOyajqCdoaFymaLPoHaSl 0QdrypE62qG+1M3+uZgw+zc9D7ZvVBsaQDnqeLWjQPayFZlDVG5Xn2rsLkp56sh3A9zDfW1DKW+2 WNHCeJH5piX9xIw0VBW1ePNt4iyTDGNUTmyj36TxqRVem3lqZsJbRk6DmSRk86bzcCvH8OuCPEci 0VzmXDyb/uXYg/OeY22U2zan25pw0dcF/cPW9HKKd/wL5/nu5vVRuud4LoaiE+FeTwnmhZnuJta+ VcqsDFPM+Cr2Dnacr1IhE2EzsuQojzEc/J3ijXIJ9s6yKcikc+25hTqtk+LUM5293qIA85G+c/vv zg0YYCtYbJBpWH9QNwKqpyHrT6t27xg3tl3HOjL22jHVaQ5idLX4MB8VSMOrXitGPA9t9pLVnA5D +1cvL6rGL1jzMLT84duNT65NXvUbZPbEFSZ6Ot1SiJ534j497ig6yjf4ihR4avUA6WTT8c+tH0iu U8/npFZfVNMJt7Lmd/HRkj6/ke9amLXt5sT3sd/17vM+/l/L+uuW3+Hyf4v0d59URzw8XtfndfCH KbZFYUAVAMXmepqGMAqIeKz0SaojgN6XfpKHX/J1fz0TSfKCgJh3beNDd6UDfa+UUkpUUToFcIgl M/YGQxRodBeCcFlHfYkTc5+wcjmyUedRgT9iY8ZAg6MUYo7WglvngWNRN2bhcymXc023Nr1BIU6I hOKxNHHCYwmVcFznaDyoTI3GdL63eqWwJHdgNYOTMkM4dckzPTknLkJoN71xPuSwaksWUGoiTxWl R1Oybhx3h+xGd9mTU3vIgn/4VHyoIdU1NBbnd19HQg44eMAnMigoLzQQgkFFB/vjF9YlXb8ERHg2 cBiU/mkJJ36eaFidGHuZN3qjSFxraGFEt4lHQobC122WR1fIZUh/JIL9R1y890/0liEI2GwY1xA9 RFjhhF3rZTutRj6ywk0EaHHHWHhPdXyDaB3M9SSs2F4RJ4tYqFqwGHqMZoshQlebN23T5B0v9TEM eCvdeI5BQWm5AmVp9ovB9X6nWGiGc08HsXi6t4DCYIUraFhWNmhgZouiREkTtIHgBjXWgIGbEUnl w0d4aC8NFmByNWWlZ4MusxjCqEamBoXZKDahMzc9CDpOg3JhWGFcQJIKVh4oeTfTJyAyol63lkuW YI60xpGLkIqe1G34dYtluCAE0iScZYpalUdEiDdW/tMz86ATwngxD/gCWRVEZDYk+2hT8cYHLmdO X6hm8bSIf6E/n0hpbqZnvaaKO/iE4whv9YgigiZCQhmOxeVuh9ZwJ/FjaNM8ZomVh/AO7siT+YND 8ViLwLeALWmGd8k43MNpTsUzC+kydaSM7xiQFDeMVAk9LGdMG7ZcVPli9HeFENlmpFhgdVmD5fWZ bwk+szhigkSaxkALc7A4GSaJouRdxCKVSLeQ6iZtq7CS22EGvRgrQrWY3/eHLyeZEBFsrnYTNxdN 5GSTzAk3zfmcWgOdTDidW1iSuok50HGEaOkHk3Od0kl1Rik3H/md5FmV2CY55ZmEhZmeKulzcVMc /pDgnUg4dJm4nvpxEPLJnld5HPkZH66pn0v4nLsxjThXIbnRnwBKmQk6Oi9yIZGxoNZ0khBaktwJ nh45oY/TFICQis6BoMTAF8wnnDMJcXJIh7sgBgn4kku5cZMpIRvRMuc1O16FZSeqdb+jlyeDm/+w TPqxZs7WFpGIjjypIpdphbGpjQ6ihH5jYDJGSKXllrQnd9G4mAKpaFN6R0eHbH0IOBc5a89Cl/IY ijh1bvGXWKrESTYFSfn0XsdDmOqkcLdTmq01f3zJLog2hz9DLvREDf9zgFzCoQQaCLIXVEz5RdhI ojEnfLokb19Xm9tYMD5IN0T6fzbzpLgopshY/oL1wF/306Ul6HaOeouV91AIqAgemjowKaTcSKco AaYFYxS8ZqmTqaf1g3vjWYOduC2FCqXzqH33oKV0OnawMqo1aX69Omp486LEOImgFmdbCUq9qEIF aXBjionYU2/mIpZngZIetXYlKi0Ll3tJllhzN2ROJnGgCkVU+q3LAqj58jwZGqhKUK42uganSoV6 A69kiaH8emI92a/m2SEYtaLCya4j1VxKCqL0arB2yFLHlBcvOkMR2X4zGpjKY5emgytBen6LNwT3 mo1rSXBzGqW96bCHdau/yKuvh2O0wQWCJZc6Oo9PObC7og/AOpGsdm+GmhZHhZeSCiRv5pC6/iaz p/JvoTQxt5Wtl+hDahqsseqSNYEgTRKuyxpqryiK+IaOYYWCYUqi6XCo+uWuzCSoTZuPxRoTwdiN ZKIOmbGXi+pWkSqyuzoUU8k0PWusI0u0YcSY3bouV9RfUJSu+AqN/qKI8IMdNfJj5+pbYAuLr7qO /vSYRvqNlmqrDYoHProQwDqkh6qa9vIpzkiH04NiqqlcfWG4/0pNNpJZDmh+DnGzEgiBsoa0lkit 0GqtxQe42dp+vJiz6USpD3iw9oVFfduQjBZg4oNY62oScZdPUNseQXaD0Bug7tmRdsuvvoEQH/sb C+QbKKecGAuwJpukCba98xqi8rSRzru+/uqbheIoMRZph0k5mC66pf5Vsc0auyqQfjnhaQ30eEgK ku72XB+Ut5k2i7VVpFaLiuO7H3v1lidoXI1rpZrqePsmpRUMlwPMs416NZ5qbHMbpnPriKDXZUYl QADJtDq2RrRlvoHIVbLauWcJjndqv3nKuElygqBmpnH7vBAmTkdrfDEspKe5TcoGFG+bez1MuZTC qT1coer3FMCrX0PstHtLvL85RH87ZVj8bRrcWqgbHHNAYoWlb0N7wKZ4tiSLmZJrcncluadrpDr3 PA+8LFW8xrcpSMDyKzGjw5x7nOMXXWGcIMpqjczqZ8P3j3oirRSjQHyHpoosMF0klgiZ/sXpG6eX vJMgmMHLK6uZGpPKG5kD+y1PHIUv57M5XJZja6GS577VWTVu6n/q8bA1GpqVKb7x6qAlVHIPijjA NIXKQ7My+ZBuxbwFW8tjsJFnJ6zF4sK7ILHktcMxen71dLgyYMQozJDE5xT/2coswUhtLMKePBLz wcglHMAICVr0GLNovBLOUliS2a5VKj2I4ceuU0Vaerdp46kpxZASrKrkRaZ+t3E5ucjTl6g+oz22 fGpU0jCotstxBJY0fCvbdcOranOnJIn13MHSeBzoW8P/zKpwC4R9lMTmhs29pcFFK0tcmogbrMft jLHIG89ovMXDS64pbUvT9mw/uSRY/nesKjvCZ0y0kfsvNPm+h4asoJlIr7ezMH21TcrOMisyGyvV dZqbO8pWg7ybCtUvRmuxFbsvvxrQ1oonDfXIKdyZFcSIUb3VbuzL8Cas8bWT3iqiHMWmgjtsYXe8 F2hqwyi4H92+ExK9qymvRKqe4iu2uNqczlw2bBi+sIzL9orYsnygx9TYLZsKwpyi7MqwmiyvxAoG fv2MsOTO+2zD5DW7Mhq7bn2yYYDSNPRxF7TUUByyesvOlRfCF3tjR5eaDdyhCJVbE3ypIQzP3crZ 7uc9V/q74shkhKNy43bb/JDbxI3CFe3bAKi0kKyWeUjBLjWDE1vdOCzSTczER7SW/hGIzgHVI2zN cCqG2eg7uncs3a8WrSRdFSati1YXqgNVyuRLnclhOi4d1Mc53K3EyWts0+Oa16ec1Cal2GDABEwg 0AZesjGNtaTrt09rwEg93aPV2gt9zV56qVVN37RqEWlLgk0pEWApLc2LqZY72IGVv93C2vKztMXK 1hxNwn1547aAg3RJyTnIynl5X6wmrgzxb5mMrgguz4C5yaCsrl3X2cR8HXFC2K68nPXZ4NVUHBBe 2ZId4OmJ2Q6m5cA9odeZH0kj5ii7ygmrvRti2D5crzv3CCRJ5s4pwGEengCanbFsH3hu5XEesG+6 52nDNYFe2NVL2VHL5n+e6HJ+tMtRTOQd/d+GrrqobM2XrqCRvulWmdmZzp6tkbpDzp+TjqKe3uks 6eapPuat3nOQbsqA/uq53ASx3tO8FJ2CbunbuaS0/uvAHuy7rMtNaOtaeOq9XOqMLeyV7kzNbpia g+wGcetqQ+3E3kzObO20PecRzuvSTunMHjXZ7u1ew+dmPtnhfh90/ucCCoU8+utiGOomyerP7ejn buzynu76/jnajsuQDr77/ur9juoAnuVQjBAJAAA7 ------=_NextPart_000_0001_01C67000.AE5E62D0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri May 05 09:36:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc0U2-0007JT-5o for capwap-archive@lists.ietf.org; Fri, 05 May 2006 09:36:38 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc0U0-0004P6-Fo for capwap-archive@lists.ietf.org; Fri, 05 May 2006 09:36:38 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 184FF430122 for ; Fri, 5 May 2006 06:36:31 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 69D61430092 for ; Fri, 5 May 2006 06:35:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4BC8E430EBB for ; Fri, 5 May 2006 06:35:58 -0700 (PDT) Received: from stlssgcorpmailfw2.anheuser-busch.com (stlssgcorpmailfw2.anheuser-busch.com [151.145.63.132]) by hermes.tigertech.net (Postfix) with ESMTP id F337D430EC0 for ; Fri, 5 May 2006 06:35:54 -0700 (PDT) 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="--344510-7129147-1017340393=:3379" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] to mux or not to mux? Date: Fri, 5 May 2006 08:35:45 -0500 Message-ID: <89525CB1203D7346BBBDFCE9CECB47CF022A3122@STLEXGUSR31.abc.corp.anheuser-busch.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] to mux or not to mux? Thread-Index: AcZv6CIDHyNVlMrvRKGoQOW8rh+SxgAXh8pQ From: "Kraus, Michael" To: "Scott G. Kelly" , "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 05 May 2006 13:35:45.0578 (UTC) FILETIME=[CFF8C0A0:01C67048] X-MessageInspectorSig: 017c5d19e5daacdd2a66f3ce089556b0 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 ----344510-7129147-1017340393=:3379 content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I know of many enterprises who have multiple 54Mbps access points all run ba= ck to the same switch, which have a 100Mbps uplink. In the future, I am anticipating multiple 802.11n access points with a single 1Gbps uplink. For= temporary uses(conferences), I have even setup a WTP having a WAN link back = to the AC. My point being, is that there will always be environments where congestion will occur between the WTP and the AC. In a perfect world, there= is no over-subscription and no congestion. When congestion occurs, typically you want to ensure that the data traffic i= s dropped, not the control traffic. I agree with your statement that the WTP = or AC could apply the appropriate DSCP or 802.1q marking, and I had too suggest= ed that earlier: =22>> One possible method could be for the WTP to assign the CoS/DSCP >> values for each traffic type so the administrator would have the >> ability to trust the markings provided by the WTP, or later perform a >> DSCP-mutation.?=22 However, I have not seen any mention that if we are going to pursue using a = mux header that this would be incorporated into the changes. If this was to be = done, it would really make sense for the CAPWAP WG to make CoS/DSCP recommendations for these values. Vendor interoperability is somewhat hampe= red from a usability perspective if you need to do different DSCP mutations base= d upon which vendor WTP/AC you are using. Thanks, Mike -----Original Message----- From: Scott G. Kelly =5Bmailto:s.kelly=40ix.netcom.com=5D Sent: Thursday, May 04, 2006 9:04 PM To: Pat Calhoun (pacalhou); Kraus, Michael; dperkins=40dsperkins.com Cc: capwap=40frascone.com Subject: RE: =5BCapwap=5D to mux or not to mux? Please explain what problem is encountered if the same QoS policy is applied= to both control and data traffic. Also explain why any such problems cannot be = solved by having the WTP and/or AC apply appropriate DSCP or 802.1q marking.= -----Original Message----- >From: =22Pat Calhoun (pacalhou)=22 >Sent: May 4, 2006 4:11 PM >To: =22Kraus, Michael=22 , >dperkins=40dsperkins.com >Cc: capwap=40frascone.com >Subject: RE: =5BCapwap=5D to mux or not to mux? > >The point Michael makes here is the same one I was making. Nearly every >enterprise class system, router or switch, is capable of providing QoS >enforcement using simple ACLs, which rely on IP addresses and ports. >QoS is just one of many features that can be (and are) implemented >through ACLs that would be very useful to CAPWAP. > >The use of the MUX makes all of the deployed equipment out there no >longer capable of applying QoS based on control/data plane. I think >this is a serious issue, and justifies the need for two ports. > >Pat Calhoun >CTO, Wireless Networking Business Unit >Cisco Systems > > > >> -----Original Message----- >> From: Kraus, Michael =5Bmailto:Michael.Kraus=40anheuser-busch.com=5D >> Sent: Thursday, May 04, 2006 8:17 AM >> To: dperkins=40dsperkins.com >> Cc: capwap=40frascone.com >> Subject: Re: =5BCapwap=5D to mux or not to mux? >> >> David, >> >> Maybe I'm misinterpreting something here and may be somewhat >> off-topic, but often in QoS you try to classify traffic by >> source/destination IP/port or by some higher level interpreter (such >> as NBAR in the cisco world). If the same UDP port number is being >> used for both control/data, how will intermediate switches/routers be >> able to determine what is control vs. data traffic? This relates >> back to your comment below of: >> >> =22So, it all comes down to whether or not we want intermediate >> network devices to distinguish between control and data.=22 >> >> One possible method could be for the WTP to assign the CoS/DSCP >> values for each traffic type so the administrator would have the >> ability to trust the markings provided by the WTP, or later perform a >> DSCP-mutation. >> >> I don't pretend to be a QoS expert, and I'm sure many products can >> classify traffic by data outside of known IP/UDP headers. However, I >> would argue that this would likely be platform dependent. For >> example, Cisco could create a PDLM for NBAR for these mux values. >> But, obviously this support does not exist today, and NBAR is >> dependent upon firmware/hardware support. >> >> We probably need a =22neutral=22 person on this topic to summarize the = >> Pros/Cons that have been already stated on this issue... >> >> >> Thanks, >> Mike >> >> ------------------------------ >> >> Message: 2 >> Date: Thu, 4 May 2006 07:19:53 -0700 (PDT) >> From: =22David T. Perkins=22 >> Subject: Re: =5BCapwap=5D to mux or not to mux? >> To: =22Kraus, Michael=22 >> Cc: capwap=40frascone.com >> Message-ID: >> >> Content-Type: TEXT/PLAIN; charset=3DUS-ASCII >> >> HI, >> >> Since UDP is being used, why cannot the data traffic packets be >> marked with a different QoS values than control traffic packets. >> >> Would you explain and provide an example of use of =22current QoS >> tools=22. >> >> Regards, >> /david t. perkins >> >> On Thu, 4 May 2006, Kraus, Michael wrote: >> > One additional upside to using separate ports would be that >> different >> > QoS >> >> > policies can be applied against data/control data. With >> mux values, >> > this >> >> would >> > be more difficult to accomplish with current QoS tools. >> With 802.11n >> > data >> rates >> > being quoted, having the ability to do some =22control plane >> policing=22 >> > for the APs, might be advantageous. >> > >> > >> --------------------------------------------------------------------- >> - >> > >> > Message: 1 >> > Date: Wed, 3 May 2006 15:16:21 -0700 (PDT) >> > From: =22David T. Perkins=22 >> > Subject: Re: =5BCapwap=5D to mux or not to mux? >> > To: Charles Clancy >> > Cc: capwap >> > Message-ID: >> > >> > Content-Type: TEXT/PLAIN; charset=3DUS-ASCII >> > >> > HI, >> > >> > Please don't forget about the discovery message. With it, >> you have 3 >> > values >> for >> > MUX. See below.. >> > >> > Also, please note that in the prototype that I'm >> developing, I'm using >> > the UNMODIFIED DTLS implementation in openSSL. >> > That is, adding the MUX header does not require any modification of >> > the >> openSSL. >> > By the way,my two wishes are: >> > 1) an Ethereal decode for the below >> > 2) the addition of the NULL encryption type to the >> > CAPWAP protocol for debugging >> > >> > On Wed, 3 May 2006, Charles Clancy wrote: >> > > The DTLS tunnels would NOT be merged. You'd have something like: >> > >> > +---------+------------+------------------------ >> > =7C UDP hdr =7C MUX =3D 0x00 =7C Discovery Request or Response >> > +---------+------------+----------- >> > >> > >> > > +---------+------------+------------------------ >> > > =7C UDP hdr =7C MUX =3D 0x01 =7C DTLS(CAPWAP Control) >> > > +---------+------------+----------- >> > > >> > > or >> > > >> > > +---------+------------+------------------------ >> > > =7C UDP hdr =7C MUX =3D 0x02 =7C CAPWAP Data >> > > +---------+------------+----------- >> > > >> > > UDP is indeed a MUX header, but it's a MUX header that everything >> > > already understands. So, it all comes down to whether or not we >> > > want intermediate network devices to distinguish between >> control and data. >> > > For NAT traversal, it's easier if the NAT treats everything the >> > > same, and doesn't have to know that the two ports are >> related. Same >> > > for firewall / port forwarding. I think intermediate network >> > > devices should treat everything as =22CAPWAP=22, and we >> should therefore do our own MUX. >> > > >> > > -- >> > > t. charles clancy, ph.d. =7C tcc=40umd.edu =7C >> www.cs.umd.edu/=7Eclancy >> > > >> > > Nancy Winget (ncamwing) wrote: >> > > > Charles, >> > > > >> > > > With a MUX, yes they are logical channels, but I believe the >> > > > implication is that these channels are merged into a >> single DTLS >> > > > tunnel...are you saying they are not? >> > > > >> > > > But as you state, if UDP is a MUX header, why the need to >> > > > introduce yet another one instead of just using UDP for >> separation? >> > > > >> > > > Nancy. >> > > > >> >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/capwap > >Archives: http://lists.frascone.com/pipermail/capwap ----344510-7129147-1017340393=:3379 Content-Type: text/plain Content-Disposition: inline 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. ----344510-7129147-1017340393=:3379 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 ----344510-7129147-1017340393=:3379-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri May 05 10:03:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc0tg-00012F-Mm for capwap-archive@lists.ietf.org; Fri, 05 May 2006 10:03:08 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc0tf-0005N5-UH for capwap-archive@lists.ietf.org; Fri, 05 May 2006 10:03:08 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B157A430139 for ; Fri, 5 May 2006 07:03:06 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id C73CD4300C4 for ; Fri, 5 May 2006 07:02:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id B5549398031 for ; Fri, 5 May 2006 07:02:34 -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 BDD2939803F for ; Fri, 5 May 2006 07:02:30 -0700 (PDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 05 May 2006 07:02:29 -0700 X-IronPort-AV: i="4.05,93,1146466800"; d="scan'208"; a="1801948889:sNHT31494916" 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 k45E2SVI024587; Fri, 5 May 2006 07:02:28 -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, 5 May 2006 07:02:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header Date: Fri, 5 May 2006 07:02:28 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D82B65@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 53: Add Data Rate to LWAPP Header Thread-Index: AcZvw7mgpUL/LygASMGoMpGhNClz0wAiM1nA From: "Pat Calhoun (pacalhou)" To: "Jim Murphy" X-OriginalArrivalTime: 05 May 2006 14:02:28.0680 (UTC) FILETIME=[8B7EB480:01C6704C] 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: be922d419820e291bde1362184dc32fd I've created issue 119 for this request. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Jim Murphy [mailto:jmurphy@trapezenetworks.com]=20 > Sent: Thursday, May 04, 2006 2:40 PM > To: Pat Calhoun (pacalhou) > Cc: capwap > Subject: Re: [Capwap] Issue 53: Add Data Rate to LWAPP Header >=20 > Pat, >=20 > Looks great. Any chance we can get a payload type in the header? > It would be nice for a switching system to be able to switch=20 > arbitrary payload types (802.11, 802.3, etc.). I think 8 bits=20 > from your Reserved field would suffice. >=20 > Thanks, >=20 > Jim >=20 > Pat Calhoun (pacalhou) wrote: > > All, > >=20 > > The following is a proposed new CAPWAP header format, as a=20 > result of=20 > > discussions on the list. Comments are most welcomed. > >=20 > > 4.1. CAPWAP Transport Header > > =20 > > All CAPWAP protocol messages are encapsulated using a=20 > common header > > format, regardless of the CAPWAP control or CAPWAP Data transport > > used to carry the messages. However, certain flags are not > > applicable for a given transport. Refer to the specific=20 > transport > > section in order to determine which flags are valid. > > =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=20 > 7 8 9 0 1 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |VERSION| RID | HLEN |W|F|L|M| Reserved =20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Fragment ID | Frag Offset =20 > |Rsv-2| > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | (optional) Radio MAC Address =20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | (optional) Wireless Specific Information =20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Payload .... =20 > | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > =20 > > 4.1.1. VERSION Field > > =20 > > A 4 bit field which contains the version of CAPWAP used in this > > packet. The value for this draft is 0. > > =20 > > 4.1.2. RID Field > > =20 > > A 5 bit field which contains the Radio ID number for this packet. > > WTPs with multiple radios but a single MAC Address use=20 > this field to > > indicate which radio is associated with the packet. > > =20 > > 4.1.3. HLEN > > Length of CAPWAP tunnel header in 4 byte words. (Similar to IP > > header length). This length includes the optional headers. > >=20 > > 4.1.4. W Bit > > =20 > > The Wireless 'W' bit is used to specify whether the=20 > optional wireless > > specific information field is present in the header. A=20 > value of one > > (1) is used to represent the fact that the optional header is=20 > > present. > >=20 > > 4.1.5. F Bit > > =20 > > The Fragment 'F' bit indicates whether this packet is a fragment. > > When this bit is one (1), the packet is a fragment and MUST be > > combined with the other corresponding fragments to reassemble the > > complete information exchanged between the WTP and AC. > > =20 > > 4.1.6. L Bit > > =20 > > 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,=20 > the packet is > > the last fragment. > >=20 > > 4.1.7. M Bit > > =20 > > The M bit is used to indicate that the Radio MAC Address optional > > header is present. This is used to communicate the MAC=20 > address of=20 > > the receiving radio when the native wireless packet. This field=20 > > MUST NOT be set to one in packets sent by the AC to the WTP. > >=20 > > 4.1.8. Reserved > > =20 > > The 15-bit Reserved field is reserved and set to 0 in=20 > this version=20 > > of the > > CAPWAP protocol. > > =20 > > 4.1.9. Fragment ID > > =20 > > An 16 bit field whose value is assigned to each group of=20 > 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=20 > Fragment ID wraps to > > zero after the maximum value has been used to identify a set of > > fragments. =20 > > =20 > > 4.1.10. Fragment Offset > > =20 > > A 13 bit field that indicates where in the payload will this=20 > > fragment belong > > during re-assembly. This field is valid when the 'F' bit=20 > is set to 1. > > The=20 > > fragment offset is measured in units of 8 octets (64 bits). The=20 > > first > >=20 > > fragment has offset zero.=20 > > =20 > > 4.1.11. Reserved-2 > > =20 > > The 3-bit Reserved-2 field is reserved and set to 0 in=20 > this version=20 > > of the > > CAPWAP protocol. > >=20 > > 4.1.12. Radio MAC Address > >=20 > > This optional field contains the MAC address of the=20 > radio receiving=20 > > the > > packet. This is useful in packets sent from the WTP to=20 > the AC, when=20 > > the > > native wireless frame format is converted to 802.3 by=20 > the WTP. This=20 > > field > > is only present if the 'M' bit is set. > >=20 > > 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=20 > 7 8 9 0 1 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Length | MAC Address > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > Length: The number of bytes in the MAC Address field.=20 > The length=20 > > field > > is present since new IEEE technologies are using 48 byte MAC=20 > > addresses > >=20 > > MAC Address: MAC Address of the receiving radio > >=20 > > =20 > > 4.1.13. Wireless Specific Information > >=20 > > This optional field contains technology specific=20 > information that may > > be used to carry per packet wireless information. This field is=20 > > only present > > if the 'W' bit is set. > >=20 > > 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=20 > 7 8 9 0 1 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Wireless ID | Length | Data > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > Wireless ID: The wireless binding identifier. The=20 > following values=20 > > are > > defined: > >=20 > > 1 - IEEE 802.11 > >=20 > > Length: The length of the data field > >=20 > > Data: Wireless specific information, whose details are=20 > defined in=20 > > the > > technology specific binding section. > >=20 > > 4.1.14. Payload > > =20 > > This field contains the header for a CAPWAP Data Message=20 > or CAPWAP > > Control Message, followed by the data associated with=20 > that message. > >=20 > > [...] > >=20 > > 11.3.2. CAPWAP Wireless Specific Information > >=20 > > The reserved CAPWAP header field (see figure Section 4.1) is only > > used with CAPWAP data frames, and it serves two=20 > purposes, depending > > upon the direction of the frame. For packets from the=20 > WTP to the AC, > > the field uses the format described in Section 11.3.2.1.=20 > However, > > for frames sent by the AC to the WTP, the format used is=20 > described in > > described in Section 11.3.2.2. > >=20 > > 11.3.2.1. IEEE 802.11 Frame Info > >=20 > > When an CAPWAP data frame is received from a station=20 > over the air, it > > is encapsulated and this field is used to include radio and PHY > > specific information associated with the frame. > >=20 > > When used with the IEEE 802.11 binding, the field follows the > > following format: > >=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=20 > 6 7 8 9 0 1 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | RSSI | SNR | Data Rate=20 > |=20 > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > RSSI: RSSI is a signed, 8-bit value. It is the received signal > > strength indication, in dBm. > >=20 > > SNR: SNR is a signed, 8-bit value. It is the signal to=20 > noise ratio > > of the received IEEE 802.11 frame, in dB. > >=20 > > Data Rate: The data rate field is a 16 bit unsigned 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=20 > received at > > =20 > > [Rest is identical to -00] > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems=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 >=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 >=20 _________________________________________________________________ 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 May 05 10:04:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc0uu-00014r-3R for capwap-archive@lists.ietf.org; Fri, 05 May 2006 10:04:24 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc0ut-0005Oq-9k for capwap-archive@lists.ietf.org; Fri, 05 May 2006 10:04:24 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id AC489430148 for ; Fri, 5 May 2006 07:04:21 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4F45C4300F2 for ; Fri, 5 May 2006 07:03:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6629E39803A for ; Fri, 5 May 2006 07:03:12 -0700 (PDT) Received: from test-iport-2.cisco.com (test-iport-2.cisco.com [171.71.176.105]) by zoidberg.tigertech.net (Postfix) with ESMTP id 058EA398031 for ; Fri, 5 May 2006 07:03:07 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-2.cisco.com with ESMTP; 05 May 2006 07:03:06 -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 k45E36w1026451; Fri, 5 May 2006 07:03: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); Fri, 5 May 2006 07:03:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header Date: Fri, 5 May 2006 07:03:06 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D82B66@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 53: Add Data Rate to LWAPP Header Thread-Index: AcZvw7mgpUL/LygASMGoMpGhNClz0wAC+7iwAAC8t6AAHn804A== From: "Pat Calhoun (pacalhou)" To: "Abhijit Choudhury" , "Jim Murphy" X-OriginalArrivalTime: 05 May 2006 14:03:06.0166 (UTC) FILETIME=[A1D69D60:01C6704C] 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 I don't think so. I believe any wireless technology could have multiple radios. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Abhijit Choudhury [mailto:Abhijit@sinett.com]=20 > Sent: Thursday, May 04, 2006 4:34 PM > To: Pat Calhoun (pacalhou); Jim Murphy > Cc: capwap > Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header >=20 > Pat, > I agree with Jim. It's easier if the packet header conveys=20 > this information, i.e., what kind of payload it is carrying. >=20 > On a related note, shouldn't RadioId be part of the Wireless=20 > Specific Information field ? >=20 > Thanks, > Abhijit >=20 >=20 >=20 >=20 > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Thursday, May 04, 2006 4:09 PM > To: Jim Murphy > Cc: capwap > Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header >=20 >=20 > Do you really see a WTP supporting both simultaneously? My thinking is > that the AC knows in advance and simply programs its data forwarding > engine accordingly. >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 > =20 >=20 > > -----Original Message----- > > From: Jim Murphy [mailto:jmurphy@trapezenetworks.com] > > Sent: Thursday, May 04, 2006 2:40 PM > > To: Pat Calhoun (pacalhou) > > Cc: capwap > > Subject: Re: [Capwap] Issue 53: Add Data Rate to LWAPP Header > >=20 > > Pat, > >=20 > > Looks great. Any chance we can get a payload type in the header? It=20 > > would be nice for a switching system to be able to switch arbitrary=20 > > payload types (802.11, 802.3, etc.). I think 8 bits from=20 > your Reserved >=20 > > field would suffice. > >=20 > > Thanks, > >=20 > > Jim > >=20 > > Pat Calhoun (pacalhou) wrote: > > > All, > > >=20 > > > The following is a proposed new CAPWAP header format, as a > > result of > > > discussions on the list. Comments are most welcomed. > > >=20 > > > 4.1. CAPWAP Transport Header > > > =20 > > > All CAPWAP protocol messages are encapsulated using a > > common header > > > format, regardless of the CAPWAP control or CAPWAP=20 > Data transport > > > used to carry the messages. However, certain flags are not > > > applicable for a given transport. Refer to the specific > > transport > > > section in order to determine which flags are valid. > > > =20 > > > 0 1 2 =20 > 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 > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |VERSION| RID | HLEN |W|F|L|M| Reserved =20 > > | > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Fragment ID | Frag Offset =20 > > |Rsv-2| > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | (optional) Radio MAC Address =20 > > | > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | (optional) Wireless Specific Information =20 > > | > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Payload .... =20 > > | > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > =20 > > > 4.1.1. VERSION Field > > > =20 > > > A 4 bit field which contains the version of CAPWAP used in this > > > packet. The value for this draft is 0. > > > =20 > > > 4.1.2. RID Field > > > =20 > > > A 5 bit field which contains the Radio ID number for=20 > this packet. > > > WTPs with multiple radios but a single MAC Address use > > this field to > > > indicate which radio is associated with the packet. > > > =20 > > > 4.1.3. HLEN > > > Length of CAPWAP tunnel header in 4 byte words. (Similar to IP > > > header length). This length includes the optional headers. > > >=20 > > > 4.1.4. W Bit > > > =20 > > > 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 header is > > > present. > > >=20 > > > 4.1.5. F Bit > > > =20 > > > The Fragment 'F' bit indicates whether this packet is=20 > a fragment. > > > When this bit is one (1), the packet is a fragment and MUST be > > > combined with the other corresponding fragments to=20 > reassemble the > > > complete information exchanged between the WTP and AC. > > > =20 > > > 4.1.6. L Bit > > > =20 > > > 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=20 > is 1, the > > > packet is not the last fragment. When this bit is 0, > > the packet is > > > the last fragment. > > >=20 > > > 4.1.7. M Bit > > > =20 > > > The M bit is used to indicate that the Radio MAC=20 > Address optional > > > header is present. This is used to communicate the MAC > > address of > > > the receiving radio when the native wireless packet.=20 > This field=20 > > > MUST NOT be set to one in packets sent by the AC to the WTP. > > >=20 > > > 4.1.8. Reserved > > > =20 > > > The 15-bit Reserved field is reserved and set to 0 in > > this version > > > of the > > > CAPWAP protocol. > > > =20 > > > 4.1.9. Fragment ID > > > =20 > > > An 16 bit 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=20 > Fragment ID is > > > incremented with each new set of fragments. The > > Fragment ID wraps to > > > zero after the maximum value has been used to identify a set of > > > fragments. > > > =20 > > > 4.1.10. Fragment Offset > > > =20 > > > A 13 bit field that indicates where in the payload will this > > > fragment belong > > > during re-assembly. This field is valid when the 'F' bit=20 > > is set to 1. > > > The=20 > > > fragment offset is measured in units of 8 octets (64 bits). The > > > first > > >=20 > > > fragment has offset zero. > > > =20 > > > 4.1.11. Reserved-2 > > > =20 > > > The 3-bit Reserved-2 field is reserved and set to 0 in > > this version > > > of the > > > CAPWAP protocol. > > >=20 > > > 4.1.12. Radio MAC Address > > >=20 > > > This optional field contains the MAC address of the > > radio receiving > > > the > > > packet. This is useful 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. > > >=20 > > > The field contains the basic format: > > > 0 1 2 =20 > 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 > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Length | MAC Address > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >=20 > > > Length: The number of bytes in the MAC Address field. > > The length > > > field > > > is present since new IEEE technologies are using 48 byte MAC > > > addresses > > >=20 > > > MAC Address: MAC Address of the receiving radio > > >=20 > > > =20 > > > 4.1.13. Wireless Specific Information > > >=20 > > > 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. > > >=20 > > > The field contains the basic format: > > > 0 1 2 =20 > 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 > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Wireless ID | Length | Data > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >=20 > > > Wireless ID: The wireless binding identifier. The > > following values > > > are > > > defined: > > >=20 > > > 1 - IEEE 802.11 > > >=20 > > > Length: The length of the data field > > >=20 > > > Data: Wireless specific information, whose details are > > defined in > > > the > > > technology specific binding section. > > >=20 > > > 4.1.14. Payload > > > =20 > > > This field contains the header for a CAPWAP Data Message > > or CAPWAP > > > Control Message, followed by the data associated with > > that message. > > >=20 > > > [...] > > >=20 > > > 11.3.2. CAPWAP Wireless Specific Information > > >=20 > > > The reserved CAPWAP header field (see figure Section=20 > 4.1) is only > > > used with CAPWAP data frames, and it serves two > > purposes, depending > > > upon the direction of the frame. For packets from the > > WTP to the AC, > > > the field uses the format described in Section 11.3.2.1. > > However, > > > for frames sent by the AC to the WTP, the format used is > > described in > > > described in Section 11.3.2.2. > > >=20 > > > 11.3.2.1. IEEE 802.11 Frame Info > > >=20 > > > When an CAPWAP data frame is received from a station > > over the air, it > > > is encapsulated and this field is used to include radio and PHY > > > specific information associated with the frame. > > >=20 > > > When used with the IEEE 802.11 binding, the field follows the > > > following format: > > >=20 > > > 0 1 2 =20 > 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 > > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | RSSI | SNR | Data Rate=20 > > | > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >=20 > > > RSSI: RSSI is a signed, 8-bit value. It is the=20 > received signal > > > strength indication, in dBm. > > >=20 > > > SNR: SNR is a signed, 8-bit value. It is the signal to > > noise ratio > > > of the received IEEE 802.11 frame, in dB. > > >=20 > > > Data Rate: The data rate field is a 16 bit unsigned=20 > value. The > > > contents of the field is set to 1/10th of the data=20 > rate of the > > > packet received by the WTP. For instance, a packet > > received at > > > =20 > > > [Rest is identical to -00] > > >=20 > > > 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 > > >=20 > > > Archives: http://lists.frascone.com/pipermail/capwap > >=20 > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit:=20 > > http://lists.frascone.com/mailman/listinfo/capwap > >=20 > > Archives: http://lists.frascone.com/pipermail/capwap > >=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 >=20 _________________________________________________________________ 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 May 05 10:05:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc0vj-00015m-3o for capwap-archive@lists.ietf.org; Fri, 05 May 2006 10:05:15 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc0vi-0005SB-ML for capwap-archive@lists.ietf.org; Fri, 05 May 2006 10:05:15 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5CAFA43013A for ; Fri, 5 May 2006 07:05:13 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1C2C94300D2 for ; Fri, 5 May 2006 07:04:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C68ED430F7F for ; Fri, 5 May 2006 07:04:34 -0700 (PDT) Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by hermes.tigertech.net (Postfix) with ESMTP id 798C9430F80 for ; Fri, 5 May 2006 07:04:29 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 05 May 2006 07:04:27 -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 k45E4RRT016000; Fri, 5 May 2006 07:04:27 -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, 5 May 2006 07:04:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header Date: Fri, 5 May 2006 07:04:28 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D82B67@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 53: Add Data Rate to LWAPP Header Thread-Index: AcZvw7mgpUL/LygASMGoMpGhNClz0wAC+7iwAAD4CCAAHk2lIA== From: "Pat Calhoun (pacalhou)" To: "Puneet Agarwal" , "Jim Murphy" X-OriginalArrivalTime: 05 May 2006 14:04:27.0556 (UTC) FILETIME=[D259BE40:01C6704C] 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 X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb > Other comments/questions: >=20 > (1) Section 4.1.6: I think intuitively, it would be better if=20 > we re-define the bit as follows >=20 > "The 'L' (Last) bit is valid only if the 'F' bit is set and=20 > indicates whether the packet contains the last fragment of a=20 > fragmented exchange between WTP and AC. Specifically: > 1: Last fragment > 0: Not last fragment" >=20 > (2) Section 4.1.12: I assume you meant 48 bits (not bytes). >=20 > (3) General: Are each of the optional headers required to be=20 > a multiple of 4 bytes (since the HLEN is required to be a=20 > multiple of 4 bytes)? If not, then do we need to define=20 > padding headers? >=20 > (4) General: Is there any requirement on the ordering of the=20 > optional headers? >=20 > (5) Section 4.1.10: Since you have introduced the notion of=20 > fragment offset, do we then allow for overlapping fragments=20 > (eg fragment 0 has {offset 0, payload length 1000} and=20 > fragment 1 has {offset 900, payload length 600})? My=20 > preference would be to disallow this behavior. >=20 > (6) General: I assume that there would be a capability=20 > mechanism (for the AC to indicate to the WTP(s)) to specify=20 > which optional header the AC supports. >=20 Puneet, your new issues have been captured under issue 120. 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 May 05 10:06:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc0wY-00016k-Rt for capwap-archive@lists.ietf.org; Fri, 05 May 2006 10:06:06 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc0wX-0005TP-Dg for capwap-archive@lists.ietf.org; Fri, 05 May 2006 10:06:06 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3EB4D430161 for ; Fri, 5 May 2006 07:06:04 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4D4B44300AC for ; Fri, 5 May 2006 07:05:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 75730398042 for ; Fri, 5 May 2006 07:05:38 -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 50E51398041 for ; Fri, 5 May 2006 07:05:32 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 05 May 2006 07:05:32 -0700 X-IronPort-AV: i="4.05,93,1146466800"; d="scan'208"; a="426515603:sNHT25326492" 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 k45E5VRT016532; Fri, 5 May 2006 07:05: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); Fri, 5 May 2006 07:05:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header Date: Fri, 5 May 2006 07:05:31 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D82B6A@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 53: Add Data Rate to LWAPP Header Thread-Index: AcZv5RRNZA5B3IICTIOsPasrxj5rmwAZ8Z8w From: "Pat Calhoun (pacalhou)" To: "Jim Murphy" X-OriginalArrivalTime: 05 May 2006 14:05:31.0005 (UTC) FILETIME=[F82B4AD0:01C6704C] 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 , Abhijit Choudhury X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Ok, good question. How would we specify 802.11, 802.16 and 802.3? I hope we are not proposing a new bit for every wireless encapsulation type, right? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Jim Murphy [mailto:jmurphy@trapezenetworks.com]=20 > Sent: Thursday, May 04, 2006 6:42 PM > To: Pat Calhoun (pacalhou) > Cc: Abhijit Choudhury; capwap > Subject: Re: [Capwap] Issue 53: Add Data Rate to LWAPP Header >=20 > If the WTP supported both 802.11 and 802.16. 802.16=20 > encapsulates 802.3 frames. >=20 > Thanks, >=20 > Jim >=20 > Pat Calhoun (pacalhou) wrote: > > But do you believe that WTPs would send both simultaneously? > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > >=20 > > =20 > >=20 > >> -----Original Message----- > >> From: Abhijit Choudhury [mailto:Abhijit@sinett.com] > >> Sent: Thursday, May 04, 2006 4:34 PM > >> To: Pat Calhoun (pacalhou); Jim Murphy > >> Cc: capwap > >> Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header > >> > >> Pat, > >> I agree with Jim. It's easier if the packet header conveys this=20 > >> information, i.e., what kind of payload it is carrying. > >> > >> On a related note, shouldn't RadioId be part of the Wireless=20 > >> Specific Information field ? > >> > >> Thanks, > >> Abhijit > >> > >> >=20 _________________________________________________________________ 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 May 05 10:09:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc0zS-0001QG-S1 for capwap-archive@lists.ietf.org; Fri, 05 May 2006 10:09:06 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc0zS-0005gj-Dz for capwap-archive@lists.ietf.org; Fri, 05 May 2006 10:09:06 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B6CC043012F for ; Fri, 5 May 2006 07:09:04 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 89101430082 for ; Fri, 5 May 2006 07:08:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id B045039801D for ; Fri, 5 May 2006 07:08:42 -0700 (PDT) Received: from test-iport-2.cisco.com (test-iport-2.cisco.com [171.71.176.105]) by zoidberg.tigertech.net (Postfix) with ESMTP id 55051398026 for ; Fri, 5 May 2006 07:08:38 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-2.cisco.com with ESMTP; 05 May 2006 07:08:38 -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 k45E8bw3029311; Fri, 5 May 2006 07:08: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, 5 May 2006 07:08:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] to mux or not to mux? Date: Fri, 5 May 2006 07:08:37 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D82B6C@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] to mux or not to mux? Thread-Index: AcZv6ClriN3YbVWGTKOcwJHZViC3uwAZNpHA From: "Pat Calhoun (pacalhou)" To: "Scott G. Kelly" , "Kraus,Michael" , X-OriginalArrivalTime: 05 May 2006 14:08:37.0162 (UTC) FILETIME=[672098A0:01C6704D] 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 > Please explain what problem is encountered if the same QoS=20 > policy is applied to both control and data traffic. Also=20 > explain why any such problems cannot be solved by having the=20 > WTP and/or AC apply appropriate DSCP or 802.1q marking. In a network, one cannot guarantee that there will not be any congestion, hence packet drops. I would contend that the control channel has priority over the data channel, and it is therefore required to allow administrators to setup policies in their networks to guarantee CAPWAP session uptime. To your second point, yes you can allow the endpoints to tag packets, but the tag values we've chosen may conflict with existing enterprise QoS tagging policies. So allowing UDP based ACLs to prioritize allows the admins to override the decisions. 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 May 05 10:16:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc168-0007ta-Iw for capwap-archive@lists.ietf.org; Fri, 05 May 2006 10:16:00 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc167-0005qO-44 for capwap-archive@lists.ietf.org; Fri, 05 May 2006 10:16:00 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B7093430103 for ; Fri, 5 May 2006 07:15:58 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id DD52B430082 for ; Fri, 5 May 2006 07:15:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id BBF72398037 for ; Fri, 5 May 2006 07:15:33 -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 8435E398034 for ; Fri, 5 May 2006 07:15:30 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 05 May 2006 07:15:31 -0700 X-IronPort-AV: i="4.05,93,1146466800"; d="scan'208"; a="426519294:sNHT25860876" 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 k45EFURT022045; Fri, 5 May 2006 07:15:30 -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, 5 May 2006 07:15:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] to mux or not to mux? Date: Fri, 5 May 2006 07:15:30 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D82B72@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] to mux or not to mux? Thread-Index: AcZv7F/Pv/3juhruR+6WnkBxqsWZpQAYSR5g From: "Pat Calhoun (pacalhou)" To: "Scott G. Kelly" , "Bob O'Hara (boohara)" , "capwap" X-OriginalArrivalTime: 05 May 2006 14:15:30.0065 (UTC) FILETIME=[5D3C9810:01C6704E] 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: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 > - there will certainly be issues with NAT traversal; you now=20 > need to run keepalives over two channels, and even at that,=20 > the behavior will not be deterministic; busy NAT devices=20 > throw out existing dgram sessions when they need the=20 > resources, and this will result in one channel up, and one down;=20 If the NAT behaves this way, it can happen even with a single UDP port, so we can't win here. I agree that we will need some form of keepalive on the data channel, and that's the cost of solving this problem. >=20 > - channel binding is ambiguous; it is not clear what data=20 > channel goes with what control channel unless we add explicit=20 > signalling, and this adds considerable complexity to the protocol. There is a clear binding, which is the BSSID (or equivalent terminology for other wireless technologies). >=20 > - all of the added corner and race conditions and error=20 > handling requirements add *significant* complexity to the=20 > state machines in both ends of the connection. That's bad. I think you are overstating the complexity of the issue here. >=20 > And all of this for what? I've heard some nebulous concerns=20 > about QoS, but nobody is offering a detailed and persuasive=20 > explanation of why all this added complexity is warranted.=20 > Please explain exactly what architectures are being=20 > precluded, and why this represents a loss that justifies the=20 > added effort the dual-port (actually, tri-port, as discover=20 > will require it's own port too) path requires. I believe I have made my case about QoS. Perhaps you are not satisfied with the fact that there are millions of Ethernet and routed ports in the world that have specific capabilities that operate at the UDP port level that we do not get to leverage by creating this multiplexed header. However, it is reality, and something that I truly believe we need to take advantage of.=20 Assume a NAT, where a WAN router exists which provides QoS capabilities. Let's also assume that the WAN router has to handle much more than just CAPWAP data. By multiplexing the data, we are eliminating the possibility for the WAN router to apply the necessary policies to minimize congestion over the link, while ensuring that the CAPWAP control session stays up. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 _________________________________________________________________ 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 May 05 10:17:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc17H-0000oC-Q5 for capwap-archive@lists.ietf.org; Fri, 05 May 2006 10:17:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc17F-0005rJ-S2 for capwap-archive@lists.ietf.org; Fri, 05 May 2006 10:17:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7C36F4300D6 for ; Fri, 5 May 2006 07:17:09 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7CD60430092 for ; Fri, 5 May 2006 07:16:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 70374398034 for ; Fri, 5 May 2006 07:16:25 -0700 (PDT) Received: from test-iport-1.cisco.com (test-iport-1.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id 044A539803A for ; Fri, 5 May 2006 07:16:20 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 05 May 2006 07:16:20 -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 k45EGKh0026569; Fri, 5 May 2006 07:16:20 -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, 5 May 2006 07:16:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Date: Fri, 5 May 2006 07:16:20 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D82B74@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Thread-Index: AcZwDS0IE1zuE0JMSta/2r1YgH1tiwAQTwbQ From: "Pat Calhoun (pacalhou)" To: "sujay" , "Saravanan Govindan" , "Dorothy Stanley" X-OriginalArrivalTime: 05 May 2006 14:16:20.0031 (UTC) FILETIME=[7B04CCF0:01C6704E] 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 93ea548d5fde6eb89af31f1faab96344 Keep in mind that the discovery is NOT secured. So if you assume that this unsecured packet implies the peer is dead, then you've created a very simple DoS attack. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: sujay [mailto:sujayg@huawei.com]=20 > Sent: Thursday, May 04, 2006 11:22 PM > To: Pat Calhoun (pacalhou); 'Saravanan Govindan'; 'Dorothy Stanley' > Cc: 'capwap' > Subject: RE: [Capwap] Proposed Resolution to Issue 45=20 > -Issueoncombiningmessages >=20 > Nevertheless, a discovery recvd in the run state should=20 > ideally indicate the peer has gone down, Probably a reboot.=20 > It may turn out to be a faster way of detecting Nbr Down than=20 > waiting for Nbr dead interval. > (Of course subject to the packet being authentic) >=20 > In general, perhaps the draft should specify about "treatment=20 > of messages when recvd in the incorrect state". > i.e should it be dropped or any action is to be taken. >=20 > Comments? >=20 > Regds, > Sujay >=20 >=20 >=20 > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Friday, May 05, 2006 4:24 AM > To: sujay; Saravanan Govindan; Dorothy Stanley > Cc: capwap > Subject: RE: [Capwap] Proposed Resolution to Issue 45=20 > -Issueoncombiningmessages >=20 >=20 > But we seem to be ignoring the state machine. Keep in mind that this > scheme has to co-exist with the state machine, so a discovery received > while in the Run state is not a valid packet to reset the timer. All > other packets would. >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 > =20 >=20 > > -----Original Message----- > > From: sujay [mailto:sujayg@huawei.com] > > Sent: Thursday, May 04, 2006 5:25 AM > > To: 'Saravanan Govindan'; Pat Calhoun (pacalhou); 'Dorothy Stanley' > > Cc: 'capwap' > > Subject: RE: [Capwap] Proposed Resolution to Issue 45=20 > > -Issueoncombiningmessages > >=20 > > Saravanan, > >=20 > > A valid point, yet ALL control messages should be monitored > > for which are VALID in the RUN state. > >=20 > > There is no reason for giving special treatment to statistics > > messages alone. > >=20 > > Considering an implementation, I see no significant overhead > > in assuming say a Configure Request packet as a keepalive=20 > > packet from the peer. > >=20 > > Regds, > > Sujay > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Saravanan Govindan=20 > [mailto:Saravanan.Govindan@sg.panasonic.com] > > Sent: Thursday, May 04, 2006 2:29 PM > > To: Pat Calhoun (pacalhou); Dorothy Stanley > > Cc: capwap > > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > > -Issueoncombiningmessages > >=20 > >=20 > > Without the text below, the specifications will require an AC > > to monitor > > the arrival of "all" control packet with respect to the=20 > > EchoInterval and > > NeighbourDeadInterval timers. There were concerns earlier on=20 > > this thread > > that this is not ideal. =20 > > =20 > > =20 > > Furthermore, not all control packets indicate that a WTP is=20 > alive and=20 > > doing well. A WTP could fail, re-start and then send Discovery=20 > > Requests to an AC. This should not be construed as an=20 > indication that > > the WTP is > > well. On the other hand, by focusing only on Statistics (WTP Event > > Request) control messages, it is unambiguous that a WTP is=20 > > operational.=20 > > =20 > > So the text in the specifications should reflect this by=20 > having Echo=20 > > Requests sent in the absence of Statistics (WTP Event > > Request) messages. > >=20 > > =20 > > Saravanan > > =20 > > =20 > > =20 > >=20 > >=20 > >=20 > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Thursday, May 04, 2006 12:50 PM > > To: Saravanan Govindan; Dorothy Stanley > > Cc: Scott G Kelly; capwap > > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > > -Issueoncombiningmessages > > =20 > > The text you are proposing doesn't change the behavior of the > > protocol. > > I'm not sure that it really adds anything since we are=20 > stating that an > > echo is sent if no control packets are sent. You are free to send > > periodic Statistics messages, which with the new language would not > > require any Echos to be sent. > > =20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > =20 > > =20 > >=20 > >=20 > >=20 > > From: Saravanan Govindan=20 > [mailto:Saravanan.Govindan@sg.panasonic.com] > > Sent: Wednesday, May 03, 2006 8:18 PM > > To: Dorothy Stanley; Pat Calhoun (pacalhou) > > Cc: Scott G Kelly; capwap > > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > > -Issueoncombiningmessages > > Hi Dorothy, > > =20 > > I suggest that the Echo Request MAY only be send in the absence of=20 > > specifically Statistics control packets as opposed to any control=20 > > packets. The reason for this is that Statistics packets are=20 > the only=20 > > regular exchanges, so the AC has just one type of packet to monitor=20 > > for the timer. > > =20 > > So I'd like to suggest the following text: > > =20 > > From: > > "If another Echo Request or other control message is not > > received by the > > AC when the timer expires, the AC > > SHOULD consider the WTP to be unreachable" > > =20 > > To: > > "If another Echo Request or Statistics message is not > > received by the AC > > when the timer expires, the AC > > SHOULD consider the WTP to be unreachable" > > =20 > > Cheers, > >=20 > > Saravanan > > =20 > > =20 > > =20 > > =20 > > =20 > >=20 > >=20 > >=20 > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > > Sent: Thursday, May 04, 2006 3:03 AM > > To: Pat Calhoun (pacalhou) > > Cc: Scott G Kelly; Saravanan Govindan; capwap > > Subject: Re: [Capwap] Proposed Resolution to Issue 45 > > -Issueoncombiningmessages > > =20 > > All, > >=20 > > After the lengthy discussion on this topic, I believe that the=20 > > conclusion is still to reject the comment, and as Pat=20 > summarized, the=20 > > echo remains, does not include any > > statistics, and MAY only be sent in the absence of any=20 > > control packets.=20 > >=20 > > Changes to the text: > >=20 > > Change text in 6.2" Echo Response" from: > > "If another Echo Request message is not received by the AC when the=20 > > timer expires, the AC SHOULD consider the WTP to be unreachable" to > >=20 > > "If another Echo Request or other control message is not > > received by the > > AC when the timer expires, the AC > > SHOULD consider the WTP to be unreachable"=20 > >=20 > > and from > >=20 > > "If the NeighborDeadInterval timer expires prior to=20 > receiving an Echo=20 > > Response message, message, the WTP enters the Reset State." > > to > > "If the NeighborDeadInterval timer expires prior to=20 > receiving an Echo > > Response message, or other control > > message, the WTP enters the Reset State." > >=20 > >=20 > > Thanks, > >=20 > > Dorothy > >=20 > > Issue 45, Issue on Combining messages currently has the following=20 > > discussion in the issues database: Currently, the keepalive and=20 > > statistics messages are separated. Separate > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > =20 > > =20 > > messages for keepalive signaling and statistics can lead to high=20 > > overhead. > >=20 > >=20 > >=20 > >=20 > >=20 > > =20 > > =20 > > Initial analysis have shown that these overhead can be reduced=20 > > significantly > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > =20 > > =20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > =20 > > =20 > > if the messages can be combined. > >=20 > >=20 > >=20 > >=20 > >=20 > > =20 > > =20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > =20 > > =20 > > Recommendation: > >=20 > >=20 > >=20 > >=20 > >=20 > > =20 > > =20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > =20 > > =20 > > To combine the keepalive and statistics message into one combined=20 > > message, > >=20 > >=20 > >=20 > >=20 > >=20 > > =20 > > =20 > > thus reducing overhead significantly. > >=20 > > Discussion: > >=20 > > The CAPWAP protocol specification currently supports the > > Echo Request Message and Echo Response Messages, which are used for=20 > > keep-alive purposes, and do not carry message elements. > >=20 > > There is an IEEE 802.11 Statistics measurement=20 > element(11.7.2.1), and=20 > > several CAPWAP statistics related measurement elements: decryption=20 > > error report, WTP descriptor, WTP radio > > information, WTP reboot statistics. > > There is no statistics message.=20 > >=20 > > There is no requirement on how often the statistics related > > measurement > > elements must be reported > > to the AC from the WTP, there is a Statistics timer, see=20 > > 7.2.5, which is > > used by the AC to indicate the > > timer value to the WTP. (separate question - should the=20 > > statistics timer > > be made general, and indicate the > > values for the other Section 12 CAPWAP timers too? Assume that the > > CAPWAP statistics timer used > > to determine how often to send the 802.11 specific statistics). > >=20 > > It is not clear that there is a high overhead in keeping the=20 > > echo/keep-alive mechanism from the statistics reporting.=20 > There is some >=20 > > benefit in keeping the echo messages simple, > > rather than complicating the processing of those messages. =20 > It is true > > that small messages (echo request, response) have high overhead. > > In this case, the design choice is to accept the overhead as=20 > > the cost of > > simplicity in design and implementation.=20 > >=20 > > Recommended resolution: reject the comment, with the > > explanation in the > > above paragraph > > On 4/28/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com> wrote: > > I will summarize my thoughts here and not try to inject in=20 > > the various=20 > > threads, but I agree that the echo remains, does not include any > > statistics, and MAY only be sent in the absence of any=20 > > control packets. > > I say MAY because an implementation could send them if it=20 > wishes, but > > the receiver must take into account control packets in=20 > > addition to the=20 > > echo prior to declaring a link dead. > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Scott G Kelly [mailto: scott@hyperthought.com] > > > Sent: Friday, April 21, 2006 5:52 AM > > > To: Saravanan Govindan > > > Cc: capwap > > > Subject: Re: [Capwap] Proposed Resolution to Issue 45=20 > > > -Issueoncombiningmessages > > > > > > Hi Saravanan, > > > > > > Saravanan Govindan wrote: > > > > Hi Scott, > > > > > > > > I think David's note does address the issue on hand. > > > > > > > > To formalize; > > > >=20 > > > > The exchange of control messages between a WTP and AC=20 > implicitly=20 > > > > indicates that the WTP is operational. For the purpose=20 > of protocol >=20 > > > > simplicity, I suggest that we focus on statistics messages > > > alone for > > > > this purpose, reason being that statistics are periodically > > > exchanged. > > > > > > > > My concern is that by using "any" control message to indicate=20 > > > > keepalive (Echo), the AC processing will be=20 > complicated. This is=20 > > > > because the AC will need to process each control message > > > for both its own value (e.g. > > > > Configure Request) and also keepalive value. > > > > > > Of course, complexity is a function of many factors, but > > > there is a straightforward way to implement an echo trigger > > > with a flag and timer: > > > when you receive a control message, unconditionally raise=20 > the flag. > > > Periodically (according to your keepalive interval timer)=20 > > > check the flag; If it's up, put it down, else send a > > > keepalive. There are more complicated ways to implement, but > > > this works just fine. > > > > > > On the AC this can easily be implemented by having the > > > fastpath raise the flag, and having the cp lower it and/or do > > > whatever it is your AC does if a WTP doesn't report in a > > > given echo interval (which may be nothing). Pretty basic stuff. > > > > > > On the WTP, implementation is similar, except that if the > > > flag is down, you send the keepalive. Again, very simple=20 > and basic. > > > > > > > So I suggest keeping it simple - arrival of statistics > > message from > > > > WTP means WTP is alive. > > > > > > Certainly, a statistics message qualifies as a control > > > message, so I have no issues with this statement when taken > > > alone. I'm concerned with the earlier suggestion that the > > > echo req/reply message be discarded and replaced by the > > > statistics message.=20 > > > > > > In some cases, the keepalive interval must be *very*=20 > brief in order=20 > > > to facilitate rapid link loss detection and recovery. I=20 > know of one=20 > > > vendor who routinely uses a one second interval, and it's=20 > > > conceivable that in some scenarios one might choose to use even=20 > > > less. > > > > > > And keep in mind that WTP and AC requirements are typically=20 > > > asymmetric in this regard: the WTP needs to react quickly=20 > (maybe try >=20 > > > to find another AC), whereas the AC simply needs to=20 > somehow report=20 > > > the event. While in some cases reporting might be=20 > considered urgent, > > > this is not the typical (or average) case.=20 > > > > > > The granularity requirements for reporting are typically much=20 > > > coarser than those of recovery. That is, the AC may, at=20 > it's option, >=20 > > > only check every 10,20,30,... seconds for WTP liveness,=20 > and it may=20 > > > very well do that via the stats message, rather than the=20 > echo, since >=20 > > > this allows echo processing to remain wholly in the AC fastpath. > > > > > > But say we eliminate the echo: what happens when, say,=20 > 500 WTPs send >=20 > > > stats potentially every second or less? > > > > > > I think we still need the echo req/rsp. > > > > > > Scott > > > > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > > > > Sent: Wednesday, April 19, 2006 1:51 AM > > > > To: capwap > > > > Subject: RE: [Capwap] Proposed Resolution to Issue 45=20 > > > > -Issueoncombiningmessages > > > > > > > > Just trying to close the loop: I think David's point (i.e. > > > that echoes > > > > should only be sent in the absence of other control > > > traffic) is dead > > > > on, and that this effectively closes the question as to > > > whether echoes > > > > and stats should be combined in the same messages. > > > > > > > > Does anyone disagree? > > > > > > > > Scott > > > > > > > > > > > >=20 > _________________________________________________________________ > > > > To unsubscribe or modify your subscription options,=20 > please visit:=20 > > > > 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 > >=20 > > Archives: http://lists.frascone.com/pipermail/capwap > > =20 > >=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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri May 05 10:27:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc1Hg-0004e2-7o for capwap-archive@lists.ietf.org; Fri, 05 May 2006 10:27:56 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc1He-0006G3-FA for capwap-archive@lists.ietf.org; Fri, 05 May 2006 10:27:56 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 149F0430125 for ; Fri, 5 May 2006 07:27:54 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 65171430082 for ; Fri, 5 May 2006 07:27:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 59033398037 for ; Fri, 5 May 2006 07:27:26 -0700 (PDT) Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by zoidberg.tigertech.net (Postfix) with ESMTP id 159B7398031 for ; Fri, 5 May 2006 07:27:21 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 05 May 2006 07:27:22 -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 k45ERLRT029233; Fri, 5 May 2006 07:27:21 -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, 5 May 2006 07:27:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] to mux or not to mux? Date: Fri, 5 May 2006 07:27:21 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D82B7D@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] to mux or not to mux? Thread-Index: AcZv6CIDHyNVlMrvRKGoQOW8rh+SxgAXh8pQAAJvOnA= From: "Pat Calhoun (pacalhou)" To: "Kraus, Michael" , "Scott G. Kelly" , X-OriginalArrivalTime: 05 May 2006 14:27:21.0550 (UTC) FILETIME=[055096E0:01C67050] 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 I completely agree with Michael's points. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Kraus, Michael [mailto:Michael.Kraus@anheuser-busch.com]=20 > Sent: Friday, May 05, 2006 6:36 AM > To: Scott G. Kelly; Pat Calhoun (pacalhou); dperkins@dsperkins.com > Cc: capwap@frascone.com > Subject: RE: [Capwap] to mux or not to mux? >=20 > I know of many enterprises who have multiple 54Mbps access=20 > points all run back to the same switch, which have a 100Mbps=20 > uplink. In the future, I am anticipating multiple 802.11n=20 > access points with a single 1Gbps uplink. For temporary=20 > uses(conferences), I have even setup a WTP having a WAN link=20 > back to the AC. My point being, is that there will always be=20 > environments where congestion will occur between the WTP and=20 > the AC. In a perfect world, there is no over-subscription=20 > and no congestion.=20 >=20 > When congestion occurs, typically you want to ensure that the=20 > data traffic is dropped, not the control traffic. I agree=20 > with your statement that the WTP or AC could apply the=20 > appropriate DSCP or 802.1q marking, and I had too suggested=20 > that earlier: =20 >=20 > ">> One possible method could be for the WTP to assign the CoS/DSCP=20 > >> values for each traffic type so the administrator would have the=20 > >> ability to trust the markings provided by the WTP, or=20 > later perform a=20 > >> DSCP-mutation.?" >=20 > However, I have not seen any mention that if we are going to=20 > pursue using a mux header that this would be incorporated=20 > into the changes. If this was to be >=20 > done, it would really make sense for the CAPWAP WG to make=20 > CoS/DSCP recommendations for these values. Vendor=20 > interoperability is somewhat hampered from a usability=20 > perspective if you need to do different DSCP mutations based=20 > upon which vendor WTP/AC you are using. >=20 > Thanks, > Mike >=20 >=20 > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > Sent: Thursday, May 04, 2006 9:04 PM > To: Pat Calhoun (pacalhou); Kraus, Michael; dperkins@dsperkins.com > Cc: capwap@frascone.com > Subject: RE: [Capwap] to mux or not to mux? >=20 > Please explain what problem is encountered if the same QoS=20 > policy is applied to both control and data traffic. Also=20 > explain why any such problems cannot be >=20 > solved by having the WTP and/or AC apply appropriate DSCP or=20 > 802.1q marking. >=20 > -----Original Message----- > >From: "Pat Calhoun (pacalhou)" > >Sent: May 4, 2006 4:11 PM > >To: "Kraus, Michael" , > >dperkins@dsperkins.com > >Cc: capwap@frascone.com > >Subject: RE: [Capwap] to mux or not to mux? > > > >The point Michael makes here is the same one I was making.=20 > Nearly every=20 > >enterprise class system, router or switch, is capable of=20 > providing QoS=20 > >enforcement using simple ACLs, which rely on IP addresses and ports. > >QoS is just one of many features that can be (and are) implemented=20 > >through ACLs that would be very useful to CAPWAP. > > > >The use of the MUX makes all of the deployed equipment out there no=20 > >longer capable of applying QoS based on control/data plane. I think=20 > >this is a serious issue, and justifies the need for two ports. > > > >Pat Calhoun > >CTO, Wireless Networking Business Unit > >Cisco Systems > > > >=20 > > > >> -----Original Message----- > >> From: Kraus, Michael [mailto:Michael.Kraus@anheuser-busch.com] > >> Sent: Thursday, May 04, 2006 8:17 AM > >> To: dperkins@dsperkins.com > >> Cc: capwap@frascone.com > >> Subject: Re: [Capwap] to mux or not to mux? > >>=20 > >> David, > >> =20 > >> Maybe I'm misinterpreting something here and may be somewhat=20 > >> off-topic, but often in QoS you try to classify traffic by=20 > >> source/destination IP/port or by some higher level=20 > interpreter (such=20 > >> as NBAR in the cisco world). If the same UDP port number is being=20 > >> used for both control/data, how will intermediate=20 > switches/routers be=20 > >> able to determine what is control vs. data traffic? This relates=20 > >> back to your comment below of: > >>=20 > >> "So, it all comes down to whether or not we want intermediate=20 > >> network devices to distinguish between control and data." > >>=20 > >> One possible method could be for the WTP to assign the CoS/DSCP=20 > >> values for each traffic type so the administrator would have the=20 > >> ability to trust the markings provided by the WTP, or=20 > later perform a=20 > >> DSCP-mutation. > >>=20 > >> I don't pretend to be a QoS expert, and I'm sure many=20 > products can=20 > >> classify traffic by data outside of known IP/UDP headers. =20 > However, I=20 > >> would argue that this would likely be platform dependent. For=20 > >> example, Cisco could create a PDLM for NBAR for these mux values. > >> But, obviously this support does not exist today, and NBAR is=20 > >> dependent upon firmware/hardware support. > >>=20 > >> We probably need a "neutral" person on this topic to=20 > summarize the=20 > >> Pros/Cons that have been already stated on this issue... > >>=20 > >>=20 > >> Thanks, > >> Mike > >>=20 > >> ------------------------------ > >>=20 > >> Message: 2 > >> Date: Thu, 4 May 2006 07:19:53 -0700 (PDT) > >> From: "David T. Perkins" > >> Subject: Re: [Capwap] to mux or not to mux? > >> To: "Kraus, Michael" > >> Cc: capwap@frascone.com > >> Message-ID: > >> > >> Content-Type: TEXT/PLAIN; charset=3DUS-ASCII > >>=20 > >> HI, > >>=20 > >> Since UDP is being used, why cannot the data traffic packets be=20 > >> marked with a different QoS values than control traffic packets. > >>=20 > >> Would you explain and provide an example of use of "current QoS=20 > >> tools". > >>=20 > >> Regards, > >> /david t. perkins > >>=20 > >> On Thu, 4 May 2006, Kraus, Michael wrote: > >> > One additional upside to using separate ports would be that > >> different > >> > QoS > >>=20 > >> > policies can be applied against data/control data. With > >> mux values, > >> > this > >>=20 > >> would > >> > be more difficult to accomplish with current QoS tools. =20 > >> With 802.11n > >> > data > >> rates > >> > being quoted, having the ability to do some "control plane > >> policing"=20 > >> > for the APs, might be advantageous. > >> >=20 > >> >=20 > >>=20 > --------------------------------------------------------------------- > >> - > >> >=20 > >> > Message: 1 > >> > Date: Wed, 3 May 2006 15:16:21 -0700 (PDT) > >> > From: "David T. Perkins" > >> > Subject: Re: [Capwap] to mux or not to mux? > >> > To: Charles Clancy > >> > Cc: capwap > >> > Message-ID: > >> > > >> > Content-Type: TEXT/PLAIN; charset=3DUS-ASCII > >> >=20 > >> > HI, > >> >=20 > >> > Please don't forget about the discovery message. With it, > >> you have 3 > >> > values > >> for > >> > MUX. See below.. > >> >=20 > >> > Also, please note that in the prototype that I'm > >> developing, I'm using > >> > the UNMODIFIED DTLS implementation in openSSL. > >> > That is, adding the MUX header does not require any=20 > modification of=20 > >> > the > >> openSSL. > >> > By the way,my two wishes are: > >> > 1) an Ethereal decode for the below > >> > 2) the addition of the NULL encryption type to the > >> > CAPWAP protocol for debugging > >> >=20 > >> > On Wed, 3 May 2006, Charles Clancy wrote: > >> > > The DTLS tunnels would NOT be merged. You'd have=20 > something like: > >> >=20 > >> > +---------+------------+------------------------ > >> > | UDP hdr | MUX =3D 0x00 | Discovery Request or Response > >> > +---------+------------+----------- > >> >=20 > >> >=20 > >> > > +---------+------------+------------------------ > >> > > | UDP hdr | MUX =3D 0x01 | DTLS(CAPWAP Control) > >> > > +---------+------------+----------- > >> > > > >> > > or > >> > > > >> > > +---------+------------+------------------------ > >> > > | UDP hdr | MUX =3D 0x02 | CAPWAP Data > >> > > +---------+------------+----------- > >> > > > >> > > UDP is indeed a MUX header, but it's a MUX header that=20 > everything=20 > >> > > already understands. So, it all comes down to whether=20 > or not we=20 > >> > > want intermediate network devices to distinguish between > >> control and data. > >> > > For NAT traversal, it's easier if the NAT treats=20 > everything the=20 > >> > > same, and doesn't have to know that the two ports are > >> related. Same > >> > > for firewall / port forwarding. I think intermediate network=20 > >> > > devices should treat everything as "CAPWAP", and we > >> should therefore do our own MUX. > >> > > > >> > > -- > >> > > t. charles clancy, ph.d. | tcc@umd.edu | > >> www.cs.umd.edu/~clancy > >> > > > >> > > Nancy Winget (ncamwing) wrote: > >> > > > Charles, > >> > > > > >> > > > With a MUX, yes they are logical channels, but I believe the=20 > >> > > > implication is that these channels are merged into a > >> single DTLS > >> > > > tunnel...are you saying they are not? > >> > > > > >> > > > But as you state, if UDP is a MUX header, why the need to=20 > >> > > > introduce yet another one instead of just using UDP for > >> separation? > >> > > > > >> > > > Nancy. > >> > > > > >>=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 >=20 _________________________________________________________________ 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 May 05 10:48:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc1b9-0003xk-Nk for capwap-archive@lists.ietf.org; Fri, 05 May 2006 10:48:03 -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 1Fc0y9-0005Xh-FK for capwap-archive@lists.ietf.org; Fri, 05 May 2006 10:07:45 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fc0qA-0003Zn-Aj for capwap-archive@lists.ietf.org; Fri, 05 May 2006 09:59:32 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2121C430137 for ; Fri, 5 May 2006 06:59:29 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 0A2A2430092 for ; Fri, 5 May 2006 06:59:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EE60A430F64 for ; Fri, 5 May 2006 06:59:03 -0700 (PDT) Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by hermes.tigertech.net (Postfix) with ESMTP id 6F21A430F5D for ; Fri, 5 May 2006 06:59:00 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-3.cisco.com with ESMTP; 05 May 2006 06:58:59 -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 k45Dwxw1024378; Fri, 5 May 2006 06:58:59 -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, 5 May 2006 06:58:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Issue 70: Section 5.2.2 Minor Editioral Comment Date: Fri, 5 May 2006 06:58:59 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D82B64@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 70: Section 5.2.2 Minor Editioral Comment Thread-Index: AcZu1skF5ZEZDgfaRA+u4B3fdJDjrABdT/0Q From: "Pat Calhoun (pacalhou)" To: "Puneet" X-OriginalArrivalTime: 05 May 2006 13:58:58.0790 (UTC) FILETIME=[0E640860:01C6704C] 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 X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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: 36c793b20164cfe75332aa66ddb21196 I've created issue 118 to track this request. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Puneet [mailto:pb.ietf@gmail.com]=20 > Sent: Wednesday, May 03, 2006 10:27 AM > To: Pat Calhoun (pacalhou) > Cc: capwap > Subject: Re: [Capwap] Issue 70: Section 5.2.2 Minor Editioral Comment >=20 > Can we change the hardware and software version numbers in=20 > this message as well as the WTP model number in the board=20 > data to be of variable length? I think there is already an=20 > issue open for making all fixed-length CAPWAP IEs variable length. >=20 > The fixed lengths in the current protocol specification are=20 > sometimes too short for existing implementations that now=20 > want to support CAPWAP, and there does not seem to be a=20 > reason to limit these to the numbers specified. We can either=20 > use Radius style tag-length-values for all these IEs, or keep=20 > the "tag" portion as-is (so that the order in which the=20 > elements appear is enforced), but make the data part=20 > "length-value" (ie a 1 byte length precedes the actual data) >=20 > thanks, > Puneet >=20 > On 4/29/06, Pat Calhoun (pacalhou) wrote: > > The issue stated that the following section refered to=20 > radios instead=20 > > of WTPs, which was a bug in the text. I have made the necessary=20 > > correction and am closing the issue. > > > > 5.2.2. AC Descriptor > > > > The AC payload message element is used by the AC to=20 > communicate it's > > current state. The 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=20 > 7 8 9 0 1 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Reserved | Hardware Version=20 > ... | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | HW Ver | Software Version=20 > ... | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | SW Ver | Stations | =20 > Limit | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Limit | Active WTPs | =20 > Max WTPs | > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Max WTPs | Security | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Type: 6 for AC Descriptor > > > > Length: 18 > > > > Reserved: MUST be set to zero > > > > Hardware Version: The AC's hardware version number > > > > Software Version: The AC's Firmware version number > > > > Stations: The number of mobile stations currently=20 > associated with > > the AC > > > > Limit: The maximum number of stations supported by the AC > > > > Active WTPs: The number of WTPs currently attached to the AC > > > > Max WTPs: The maximum number of WTPs supported by the AC > > > > Security: A 8 bit bit mask specifying the=20 > authentication credential > > type supported by the AC. The following values are=20 > supported (see > > Section 10): > > > > 1 - X.509 Certificate Based > > > > 2 - Pre-Shared Secret > > > > > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems=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 _________________________________________________________________ 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 May 05 11:01:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc1o3-0002nv-DX for capwap-archive@lists.ietf.org; Fri, 05 May 2006 11:01:23 -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 1Fc0yA-0005Xh-6R for capwap-archive@lists.ietf.org; Fri, 05 May 2006 10:07:46 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fc0oF-0003YI-27 for capwap-archive@lists.ietf.org; Fri, 05 May 2006 09:57:34 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DB568430122 for ; Fri, 5 May 2006 06:57:26 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 44398430092 for ; Fri, 5 May 2006 06:57:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id AC82A398034 for ; Fri, 5 May 2006 06:57:03 -0700 (PDT) Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4FCBF398031 for ; Fri, 5 May 2006 06:56:58 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 05 May 2006 06:56:58 -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 k45DuvRV012019; Fri, 5 May 2006 06:56:58 -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, 5 May 2006 06:56:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 May 2006 06:56:58 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D82B63@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues 101: 11.8.1.1 Change to re-use 802.11 Information element definitions Thread-Index: AcZu1LIWJguhMiJSRS2EpfFz5npNxwBdth0w From: "Pat Calhoun (pacalhou)" To: "Puneet" X-OriginalArrivalTime: 05 May 2006 13:56:57.0761 (UTC) FILETIME=[C6407910:01C6704B] 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: [Capwap] RE: Issues 101: 11.8.1.1 Change to re-use 802.11 Information element definitions X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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: cab78e1e39c4b328567edb48482b6a69 > > Encryption Policy: A 32-bit value specifying the=20 > encryption scheme > > to apply to traffic to and from the mobile station. >=20 > this might also be a good place to note that the format of=20 > those 32 bits is the same as what the IEEE 802.11i=20 > specification mentions. That allows vendor specific=20 > encryption types, and can also be updated by IEEE for new=20 > types without having to update the CAPWAP specification. Issue 116 created for this. > > 4. Does the 'Suppress SSID' field also disable the=20 > use of that=20 > > SSID in broadcast probe responses? If so, why do we also need the=20 > > 'IEEE > > 802.11 Broadcast Probe Mode' in section 11.9.12? Also, why=20 > is this IE=20 > > global for the WTP? The AC might configure the WTP with 10=20 > WLANs, but=20 > > it may want probe responses generated for only four of those when a=20 > > broadcast probe request comes in. > > > > Section 11.9.12 deals with the changing of the mode=20 > of operation=20 > > after the WLAN is already operational. >=20 > I still dont understand why this needs to be global. To quote=20 > the current draft: > "Since broadcast NULL probes are not sent to a specific=20 > BSSID, the WTP cannot know which SSID the sending station is=20 > querying. Therefore, this behavior must be global to the WTP." > However when a broadcast probe request comes in, of all the=20 > WLANs mapped to that WTP, the user should be able to=20 > configure which ones are responded to. That text seems incorrect. Issue 117 created to track this issue 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 May 05 12:01:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc2k3-0008AJ-DX for capwap-archive@lists.ietf.org; Fri, 05 May 2006 12:01:19 -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 1Fc2k3-0001wF-BT for capwap-archive@lists.ietf.org; Fri, 05 May 2006 12:01:19 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fc2XJ-0004YR-38 for capwap-archive@lists.ietf.org; Fri, 05 May 2006 11:48:14 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A974E4300FF for ; Fri, 5 May 2006 08:48:07 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 920D2430082 for ; Fri, 5 May 2006 08:47:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3DAA0398041 for ; Fri, 5 May 2006 08:47:33 -0700 (PDT) Received: from huawei.com (szxga01-in.huawei.com [61.144.161.53]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8FF45398031 for ; Fri, 5 May 2006 08:47:29 -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 <0IYS001HVUJTMH@szxga01-in.huawei.com> for capwap@frascone.com; Fri, 05 May 2006 23:47:53 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYS006J9UJRVT@szxga01-in.huawei.com> for capwap@frascone.com; Fri, 05 May 2006 23:47:53 +0800 (CST) Received: from dell60 ([10.18.7.113]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IYS007APVD3SZ@szxml01-in.huawei.com>; Sat, 06 May 2006 00:05:28 +0800 (CST) Date: Fri, 05 May 2006 21:17:15 +0530 From: sujay Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages In-reply-to: <4FF84B0BC277FF45AA27FE969DD956A201D82B74@xmb-sjc-235.amer.cisco.com> To: "'Pat Calhoun (pacalhou)'" , 'Saravanan Govindan' , 'Dorothy Stanley' Message-id: <00bb01c6705b$2f86dc20$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 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT 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' X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (--) X-Scan-Signature: f2a5dc784731617f446f668f2c529db6 Correct,. But could the draft talk about the expected behaviour on reception of Messages beyond the scope of current state.?? It would be nice to have addition. -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Friday, May 05, 2006 7:46 PM To: sujay; Saravanan Govindan; Dorothy Stanley Cc: capwap Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Keep in mind that the discovery is NOT secured. So if you assume that this unsecured packet implies the peer is dead, then you've created a very simple DoS attack. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: sujay [mailto:sujayg@huawei.com] > Sent: Thursday, May 04, 2006 11:22 PM > To: Pat Calhoun (pacalhou); 'Saravanan Govindan'; 'Dorothy Stanley' > Cc: 'capwap' > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > -Issueoncombiningmessages > > Nevertheless, a discovery recvd in the run state should > ideally indicate the peer has gone down, Probably a reboot. > It may turn out to be a faster way of detecting Nbr Down than > waiting for Nbr dead interval. > (Of course subject to the packet being authentic) > > In general, perhaps the draft should specify about "treatment > of messages when recvd in the incorrect state". > i.e should it be dropped or any action is to be taken. > > Comments? > > Regds, > Sujay > > > > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Friday, May 05, 2006 4:24 AM > To: sujay; Saravanan Govindan; Dorothy Stanley > Cc: capwap > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > -Issueoncombiningmessages > > > But we seem to be ignoring the state machine. Keep in mind that this > scheme has to co-exist with the state machine, so a discovery received > while in the Run state is not a valid packet to reset the timer. All > other packets would. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: sujay [mailto:sujayg@huawei.com] > > Sent: Thursday, May 04, 2006 5:25 AM > > To: 'Saravanan Govindan'; Pat Calhoun (pacalhou); 'Dorothy Stanley' > > Cc: 'capwap' > > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > > -Issueoncombiningmessages > > > > Saravanan, > > > > A valid point, yet ALL control messages should be monitored for > > which are VALID in the RUN state. > > > > There is no reason for giving special treatment to statistics > > messages alone. > > > > Considering an implementation, I see no significant overhead in > > assuming say a Configure Request packet as a keepalive packet from > > the peer. > > > > Regds, > > Sujay > > > > > > > > -----Original Message----- > > From: Saravanan Govindan > [mailto:Saravanan.Govindan@sg.panasonic.com] > > Sent: Thursday, May 04, 2006 2:29 PM > > To: Pat Calhoun (pacalhou); Dorothy Stanley > > Cc: capwap > > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > > -Issueoncombiningmessages > > > > > > Without the text below, the specifications will require an AC to > > monitor the arrival of "all" control packet with respect to the > > EchoInterval and > > NeighbourDeadInterval timers. There were concerns earlier on > > this thread > > that this is not ideal. > > > > > > Furthermore, not all control packets indicate that a WTP is > alive and > > doing well. A WTP could fail, re-start and then send Discovery > > Requests to an AC. This should not be construed as an > indication that > > the WTP is > > well. On the other hand, by focusing only on Statistics (WTP Event > > Request) control messages, it is unambiguous that a WTP is > > operational. > > > > So the text in the specifications should reflect this by > having Echo > > Requests sent in the absence of Statistics (WTP Event > > Request) messages. > > > > > > Saravanan > > > > > > > > > > > > > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Thursday, May 04, 2006 12:50 PM > > To: Saravanan Govindan; Dorothy Stanley > > Cc: Scott G Kelly; capwap > > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > > -Issueoncombiningmessages > > > > The text you are proposing doesn't change the behavior of the > > protocol. I'm not sure that it really adds anything since we are > stating that an > > echo is sent if no control packets are sent. You are free to send > > periodic Statistics messages, which with the new language would not > > require any Echos to be sent. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > > > > From: Saravanan Govindan > [mailto:Saravanan.Govindan@sg.panasonic.com] > > Sent: Wednesday, May 03, 2006 8:18 PM > > To: Dorothy Stanley; Pat Calhoun (pacalhou) > > Cc: Scott G Kelly; capwap > > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > > -Issueoncombiningmessages Hi Dorothy, > > > > I suggest that the Echo Request MAY only be send in the absence of > > specifically Statistics control packets as opposed to any control > > packets. The reason for this is that Statistics packets are > the only > > regular exchanges, so the AC has just one type of packet to monitor > > for the timer. > > > > So I'd like to suggest the following text: > > > > From: > > "If another Echo Request or other control message is not received by > > the AC when the timer expires, the AC > > SHOULD consider the WTP to be unreachable" > > > > To: > > "If another Echo Request or Statistics message is not received by > > the AC when the timer expires, the AC > > SHOULD consider the WTP to be unreachable" > > > > Cheers, > > > > Saravanan > > > > > > > > > > > > > > > > > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > > Sent: Thursday, May 04, 2006 3:03 AM > > To: Pat Calhoun (pacalhou) > > Cc: Scott G Kelly; Saravanan Govindan; capwap > > Subject: Re: [Capwap] Proposed Resolution to Issue 45 > > -Issueoncombiningmessages > > > > All, > > > > After the lengthy discussion on this topic, I believe that the > > conclusion is still to reject the comment, and as Pat > summarized, the > > echo remains, does not include any > > statistics, and MAY only be sent in the absence of any > > control packets. > > > > Changes to the text: > > > > Change text in 6.2" Echo Response" from: > > "If another Echo Request message is not received by the AC when the > > timer expires, the AC SHOULD consider the WTP to be unreachable" to > > > > "If another Echo Request or other control message is not received by > > the AC when the timer expires, the AC > > SHOULD consider the WTP to be unreachable" > > > > and from > > > > "If the NeighborDeadInterval timer expires prior to > receiving an Echo > > Response message, message, the WTP enters the Reset State." to > > "If the NeighborDeadInterval timer expires prior to > receiving an Echo > > Response message, or other control > > message, the WTP enters the Reset State." > > > > > > Thanks, > > > > Dorothy > > > > Issue 45, Issue on Combining messages currently has the following > > discussion in the issues database: Currently, the keepalive and > > statistics messages are separated. Separate > > > > > > > > > > > > > > > > > > messages for keepalive signaling and statistics can lead to high > > overhead. > > > > > > > > > > > > > > > > Initial analysis have shown that these overhead can be reduced > > significantly > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > if the messages can be combined. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Recommendation: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To combine the keepalive and statistics message into one combined > > message, > > > > > > > > > > > > > > > > thus reducing overhead significantly. > > > > Discussion: > > > > The CAPWAP protocol specification currently supports the Echo > > Request Message and Echo Response Messages, which are used for > > keep-alive purposes, and do not carry message elements. > > > > There is an IEEE 802.11 Statistics measurement > element(11.7.2.1), and > > several CAPWAP statistics related measurement elements: decryption > > error report, WTP descriptor, WTP radio > > information, WTP reboot statistics. > > There is no statistics message. > > > > There is no requirement on how often the statistics related > > measurement elements must be reported > > to the AC from the WTP, there is a Statistics timer, see > > 7.2.5, which is > > used by the AC to indicate the > > timer value to the WTP. (separate question - should the > > statistics timer > > be made general, and indicate the > > values for the other Section 12 CAPWAP timers too? Assume that the > > CAPWAP statistics timer used > > to determine how often to send the 802.11 specific statistics). > > > > It is not clear that there is a high overhead in keeping the > > echo/keep-alive mechanism from the statistics reporting. > There is some > > > benefit in keeping the echo messages simple, > > rather than complicating the processing of those messages. > It is true > > that small messages (echo request, response) have high overhead. In > > this case, the design choice is to accept the overhead as the cost > > of simplicity in design and implementation. > > > > Recommended resolution: reject the comment, with the explanation in > > the above paragraph > > On 4/28/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com> wrote: > > I will summarize my thoughts here and not try to inject in > > the various > > threads, but I agree that the echo remains, does not include any > > statistics, and MAY only be sent in the absence of any > > control packets. > > I say MAY because an implementation could send them if it > wishes, but > > the receiver must take into account control packets in > > addition to the > > echo prior to declaring a link dead. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Scott G Kelly [mailto: scott@hyperthought.com] > > > Sent: Friday, April 21, 2006 5:52 AM > > > To: Saravanan Govindan > > > Cc: capwap > > > Subject: Re: [Capwap] Proposed Resolution to Issue 45 > > > -Issueoncombiningmessages > > > > > > Hi Saravanan, > > > > > > Saravanan Govindan wrote: > > > > Hi Scott, > > > > > > > > I think David's note does address the issue on hand. > > > > > > > > To formalize; > > > > > > > > The exchange of control messages between a WTP and AC > implicitly > > > > indicates that the WTP is operational. For the purpose > of protocol > > > > > simplicity, I suggest that we focus on statistics messages > > > alone for > > > > this purpose, reason being that statistics are periodically > > > exchanged. > > > > > > > > My concern is that by using "any" control message to indicate > > > > keepalive (Echo), the AC processing will be > complicated. This is > > > > because the AC will need to process each control message > > > for both its own value (e.g. > > > > Configure Request) and also keepalive value. > > > > > > Of course, complexity is a function of many factors, but there is > > > a straightforward way to implement an echo trigger with a flag and > > > timer: when you receive a control message, unconditionally raise > the flag. > > > Periodically (according to your keepalive interval timer) > > > check the flag; If it's up, put it down, else send a > > > keepalive. There are more complicated ways to implement, but > > > this works just fine. > > > > > > On the AC this can easily be implemented by having the fastpath > > > raise the flag, and having the cp lower it and/or do whatever it > > > is your AC does if a WTP doesn't report in a given echo interval > > > (which may be nothing). Pretty basic stuff. > > > > > > On the WTP, implementation is similar, except that if the flag is > > > down, you send the keepalive. Again, very simple > and basic. > > > > > > > So I suggest keeping it simple - arrival of statistics > > message from > > > > WTP means WTP is alive. > > > > > > Certainly, a statistics message qualifies as a control message, so > > > I have no issues with this statement when taken alone. I'm > > > concerned with the earlier suggestion that the echo req/reply > > > message be discarded and replaced by the statistics message. > > > > > > In some cases, the keepalive interval must be *very* > brief in order > > > to facilitate rapid link loss detection and recovery. I > know of one > > > vendor who routinely uses a one second interval, and it's > > > conceivable that in some scenarios one might choose to use even > > > less. > > > > > > And keep in mind that WTP and AC requirements are typically > > > asymmetric in this regard: the WTP needs to react quickly > (maybe try > > > > to find another AC), whereas the AC simply needs to > somehow report > > > the event. While in some cases reporting might be > considered urgent, > > > this is not the typical (or average) case. > > > > > > The granularity requirements for reporting are typically much > > > coarser than those of recovery. That is, the AC may, at > it's option, > > > > only check every 10,20,30,... seconds for WTP liveness, > and it may > > > very well do that via the stats message, rather than the > echo, since > > > > this allows echo processing to remain wholly in the AC fastpath. > > > > > > But say we eliminate the echo: what happens when, say, > 500 WTPs send > > > > stats potentially every second or less? > > > > > > I think we still need the echo req/rsp. > > > > > > Scott > > > > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > > > > Sent: Wednesday, April 19, 2006 1:51 AM > > > > To: capwap > > > > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > > > > -Issueoncombiningmessages > > > > > > > > Just trying to close the loop: I think David's point (i.e. > > > that echoes > > > > should only be sent in the absence of other control > > > traffic) is dead > > > > on, and that this effectively closes the question as to > > > whether echoes > > > > and stats should be combined in the same messages. > > > > > > > > Does anyone disagree? > > > > > > > > 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 Fri May 05 12:44:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc3PT-00074R-SX for capwap-archive@lists.ietf.org; Fri, 05 May 2006 12:44:07 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc3PR-0003Wn-Et for capwap-archive@lists.ietf.org; Fri, 05 May 2006 12:44:07 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1F77A4300EE for ; Fri, 5 May 2006 09:44:05 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id A392E4300AC for ; Fri, 5 May 2006 09:43:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8663C431217 for ; Fri, 5 May 2006 09:43:39 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by hermes.tigertech.net (Postfix) with ESMTP id 7188543121E for ; Fri, 5 May 2006 09:43:36 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id g2so580840nfe for ; Fri, 05 May 2006 09:43:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SbKpSWXK51NY1SU9eTzey+wG6mY3U4ihN0dduLn/3SGXP32+5z0OcHGwhHqZz/bZ2spXtcERziWTPQOYmQJFSfPO7luPHZruAs57jBp7xukutP1oU6KwHFZgOFYc6sbDWYri5yNWKWyKmmdeX62bN3guRZtqb9IrMOoZ7r1L57M= Received: by 10.49.80.7 with SMTP id h7mr1838104nfl; Fri, 05 May 2006 09:43:34 -0700 (PDT) Received: by 10.49.90.6 with HTTP; Fri, 5 May 2006 09:43:34 -0700 (PDT) Message-ID: <1013407b0605050943k379d1a1eq26282e5c3ea56f8a@mail.gmail.com> Date: Fri, 5 May 2006 09:43:34 -0700 From: Puneet To: "Pat Calhoun (pacalhou)" Subject: Re: [Capwap] to mux or not to mux? In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201D82B72@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4FF84B0BC277FF45AA27FE969DD956A201D82B72@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=RCVD_BY_IP X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 > > - 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. > > There is a clear binding, which is the BSSID (or equivalent terminology > for other wireless technologies). I am not sure I understand: Does every control message also contain the BSSID? If not, then how is BSSID the binding between the control and data messages? With a single port approach all traffic on that is one bound channel. > I believe I have made my case about QoS. Perhaps you are not satisfied > with the fact that there are millions of Ethernet and routed ports in > the world that have specific capabilities that operate at the UDP port > level that we do not get to leverage by creating this multiplexed > header. However, it is reality, and something that I truly believe we > need to take advantage of. I thought the DSCP/ToS values in the IP header was the standard way to do QoS (and the 802.1p priorities), not based on UDP port numbers. WiFi WMM tests for example dont map wired traffic to wireless access categories depending on what UDP port number that traffic came on, they use DSCP/802.1p. > Assume a NAT, where a WAN router exists which provides QoS capabilities. > Let's also assume that the WAN router has to handle much more than just > CAPWAP data. By multiplexing the data, we are eliminating the > possibility for the WAN router to apply the necessary policies to > minimize congestion over the link, while ensuring that the CAPWAP > control session stays up. So the WAN router looks at the DSCP values of the packets, and provides better service to the CAPWAP control frames. In fact this should work without any configuration on a networking device that honors DSCP/ToS bits. With the UDP port QoS proposal every device between the AC and the WTP would have to be configured to understand that there are two port numbers here and one of them is of higher priority than the other. Thanks, Puneet _________________________________________________________________ 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 May 05 13:08:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc3mt-0002Hc-Q4 for capwap-archive@lists.ietf.org; Fri, 05 May 2006 13:08:19 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc3ms-0004Gz-Cn for capwap-archive@lists.ietf.org; Fri, 05 May 2006 13:08:19 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id ADB8F430117 for ; Fri, 5 May 2006 10:08:17 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 533BC43006D for ; Fri, 5 May 2006 10:07:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2B771398034 for ; Fri, 5 May 2006 10:07:55 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7EE74398010 for ; Fri, 5 May 2006 10:07:52 -0700 (PDT) Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Fri, 05 May 2006 10:07:38 -0700 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 364202AF; Fri, 5 May 2006 10:07:38 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 0D5D12AE; Fri, 5 May 2006 10:07:38 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5-GA) with ESMTP id DLK67718; Fri, 5 May 2006 10:07:37 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 1A4B420501; Fri, 5 May 2006 10:07:37 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header Date: Fri, 5 May 2006 10:07:36 -0700 Message-ID: <8954613CA6BB3242A1531D916A527A41BDAE55@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [Capwap] Issue 53: Add Data Rate to LWAPP Header Thread-Index: AcZv5RRNZA5B3IICTIOsPasrxj5rmwAZ8Z8wAAYHtUA= From: "Puneet Agarwal" To: "Pat Calhoun (pacalhou)" , "Jim Murphy" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006050505; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230342E34343542383437422E303030432D412D; ENG=IBF; TS=20060505170742; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006050505_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 684559D00HW13367581-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 , Abhijit Choudhury X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Hi Pat, One suggestion: The "payload type" should be an encoded value. If one assumes that it is 3 bits for now, one could have the following encoded with enough reserved encoding available for future technologies. 0b000: 802.3 payload 0b001: 802.11 payload 0b010: 802.16 payload 0b011 - 0b111: Reserved Thanks. -Puneet -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Friday, May 05, 2006 7:06 AM To: Jim Murphy Cc: capwap; Abhijit Choudhury Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header Ok, good question. How would we specify 802.11, 802.16 and 802.3? I hope we are not proposing a new bit for every wireless encapsulation type, right? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Jim Murphy [mailto:jmurphy@trapezenetworks.com] > Sent: Thursday, May 04, 2006 6:42 PM > To: Pat Calhoun (pacalhou) > Cc: Abhijit Choudhury; capwap > Subject: Re: [Capwap] Issue 53: Add Data Rate to LWAPP Header >=20 > If the WTP supported both 802.11 and 802.16. 802.16 encapsulates 802.3 > frames. >=20 > Thanks, >=20 > Jim >=20 > Pat Calhoun (pacalhou) wrote: > > But do you believe that WTPs would send both simultaneously? > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > >=20 > > =20 > >=20 > >> -----Original Message----- > >> From: Abhijit Choudhury [mailto:Abhijit@sinett.com] > >> Sent: Thursday, May 04, 2006 4:34 PM > >> To: Pat Calhoun (pacalhou); Jim Murphy > >> Cc: capwap > >> Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header > >> > >> Pat, > >> I agree with Jim. It's easier if the packet header conveys this=20 > >> information, i.e., what kind of payload it is carrying. > >> > >> On a related note, shouldn't RadioId be part of the Wireless=20 > >> Specific Information field ? > >> > >> Thanks, > >> Abhijit > >> > >> >=20 _________________________________________________________________ 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 May 05 13:30:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc48n-0004qk-9E for capwap-archive@lists.ietf.org; Fri, 05 May 2006 13:30:57 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc48l-0005Hc-Ag for capwap-archive@lists.ietf.org; Fri, 05 May 2006 13:30:57 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 85878430106 for ; Fri, 5 May 2006 10:30:54 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 44B28430082 for ; Fri, 5 May 2006 10:30:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2F3B6398034 for ; Fri, 5 May 2006 10:30:21 -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 13F3A398026 for ; Fri, 5 May 2006 10:30:17 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 05 May 2006 10:30:17 -0700 X-IronPort-AV: i="4.05,93,1146466800"; d="scan'208"; a="426584356:sNHT33178456" 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 k45HUFRT028778; Fri, 5 May 2006 10:30:16 -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, 5 May 2006 10:30:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Date: Fri, 5 May 2006 10:30:14 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D82CA5@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Thread-Index: AcZwW0RiA2hjC0nZQ6GRXLfde6dJNAADkfhg From: "Pat Calhoun (pacalhou)" To: "sujay" , "Saravanan Govindan" , "Dorothy Stanley" X-OriginalArrivalTime: 05 May 2006 17:30:15.0147 (UTC) FILETIME=[92169BB0:01C67069] 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 0e831a3b581a967a651997b2cbc2bae7 Note that I have created issue 121 to track this. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: sujay [mailto:sujayg@huawei.com]=20 > Sent: Friday, May 05, 2006 8:47 AM > To: Pat Calhoun (pacalhou); 'Saravanan Govindan'; 'Dorothy Stanley' > Cc: 'capwap' > Subject: RE: [Capwap] Proposed Resolution to Issue 45=20 > -Issueoncombiningmessages >=20 > Correct,. > But could the draft talk about the expected behaviour on=20 > reception of Messages beyond the scope of current state.?? > It would be nice to have addition. >=20 >=20 > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 > Sent: Friday, May 05, 2006 7:46 PM > To: sujay; Saravanan Govindan; Dorothy Stanley > Cc: capwap > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > -Issueoncombiningmessages >=20 >=20 > Keep in mind that the discovery is NOT secured. So if you assume that > this unsecured packet implies the peer is dead, then you've created a > very simple DoS attack. >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 > =20 >=20 > > -----Original Message----- > > From: sujay [mailto:sujayg@huawei.com] > > Sent: Thursday, May 04, 2006 11:22 PM > > To: Pat Calhoun (pacalhou); 'Saravanan Govindan'; 'Dorothy Stanley' > > Cc: 'capwap' > > Subject: RE: [Capwap] Proposed Resolution to Issue 45=20 > > -Issueoncombiningmessages > >=20 > > Nevertheless, a discovery recvd in the run state should > > ideally indicate the peer has gone down, Probably a reboot.=20 > > It may turn out to be a faster way of detecting Nbr Down than=20 > > waiting for Nbr dead interval. > > (Of course subject to the packet being authentic) > >=20 > > In general, perhaps the draft should specify about "treatment > > of messages when recvd in the incorrect state". > > i.e should it be dropped or any action is to be taken. > >=20 > > Comments? > >=20 > > Regds, > > Sujay > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Friday, May 05, 2006 4:24 AM > > To: sujay; Saravanan Govindan; Dorothy Stanley > > Cc: capwap > > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > > -Issueoncombiningmessages > >=20 > >=20 > > But we seem to be ignoring the state machine. Keep in mind=20 > that this=20 > > scheme has to co-exist with the state machine, so a=20 > discovery received >=20 > > while in the Run state is not a valid packet to reset the=20 > timer. All=20 > > other packets would. > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: sujay [mailto:sujayg@huawei.com] > > > Sent: Thursday, May 04, 2006 5:25 AM > > > To: 'Saravanan Govindan'; Pat Calhoun (pacalhou);=20 > 'Dorothy Stanley' > > > Cc: 'capwap' > > > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > > > -Issueoncombiningmessages > > >=20 > > > Saravanan, > > >=20 > > > A valid point, yet ALL control messages should be monitored for=20 > > > which are VALID in the RUN state. > > >=20 > > > There is no reason for giving special treatment to statistics=20 > > > messages alone. > > >=20 > > > Considering an implementation, I see no significant overhead in=20 > > > assuming say a Configure Request packet as a keepalive=20 > packet from=20 > > > the peer. > > >=20 > > > Regds, > > > Sujay > > >=20 > > >=20 > > >=20 > > > -----Original Message----- > > > From: Saravanan Govindan > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > Sent: Thursday, May 04, 2006 2:29 PM > > > To: Pat Calhoun (pacalhou); Dorothy Stanley > > > Cc: capwap > > > Subject: RE: [Capwap] Proposed Resolution to Issue 45=20 > > > -Issueoncombiningmessages > > >=20 > > >=20 > > > Without the text below, the specifications will require an AC to=20 > > > monitor the arrival of "all" control packet with respect to the > > > EchoInterval and > > > NeighbourDeadInterval timers. There were concerns earlier on=20 > > > this thread > > > that this is not ideal. =20 > > > =20 > > > =20 > > > Furthermore, not all control packets indicate that a WTP is > > alive and > > > doing well. A WTP could fail, re-start and then send Discovery > > > Requests to an AC. This should not be construed as an=20 > > indication that > > > the WTP is > > > well. On the other hand, by focusing only on Statistics (WTP Event > > > Request) control messages, it is unambiguous that a WTP is > > > operational.=20 > > > =20 > > > So the text in the specifications should reflect this by > > having Echo > > > Requests sent in the absence of Statistics (WTP Event > > > Request) messages. > > >=20 > > > =20 > > > Saravanan > > > =20 > > > =20 > > > =20 > > >=20 > > >=20 > > >=20 > > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > > Sent: Thursday, May 04, 2006 12:50 PM > > > To: Saravanan Govindan; Dorothy Stanley > > > Cc: Scott G Kelly; capwap > > > Subject: RE: [Capwap] Proposed Resolution to Issue 45=20 > > > -Issueoncombiningmessages > > > =20 > > > The text you are proposing doesn't change the behavior of the=20 > > > protocol. I'm not sure that it really adds anything since we are > > stating that an > > > echo is sent if no control packets are sent. You are free to send=20 > > > periodic Statistics messages, which with the new language=20 > would not=20 > > > require any Echos to be sent. > > > =20 > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit > > > Cisco Systems > > > =20 > > > =20 > > >=20 > > >=20 > > >=20 > > > From: Saravanan Govindan > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > Sent: Wednesday, May 03, 2006 8:18 PM > > > To: Dorothy Stanley; Pat Calhoun (pacalhou) > > > Cc: Scott G Kelly; capwap > > > Subject: RE: [Capwap] Proposed Resolution to Issue 45=20 > > > -Issueoncombiningmessages Hi Dorothy, > > > =20 > > > I suggest that the Echo Request MAY only be send in the absence of > > > specifically Statistics control packets as opposed to any control=20 > > > packets. The reason for this is that Statistics packets are=20 > > the only > > > regular exchanges, so the AC has just one type of packet=20 > to monitor > > > for the timer. > > > =20 > > > So I'd like to suggest the following text: > > > =20 > > > From: > > > "If another Echo Request or other control message is not=20 > received by >=20 > > > the AC when the timer expires, the AC > > > SHOULD consider the WTP to be unreachable" > > > =20 > > > To: > > > "If another Echo Request or Statistics message is not received by=20 > > > the AC when the timer expires, the AC > > > SHOULD consider the WTP to be unreachable" > > > =20 > > > Cheers, > > >=20 > > > Saravanan > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > >=20 > > >=20 > > >=20 > > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > > > Sent: Thursday, May 04, 2006 3:03 AM > > > To: Pat Calhoun (pacalhou) > > > Cc: Scott G Kelly; Saravanan Govindan; capwap > > > Subject: Re: [Capwap] Proposed Resolution to Issue 45=20 > > > -Issueoncombiningmessages > > > =20 > > > All, > > >=20 > > > After the lengthy discussion on this topic, I believe that the > > > conclusion is still to reject the comment, and as Pat=20 > > summarized, the > > > echo remains, does not include any > > > statistics, and MAY only be sent in the absence of any > > > control packets.=20 > > >=20 > > > Changes to the text: > > >=20 > > > Change text in 6.2" Echo Response" from: > > > "If another Echo Request message is not received by the=20 > AC when the > > > timer expires, the AC SHOULD consider the WTP to be=20 > unreachable" to > > >=20 > > > "If another Echo Request or other control message is not=20 > received by >=20 > > > the AC when the timer expires, the AC > > > SHOULD consider the WTP to be unreachable"=20 > > >=20 > > > and from > > >=20 > > > "If the NeighborDeadInterval timer expires prior to > > receiving an Echo > > > Response message, message, the WTP enters the Reset State." to > > > "If the NeighborDeadInterval timer expires prior to=20 > > receiving an Echo > > > Response message, or other control > > > message, the WTP enters the Reset State." > > >=20 > > >=20 > > > Thanks, > > >=20 > > > Dorothy > > >=20 > > > Issue 45, Issue on Combining messages currently has the following > > > discussion in the issues database: Currently, the keepalive and=20 > > > statistics messages are separated. Separate > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > =20 > > > =20 > > > messages for keepalive signaling and statistics can lead to high > > > overhead. > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > =20 > > > =20 > > > Initial analysis have shown that these overhead can be reduced > > > significantly > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > =20 > > > =20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > =20 > > > =20 > > > if the messages can be combined. > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > =20 > > > =20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > =20 > > > =20 > > > Recommendation: > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > =20 > > > =20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > =20 > > > =20 > > > To combine the keepalive and statistics message into one combined > > > message, > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > =20 > > > =20 > > > thus reducing overhead significantly. > > >=20 > > > Discussion: > > >=20 > > > The CAPWAP protocol specification currently supports the Echo=20 > > > Request Message and Echo Response Messages, which are used for=20 > > > keep-alive purposes, and do not carry message elements. > > >=20 > > > There is an IEEE 802.11 Statistics measurement > > element(11.7.2.1), and > > > several CAPWAP statistics related measurement elements: decryption > > > error report, WTP descriptor, WTP radio > > > information, WTP reboot statistics. > > > There is no statistics message.=20 > > >=20 > > > There is no requirement on how often the statistics related=20 > > > measurement elements must be reported > > > to the AC from the WTP, there is a Statistics timer, see=20 > > > 7.2.5, which is > > > used by the AC to indicate the > > > timer value to the WTP. (separate question - should the=20 > > > statistics timer > > > be made general, and indicate the > > > values for the other Section 12 CAPWAP timers too? =20 > Assume that the > > > CAPWAP statistics timer used > > > to determine how often to send the 802.11 specific statistics). > > >=20 > > > It is not clear that there is a high overhead in keeping the > > > echo/keep-alive mechanism from the statistics reporting.=20 > > There is some > >=20 > > > benefit in keeping the echo messages simple, > > > rather than complicating the processing of those messages. > > It is true > > > that small messages (echo request, response) have high=20 > overhead. In=20 > > > this case, the design choice is to accept the overhead as=20 > the cost=20 > > > of simplicity in design and implementation. > > >=20 > > > Recommended resolution: reject the comment, with the=20 > explanation in=20 > > > the above paragraph > > > On 4/28/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com> wrote: > > > I will summarize my thoughts here and not try to inject in=20 > > > the various=20 > > > threads, but I agree that the echo remains, does not include any > > > statistics, and MAY only be sent in the absence of any=20 > > > control packets. > > > I say MAY because an implementation could send them if it=20 > > wishes, but > > > the receiver must take into account control packets in > > > addition to the=20 > > > echo prior to declaring a link dead. > > >=20 > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit > > > Cisco Systems > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Scott G Kelly [mailto: scott@hyperthought.com] > > > > Sent: Friday, April 21, 2006 5:52 AM > > > > To: Saravanan Govindan > > > > Cc: capwap > > > > Subject: Re: [Capwap] Proposed Resolution to Issue 45 > > > > -Issueoncombiningmessages > > > > > > > > Hi Saravanan, > > > > > > > > Saravanan Govindan wrote: > > > > > Hi Scott, > > > > > > > > > > I think David's note does address the issue on hand. > > > > > > > > > > To formalize; > > > > >=20 > > > > > The exchange of control messages between a WTP and AC > > implicitly > > > > > indicates that the WTP is operational. For the purpose > > of protocol > >=20 > > > > > simplicity, I suggest that we focus on statistics messages > > > > alone for > > > > > this purpose, reason being that statistics are periodically > > > > exchanged. > > > > > > > > > > My concern is that by using "any" control message to indicate > > > > > keepalive (Echo), the AC processing will be=20 > > complicated. This is > > > > > because the AC will need to process each control message > > > > for both its own value (e.g. > > > > > Configure Request) and also keepalive value. > > > > > > > > Of course, complexity is a function of many factors,=20 > but there is=20 > > > > a straightforward way to implement an echo trigger with=20 > a flag and >=20 > > > > timer: when you receive a control message, unconditionally raise > > the flag. > > > > Periodically (according to your keepalive interval timer) > > > > check the flag; If it's up, put it down, else send a > > > > keepalive. There are more complicated ways to implement, but > > > > this works just fine. > > > > > > > > On the AC this can easily be implemented by having the fastpath=20 > > > > raise the flag, and having the cp lower it and/or do=20 > whatever it=20 > > > > is your AC does if a WTP doesn't report in a given echo=20 > interval=20 > > > > (which may be nothing). Pretty basic stuff. > > > > > > > > On the WTP, implementation is similar, except that if=20 > the flag is=20 > > > > down, you send the keepalive. Again, very simple > > and basic. > > > > > > > > > So I suggest keeping it simple - arrival of statistics > > > message from > > > > > WTP means WTP is alive. > > > > > > > > Certainly, a statistics message qualifies as a control=20 > message, so >=20 > > > > I have no issues with this statement when taken alone. I'm=20 > > > > concerned with the earlier suggestion that the echo req/reply=20 > > > > message be discarded and replaced by the statistics message. > > > > > > > > In some cases, the keepalive interval must be *very* > > brief in order > > > > to facilitate rapid link loss detection and recovery. I > > know of one > > > > vendor who routinely uses a one second interval, and it's > > > > conceivable that in some scenarios one might choose to use even=20 > > > > less. > > > > > > > > And keep in mind that WTP and AC requirements are typically > > > > asymmetric in this regard: the WTP needs to react quickly=20 > > (maybe try > >=20 > > > > to find another AC), whereas the AC simply needs to > > somehow report > > > > the event. While in some cases reporting might be > > considered urgent, > > > > this is not the typical (or average) case. > > > > > > > > The granularity requirements for reporting are typically much > > > > coarser than those of recovery. That is, the AC may, at=20 > > it's option, > >=20 > > > > only check every 10,20,30,... seconds for WTP liveness, > > and it may > > > > very well do that via the stats message, rather than the > > echo, since > >=20 > > > > this allows echo processing to remain wholly in the AC fastpath. > > > > > > > > But say we eliminate the echo: what happens when, say, > > 500 WTPs send > >=20 > > > > stats potentially every second or less? > > > > > > > > I think we still need the echo req/rsp. > > > > > > > > Scott > > > > > > > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > > > > > Sent: Wednesday, April 19, 2006 1:51 AM > > > > > To: capwap > > > > > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > > > > > -Issueoncombiningmessages > > > > > > > > > > Just trying to close the loop: I think David's point (i.e. > > > > that echoes > > > > > should only be sent in the absence of other control > > > > traffic) is dead > > > > > on, and that this effectively closes the question as to > > > > whether echoes > > > > > and stats should be combined in the same messages. > > > > > > > > > > Does anyone disagree? > > > > > > > > > > Scott > > > > > > > > > > > > > > >=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 > _________________________________________________________________ > > > > To unsubscribe or modify your subscription options,=20 > please visit:=20 > > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit:=20 > > > http://lists.frascone.com/mailman/listinfo/capwap > > >=20 > > > Archives: http://lists.frascone.com/pipermail/capwap > > > =20 > > >=20 > >=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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri May 05 13:34:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc4Bo-0005ta-3c for capwap-archive@lists.ietf.org; Fri, 05 May 2006 13:34:04 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc4Bl-0005MK-L6 for capwap-archive@lists.ietf.org; Fri, 05 May 2006 13:34:04 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D4BC24300F9 for ; Fri, 5 May 2006 10:34:00 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C34C84300C0 for ; Fri, 5 May 2006 10:33:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 68F104312AD for ; Fri, 5 May 2006 10:33:39 -0700 (PDT) Received: from test-iport-2.cisco.com (test-iport-2.cisco.com [171.71.176.105]) by hermes.tigertech.net (Postfix) with ESMTP id 84E9A4312BB for ; Fri, 5 May 2006 10:33:36 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-2.cisco.com with ESMTP; 05 May 2006 10:33:35 -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 k45HXWhI022560; Fri, 5 May 2006 10:33: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); Fri, 5 May 2006 10:33:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] to mux or not to mux? Date: Fri, 5 May 2006 10:33:35 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D82CAC@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] to mux or not to mux? Thread-Index: AcZwYy5zuAOcPB3VQA2cXqKM9n2LBwABnYtA From: "Pat Calhoun (pacalhou)" To: "Puneet" X-OriginalArrivalTime: 05 May 2006 17:33:35.0172 (UTC) FILETIME=[09500040:01C6706A] 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 X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b > I am not sure I understand: Does every control message also=20 > contain the BSSID? If not, then how is BSSID the binding=20 > between the control and data messages? With a single port=20 > approach all traffic on that=20 > is one bound channel. It is part of the CAPWAP header, but as requested it is optional. If the encap type is 802.11, then this is not required, because the BSSID is part of the 802.11 header. However, the MAC address field is useful for 802.3 data. So yes, it is present. > I thought the DSCP/ToS values in the IP header was the=20 > standard way to do QoS (and the 802.1p priorities), not based=20 > on UDP port numbers. > WiFi WMM tests for example dont map wired traffic to wireless=20 > access categories depending on what UDP port number that=20 > traffic came on, they use DSCP/802.1p. What we have done in the protocol is define a default set of values. While this happens in many protocols today, IT administrators still use ACLs to provide additional policy enforcement. > So the WAN router looks at the DSCP values of the packets,=20 > and provides better service to the CAPWAP control frames. In=20 > fact this should work without any configuration on a=20 > networking device that honors DSCP/ToS bits. With the UDP=20 > port QoS proposal every device between the AC and the WTP=20 > would have to be configured to understand that there are two=20 > port numbers here and one of them is of higher priority than=20 > the other. Except the values we've provided may conflict with existing values they use, so the administrator may want to *re-write* the DSCP/ToS bits based on the packet type. 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 May 05 13:57:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc4YI-0002AK-IA for capwap-archive@lists.ietf.org; Fri, 05 May 2006 13:57:18 -0400 Received: from g1-43.tigertech.net ([64.62.209.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc4YH-0006Iw-4w for capwap-archive@lists.ietf.org; Fri, 05 May 2006 13:57:18 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1C142430128 for ; Fri, 5 May 2006 10:57:14 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 80E0A430082 for ; Fri, 5 May 2006 10:56:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C122C1448009 for ; Fri, 5 May 2006 10:56:43 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by hermes.tigertech.net (Postfix) with ESMTP id 9AEE61448007 for ; Fri, 5 May 2006 10:56:40 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id g2so593076nfe for ; Fri, 05 May 2006 10:56:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HTJzjkDa6rT6wNldT9HzQHRzwtE8tMk/msPrzGkN/THejj4kr0m7D/pwK+RAY1i0vyLEW12FGbCl/xnudDl+8lBVTMGdjQ2KyBRAx7rr4kvzBw1gxc2c/+MwiPlpH3N/sSO2wg1G8UdaxdB4Haohjv9cZZoWhQLLIb0Lf2NfYzk= Received: by 10.48.235.15 with SMTP id i15mr770641nfh; Fri, 05 May 2006 10:56:28 -0700 (PDT) Received: by 10.49.90.6 with HTTP; Fri, 5 May 2006 10:56:28 -0700 (PDT) Message-ID: <1013407b0605051056i467b8502wc65242b1403eca8d@mail.gmail.com> Date: Fri, 5 May 2006 10:56:28 -0700 From: Puneet To: "Pat Calhoun (pacalhou)" Subject: Re: [Capwap] to mux or not to mux? In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201D82CAC@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4FF84B0BC277FF45AA27FE969DD956A201D82CAC@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=RCVD_BY_IP X-Spam-Level: Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 > > I am not sure I understand: Does every control message also > > contain the BSSID? If not, then how is BSSID the binding > > between the control and data messages? With a single port > > approach all traffic on that > > is one bound channel. > > It is part of the CAPWAP header, but as requested it is optional. If the > encap type is 802.11, then this is not required, because the BSSID is > part of the 802.11 header. However, the MAC address field is useful for > 802.3 data. So yes, it is present. but thats an optional field, unlike the binding that mux provides which will always be present. So strictly speaking, use of 2 ports *might* provide binding between the control and data channels depending on the implementation. A single port + mux always works. > > So the WAN router looks at the DSCP values of the packets, > > and provides better service to the CAPWAP control frames. In > > fact this should work without any configuration on a > > networking device that honors DSCP/ToS bits. With the UDP > > port QoS proposal every device between the AC and the WTP > > would have to be configured to understand that there are two > > port numbers here and one of them is of higher priority than > > the other. > > Except the values we've provided may conflict with existing values they > use, so the administrator may want to *re-write* the DSCP/ToS bits based > on the packet type. for that case how about making the DSCP mappings configurable? The AC can pick the value that is provided to it by the local configuration, and the AC can then provide these values to the WTP in the configuration message. The WTP can then start using these DSCP/ToS values for its control and data frames. This way the users can get whatever QoS values they want from the two devices that are actually doing the talking, without having to muck with ACL rules in the intermediate devices. Thanks, Puneet _________________________________________________________________ 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 May 05 14:15:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc4pT-0003rR-KU for capwap-archive@lists.ietf.org; Fri, 05 May 2006 14:15:03 -0400 Received: from g1-43.tigertech.net ([64.62.209.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc4pS-0006zj-7B for capwap-archive@lists.ietf.org; Fri, 05 May 2006 14:15:03 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BCEAA430103 for ; Fri, 5 May 2006 11:15:00 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 38C68430082 for ; Fri, 5 May 2006 11:14:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 64C291448003 for ; Fri, 5 May 2006 11:14:36 -0700 (PDT) Received: from stlssgcorpmailfw3.anheuser-busch.com (stlssgcorpmailfw3.anheuser-busch.com [151.145.63.133]) by hermes.tigertech.net (Postfix) with ESMTP id 347121448001 for ; Fri, 5 May 2006 11:14:30 -0700 (PDT) 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="--344510-7129147-1017340393=:3379" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] to mux or not to mux? Date: Fri, 5 May 2006 12:46:43 -0500 Message-ID: <89525CB1203D7346BBBDFCE9CECB47CF022A33A9@STLEXGUSR31.abc.corp.anheuser-busch.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] to mux or not to mux? Thread-Index: AcZwYM9qEo4aTGweRSmpdmdPznfxRwACoW4A From: "Kraus, Michael" To: "Puneet" X-OriginalArrivalTime: 05 May 2006 17:46:44.0128 (UTC) FILETIME=[DF912200:01C6706B] X-MessageInspectorSig: 361a72a4b85874cfaf752a396b3d6e3b 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c ----344510-7129147-1017340393=:3379 content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My oversight there=21=21 Is it needed to specify that data traffic =22SHOUL= D=22 be passed without setting the 802.1p/DSCP value? Or, is it safe to assume this= ? -----Original Message----- From: Puneet =5Bmailto:pb.ietf=40gmail.com=5D Sent: Friday, May 05, 2006 11:27 AM To: Kraus, Michael Cc: Scott G. Kelly; Pat Calhoun (pacalhou); dperkins=40dsperkins.com; capwap=40frascone.com Subject: Re: =5BCapwap=5D to mux or not to mux? > However, I have not seen any mention that if we are going to pursue > using a mux header that this would be incorporated into the changes. > If this was to be done, it would really make sense for the CAPWAP WG > to make CoS/DSCP recommendations for these values. Vendor > interoperability is somewhat hampered from a usability perspective if > you need to do different DSCP mutations based upon which vendor WTP/AC you= are using. I thought the draft did make CoS DSCP recommendations for the control channe= l. >From Section 4.3.3. Quality of Service. 802.1P: The precedence value of 7 SHOULD be used. DSCP: The DSCP tag value of 46 SHOULD be used. so if we use the MUX header, and also specify these DSCP/802.1P values, then= is there still any QoS related benefit in breaking up the control and data chan= nels into two different ports? Thanks, Puneet ----344510-7129147-1017340393=:3379 Content-Type: text/plain Content-Disposition: inline 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. ----344510-7129147-1017340393=:3379 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 ----344510-7129147-1017340393=:3379-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri May 05 14:19:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc4tt-00070F-T5 for capwap-archive@lists.ietf.org; Fri, 05 May 2006 14:19: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 1Fc3MK-0003Lh-Mn for capwap-archive@lists.ietf.org; Fri, 05 May 2006 12:40:52 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fc39k-0004tj-LL for capwap-archive@lists.ietf.org; Fri, 05 May 2006 12:27:55 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DDE63430118 for ; Fri, 5 May 2006 09:27:51 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 5D793430082 for ; Fri, 5 May 2006 09:27:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 401644311E6 for ; Fri, 5 May 2006 09:27:32 -0700 (PDT) X-Greylist-Status: Sender first seen 20 days 16:26:27 ago Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by hermes.tigertech.net (Postfix) with ESMTP id 4B1994311C9 for ; Fri, 5 May 2006 09:27:29 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id g2so578059nfe for ; Fri, 05 May 2006 09:27:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GiNzMM336Tl76K6eEM1W3eCHhp6IG8c4RPIqlrCUFNihXPdqUZRrZ2dMFrAKiVvpriYoJnBAEUg5weaIGITPsvzYmWHcsOu0+dyrVOvJa0n566g4VEnU2DRhTftvHGCfYWVEYwGO840M1NOCGOfLpn5tyrjirj6CA14bnJvIZf4= Received: by 10.49.34.2 with SMTP id m2mr70564nfj; Fri, 05 May 2006 09:27:26 -0700 (PDT) Received: by 10.49.90.6 with HTTP; Fri, 5 May 2006 09:27:26 -0700 (PDT) Message-ID: <1013407b0605050927m3665ceffnbf7522ce3e00ad06@mail.gmail.com> Date: Fri, 5 May 2006 09:27:26 -0700 From: Puneet To: "Kraus, Michael" Subject: Re: [Capwap] to mux or not to mux? In-Reply-To: <89525CB1203D7346BBBDFCE9CECB47CF022A3122@STLEXGUSR31.abc.corp.anheuser-busch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <89525CB1203D7346BBBDFCE9CECB47CF022A3122@STLEXGUSR31.abc.corp.anheuser-busch.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.0 tagged_above=-999.0 required=7.0 tests=RCVD_BY_IP, RCVD_IN_BL_SPAMCOP_NET X-Spam-Level: *** Cc: capwap@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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: -1.3 (-) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d > However, I have not seen any mention that if we are going to pursue using= a mux > header that this would be incorporated into the changes. If this was to = be > done, it would really make sense for the CAPWAP WG to make CoS/DSCP > recommendations for these values. Vendor interoperability is somewhat ha= mpered > from a usability perspective if you need to do different DSCP mutations b= ased > upon which vendor WTP/AC you are using. I thought the draft did make CoS DSCP recommendations for the control channel. From Section 4.3.3. Quality of Service. 802.1P: The precedence value of 7 SHOULD be used. DSCP: The DSCP tag value of 46 SHOULD be used. so if we use the MUX header, and also specify these DSCP/802.1P values, then is there still any QoS related benefit in breaking up the control and data channels into two different ports? Thanks, Puneet _________________________________________________________________ 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 May 05 15:22:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc5sj-0003Tv-90 for capwap-archive@lists.ietf.org; Fri, 05 May 2006 15:22: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 1Fc5jx-0001UX-6Y for capwap-archive@lists.ietf.org; Fri, 05 May 2006 15:13:25 -0400 Received: from g1-43.tigertech.net ([64.62.209.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fc5YJ-00062T-Vj for capwap-archive@lists.ietf.org; Fri, 05 May 2006 15:01:25 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A9BCE4300F2 for ; Fri, 5 May 2006 12:01:22 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id AA657430082 for ; Fri, 5 May 2006 12:01:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 657EE144800D for ; Fri, 5 May 2006 12:01:00 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.199]) by hermes.tigertech.net (Postfix) with ESMTP id A2C5A1448009 for ; Fri, 5 May 2006 12:00:55 -0700 (PDT) Received: by nz-out-0102.google.com with SMTP id 14so739424nzn for ; Fri, 05 May 2006 12:00:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JgADOgxPQiUB2a0IVXJb+KDARU84i3x93ZZ7Pxas2zuY5ha5mOROjMrrBZHQrfW2muHQBaJpsEFwcP0mo/85pzTI334SiFQBn+gTc0HsGUBdJoq4iejG7WojL5OJWtbUDKKq7JYwzLsU4d1UEQ0RCIzcHNU8OSoparx4u91IedU= Received: by 10.36.129.10 with SMTP id b10mr1510144nzd; Fri, 05 May 2006 12:00:54 -0700 (PDT) Received: by 10.36.132.2 with HTTP; Fri, 5 May 2006 12:00:54 -0700 (PDT) Message-ID: Date: Fri, 5 May 2006 12:00:54 -0700 From: "Clint Chaplin" To: "Puneet Agarwal" Subject: Re: [Capwap] Issue 53: Add Data Rate to LWAPP Header In-Reply-To: <8954613CA6BB3242A1531D916A527A41BDAE55@NT-SJCA-0751.brcm.ad.broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <8954613CA6BB3242A1531D916A527A41BDAE55@NT-SJCA-0751.brcm.ad.broadcom.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=RCVD_BY_IP X-Spam-Level: Cc: capwap , Abhijit Choudhury X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.5 (--) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 3 bits won't be enough. 802.15 slrrp (or something like that) wi-bro and so forth. On 5/5/06, Puneet Agarwal wrote: > Hi Pat, > > One suggestion: The "payload type" should be an encoded value. If one > assumes that it is 3 bits for now, one could have the following encoded > with enough reserved encoding available for future technologies. > > 0b000: 802.3 payload > 0b001: 802.11 payload > 0b010: 802.16 payload > 0b011 - 0b111: Reserved > > Thanks. > > -Puneet > > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Friday, May 05, 2006 7:06 AM > To: Jim Murphy > Cc: capwap; Abhijit Choudhury > Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header > > Ok, good question. How would we specify 802.11, 802.16 and 802.3? I hope > we are not proposing a new bit for every wireless encapsulation type, > right? > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Jim Murphy [mailto:jmurphy@trapezenetworks.com] > > Sent: Thursday, May 04, 2006 6:42 PM > > To: Pat Calhoun (pacalhou) > > Cc: Abhijit Choudhury; capwap > > Subject: Re: [Capwap] Issue 53: Add Data Rate to LWAPP Header > > > > If the WTP supported both 802.11 and 802.16. 802.16 encapsulates 802.3 > > > frames. > > > > Thanks, > > > > Jim > > > > Pat Calhoun (pacalhou) wrote: > > > But do you believe that WTPs would send both simultaneously? > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > >> -----Original Message----- > > >> From: Abhijit Choudhury [mailto:Abhijit@sinett.com] > > >> Sent: Thursday, May 04, 2006 4:34 PM > > >> To: Pat Calhoun (pacalhou); Jim Murphy > > >> Cc: capwap > > >> Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header > > >> > > >> Pat, > > >> I agree with Jim. It's easier if the packet header conveys this > > >> information, i.e., what kind of payload it is carrying. > > >> > > >> On a related note, shouldn't RadioId be part of the Wireless > > >> Specific Information field ? > > >> > > >> Thanks, > > >> Abhijit > > >> > > >> > > > _________________________________________________________________ > 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 > -- Clint (JOATMON) Chaplin Wireless Security Technologist Wireless Standards Manager _________________________________________________________________ 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 May 05 15:50:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc6Ju-0006ff-9U for capwap-archive@lists.ietf.org; Fri, 05 May 2006 15:50:34 -0400 Received: from g1-43.tigertech.net ([64.62.209.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc6Js-0002fu-Pg for capwap-archive@lists.ietf.org; Fri, 05 May 2006 15:50:34 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 42B33430105 for ; Fri, 5 May 2006 12:50:32 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id AB894430082 for ; Fri, 5 May 2006 12:50:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7FCE3398016 for ; Fri, 5 May 2006 12:50:05 -0700 (PDT) Received: from cypress.neustar.com (cypress.neustar.com [209.173.57.84]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8CEEA398017 for ; Fri, 5 May 2006 12:50:02 -0700 (PDT) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k45Jo10e026716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fc6JN-0008Nr-B3; Fri, 05 May 2006 15:50:01 -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: Fri, 05 May 2006 15:50:01 -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-01.txt X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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: 9a2be21919e71dc6faef12b370c4ecf5 --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-01.txt Pages : 141 Date : 2006-5-5 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 and radio management from the single access point to a centralized controller. 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-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-capwap-protocol-specification-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-capwap-protocol-specification-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-5124851.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-capwap-protocol-specification-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-capwap-protocol-specification-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-5124851.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 anuo@bcma.bc.ca Fri May 05 18:35:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc8tE-0007DR-7u for capwap-archive@ietf.org; Fri, 05 May 2006 18:35:12 -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 1Fc8tD-0005eE-Va for capwap-archive@ietf.org; Fri, 05 May 2006 18:35:12 -0400 Received: from 48-131-235-201.fibertel.com.ar ([201.235.131.48] helo=bcma.bc.ca) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Fc8sz-0000Vz-PP for capwap-archive@ietf.org; Fri, 05 May 2006 18:35:11 -0400 Message-ID: <000001c67093$ed7d40b0$5550a8c0@oyx65> Reply-To: "Anu Gonyea" From: "Anu Gonyea" To: capwap-archive@ietf.org Subject: Re: good cxredit Date: Fri, 5 May 2006 15:33:27 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C67059.411E68B0" 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.2 (+++) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C67059.411E68B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0002_01C67059.411E68B0" ------=_NextPart_001_0002_01C67059.411E68B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable our www site =20 =20 =20 =20 =20 at least that he could feel quite certain that the dwarves now were absolutely honest when they declared that they had never thought at all about what would happen after the treasure had been won. We knew it would be a desperate venture, said Thorin, and we know that still; and I still think that when we have won it will be time enough to think what to do about it. As for your share, Mr. Baggins, I assure you we are more than grateful and you shall choose you own fourteenth, as soon as we have anything to divide, am sorry if you are worried about transport, and I admit the difficulties are great-the lands have not become less wild with the passing of time, rather the reverse-but we will do whatever we can for you, and take our share of the cost when the time comes. Believe me or not as you like! From that the talk turned to the great hoard itself and to the things that Thorin and Balin remembered. They wondered if they were still lying there.unharmed in the hall below: the spears that were made for the armies of the great King Bladorthin (long since dead), each had a ------=_NextPart_001_0002_01C67059.411E68B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
 
 
 
at least that he could feeldie. I think I would rather be smashed by Smaug = in
the open than suffocate in here!
So several of the dwarves got up and groped back to where the = door
had been. But they found that the upper end of the tunnel had been
shattered and blocked with broken rock. Neither key nor the magic it = had
once obeyed would ever open that door again.
We are trapped! they groaned. This is the end. We shall die here.
But somehow, just when the dwarves were most despairing, Bilbo felt = a
strange lightening of the heart, as if a heavy weight had gone from
under his waistcoat.
Come, come! he said. While theres life theres hope! as my
father used to say, and =80=98Third time pays for all. I am going down = the
tunnel once again. I have been that way twice, when I knew there was = a
------=_NextPart_001_0002_01C67059.55BF52C0-- ------=_NextPart_000_0001_01C67059.55BF52C0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <000101c67094$01bee18f$a36da8c0@bxg77> R0lGODdhHQFFAcIAAAAAAAAAAP///wAA//8AAKeRmQAAAAAAACwAAAAAHQFFAQAD/ii63P4wviKr vTjrzbtX1CeOUkieaKqubOu+cCzPdG2Zdi7ieg+qPJ9wSCwaX8GjspJcNpfQ0zNKmlKvHZMVy+16 UVuPNfwFl8/oNFDNZpDbFy38/FbXI/dVnrWfO959foKDgXhphTcCiEM4coN0jygBk5QBLpYOmDWV kZ0TL5oLoSmjCqWgoaeeqyunmIuiD6otpbOJDbCsGLkaqpqUDZW/ApOZsgzAscnJosUQrpapyMTE zsjW1NgpvFlmRL6msaa/mNriwefk48Ph4UGW79Tryuzt8tVRhdxHAUnR6PfazRLGKaA8aaIojHL1 DF82UwpNsAtRbsY+N2LQgFuY/snZwGMGK547CLCkInEVRSIMaa/FRV0WNhJsVkwkSID9pgVESJAh yGhASaabaRCmn40NdY6S+BOnToEXoIUbZvMeOKOPfHJkWXQkSqcUlZp8OpRc1XpQsc6hUKDWU3WK PEbwaXXkSrTGmundu/OtV7U5cvXsuBBY1bEQaZJdWc3Wupxk63plVtQxYA0vf1xukjlpjM52PtsA HUMVaVanOZBOfXn0n9YnYX9gPYJ2HNkLbKveTeSJ7gy/fQT3hrvLHkCoiytfjgTw8N7dmMN8Lj2j ZhjDqfN2Dv169e/EwYsfP528eVwutPtRzwdzmymIOh93+YnJefv3YbPfbjF//nT/AP4HQQj7BUif geHlVqARBQaxIIIQRuidF3RtQEYhNlnWEigbnoAXBxqKEOIQW2HhVlQzHObhXxuMaMhcFMI1oREn xlQfKR2S8GGLpZXAz1+U3eUQYfQoFkxbQhVEZCrmUNYYVdgA1WRj8zTTVjmDnRTkkI8ZedNOW37x T0n1IDkOjAIJOVRcLNpjDVr18PShL1iy82aGZPJl0kR72tVmFGNO1tKOOTIm1Fc5crXVol/W2Cei kBqqYjqI9ZWoi9/khahCf1bIqFiXOqUUDuXEA6RnAbF1DZ6CduVmpXdV6BqPY53VaaNEvZKWq5+i RNSTflZqqZuGvUpTQR9t/ujpqoZy4eih9zyx7JeHXgUpVFbYKixjh7EaqmclxtassQm2oumu0aL5 6LXVxhZZt8o2ldC2i8Vr5rDo5hnZoOCidwVdccLjqrElxkqupm8GK1lanNIb7J0HL5xsxGvym5sT 6gajTbGJdtkhJTxwbNYzNa1KJLMKazmlwpzUSaWXAzPjpMaBAvunhPoJ0eBrNTzYX3pYIEeDzzjf 0t4XRBet9C4CMu3v0lB3Z/R6USd3cdUR6tPcgFjfl3RruTwI2tdYhU1FamR7TZ7P8XXdg3ZpYyxb 3G67JyHdRwMXtBRl81f321XPVxzef+tCeOFXOIj4Gt8dvngV5QFNiHCP/gOeAZPWvYjyvieurMJS IKJoA6ahU0Ho1R5ySzNOz66o97kZp9ij6Tebu+5DlIaLkQekw8716LMD6nGrVVoMK5zD1kxNyEM6 KczNQU5CkcycXHlnKCErKWX2yqv+pMBSHnsg7ywWTGn5/cYVFMH7chnwXhNri/mZyZMMP/L0l1Uk /QnP+GOHDVsYunTVpjidT2KNEhW7BDWtSMFKgQIMSUrOxJF7RVAJhDIgqAqFKlapqSuSOpm1ptK6 KuHFMcvwC+em8jG5HHAHLMjgC6GlCYn4Yxoc8R5Dpve8Lk3qex6RGc3GBL5fDZGGxLtYTQLVMuON qA6IOF3NegVCWUiD/oBTREcDa/Ut1F2rVxqi4gmNQZV41Y92HcviD7Tlu8K48V1VbBUV4QhBMD5w gxF8x/Xs9cEb1aZ0MdvYAc1hl8JYkXOyeh8IfigZnlwDfirsCCRZVgvMKQQufYyNdgh1yZMpBnTi o5Y9AqgnIG1MZBKI3h59WLyZoYyN67Ag8axHxLcQsgwELBfYKmehufSub8aB2i3L0LbMDQ1ykODl 1JKpTMY1UxdSTONjepglUi6mJ3UyIo5sNCsM2KKSZBSl5GjFJfj5g5GVKR8hS4gfQKbSWb40JAQH 9j/cGal7LkTVtcJSAFO17xKi+xeMcsi6UvpRB2VEhpm6By3fsTCc/m3ETJSU9KSwuNJmLyNZwihz ySs2qWQNIWgkfcEUX6VwX3lIqDIeulJ6CkyLCIuoN301yTQVMJKP6h+5dGoVa0nDgldUlxAhpjvy 7aoiC0UUNm9ao9aBjKLow2PKdseVO7KLjUXVDFDPx6mBTBAfdnRdu5Kk1Hceo6ky5eaAluEonx4P dvA6402dmER3QUVFJ6VnL3LnQDuZFaLHcp5DxQkss+Avpv/UHuuoiVMQ/sqR/ywSSAtLMaPei4mv 8mvsWlpXt2whkfLqYlbn+cNM7nCG0SBVBTAbV3vqSH9H7R8oAdhaM0bWqhzEV2MtE1cxnsOathVp 7ajXWuXxLKA6/hSXVBFz2HoJ60ZYqikSE9jFgxy2uTKKKjhv6z4ZrVKsyX3YUoHovdtNE6rDo+zw xpXRi64XvWFS1mTLB1xBrnZPHMuf3drpN2f+DIbbrM4vGUTgRCguBwP+IwYT/Ey+daw1w9RcaLgT mP9Sjgbgqx3wXiuJv3o4oBptVi06mqtqHlSgg4UDgy8H4hY/ErX2/WaKzyCrChuTuwG2K47dMLEX qjFVuJVBuIQ4VwGSKsKrI6EVdRq+9ma0oUPeoGIvqr1hjlC6P5bxjGOoL2g1QYOIXW1Yyvmw+9lJ g7obWVrkVOQLVlcsnWTyhx9MC9TqdpDUqmGeY3aT8DqwhQ91/uEWd0vYq4DZsIp9Loci9uMuw1Kv wpVkly0V1jjW0qbmfWFb/OmwsbL3vCvuAJhZKg/mZZZJPYydcTcnQMj+uYpLlBgwSOnWknY6T5HW Mpk3AWQcJrZip9PnqkPr5wHyqi47erSdBysVUrtW17vWJWdLTWpQHrqucNXrqyldR159VytUnXQc RYnqJG9ItS9GsH2r5Va60pl9HTwYm+V9y4niUdnunvH89KsnaAMwRZXUVX4dTaZ1d8TWS9az8awb X37TkVg8pRP47sW9Shx5nXkeb41lt4RQi/W+/p0Nf4uDZGSyWAafjYrHoXaHki/npfZr8OKS4LhI 1NzGMr+w/o7zhsFfIy0pYVg5dR3K6cShOEeynPBMl3nyd4M8cnVus2i43PSoO33OPhhyxPeHwyC+ kR6GJWFQ29fkwJqxyc6L0suqjHEiFxC+KYzv+qgk9OOqdadOpFMrBzlqOWeVyepY1CvkTKwvIvKq h3T4vhVZ+HqOMZPOzRdWI+8tLirKx1KVX/sQThLg2jZlfVf0fj8w6mffqsz39tOYx5rtJId+Xr4F 04crr9FzfTCEjmdgYyMP5XyfUYa2BKkBV89w61nMjaB1MyvRnW/c/yiEd/myc/U8eZZN2/LmK29D UU9uXKv6XMxvrraBB/3dg/7sOBVSV79f1Ua7mk19SXos/pifWfbz/vUaHt26MxRN6wewj7dnZYz3 XfhybYZnSnYhf/njOXJVMAP2Eh9Vbv23cA2nZgDoVWk3X2oHehuYJmFHRh8VbuplMg14NQNHIwp2 dIT1dBSSH0h2cw63YxpzYwC2WnUXCS53G1CAZJiSg0Xgg16kBzl3YkMoN4dQhDlHOsPxae60V0j4 cQf1HExITlT4hKS3c2h0dS62dOYxVG7BVl/XVeVmIxnYdSSYcFByhptTdjCzJGr4PYUEhBexSTSV eG7HeJU1g+1wWaWUbJhkPrZ3XeByaJg0VbABGc52f+j3cPF2eYy4iPN3Kta3QplnRpynBItQB1jE Z9wn/nmi9369d1t59XkUiG1zVEmrVwyqohyRphnFBmXaZFdywljM4kpNJEGpFiz/F4uCl2q3KHDu 9TTjQ4Qd5muN6IqkRYWlJXqOqGHlxVvzJEf6BAUEYndGdX2K2IykaHuQuI1bYWqS6HvpVInaKIM6 AwOaNXQI9DHOOFLhCA3Tw465VYotYWuE1zyVd4M0aI2SwFO3M4aFYnAcOC7MUHHb92QkKCkRNnAZ eGnpJYIotzU89zlWGCCdoY81KIxRox4wWB220U8QyUsdaRQjiYXM6DTx9FSpcCWEgV7bOH5FUJIt iGCSRHwGkXSCZY6B0zSLtmGUOI/OJj0xqDYqGCsy/oF8tRWML+mPfoJW07gKaMNxVNIwflgxYIWI pYcLowV8FzRsE7k00vJV81UZ9qhAY2R/4oY6c+IqMql0V4g7tbVw97RswpY+YbZxhgMYQSF8vHhN kzVFsfiIM2RS8AUebWlPDpkxZ2l6t/F3wFdUGIlzArZKkDkN1mQWnFcKl9hWfcZcOymR3oSVkCeL fNGBMwSO17RCnjdajJAfQVcr1kB/qFYz58RbtRlwFJV8mwUHC3KYIYcGvOCb58h0JlmRayNho0eM vzM3uCGcxnk2zwl1/mM50UmNGiltP9ea57Ez2wCWwGmEQViE8NFNznkE5Wmd1SmdBnKe6WlygjCe /u2pnfGZkbxJnfMZnkd4nzn3G/DJnr2UNUrDkTzJj+jJcuJJoOqpgwi6oFP3lf2lnw/6OkbjnzYn n1KzkSg4n75RNS75deLCgxHoSTn2DQuJDbREgNjDTPS5UqeUfqcnV8r3lsspOUE0iFF1KBRKK7Zy ln+XjFUFhVm3Y8kGKTnqhCMWQXHZjaE4RLPZQVunTiATSiyoJU+JbHVnNkIwlqznibBjk0kKMXe2 jmpWGYU4Enp0VhMVJBbloDonavsnKLKUfKfYetDIEnIRXdgXmnrXeGAyd/cxiinKP0HWW4rGViBX QWJpg3jKhYKZW0o5nEGak580SuPGpY75l1SG/n6xJnFM9KjyWEDxEGyGMwXZlIvkyGPuQqg/CZSI h5iV+qrTuJV5Iao5s31wkqTl+KVBZqkEiG2v+iy6GqMk51qTWFn/p0lmqk5Y1pl8Gm1gSpBc6V2I pYD5MKCKKmwh+i7Z+oY8hqn19oaseYsY1ZL4FXC4Epk6wAsYia7ueZ0haTsR2TX0Z3QpOKJuEwhY WmAQ2pPTWZ2raK0VGhOqxKQAWXvm1oZA2p29UKLmqoYrVo1ZkQ3rY2WDiXniyGEkOpSCCG/9Khsq EaZIegwlNaf2amFhSrLpWKA9wEiBGrJ06qNMymrlen5amZueKqdmGW27JEl7+ig2qaRfWqbz/piO blea+JZudGRH7Aqd+Fk8CCuXOHuq0ghyzHOniheNBvuywaez4GGL6hhHY0ayBiuUaPIpiblkQ1ml QuuoQAhhu8aZZOejl9qp33p5mxpiPZWDErekaySsrMiq2LOJWtuqjQpuYqFShbuFMLtttQoqDPWI suKl7hCOrLorVHknNxS3WumZ0jWOtHqIcLmWaWmxMKoyy3qX/daz+eRYRQZ5WXljMKhKGyepTlu7 CPlKUjqzjcpKDymzfSqicXgep7AIS9uu9RSvGKqTTWuyx3SSCttgh1mk5sGf8vodxYuJfZCj0pu7 k7GtWYuwnlqFKFkCmsiwHuq015sG/9Ci/qQbP7mxsSWLUItacHiWL11rbJm5lHILELCQvh4WtX/G YMFBGkglZYs7tYRbi77rRUW7ki3ZpHdXtjnbtpehpbSHqyjLXGsLMFSatwgoqMMVRpAIc8GkbgUj uT+KwFyatNyUQ2IJrIkhsCIcXLFmnqazugazPDdqqYVao2ZltgeZkC5SpynsgR0rmZEqkKikua06 t5eVqcSAbns5bOLqkqKEcD36ufq6vCNQqlaMwfu7qrAaiqwlC/PqdD1WxLTHHB87aav7q0DbenfU i0/bo3KMjJZnwFTTYasGgC/qxwF5ugSnX/W2wYl3bMzqjltMIuZwmd4bp95ru+LzgcbA/kN5TK6U TK5KYURe+7TDuI/JiXVP8wb+ix00ua9TCpqDUMpGuL2ozAqsTJLMO73TabNpOrCpZKK3G77AEcvf C7yPZZrEqaAjl6USy6cknIetVqwP6st6uE7zm7lBLB0fC4iXrMJ8i7ERKmpMfLILVJ/FqGVX5hNh C0Hyl4tffIbaZ3bcW6XmZ6X1ioNeyXDCDMCJAZlluprnM6bb5RBTCKIJQbb196cUu4C+msFizEjl bIahO7jXGk/pJoHO/BL70Mlqqb/kyJprh0KLeLYiNMQRjFIu04XlJM6DGseY3M48fLcJl7chMrw6 gZqcNdEo9s8Y3cScu8M4jbgHrbg+/qfHw9wJbTyOrYpuC53AN53RvZrUpnjAWypgrippwyItLFOW Uu0MZ7yO3RVz/myZesi6yIy640FctgzMGqNHDdvSmeyX14y7vcu9a327v2s11wivDGrKM3mvzevM R5Gur/zX7uHKobzNgE0cfF3YbHBgtny+ksytM8PLVUeiGEhcLIm+wnvMPdW+QtW3F9vF4xtD8/vT KnTYKLam74vStXKZLymjJCLaTIxOL/dg8CC2LCy17PzWc12AaLjARfdmuUPaNqwXJm3bKI3PgqzI /HzVR2tQcHjbyAap/1LQubpnuSrTsN17Vktmc/RlhWyVEu0F1GHRtI3NuSTbPizB/o47zSYE0iHN tsBNzEJW0rWt06oKpXRraE6xqbfp0ow6jZxStfnnsVCrQPqc0Tldub2HJDzN1O4sdayXGfuQB6/5 1NNtjfX9qQjeW6Kpm8p1x6j9Z3CDgoEifZ0tb8UqEWsrzb8Qj8yNj3Jp0FddmmJN2HNA1rgMrgdr u+4lPfftpGmWkvyNt1gcyYNCwfkpvj6CHy4SN6zx3kvj5JAA5YjdvEkuy+PBGoINznsT1DQesFM+ Tn7t5fCtsnuM14n9yV/enMhL167cCAl6oe85OWIeoGqe5nVu53ie5wDrr3reM2eu5Y/DGdBdvSXc 5WO+5fZp5QAykmMz2EOY5bOcqbwxyabPe+dEqdeV/kzZ0efK+ehrkekrWuaTLnKcXuqmnuinHupQ SWHI2aCL7ulVnuqaPqOy3jjSkeWQ3gn5Wq3eaZwwmOvfCcqvnInZGeaYyOcWWet/XjeCc+zKvp9z vp3BzenAPujL/unF3Ol2fiGAXe36Sewqmu2t/uyGPupc4O1cg+67pL0TApIGGuv0Gu6OTu58M4fv SubGzsX03usZyR60IR9qkQAAOw== ------=_NextPart_000_0001_01C67059.55BF52C0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri May 05 21:38:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcBkW-0000aF-GT for capwap-archive@lists.ietf.org; Fri, 05 May 2006 21:38:24 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcBkV-000571-2T for capwap-archive@lists.ietf.org; Fri, 05 May 2006 21:38:24 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2FBE5430102 for ; Fri, 5 May 2006 18:38:18 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id AABF943006D for ; Fri, 5 May 2006 18:37:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9E236398016 for ; Fri, 5 May 2006 18:37:52 -0700 (PDT) Received: from trpz.com (mail1.trpz.com [66.7.225.38]) by zoidberg.tigertech.net (Postfix) with ESMTP id E6360398013 for ; Fri, 5 May 2006 18:37:49 -0700 (PDT) Received: from exch2.trpz.com (exch2.trpz.com [172.21.8.8]) by trpz.com (8.13.5/8.11.6) with ESMTP id k460ZHg8029666; Fri, 5 May 2006 17:35:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header Date: Fri, 5 May 2006 18:37:47 -0700 Message-ID: <3A82378045B7B34494897B0907E06E3B03D3F8@exch2.trpz.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 53: Add Data Rate to LWAPP Header Thread-Index: AcZwdj5mRrr2U+6DS2G2ZLqmhPFX0AAN14HM References: <8954613CA6BB3242A1531D916A527A41BDAE55@NT-SJCA-0751.brcm.ad.broadcom.com> From: "Jim Murphy" To: "Clint Chaplin" , "Puneet Agarwal" 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 , Abhijit Choudhury X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 I suggest 8 bits and let IANA dole them out. -----Original Message----- From: Clint Chaplin [mailto:clint.chaplin@gmail.com] Sent: Fri 5/5/2006 12:00 PM To: Puneet Agarwal Cc: Pat Calhoun (pacalhou); Jim Murphy; capwap; Abhijit Choudhury Subject: Re: [Capwap] Issue 53: Add Data Rate to LWAPP Header 3 bits won't be enough. 802.15 slrrp (or something like that) wi-bro and so forth. On 5/5/06, Puneet Agarwal wrote: > Hi Pat, > > One suggestion: The "payload type" should be an encoded value. If one > assumes that it is 3 bits for now, one could have the following = encoded > with enough reserved encoding available for future technologies. > > 0b000: 802.3 payload > 0b001: 802.11 payload > 0b010: 802.16 payload > 0b011 - 0b111: Reserved > > Thanks. > > -Puneet > > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Friday, May 05, 2006 7:06 AM > To: Jim Murphy > Cc: capwap; Abhijit Choudhury > Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header > > Ok, good question. How would we specify 802.11, 802.16 and 802.3? I = hope > we are not proposing a new bit for every wireless encapsulation type, > right? > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Jim Murphy [mailto:jmurphy@trapezenetworks.com] > > Sent: Thursday, May 04, 2006 6:42 PM > > To: Pat Calhoun (pacalhou) > > Cc: Abhijit Choudhury; capwap > > Subject: Re: [Capwap] Issue 53: Add Data Rate to LWAPP Header > > > > If the WTP supported both 802.11 and 802.16. 802.16 encapsulates = 802.3 > > > frames. > > > > Thanks, > > > > Jim > > > > Pat Calhoun (pacalhou) wrote: > > > But do you believe that WTPs would send both simultaneously? > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > >> -----Original Message----- > > >> From: Abhijit Choudhury [mailto:Abhijit@sinett.com] > > >> Sent: Thursday, May 04, 2006 4:34 PM > > >> To: Pat Calhoun (pacalhou); Jim Murphy > > >> Cc: capwap > > >> Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header > > >> > > >> Pat, > > >> I agree with Jim. It's easier if the packet header conveys this > > >> information, i.e., what kind of payload it is carrying. > > >> > > >> On a related note, shouldn't RadioId be part of the Wireless > > >> Specific Information field ? > > >> > > >> Thanks, > > >> Abhijit > > >> > > >> > > > _________________________________________________________________ > 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 > -- Clint (JOATMON) Chaplin Wireless Security Technologist Wireless Standards Manager _________________________________________________________________ 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 May 05 21:57:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcC3S-0005zB-TN for capwap-archive@lists.ietf.org; Fri, 05 May 2006 21:57:58 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcC3Q-0005pc-GQ for capwap-archive@lists.ietf.org; Fri, 05 May 2006 21:57:58 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2E7B64300DA for ; Fri, 5 May 2006 18:57:56 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 96AD143009F for ; Fri, 5 May 2006 18:57:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 885D8398013 for ; Fri, 5 May 2006 18:57:37 -0700 (PDT) Received: from trpz.com (mail1.trpz.com [66.7.225.38]) by zoidberg.tigertech.net (Postfix) with ESMTP id E2ACA398016 for ; Fri, 5 May 2006 18:57:34 -0700 (PDT) Received: from exch2.trpz.com (exch2.trpz.com [172.21.8.8]) by trpz.com (8.13.5/8.11.6) with ESMTP id k460t3aV029911; Fri, 5 May 2006 17:55:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header Date: Fri, 5 May 2006 18:57:34 -0700 Message-ID: <3A82378045B7B34494897B0907E06E3B03D3FA@exch2.trpz.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 53: Add Data Rate to LWAPP Header Thread-Index: AcZv5RRNZA5B3IICTIOsPasrxj5rmwAZ8Z8wABh8yz0= References: <4FF84B0BC277FF45AA27FE969DD956A201D82B6A@xmb-sjc-235.amer.cisco.com> From: "Jim Murphy" To: "Pat Calhoun (pacalhou)" 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 , Abhijit Choudhury X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 I see no need to specify two or more payload types simultaneously. A single data packet would only be of one type. Perhaps you are thinking of some issue with control plane packets that might apply to multiple protocols? I don't know what such packets would be. However, this discussion does suggest a possible need to have different headers for data versus control. Many of my comments have been focused at trying to optimize and generalize the data (forwarding) plane. Some these modifications may not be appropriate in the control plane. Thanks, Jim -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Fri 5/5/2006 7:05 AM To: Jim Murphy Cc: Abhijit Choudhury; capwap Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header Ok, good question. How would we specify 802.11, 802.16 and 802.3? I hope we are not proposing a new bit for every wireless encapsulation type, right? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Jim Murphy [mailto:jmurphy@trapezenetworks.com]=20 > Sent: Thursday, May 04, 2006 6:42 PM > To: Pat Calhoun (pacalhou) > Cc: Abhijit Choudhury; capwap > Subject: Re: [Capwap] Issue 53: Add Data Rate to LWAPP Header >=20 > If the WTP supported both 802.11 and 802.16. 802.16=20 > encapsulates 802.3 frames. >=20 > Thanks, >=20 > Jim >=20 > Pat Calhoun (pacalhou) wrote: > > But do you believe that WTPs would send both simultaneously? > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > >=20 > > =20 > >=20 > >> -----Original Message----- > >> From: Abhijit Choudhury [mailto:Abhijit@sinett.com] > >> Sent: Thursday, May 04, 2006 4:34 PM > >> To: Pat Calhoun (pacalhou); Jim Murphy > >> Cc: capwap > >> Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header > >> > >> Pat, > >> I agree with Jim. It's easier if the packet header conveys this=20 > >> information, i.e., what kind of payload it is carrying. > >> > >> On a related note, shouldn't RadioId be part of the Wireless=20 > >> Specific Information field ? > >> > >> Thanks, > >> Abhijit > >> > >> >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From hippolyo@co.shawnee.ks.us Sun May 07 10:14:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fck1m-0002fu-2r for capwap-archive@ietf.org; Sun, 07 May 2006 10:14:30 -0400 Received: from p3123-ipad03wakayama.wakayama.ocn.ne.jp ([219.162.174.123] helo=co.shawnee.ks.us) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fck1k-0003kc-Ae for capwap-archive@ietf.org; Sun, 07 May 2006 10:14:30 -0400 Message-ID: <000001c671e0$69657e70$dea6a8c0@jtu48> Reply-To: "Hippolytos Grimm" From: "Hippolytos Grimm" To: capwap-archive@ietf.org Subject: Re: good crnedit Date: Sun, 7 May 2006 07:13:28 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C671A5.BD08F060" 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: 2.7 (++) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C671A5.BD08F060 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0002_01C671A5.BD08F060" ------=_NextPart_001_0002_01C671A5.BD08F060 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable the www site =20 =20 =20 =20 =20 halls! But their spirits sank at his grave words, and they all felt that the adventure was far more dangerous than they had thought, while all the time, even if they passed all the perils of the road, the dragon was waiting at the end. All that morning they were busy with preparations. Soon after midday they ate with Beorn for the last time, and after the meal they mounted the steeds he was lending them, and bidding him many farewells they rode off through his gate at a good pace. As soon as they left his high hedges at the east of his fenced lands they turned north and then bore to the north-west. By his advice they were no longer making for the main forest-road to the south of his land. Had they followed the pass, their path would have led them down the stream from the mountains that joined the great river miles south of the Carrock. At that point there was a deep ford which they might have passed, if they had still had their ponies, and beyond that a track led to the skirts of the wood and to the entrance of the old forest road. But Beorn had warned them that that way was now often used by the ------=_NextPart_001_0002_01C671A5.BD08F060 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
 
 
 
halls! But their spirits sank at his grave words, and they all = felt
that the adventure was far more dangerous than they had thought, = while
all the time, even if they passed all the perils of the road, the = dragon
was waiting at the end. All that morning they were busy with
preparations. Soon after midday they ate with Beorn for the last = time,
and after the meal they mounted the steeds he was lending them, and
bidding him many farewells they rode off through his gate at a good = pace.
As soon as they left his high hedges at the east of his fenced lands = they
turned north and then bore to the north-west. By his advice they were = no
longer making for the main forest-road to the south of his land. Had = they
followed the pass, their path would have led them down the stream
from the mountains that joined the great river miles south of the
Carrock. At that point there was a deep ford which they might have
passed, if they had still had their ponies, and beyond that a track = led
to the skirts of the wood and to the entrance of the old forest = road.
But Beorn had warned them that that way was now often used by = the
------=_NextPart_001_0002_01C671A5.BD08F060-- ------=_NextPart_000_0001_01C671A5.BD08F060 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <000101c671e0$68c5c5c4$dea6a8c0@jtu48> R0lGODdhLwE/AcIAAAAAAAAAAP///wAA//8AAJKAtwAAAAAAACwAAAAALwE/AQAD/ii63F4uSgWn lfWu3Lj+YCiO5OiVaHQya+qm7SuX8VzL96zvfO/Dv6BweMkRj8hiEmVcKp3QqHRKBRWa1agHm+16 XdyvMCwum89LMnrNbrvfHbh8Tq+X1fa8fs/vT/F+gYKDbmGAhGCIf4qMjY5fhzSPk2KRIgGYmQFB mw6dkhYrmpRElnafC6gCpqoKrUKYDK1NpqRJtRqvry+6S62bEBy4tra7n5kcmscCsQ29qc2uzM2Z ztEb0p6bqNzM07/X27uNw2jG2d6ux53XshHL6NTR8Okes97ry/Pu8QHlSBX+QXJxb5szdNnGKRuV LhXCbg0ROnw3TRo7gxMjphsn/kLgKmI9zqkCJovahGcjH/JLyaLewY0wI9JLCJKYyIXQYrE7SVHj zowbcXqSsFMnRojfGHK0kiVYISciRb1U2JMkTaA/L/jTZtFh1obnMLzw+IbsA6JxvsacSPWsT5Vs Xw7Flg9aBaQsl9Yc9Isf2HUS/folORMv0LnqoMnKgBTs4TORruxdCG5kNbWCsYYTzK0dhZKeWcq0 1jjwHMl7dxzyaJZgmh+t2QhLDUUvyNiJaOvWgLtHbyB9fu8eTnzsnabEhAdRXrx5ntl0mDv/ID1g y+jTs4M6rUi6itvavXjnMZ7pEeXjy4cnzkX9erdU3JsQ+77+Hvn28+t/+tEG/v3zNa32BCLoFYff dAca99mC+zXo4IOPeBdbgoxQCOF3yF2oYSDPrJGVbRpxYhovj40AYgonzoFKASlK0dcHLaKAmQwz lRCjiVKYNc+NUCGmFRIzkjhiCDxiY4FVvM3n4mPVYOWVMfvsWFlMDGkDQWdTgqbPZlU+eRGW8gil TjftVNlkTw+dGaIgGA3mZGJoJWRYRiYNCVg8bsIVzQmvsPglW3fWSI9ncK05WqFF/pdFmxJ9VWNm hV4V14h5TfWSVEzGqaelka6FmGiclWhoKHK8OCmeRPGZmVofosVYo7BWJFeIYXX6DaqxtvWWj3fO igiSu86JJmdCVUopp4Aq/pNTYT6GSudluCbVpK6gvjlmaYSoyk8yoq7ZyZWaSgpsrsgeaWuthxp7 KIPU+mprtL8262i3HQaLLLqe5jvLvO5Gymq06n7aL7bwEqLLXc9269iu6261MJr7IPpmaSyGC9GO 8A7KE52aRjzkgHBAaVmbHJmpzZQfEvpNxTmdTBqzpMHXMLS3qmnzSVIeqZOWkFqoJHd1kOWzedcJ MnQgtGRLwtG6WcI0hmVtp8TTG3ZUddDYpUb1QEUH50NkV/8cdoZji112fVu3kfbZSbItMw7JKe3c 2ta5HbWRdjNx9m9rj933BH/nHYfgABEOnuEAIg6c4ow3/nV/jpcieODD/lGu4CCWT4KHfNVBPUTm dHTmi5/uvhiaD+PimEttS1+CBhn0tLbZYWoG1ewMiX6s8A+5r87h7jyYOpph1eJOI4ysD9E7FC18 WS2Wzg7MLPEDy3qrlo+CxnNSyzrfMs5nioPyrBebHH7tjxORvWgal1grYeJwPJo9wmI8KjwXl6RY w0QFCrP1/djS/lj2sD5k72EBq1eeECg/b62KXMPCx7DUVTx7NRBc+pNgRRIIvDEAjjqvOlbG3oWu VvHPNKXJEr7i16/rCUordRqhpTAzrQUaUFTtO5UDJ/iWxswITOfbmaEocy3a0SwfXerPKPjFsCdt cFmeOqAZciBFRnHw/nYAZJQGEVKxeq1QhOaKiD0KhrcrNrEraDQjiJ5WxXVJaohv88fIHujFcuWL dnNJoQx9xcTiBRGCZMxDFcvUQJUR0HpX0gW2CMW+/cmqXenK4DQwGEgCxnBmXHGk/YR1w4+FpkxC 7J/KFAiOCF4PikEa0/ZOuURVulKUR1lVKB+ISkSpLD6wUJTe/AM62DAIl3yg4vIitzciDTOYxBwc 0CADB4HEoJfUeY0ekqbLsHXuCG2837WUJa1mUJJ8lHEeN62mFSq2oWSZdIcCK2EjR2aQkamklfsY 2ZJEccE2xyQa8kRpjTy2sG2kioI+YrZFV6LTn0NxGKTy+UF8mk19/jwZY156xSavHKQoF/UkWr6l zggeMhfh6JL5RvlHnFnylN+zyCe12NGWFtJiK1HKP8ky0JZqMZYbS6jASkckQFHgkhf5KUzBaDtE 3eV/o5xYqKgVJcBUEJun+okJxRm+je50oUTEYl60NaIQui+C/zohDq01k2/2U4OzXAtDlblT/Inr jVgsaMGEF0bwwSl6cqng6VZSrhdCbIFPjQsNY7hWEDispmpd2EF1ij1C/nNBIiNZVccaqwdMNlky bSAKxZQ/SF00fkhMrDTBgjC3ovGOnpXr8+Kq1eq50YYNaR4g5XJSzzbSpbojmb4sCjnJ4QoTIawL XF272oUaFqxV/kmtX8MYsCjiMY54DOwra+imwh43UghTak45ll3yjfG6RSVdJCkbyPKR1Vp/aW2I PrqUkGpSuEvyl3y7OS0xvfZc4XyHHHn2LZPhMGfgQ2KWOkUz2wbGsXVN0yxvCTLGSce6BXKNdqBj NNXBLZpnYPBDm+MeQECTRjziHNLktsy3MfODdf3EgZZ3zMUmWAntvRlP6RsmbtZiGC04xDpD4DPr sja12z1rxq7BMhdLpDxqCMOOfZk+IKPYwi/2HUW4pZI5YeqxXQDVZeEYSJTCUIAn01h9t9TZ526q iCoVGWNuiS84kQm2rvWQM7rLjoC87zGUdKichuo//LWvuKx8/mNQiXrANkvDkiwsoHqrKVDNFvTO KMRySnRlwzK/9cA7uUt2V/QuRS85LDkU8JZ119v4evq+vyXwj3ArZM1aWrQ7xGlR8QrbHX9Ufqb1 pH3ZkMPTctkxIR1nuOT6Mlfz9diKVukTA/i/vMa5hYj1tUI/5WPUMcOr0u7Y/qQYri5et9lhfbNl gf1VVJ86rorkrbpHJZNqB++1VkxVqis7bJbGCdscDTerUzpqQWvbwMNut2WoXG93K4l+t6UoYBcu 5VSWmRvB7TX67prFMxOavBMUXTq9IduZlmGl2oM0w2qnkIiJ4rI+3KYsg4yXLYsspWEm+cT39TJu LtkMKv5l/qO9ACKDEwhrGt75hoUEQ/EspzhB141egp6DD5NTC+QxEDBv4bYMOB1vantOMrHbra2l qNoEY7eTWycbfe6SfAGvw9eVN/Yi+Lw5YX97Lns6d1KXuu1yJlZhStuXMRM0zVDEB5eqJ3PqGkl8 r0w84rn3U3qOOrKVKcrsBN8yuYfE2f6m+Ds9NiiJi1l6CUvMRKcr1H7ocJH4I7gk93rXzg9mmMzp 9aPphe9YETzll5YXIMG9iiuG/bmFnrHEVK0H2cfbTs5SY/RMqHuCShzZmdd4vbsM8/kWULpuML5Y eQV951qf+bNCtBCfj1nD6wu4paZggOV53kPTm+xUOP66/rOJjiIvqLvX92q0+VhZ+Y+3nnx1ZWZm b9mAf9+HXmJ3OSKiR5yEdjrkfW70edM3chF4Hb73ZAOoTcZlLbWHd0PHOwiWMvSyfMZ2gIknZL0C YCZ4fdanSdrTP+60guyzFBaSDDmHUgVGaT60Jy3XR5IUc8UmfRUIc+UTWgn1STqTVi7EcCHXSaP1 ORpFApZHdGGTdDkCYlF2Awy2YlMYdWRjhZ4DGRrWImC4KF0IUB+4dWq4hndnH1eHgZOwC1uAhvB3 fwhoYkFGd1JXYnrYNWJgFS0mI06QYxwGUaXigfskhVqDOgqVaF5ygjcTbMhTeOoEPRgwUi9YbII3 YPpl/kVl4ieFMXH+kRujqAP9pXnbxnmh52j69VKatz7+g3ng1H7UVkiBcofvMWnb9Wqsono8ZEFm Bnz854B7JIzdB36Jg0w9tIvHWIDvx33XthhnVDKXdEZDyDAGGFYveFhn2EwvRoBD2FxZxYz0ZVbj yF+NsmvXCFxJFCycdUSrdHakmH0ZNVRwpY3ghVo+oYV2tHQkuGoPaIw/VmHGs2/opW+rUgO8+H50 hY/sN3x41o+zhYhIF5AH6YpwBo0MJIurR0PltoJ5FTvvBTD04XS10G8XSYSd+GyWuFklN34rqV/d xV4MVmBe1koC140YZnYgoZNseCE3+JP58YZwGCCL/lB2OjAhASWUDfJ24QQmMZdUABch/BE6ddhO reZHLkNL80gKW1M31pY8GxhpANiRTCl0M3MTI1ONnWFOthV869ZlPsmHqmGIgZZs1pOCjngMBth8 VyWLfccgEZZMJhFUWulozCddoKJ//yZPcxkeuIFBOHWYLskuweiXHMmEFJmUZ6ls46eOKgaV0XaO mLkBcEmaCdiVnelSskaOFPh7yDVuIkSZqwkVAEabyyVjCkNXqLZcHQR1dZmLQrg+r+dOpqIK3zWL mUKWv1mbCjiNUqlg/ld9poRmjUUw2HcPcuAUeOicbXiVF+adfiBikKk4FCaeWbcbREmHWlchOjc3 /lKDnvKJOUUZN25oC+s5n0e5nRP2hFNEYg6mnwI6oI2Tn/3phwS6lAm6oOWZN2DJoFjjhQj6c+NJ oRD6OkymhjVgoMGZHXPonxcanxk6TccRovrBoYy2Hkj2bsnYZFhXoULZjj4Bckm4lZm4A49pF2JR eCVld0ZXdo5YcRD5l0h1efspDx1DnMNViHQ3L36lV5CDkM05oan5ojiKd0qqjw/ikeeWc6Q0kYrU JIkUnXdJQnIElVKmXNpWhpqDIiy1FWXlkGD6jJs0lYcVQExyi6WHMxRhMyIVlxCyZrcFjMx5j3Rq R8lViWnUkD4qipwXikFahUBVnNZIqLtlVwCU/qiT0poxWYZfWkZVAYYoajaLZ0Sc+qni2ImSJZWV YhRDlIOieDtP1Qs1ciBpQ1WO+oyWKqdQilCCBaiVqmdcOWNBqaIbw6XtpqupGo3L2ZexdikqOKwf eWASeS9VYxB1NKQcWaTpNKlXRVEktW0T6jGA+Siyx5NKR6ZedpN/R52xipOMxyvoNxHOWkRGqKrg xImakaN+YF38egomipUQwlHfMapb1x4d+qPXSqINNnUteqA24qdrKYk12q4nWJBPFxI1SaMqWYWU h6SNCUkk6aN9GH+DRqSu2IXrKVXm5pu0Y466iiI8N5WGqlht6hu+2gEiV6iXqlcilavfc0jY/vmz FcOPc7Fp1sqm6wGnMKiRPPsV9vcZpeRmdhpV5Np6TDQ43kRLSNIqPndj58SxxPi0vVetXOs5/1KY qNhcmNp8MxipV4M+twZvsbmsRVNfq1YpkhFPLpQ6aZdewXqxV1iVfbpOeuS2ZouO1lmtoEWA8Hqm +diEgcttUFhRsXWZvfqA+Aiz6tWqwJq5UZaz7Ee59cGygKasjCt8PFuz87qugVuaySpGpjOlVeA0 ItpRJ8ub9NeItGiWvWmLP+i7Q0teDbiRGyKxnOYtCHax6POusEqmJPdPj+u8y9u89ESdIOqibMc7 adiT6ck2/6p2zvmV4xuw3VG59PmcWPYe/k9ju3A3r75ovTGmr65LhWZIjaA0R7TrQXuArZZRaSM4 pKQLZSaLiqY3b1rKn1nmb0/6bD27vq7TvQK7Q6U3bVOVvvE1u3OKuM0IhIEnr7zXW8ImowPJuk5U n3djm6MrkGS7q92atalAZ3iKaeK6O0knpeA4sCHIwnO7rNXCXqSWthiVqZbatikWknDLpCbirQdM sKiauFs5huTibWKHtzzWcMTlTQYroZsYpTEDDKD7wG8ZSiSsb64aWX9hhS4GpQOMoQ0rIteGmjU7 jHZ7mWTpub5mx6k5bdKqwd/Jv8DJosiqcWEspdRKs5o7Xdc7rXr8kPWXe0BJbNu3uwC8/llH5QrY BqoHbMB5iX/pRlRwdq5ubA7qKr989El8wmbPW0LLez+rvH4xNcKLXL/s6TUyy72RjLPoaU9Kd3QI 8r0wyjZMg5xNkzWN87MhBYo3GpPLTMu3zHMbO7HwVaUZC6AZRVhwqYGTTLtGa4YGDLLMybcXVoMo fKx5nKUtXMfHo5oTnK3hTLInlr1LapGvm8jBisysHMI1F495eLR3Jqry2AhKGMuTl85QnJcw/Ft5 drUI3Wkx+MK6mcNbymYuiLodTJsJnBDcUpiJNBTBZVjRvHohF74cMssH7cKV+j2E8tHHxqlRzBHJ 2c93rLThEaQHVcgbHIRQpC2tClqw/pTGPZemUtun9FrNdjAMCW22mWzIjrxeKDFDn+vAf6um1vrL 3zZXEhnT+ZKNsPussYy9YUynVNa1vkrSpQhVutWtGTmy2zeSv/tbQii8bzlPq3icwCMhISMlyGyj 6Ui/1Luq+TyMFrjKORa9iyu4LQme8vzGpgjHt2sT5kvAi1MMyjjZlEC+kZ2gW2zNkYuuKTzK3onP FuvM62rKRkp1RlxzotaxHBob/rvJSNVx2wzPiVgF4Axtf0XNij2iU2C6qYvITJ1PRYILcadzHSLO zCNIUajOG+yzyGsx5Dq0z13LhgZsKWKSGstuwR2G242CSf1n/PbCDv3N+Ew9wWzb/hQNSGbV3Kqb 0bultkTMtvzUirA90vdBysd90j5MFxUrxRbk0s63dkJdbrHKmZRg02cL3DmtuPGaumf80/cKkDJN q10XhoxdohJ2uPZMxwcd1jDx0ftXWZk81RgHyWxV0yYeLL7I3mO5uj0brXr8DH3J3Mi4pVu0s5Rc gspbw4+MwO5F37Ky4nkJ5Cn4rRALI3otsQh3yn6tymQMtJDoxbBEQMr804IhXs0scH9s1dUZn2Yt IEbd2Rh+NrBXE2a92Jkd5vLJnWn+sAG12egJ54UjlHJ+4oTb5sBMpeiL5wzrnXVODgrK21zM53z+ 54Q+uIe+n1y+55b9nrUL6InutyCGfp8BauGRHuh6TriTPunh+Z9vw+mYzjWBfN9r2HS77dnuWc61 rL1+s5OoPZ8bqk+gbqUQWg6G0Jn4saLsfOkOGqjWZOcWyusKPOp0vqDqMesEaexGed6rfuqvPuxb fufEXuqL7ujCbqxk4wjIzuqonu1oztlKLMFVF+nbbp7XPubeCOy0/u3qqbBq7uvOzu5I+ezQ3u6V re7Vvu72rr6UfukPeu+gnaLn3ucDb8vsNO+MTggJAAA7 ------=_NextPart_000_0001_01C671A5.BD08F060-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun May 07 19:55:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fct68-0006rk-He for capwap-archive@lists.ietf.org; Sun, 07 May 2006 19:55:36 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fct66-00036T-1b for capwap-archive@lists.ietf.org; Sun, 07 May 2006 19:55:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0D6414300F2 for ; Sun, 7 May 2006 16:55:25 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3E251430054 for ; Sun, 7 May 2006 16:55:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 318AA398013 for ; Sun, 7 May 2006 16:55:06 -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 8805B39800B for ; Sun, 7 May 2006 16:55:03 -0700 (PDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 07 May 2006 16:55:02 -0700 X-IronPort-AV: i="4.05,99,1146466800"; d="scan'208"; a="273387012:sNHT35509520" 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 k47Nt2Yg017934 for ; Sun, 7 May 2006 16:55:02 -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); Sun, 7 May 2006 16:55:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 7 May 2006 16:55:01 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D82FC2@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-capwap-protocol-specification-01.txt is available Thread-Index: AcZyMadY1K/JDD/MSlCrKD+c0awjXw== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 07 May 2006 23:55:02.0467 (UTC) FILETIME=[A8079130:01C67231] 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: Subject: [Capwap] draft-ietf-capwap-protocol-specification-01.txt is available X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 All, =20 The CAPWAP editors wanted to announce the availability of the -01 version of the draft. Please note that the following issues were addressed in this version: 38, 39, 40, 42, 43, 44, 45, 46, 49, 50, 53, 58, 59, 61, 62, 65, 70, 71, 76, 88, 91, 93, 102, 110. There are also a few issues that were partially resolved, including 101 and 111. In addition, you will notice some significant structural editing, which was discussed at the Dallas face to face meeting. The message elements have also been renumbered. As of today, there are only 45 remaining issues open. =20 The goal of the team is to close as many issues as possible and submit the -02 draft a few days prior to the June deadline. =20 =20 Thanks, Dorothy, Mike and Pat _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From cleencasavant@giaronomo.com Sun May 07 23:44:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcwfR-0008G6-KR for capwap-archive@ietf.org; Sun, 07 May 2006 23:44:17 -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 1FcwfR-0005ea-IO for capwap-archive@ietf.org; Sun, 07 May 2006 23:44:17 -0400 Received: from [58.239.9.203] (helo=giaronomo.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Fcwag-0007pz-Le for capwap-archive@ietf.org; Sun, 07 May 2006 23:39:24 -0400 Message-ID: <000001c67250$f4962ab0$774da8c0@jay36> Reply-To: "Cleena Casavant" From: "Cleena Casavant" To: capwap-archive@ietf.org Subject: Re: your good crdit Date: Sun, 7 May 2006 20:39:05 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C67216.483752B0" 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: 6e8a3b85ef670172081194f0b0f68e6f This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C67216.483752B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D a=20 ea t=20 r H d=20 om p=20 e O v=20 wn k=20 er, Your c t=20 re q=20 di d=20 t doesn't matter to us!=20 If you O w=20 WN b=20 r c=20 ea s=20 l e y=20 st u=20 at p=20 e and want I a=20 MM x=20 EDIAT w=20 E c y=20 as g=20 h to s r=20 pen w=20 d ANY way you like, or simply wish to L i=20 OW t=20 ER your monthly pa i=20 yme i=20 nt i=20 s by a third or more,=20 here are the d z=20 ea r=20 ls s=20 we have T u=20 ODA m=20 Y: $ 49 c=20 0 , 00 p=20 0 as lo b=20 w as 3 , 6 z=20 5% $ 37 t=20 0 , 0 z=20 00 as l z=20 ow as 3 , 9 i=20 0% $ 4 z=20 90 , 00 y=20 0 as l d=20 ow as 3 , 2 k=20 0% $ 2 j=20 50 , 0 k=20 00 as lo z=20 w as 3 , 3 p=20 5% $ 20 f=20 0 , 0 z=20 00 as lo s=20 w as 3 , 5 q=20 5% V =20 x=20 is k=20 it o c=20 ur s j=20 it w=20 e Cleena Casavant , Ap w=20 pr o=20 ov z=20 al Ma m=20 na u=20 ger _____ =20 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. So Thorin went on: We are met to discuss our plans, our ways, means, policy and ------=_NextPart_000_0001_01C67216.483752B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D a
ea t
r H d
om p e O v wn k er,

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

If you O w WN b r c ea s l e y st u at p e and want
I a MM x EDIAT w E c y as g h to s r pen w d ANY=20 way you like,
or simply wish to L i OW t ER your monthly pa i yme i nt i s
=20 by a third or more,
here are the d z ea r ls s we have T u ODA m Y:

$ 49 c 0 , 00 p 0 as lo b w as 3 , 6 z 5%
$ 37 t 0 , 0 z 00 as l z ow as 3 , 9 i 0%
$ 4 z 90 , 00 y 0 as l d ow as 3 , 2 k 0%
$ 2 j 50 , 0 k 00 as lo z w as 3 , 3 p 5%
$ 20 f 0 , 0 z 00 as lo s w as 3 , 5 q 5%

V x is k it o c ur s j it w e

Cleena Casavant , Ap w pr o ov z al Ma m na u ger
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.
So Thorin went on:
We are met to discuss our plans, our ways, means, policy = and
------=_NextPart_000_0001_01C67216.483752B0-- From eppersyqasim@asiaep.com Mon May 08 08:45:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd574-0004HA-5W for capwap-archive@ietf.org; Mon, 08 May 2006 08:45:22 -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 1Fd574-0006TW-3H for capwap-archive@ietf.org; Mon, 08 May 2006 08:45:22 -0400 Received: from udp070997uds.hawaiiantel.net ([72.234.112.243] helo=asiaep.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Fd538-00067h-97 for capwap-archive@ietf.org; Mon, 08 May 2006 08:41:23 -0400 Message-ID: <000001c6729c$a6ba2700$68e2a8c0@hdm38> Reply-To: "Qasim Epperson" From: "Qasim Epperson" To: capwap-archive@ietf.org Subject: Re: your crdit Date: Mon, 8 May 2006 05:40:56 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C67261.FA5DC000" 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: 5ba9b8496764663b12c333825fbf6b3d This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C67261.FA5DC000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D v ea c r H l om g e O l wne a r, Your c x re g di x t doesn't matter to us! If you O v WN s r s ea c l e w st n at b e and want I u MME c DI v ATE c m as f h to s k pe t nd ANY way you like, or simply wish to L n OW b ER your monthly p j ayme u nt s s by a third or more, here are the d v ea z ls q we have T o ODA e Y: $ 49 u 0 , 00 c 0 as l i ow as 3 , 6 k 5 % $ 37 v 0 , 0 a 00 as l u ow as 3 , 9 g 0 % $ 49 i 0 , 00 k 0 as lo p w as 3 , 2 b 0 % $ 2 b 50 , 0 r 00 as l b ow as 3 , 3 x 5 % $ 20 y 0 , 0 e 00 as l n ow as 3 , 5 n 5 % V t is i it o i ur s d it i e =20 Qasim Epperson , A i ppr e ov c al M t anag p er _____ =20 At any rate he is under no enchantment but his own. He lives in an oak-wood and has a great wooden house; and as a man he keeps cattle and horses which are nearly is marvellous as himself. They work for him and talk to him. He does not eat them; neither does he hunt or eat wild ------=_NextPart_000_0001_01C67261.FA5DC000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D v ea c r H l om g e O l wne a r,

Your c x re g di x t doesn't matter to us!

If you O v WN s r s ea c l e w st n at b e and want
I u MME c DI v ATE c m as f h to s k pe t nd ANY=20 way you like,
or simply wish to L n OW b ER your monthly p j ayme u nt s s
=20 by a third or more,
here are the d v ea z ls q we have T o ODA e Y:

$ 49 u 0 , 00 c 0 as l i ow as 3 , 6 k 5 %
$ 37 v 0 , 0 a 00 as l u ow as 3 , 9 g 0 %
$ 49 i 0 , 00 k 0 as lo p w as 3 , 2 b 0 %
$ 2 b 50 , 0 r 00 as l b ow as 3 , 3 x 5 %
$ 20 y 0 , 0 e 00 as l n ow as 3 , 5 n 5 %

V t is i it o i ur s d it i e

Qasim Epperson , A i ppr e ov c al M t anag p er
At any rate he is under no = enchantment but his own. He lives in an
oak-wood and has a great wooden house; and as a man he keeps cattle = and
horses which are nearly is marvellous as himself. They work for him = and
talk to him. He does not eat them; neither does he hunt or eat = wild
------=_NextPart_000_0001_01C67261.FA5DC000-- From blosey@visir.is Tue May 09 13:51:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdWNB-0006BT-Sk for capwap-archive@ietf.org; Tue, 09 May 2006 13:51:49 -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 1FdWNB-0004Y7-Qj for capwap-archive@ietf.org; Tue, 09 May 2006 13:51:49 -0400 Received: from [88.134.147.117] (helo=visir.is) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FdWN8-0001Wy-Cw for capwap-archive@ietf.org; Tue, 09 May 2006 13:51:47 -0400 Message-ID: <000001c67391$3a8c1930$81e7a8c0@zpu80> Reply-To: "Cruz Blose" From: "Cruz Blose" To: capwap-archive@ietf.org Subject: Re: good csredit Date: Tue, 9 May 2006 10:51:41 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C67356.8E2D4130" 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.2 (+++) X-Scan-Signature: 7b8e6f6ef974ecda19a6b57d59caeb7d This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C67356.8E2D4130 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D f ea c r H f om l e O o wn u er, Your c q re t di f t doesn't matter to us! If you O n WN t r c ea w l e c st n at p e and want I g MM c EDIA n TE c z as g h to s t pe u nd ANY way you like, or simply wish to L n OW x ER your monthly pa p ym h ent b s by a third or more, here are the d v ea h ls z we have T h OD z AY: $ 4 j 90 , 00 f 0 as l k ow as 3 , 6 y 5 % $ 37 c 0 , 00 u 0 as l z ow as 3 , 9 j 0 % $ 4 i 90 , 00 n 0 as l f ow as 3 , 2 m 0 % $ 25 e 0 , 00 f 0 as l k ow as 3 , 3 u 5 % $ 2 j 00 , 00 s 0 as l l ow as 3 , 5 t 5 % V w isi a t ou e r s o it a e =20 Cruz Blose , Ap k pr m ov x al M z anag l er _____ =20 Down too came many of the Lake-men, for Bard could not restrain them; and out upon the other side came many of the spearmen of the elves. Once again the goblins were stricken in the valley; and they were piled in heaps till Dale was dark and hideous with their corpses. The Wargs were ------=_NextPart_000_0001_01C67356.8E2D4130 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D f ea c r H f om l e O o wn u er,

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

If you O n WN t r c ea w l e c st n at p e and want
I g MM c EDIA n TE c z as g h to s t pe u nd ANY=20 way you like,
or simply wish to L n OW x ER your monthly pa p ym h ent b s
=20 by a third or more,
here are the d v ea h ls z we have T h OD z AY:

$ 4 j 90 , 00 f 0 as l k ow as 3 , 6 y 5 %
$ 37 c 0 , 00 u 0 as l z ow as 3 , 9 j 0 %
$ 4 i 90 , 00 n 0 as l f ow as 3 , 2 m 0 %
$ 25 e 0 , 00 f 0 as l k ow as 3 , 3 u 5 %
$ 2 j 00 , 00 s 0 as l l ow as 3 , 5 t 5 %

V w isi a t ou e r s o it a e

Cruz Blose , Ap k pr m ov x al M z anag l er
Down too came many of the Lake-men, for = Bard could not restrain them;
and out upon the other side came many of the spearmen of the elves. = Once
again the goblins were stricken in the valley; and they were piled = in
heaps till Dale was dark and hideous with their corpses. The Wargs = were
------=_NextPart_000_0001_01C67356.8E2D4130-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue May 09 16:27:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdYo1-0002hx-Tc for capwap-archive@lists.ietf.org; Tue, 09 May 2006 16:27:41 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdYnz-00048T-Cv for capwap-archive@lists.ietf.org; Tue, 09 May 2006 16:27:41 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id AD6974300DF for ; Tue, 9 May 2006 13:27:38 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7754B430067 for ; Tue, 9 May 2006 13:27:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 60A26398047 for ; Tue, 9 May 2006 13:27:13 -0700 (PDT) Received: from mail-relay-2.tiscali.it (mail-relay-2.tiscali.it [213.205.33.42]) by zoidberg.tigertech.net (Postfix) with ESMTP id 036FE39801B for ; Tue, 9 May 2006 13:27:09 -0700 (PDT) Received: from Anna (84.220.39.164) by mail-relay-2.tiscali.it (7.3.104) id 443AD4620034EF07 for capwap@frascone.com; Tue, 9 May 2006 22:27:07 +0200 Message-ID: <003801c673a6$f14368d0$a427dc54@Anna> From: "Annarita Levanti" To: Date: Tue, 9 May 2006 22:27:07 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 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: Subject: [Capwap] some questions X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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="===============0256427150==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 This is a multi-part message in MIME format. --===============0256427150== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01C673B7.B48BD470" This is a multi-part message in MIME format. ------=_NextPart_000_0035_01C673B7.B48BD470 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reading the new version of capwap, in particular IEEE 802.11 binding I = don't understand what can be considered as "802.11 Action frame" and, = referred to the split mac, if a WTP can forward to AC also data packets, = that is 802.11 payloads of mobile users, or also other 802.11 traffic. I think maybe a WTP could forward beacons of others WTP to its AC, in = this way the AC can know which access point are listening from the WTP = and, for example, can assign a different frequency to the WTP in order = to reduce interference in the network. Please, someone could help me? Thanks. =20 Annarita Levanti=20 ------=_NextPart_000_0035_01C673B7.B48BD470 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Reading the new version of = capwap,=20 in particular IEEE 802.11 binding I don't understand what can be = considered=20 as "802.11 Action frame" and, referred to the split mac, if a WTP can = forward to AC=20 also data packets, that is 802.11 payloads of mobile users, = or also=20 other 802.11 traffic.

I think maybe a WTP could = forward=20 beacons of others WTP to its AC, in this way the AC can know = which=20 access point are listening from the WTP and, for example, = can assign=20 a different frequency to the WTP in order to reduce interference in the=20 network.

Please,=20 someone could help me?

Thanks.

 

Annarita=20 Levanti 

------=_NextPart_000_0035_01C673B7.B48BD470-- --===============0256427150== 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 --===============0256427150==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue May 09 17:11:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdZUE-0007ZB-Mf for capwap-archive@lists.ietf.org; Tue, 09 May 2006 17:11:18 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdZUB-0006WP-Ot for capwap-archive@lists.ietf.org; Tue, 09 May 2006 17:11:18 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8FBD64300F0 for ; Tue, 9 May 2006 14:11:06 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1CA97430071 for ; Tue, 9 May 2006 14:10:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 089061448018 for ; Tue, 9 May 2006 14:10:38 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by hermes.tigertech.net (Postfix) with ESMTP id CD6151448012 for ; Tue, 9 May 2006 14:10:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=TUY3HNsEWAjlpOVakPlrsyGEKvYFiQBYTbEhBPg+nHXH5qTk+rC+s9ba1XwfWSk4; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.53] (helo=elwamui-wigeon.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FdZTW-0001cm-Dl for capwap@frascone.com; Tue, 09 May 2006 17:10:34 -0400 Received: from 72.115.233.135 by webmail.pas.earthlink.net with HTTP; Tue, 9 May 2006 17:10:34 -0400 Message-ID: <159451.1147209034066.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Date: Tue, 9 May 2006 14:10:34 -0700 (GMT-07:00) From: "Scott G. Kelly" To: capwap Subject: Fw: RE: [Capwap] to mux or not to mux? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710b14615c6131feb1b0dad8694519188d3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.53 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: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 Meant to send this to the list... -----Forwarded Message----- >From: "Scott G. Kelly" >Sent: May 8, 2006 6:27 PM >To: Michael.G.Williams@nokia.com, pcalhoun@cisco.com, Michael.Kraus@anheuser-busch.com, scott@hyperthought.com, dperkins@dsperkins.com >Subject: RE: [Capwap] to mux or not to mux? > >It seems clear that the AC/WTP should not be applying a one-size-fits-all QoS policy to the data channel. It also seems clear that they can affect control channel QoS using appropriate standardized QoS marking techniques. > >Currently deployed Internet gear uses these standardized techniques to implement QoS, and we've heard no compelling arguments as to why these standards are insufficient for our purposes. > >Based on the messages in this and previous related threads, there is no technical basis for using separate UDP ports, but there is clear technical rationale for multiplexing data and control over one UDP channel. > > >-----Original Message----- >>From: Michael.G.Williams@nokia.com >>Sent: May 5, 2006 11:40 AM >>To: pcalhoun@cisco.com, Michael.Kraus@anheuser-busch.com, scott@hyperthought.com, dperkins@dsperkins.com >>Subject: RE: [Capwap] to mux or not to mux? >> >>Question, doesn't the QoS of the STA's data need to determine the QoS of >>the data channel carrying it? Other tunnels often copyout the inner DSCP >>to the outer. >> >>BR, >>Michael >> >>-----Original Message----- >>From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] >>Sent: Friday, May 05, 2006 7:27 AM >>To: Kraus, Michael; Scott G. Kelly; dperkins@dsperkins.com >>Cc: capwap@frascone.com >>Subject: RE: [Capwap] to mux or not to mux? >> >>I completely agree with Michael's points. >> >>Pat Calhoun >>CTO, Wireless Networking Business Unit >>Cisco Systems >> >> >> >>> -----Original Message----- >>> From: Kraus, Michael [mailto:Michael.Kraus@anheuser-busch.com] >>> Sent: Friday, May 05, 2006 6:36 AM >>> To: Scott G. Kelly; Pat Calhoun (pacalhou); dperkins@dsperkins.com >>> Cc: capwap@frascone.com >>> Subject: RE: [Capwap] to mux or not to mux? >>> >>> I know of many enterprises who have multiple 54Mbps access points all >>> run back to the same switch, which have a 100Mbps uplink. In the >>> future, I am anticipating multiple 802.11n access points with a single >> >>> 1Gbps uplink. For temporary uses(conferences), I have even setup a >>> WTP having a WAN link back to the AC. My point being, is that there >>> will always be environments where congestion will occur between the >>> WTP and the AC. In a perfect world, there is no over-subscription and >> >>> no congestion. >>> >>> When congestion occurs, typically you want to ensure that the data >>> traffic is dropped, not the control traffic. I agree with your >>> statement that the WTP or AC could apply the appropriate DSCP or >>> 802.1q marking, and I had too suggested that earlier: >>> >>> ">> One possible method could be for the WTP to assign the CoS/DSCP >>> >> values for each traffic type so the administrator would have the >>> >> ability to trust the markings provided by the WTP, or >>> later perform a >>> >> DSCP-mutation.?" >>> >>> However, I have not seen any mention that if we are going to pursue >>> using a mux header that this would be incorporated into the changes. >>> If this was to be >>> >>> done, it would really make sense for the CAPWAP WG to make CoS/DSCP >>> recommendations for these values. Vendor interoperability is somewhat >> >>> hampered from a usability perspective if you need to do different DSCP >> >>> mutations based upon which vendor WTP/AC you are using. >>> >>> Thanks, >>> Mike >>> >>> >>> -----Original Message----- >>> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >>> Sent: Thursday, May 04, 2006 9:04 PM >>> To: Pat Calhoun (pacalhou); Kraus, Michael; dperkins@dsperkins.com >>> Cc: capwap@frascone.com >>> Subject: RE: [Capwap] to mux or not to mux? >>> >>> Please explain what problem is encountered if the same QoS policy is >>> applied to both control and data traffic. Also explain why any such >>> problems cannot be >>> >>> solved by having the WTP and/or AC apply appropriate DSCP or 802.1q >>> marking. >>> >>> -----Original Message----- >>> >From: "Pat Calhoun (pacalhou)" >>> >Sent: May 4, 2006 4:11 PM >>> >To: "Kraus, Michael" , >>> >dperkins@dsperkins.com >>> >Cc: capwap@frascone.com >>> >Subject: RE: [Capwap] to mux or not to mux? >>> > >>> >The point Michael makes here is the same one I was making. >>> Nearly every >>> >enterprise class system, router or switch, is capable of >>> providing QoS >>> >enforcement using simple ACLs, which rely on IP addresses and ports. >>> >QoS is just one of many features that can be (and are) implemented >>> >through ACLs that would be very useful to CAPWAP. >>> > >>> >The use of the MUX makes all of the deployed equipment out there no >>> >longer capable of applying QoS based on control/data plane. I think >>> >this is a serious issue, and justifies the need for two ports. >>> > >>> >Pat Calhoun >>> >CTO, Wireless Networking Business Unit Cisco Systems >>> > >>> > >>> > >>> >> -----Original Message----- >>> >> From: Kraus, Michael [mailto:Michael.Kraus@anheuser-busch.com] >>> >> Sent: Thursday, May 04, 2006 8:17 AM >>> >> To: dperkins@dsperkins.com >>> >> Cc: capwap@frascone.com >>> >> Subject: Re: [Capwap] to mux or not to mux? >>> >> >>> >> David, >>> >> >>> >> Maybe I'm misinterpreting something here and may be somewhat >>> >> off-topic, but often in QoS you try to classify traffic by >>> >> source/destination IP/port or by some higher level >>> interpreter (such >>> >> as NBAR in the cisco world). If the same UDP port number is being >>> >> used for both control/data, how will intermediate >>> switches/routers be >>> >> able to determine what is control vs. data traffic? This relates >>> >> back to your comment below of: >>> >> >>> >> "So, it all comes down to whether or not we want intermediate >>> >> network devices to distinguish between control and data." >>> >> >>> >> One possible method could be for the WTP to assign the CoS/DSCP >>> >> values for each traffic type so the administrator would have the >>> >> ability to trust the markings provided by the WTP, or >>> later perform a >>> >> DSCP-mutation. >>> >> >>> >> I don't pretend to be a QoS expert, and I'm sure many >>> products can >>> >> classify traffic by data outside of known IP/UDP headers. >>> However, I >>> >> would argue that this would likely be platform dependent. For >>> >> example, Cisco could create a PDLM for NBAR for these mux values. >>> >> But, obviously this support does not exist today, and NBAR is >>> >> dependent upon firmware/hardware support. >>> >> >>> >> We probably need a "neutral" person on this topic to >>> summarize the >>> >> Pros/Cons that have been already stated on this issue... >>> >> >>> >> >>> >> Thanks, >>> >> Mike >>> >> >>> >> ------------------------------ >>> >> >>> >> Message: 2 >>> >> Date: Thu, 4 May 2006 07:19:53 -0700 (PDT) >>> >> From: "David T. Perkins" >>> >> Subject: Re: [Capwap] to mux or not to mux? >>> >> To: "Kraus, Michael" >>> >> Cc: capwap@frascone.com >>> >> Message-ID: >>> >> >>> >> Content-Type: TEXT/PLAIN; charset=US-ASCII >>> >> >>> >> HI, >>> >> >>> >> Since UDP is being used, why cannot the data traffic packets be >>> >> marked with a different QoS values than control traffic packets. >>> >> >>> >> Would you explain and provide an example of use of "current QoS >>> >> tools". >>> >> >>> >> Regards, >>> >> /david t. perkins >>> >> >>> >> On Thu, 4 May 2006, Kraus, Michael wrote: >>> >> > One additional upside to using separate ports would be that >>> >> different >>> >> > QoS >>> >> >>> >> > policies can be applied against data/control data. With >>> >> mux values, >>> >> > this >>> >> >>> >> would >>> >> > be more difficult to accomplish with current QoS tools. >>> >> With 802.11n >>> >> > data >>> >> rates >>> >> > being quoted, having the ability to do some "control plane >>> >> policing" >>> >> > for the APs, might be advantageous. >>> >> > >>> >> > >>> >> >>> --------------------------------------------------------------------- >>> >> - >>> >> > >>> >> > Message: 1 >>> >> > Date: Wed, 3 May 2006 15:16:21 -0700 (PDT) >>> >> > From: "David T. Perkins" >>> >> > Subject: Re: [Capwap] to mux or not to mux? >>> >> > To: Charles Clancy >>> >> > Cc: capwap >>> >> > Message-ID: >>> >> > >>> >> > Content-Type: TEXT/PLAIN; charset=US-ASCII >>> >> > >>> >> > HI, >>> >> > >>> >> > Please don't forget about the discovery message. With it, >>> >> you have 3 >>> >> > values >>> >> for >>> >> > MUX. See below.. >>> >> > >>> >> > Also, please note that in the prototype that I'm >>> >> developing, I'm using >>> >> > the UNMODIFIED DTLS implementation in openSSL. >>> >> > That is, adding the MUX header does not require any >>> modification of >>> >> > the >>> >> openSSL. >>> >> > By the way,my two wishes are: >>> >> > 1) an Ethereal decode for the below >>> >> > 2) the addition of the NULL encryption type to the >>> >> > CAPWAP protocol for debugging >>> >> > >>> >> > On Wed, 3 May 2006, Charles Clancy wrote: >>> >> > > The DTLS tunnels would NOT be merged. You'd have >>> something like: >>> >> > >>> >> > +---------+------------+------------------------ >>> >> > | UDP hdr | MUX = 0x00 | Discovery Request or Response >>> >> > +---------+------------+----------- >>> >> > >>> >> > >>> >> > > +---------+------------+------------------------ >>> >> > > | UDP hdr | MUX = 0x01 | DTLS(CAPWAP Control) >>> >> > > +---------+------------+----------- >>> >> > > >>> >> > > or >>> >> > > >>> >> > > +---------+------------+------------------------ >>> >> > > | UDP hdr | MUX = 0x02 | CAPWAP Data >>> >> > > +---------+------------+----------- >>> >> > > >>> >> > > UDP is indeed a MUX header, but it's a MUX header that >>> everything >>> >> > > already understands. So, it all comes down to whether >>> or not we >>> >> > > want intermediate network devices to distinguish between >>> >> control and data. >>> >> > > For NAT traversal, it's easier if the NAT treats >>> everything the >>> >> > > same, and doesn't have to know that the two ports are >>> >> related. Same >>> >> > > for firewall / port forwarding. I think intermediate network >>> >> > > devices should treat everything as "CAPWAP", and we >>> >> should therefore do our own MUX. >>> >> > > >>> >> > > -- >>> >> > > t. charles clancy, ph.d. | tcc@umd.edu | >>> >> www.cs.umd.edu/~clancy >>> >> > > >>> >> > > Nancy Winget (ncamwing) wrote: >>> >> > > > Charles, >>> >> > > > >>> >> > > > With a MUX, yes they are logical channels, but I believe the >>> >> > > > implication is that these channels are merged into a >>> >> single DTLS >>> >> > > > tunnel...are you saying they are not? >>> >> > > > >>> >> > > > But as you state, if UDP is a MUX header, why the need to >>> >> > > > introduce yet another one instead of just using UDP for >>> >> separation? >>> >> > > > >>> >> > > > Nancy. >>> >> > > > >>> >> >>> >_________________________________________________________________ >>> >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 May 09 18:30:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdaj2-0000w3-Pw for capwap-archive@lists.ietf.org; Tue, 09 May 2006 18:30:40 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdaj0-0001RL-9Q for capwap-archive@lists.ietf.org; Tue, 09 May 2006 18:30:40 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E2CFF43010B for ; Tue, 9 May 2006 15:30:37 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 64FAE430094 for ; Tue, 9 May 2006 15:30:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2631F1448012 for ; Tue, 9 May 2006 15:30:04 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 2CC0E144800B for ; Tue, 9 May 2006 15:30:01 -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 k49MTx6O011789 for ; Wed, 10 May 2006 07:29:59 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k49MU0914331 for ; Wed, 10 May 2006 07:30:00 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with SMTP id k49MU1j06455 for ; Wed, 10 May 2006 07:30:01 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 10 May 2006 06:27:57 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDDEDAA6@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WLAN definition Thread-Index: AcZzt8+BexJigUnVQ6yGBHfNhC3IDA== From: "Saravanan Govindan" To: 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] WLAN definition X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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="===============0946026850==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 This is a multi-part message in MIME format. --===============0946026850== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C673B7.D8CEDF61" This is a multi-part message in MIME format. ------_=_NextPart_001_01C673B7.D8CEDF61 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 I would like to suggest a section in the draft for terminology. We can reference previous drafts for some terms, but I think the specifications itself introduces certain terms that may be difficult for first-time readers to understand.=20 =20 One particular case is with "WLAN". This seems to be in line with "Logical Group" that was defined in the CAPWAP Objectives. I think we should consistent terminologies or introduce new definitions in the specifications.=20 =20 I will send out another post with some terminologies / definitions. =20 Cheers, Saravanan =20 ------_=_NextPart_001_01C673B7.D8CEDF61 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

I would like to suggest a section in the draft for terminology. We can reference previous drafts for some terms, but I = think the specifications itself introduces certain terms that may be difficult for first-time readers to understand.

 

One particular case is with “WLAN”. This = seems to be in line with “Logical Group” that was defined in the = CAPWAP Objectives. I think we should consistent terminologies or introduce new definitions in the specifications.

 

I will send out another post with some terminologies = / definitions.

 

Cheers,


Saravanan

 

------_=_NextPart_001_01C673B7.D8CEDF61-- --===============0946026850== 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 --===============0946026850==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue May 09 18:32:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdakZ-0001hE-1s for capwap-archive@lists.ietf.org; Tue, 09 May 2006 18:32:15 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdakX-0001Xc-Kc for capwap-archive@lists.ietf.org; Tue, 09 May 2006 18:32:15 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 49C944300F7 for ; Tue, 9 May 2006 15:32:13 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 413704300E7 for ; Tue, 9 May 2006 15:31:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 30F351448010 for ; Tue, 9 May 2006 15:31:16 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 5C3E2144800B for ; Tue, 9 May 2006 15:31:13 -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 k49MVAoj012234; Wed, 10 May 2006 07:31:10 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k49MVBk11196; Wed, 10 May 2006 07:31:11 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with SMTP id k49MVB315070; Wed, 10 May 2006 07:31:11 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Capwap] draft-ietf-capwap-protocol-specification-01.txt isavailable Date: Wed, 10 May 2006 06:29:09 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDDEDAA7@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] draft-ietf-capwap-protocol-specification-01.txt isavailable Thread-Index: AcZyMadY1K/JDD/MSlCrKD+c0awjXwA4A/Bw From: "Saravanan Govindan" To: "Pat Calhoun (pacalhou)" , "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 X-Spam-Level: Cc: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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: 0ddefe323dd869ab027dbfff7eff0465 Hi, I can't seem to find how Issue 43 - relating to 802.11i in different WTP designs - was resolved in the new draft. The note below says that it is. I would appreciate help with this. Thanks Saravanan -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Monday, May 08, 2006 7:55 AM To: capwap Subject: [Capwap] draft-ietf-capwap-protocol-specification-01.txt isavailable All, =20 The CAPWAP editors wanted to announce the availability of the -01 version of the draft. Please note that the following issues were addressed in this version: 38, 39, 40, 42, 43, 44, 45, 46, 49, 50, 53, 58, 59, 61, 62, 65, 70, 71, 76, 88, 91, 93, 102, 110. There are also a few issues that were partially resolved, including 101 and 111. In addition, you will notice some significant structural editing, which was discussed at the Dallas face to face meeting. The message elements have also been renumbered. As of today, there are only 45 remaining issues open. =20 The goal of the team is to close as many issues as possible and submit the -02 draft a few days prior to the June deadline. =20 =20 Thanks, Dorothy, Mike and Pat _________________________________________________________________ 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 May 10 09:41:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdowi-0007hT-MK for capwap-archive@lists.ietf.org; Wed, 10 May 2006 09:41:44 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdowg-0006HR-7q for capwap-archive@lists.ietf.org; Wed, 10 May 2006 09:41:44 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 180314300D2 for ; Wed, 10 May 2006 06:41:39 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id BA56F430059 for ; Wed, 10 May 2006 06:41:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 75A7D430FE2 for ; Wed, 10 May 2006 06:41:16 -0700 (PDT) X-Greylist-Status: Sender first seen 00:10:41 ago Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by hermes.tigertech.net (Postfix) with ESMTP id 8B69F431032 for ; Wed, 10 May 2006 06:41:13 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by test-iport-3.cisco.com with ESMTP; 10 May 2006 06:30:30 -0700 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 k4ADUUUV005599; Wed, 10 May 2006 06:30:30 -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 k4ADUUB7028729; Wed, 10 May 2006 06:30:30 -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, 10 May 2006 06:30:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: [Capwap] to mux or not to mux? Date: Wed, 10 May 2006 06:30:29 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201D83986@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Capwap] to mux or not to mux? Thread-Index: AcZzrRqNjX2wvPEhTO6cP8q77nz2iAAiKFRA From: "Pat Calhoun (pacalhou)" To: "Scott G. Kelly" , "capwap" X-OriginalArrivalTime: 10 May 2006 13:30:30.0715 (UTC) FILETIME=[E85D38B0:01C67435] DKIM-Signature: a=rsa-sha1; q=dns; l=990; t=1147267830; x=1148131830; c=relaxed/simple; s=sjdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pcalhoun@cisco.com; z=From:=22Pat=20Calhoun=20\(pacalhou\)=22=20 |Subject:RE=3A=20RE=3A=20[Capwap]=20to=20mux=20or=20not=20to=20mux?; X=v=3Dcisco.com=3B=20h=3DZwZzn8+k4xCV+UpLpycQjOucbp8=3D; b=HAKofJMdiU+1bL4UycS53Mc3QAYaC2Vr5rZfju+aul4+ATMcqO3RQKrVe/gpMSm4zR2wqFv0 hJZm5b8C6agJitGCp9ba8IazxUZpea9TCfC+n8T8eq49F1BXGZDFLqMY; 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=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: *** Cc: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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: 1.8 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com]=20 > >Currently deployed Internet gear uses these standardized=20 > techniques to implement QoS, and we've heard no compelling=20 > arguments as to why these standards are insufficient for our purposes. I disagree with your assessment, and don't believe we have rough consensus.=20 A packet is received by the AP. The AP will have to mark the outer header to replicate the inner header. The AP doesn't have all of the complex QoS policies that are required to determine how to deal with the packet - so the best it can do is replication. The edge device will have to police, and optionally remark. It may have a separate set of policies for data vs. control, because the admin knows that control is more important. I honestly don't see how the edge device does this job without knowing the difference between a data packet and a control packet. 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 lujayweath@hpcs.de Wed May 10 10:05:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdpJd-00006l-V4 for capwap-archive@ietf.org; Wed, 10 May 2006 10:05:25 -0400 Received: from [82.159.51.113] (helo=hpcs.de) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FdpJc-0007BX-5d for capwap-archive@ietf.org; Wed, 10 May 2006 10:05:25 -0400 Message-ID: <000001c6743a$c0a21250$4ba0a8c0@zcl34> Reply-To: "Lujayn Weatherall" From: "Lujayn Weatherall" To: capwap-archive@ietf.org Subject: Re: the AMBltEN Date: Wed, 10 May 2006 07:05:11 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C67400.14433A50" 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: 2.0 (++) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C67400.14433A50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0002_01C67400.14433A50" ------=_NextPart_001_0002_01C67400.14433A50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable web site =20 =20 =20 =20 =20 Bilbo Baggins was grown up, being about fifty years old or so, and living in the beautiful hobbit-hole built by his father, which I have just described for you, until he had in fact apparently settled down immovably. By some curious chance one morning long ago in the quiet of the world, when there was less noise and more green, and the hobbits were still numerous and prosperous, and Bilbo Baggins was standing at his door after breakfast smoking an enormous long wooden pipe that reached nearly down to his woolly toes (neatly brushed) =13 Gandalf came by. Gandalf! If you had heard only a quarter of what I have heard about him, and I have only heard very little of all there is to hear, you would be prepared for any sort I of remarkable tale. Tales and adventures sprouted up all over the place wherever he went, in the most ------=_NextPart_001_0002_01C67400.14433A50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
 
 
 
Bilbo Baggins was grown up, being about fifty years old or so, = and
living in the beautiful hobbit-hole built by his father, which I = have
just described for you, until he had in fact apparently settled down
immovably.
By some curious chance one morning long ago in the quiet of the
world, when there was less noise and more green, and the hobbits = were
still numerous and prosperous, and Bilbo Baggins was standing at his
door after breakfast smoking an enormous long wooden pipe that = reached
nearly down to his woolly toes (neatly brushed) =80=93 Gandalf came = by.
Gandalf! If you had heard only a quarter of what I have heard about = him,
and I have only heard very little of all there is to hear, you would = be
prepared for any sort I of remarkable tale. Tales and adventures
sprouted up all over the place wherever he went, in the = most
------=_NextPart_001_0002_01C67400.14433A50-- ------=_NextPart_000_0001_01C67400.14433A50 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <000101c6743a$c098a634$4ba0a8c0@zcl34> R0lGODdh0QDOAMIAAAAAAAAAAP///wAA//8AAK2llAAAAAAAACwAAAAA0QDOAAAD/ii63O7lQUnr ilZiurP/YNh0YmmeKEheacspqyvPZ0zfMmnj7u75FiBvSJwUH8KjKPlTOZUCJnR6FEpRV+qLgcli n9rwzCvOfaPcNBRILqPdxXYVzjKH5CP6tlfx4vt6eYAZfy2FgXp+iIuMPIdGjI+QiXyNlpeSk3Z3 mpc4mTWeSj4xG6CiVFmnGlqrhnVnqLKLf3KuhJyFt4KUs5BSu3TBvr2IoIfDxMKsvJ6lb8rRSEvS 1WKnyQ4BxTTZJwHbEgGm2uHjYCng6g/gFurt7OF7JUze7ufxFfDwVOAF7+X0vWtHgh8uayUMLlAY 0J6AddvWKQAojp/EiRIdtmry/lDeG4IUGHLqFPBhuYslF8obaELjIBkoO66k2BGjSgb7IkqkKTBi QHwfQLYTCeuDSxxAbcpkWbOp06YDhzK9R/RpBoZVmUFzREdhTpzmwt4cu7Osx6JRpoKdlnLtvCFd LFk8i/GrU4N2ler1wHOvwIocD36CgRZdyJlgmebl90/sWL/uZDbIiqFqVoQz5qokaFczWY946erz e9nq5G3BjtaQ6lbpYtCO91KGSppuh8ulMbvg3LqsXrOyYV8d2jGu6dZqIF9rpvVIzKidZ0YNjvyw 2tp1p5/uVuZWY23fIVaGzfqpwX9B+2Jfev24KGzey4g2xla3fS7zg9AyzN3N/opMqhET4EiWDLiR LB1EgIeB1AhGID3yeZVbJS/dN0dzFVK1WWAQjsKch8tN4VmIFvInYF3FveVgMQWwsQlhJWZ3llpS SehbdSrGaB9K0OEDXYvs3eheYWroUqI9PAo3EXqSmYfYhJgB418LMS303V5MJiYdlPbZcAWDa4U2 VWib8VSlM5E0SAREOb3mFkViYkigcSmQI2d3GbbUpGRZNnWla0qyp+OgfM2o04bU3aXZbAf2R+ie MmrnZKRu5gnjfh9OEcw6BU0npKI1SmgiEUASiSdXK+qH5g1gWmjkMo+Gklyso9KK6WAvmprmpXde yOGRXLXKqq3sIFSLpUNY/nZmpnD1pd5JdD0b5Q5ZKAvSVmJAV2ZWkgaJLbEseCkSl3qCAJFk/qC4 AnBNLgvGMFJ+Ixq5s2ZmznaP4QsojuCmZ+ih255WXnmC1otifpBaFw/CuhpljahQaUtpWOFJPMF4 REmrJbSNOgIKxHlFLB2KiQ6XrsBEYWxjaXaqauFc43FsVcgbm7tslevCcxu9/f6GWF2NxQaD0Ev9 SZgNOs03YcYM9wyYz0NHh6+YMZvrV9XDPd3rgg5TWN9PSpI5s9Bi/2VSTRDra5NCfQ47RhxIA7wv yRepE0HZ7m6Y9J5n1l0jomr22rHLJ40QlqQ9BtetdQDd3e1cYy7udAjP/qG2FN9s2rQBQHkHrKWh m7+zc+ffTp5s09+YHqvjiZXbDOokBm66P+2hIuzstXeILK/KwKv62zqWqkWP1J76e4Hbatz1sP8x uzqu9whsfMOwHm8az1/HDv2v7wnSaUNyRz6d41UqH8vghGKVdJu0Zxd0kGKiVM+DzuuOPJX/Yj6y 9Hjv0zZc4IpX6RamnbIpLlp+09SuWJQQixmwJuQjD02wR6ocuc0XyqpOm0YnFtYtsBoAIlIG84W2 a5WMgt1QhfXcYzS/NW475EMU6ewHB1JIQyQeTN76WJI4lTHmFbzLngJ3F7sRfm5ihxtHki5zlNuh aoWCm14Y6FSrKUIx/hXVi0KAyPAMJ8RLgKqTRBucGA0uEu6KsnJdFivhpTV2r4pIkUfLBqi256Xx ZQxjQrpQSEM1otFsN+DjGqh3QWMZzV4kqWAf75MgRFbkUxDc4dq2BDshAvCP7vHH+0QVqiTucIZQ fIQiSEiyiH1GcSoJHSaXZzA48ouTlpMa1lBmPW/oYlyJ80zIVnYRMrJyForApcQItks5wsk2J0rk G22Ws8MoqmSTWuWUgkgYYSLqfZ/pQv8qacFUcY8ZvhRB4uDXugskUSkRFF03n7g9BFGFdpSU3mMg yTlB/vINqfHmB6n5Ehsqkz6MJOQ6bxW8BuXzjoQbpTS5sVB90k92/m68IT2+5NArTuWQ+dAcClgS Om4pUTGLs4UfF/lPfqJsgk0bkQkcmLuiHbOljlKkSXeTlM7tzF4+YdPhrKacOICInZAB5ZDEeS/k LG2nNRyoMcZ1wJ+BKjfnMsLJotfThmbUmfCLDfvMd7l4/I9XfwqVJXP1MIb5L3Q5LGahysfV+HF1 lbhBYE6qJlRaIiGuOMlSXaGIV4wETavxpFzCSGnOlJ6FjAOaapgo5hiVdjUoerkpVgFp1TqaMpon s6bZxMK2wwJuPdrzWiu9ucS5tQsxLTQrccSzv6sCLiPAQugjx6QybAIFcm1F3OMChR+YztSV9yOg ocqELtTKyF+8/lQb0/ZqGBX+Fq4ldecZiXWsYlUWuIUc1BwrOt2fAi+0Cr3uQ4Eo0FX1TEHPxaJs 89RF6Y51FpK7RiNdFcXuishiETVWTLsSJ1+JVxTqs+p8xyvTOL7zSWb5lz1XGZ+FzTbBFXupb79L qwHXNzA0gtxp2wRNpzXPRRdWAki3Y0D1LbgPuzgoMTK3WKN29K1SHG2/OtVMWMIgtdmpalEc0rxp LiImFSMxb5n0wPRe91Ua0puGSwzY/ISTlU9e6TjJCcEciuw6UY6RJBYXOaNuabAybvB/WRXCAvv0 xgYaY3Tb6SsrlJeO5H0vWeu04zH/0blWjK2dKwxn9CVZxtBg/trbkPxNNDKXsE8ZUIqVamaaHjpF GgBjobM7yPqFgWBOOHGe5/zmpK4Vc11F6WPdehMY9y59TtVWAYdJya2CMst9vmGq2Ue3Je/Ug+za 53ld+ymx2Xhs0Qwgo0NsX+JBk2YDy6VH/gHrWKu3kD0im+UuW+pw/LWe/JrfsPO7ZhrgMi2qPGWY ZunlZFKY299mcilZ7EIch9LS9qVcfswUNlbrsMN0thUw5GAtJeF6ffnqMqLRuF23lXlyqlFzKLJs xj13Or+tanYZiTjpOMN7mdBABsVPXVACc9yVVMw37yS+cYg6j+QkXe/FK67vIFZ35dsuuDVQjl2M E9sXbfS0jMOpC9CV05y7prNlzXXjTz33QNvn3rmwnS2NNMc7EE8u3tMxYfFGCM+7Ilf6mENOKEIv 1MLPZqjXAS1nI/u321pPe5d0PvOem9yOQD+eSN0LRKHHfaScrjSb1X73s28a62bH58fRoGj6drzl UWpGy2QO9TP7vVxcgzul/SxgXWd9ShrXu9Enfikx6yEBADs= ------=_NextPart_000_0001_01C67400.14433A50-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 10 15:38:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FduVZ-0004fC-HO for capwap-archive@lists.ietf.org; Wed, 10 May 2006 15:38:05 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FduVX-0005OT-1p for capwap-archive@lists.ietf.org; Wed, 10 May 2006 15:38:05 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6B9C04300F8 for ; Wed, 10 May 2006 12:37:53 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1F195430059 for ; Wed, 10 May 2006 12:37:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 715EE1448010 for ; Wed, 10 May 2006 12:37:33 -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 11DB91448002 for ; Wed, 10 May 2006 12:37:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=QIDSCNeUfLhCGVycI42dtib/EI5ZIQ0qrmAVn9OHSU6X/wS1OrUWsejYrMG8+xZt; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; 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 1FduUz-0005sT-DI; Wed, 10 May 2006 15:37:29 -0400 Received: from 72.115.85.42 by webmail.pas.earthlink.net with HTTP; Wed, 10 May 2006 15:37:29 -0400 Message-ID: <11815019.1147289849339.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Date: Wed, 10 May 2006 15:37:29 -0400 (EDT) From: "Scott G. Kelly" To: "Pat Calhoun (pacalhou)" , capwap Subject: RE: RE: [Capwap] to mux or not to mux? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710d9e11cae177c7715bf9e1c5c57288aa3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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: Cc: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hi Pat, >> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >> >Currently deployed Internet gear uses these standardized >> techniques to implement QoS, and we've heard no compelling >> arguments as to why these standards are insufficient for our purposes. > >I disagree with your assessment, and don't believe we have rough >consensus. > >A packet is received by the AP. The AP will have to mark the outer >header to replicate the inner header. The AP doesn't have all of the >complex QoS policies that are required to determine how to deal with the >packet - so the best it can do is replication. The edge device will have >to police, and optionally remark. It may have a separate set of policies >for data vs. control, because the admin knows that control is more >important. > >I honestly don't see how the edge device does this job without knowing >the difference between a data packet and a control packet. Actually, I don't agree that the WTP can't enforce QoS policies - that's an implementation choice, but it's also beside the point. Your earlier arguments seemed to indicate that intermediate devices need the UDP header to apply some sort of "QoS ACLs". We saw in discussion on this list that this is not the case. This current comment suggests that some "edge device" may need to re-mark packets. Since these packets are tunneled to the AC, the AC must be the edge device we're talking about here, and if this is true, I'm not understanding is why the AC can't look at a mux header to make the decision. Modern NPUs can easily scan 64 bytes into the packet, and many can go as far as you like. Are you saying your hardware has some limitation which precludes this? 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 May 10 15:38:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FduWC-0004ha-A2 for capwap-archive@lists.ietf.org; Wed, 10 May 2006 15:38:44 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FduWB-0005P3-Sl for capwap-archive@lists.ietf.org; Wed, 10 May 2006 15:38:44 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BA513430126 for ; Wed, 10 May 2006 12:38:42 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id EE5A9430137 for ; Wed, 10 May 2006 12:37:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 26C391448004 for ; Wed, 10 May 2006 12:37:54 -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 DDFD71448002 for ; Wed, 10 May 2006 12:37:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=H3LvC9M/BZRf6Nom2deh9Vfxp6I0opfhM+AAZSKb14OcvnMw2xXpEJDP9frrTUsQ; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; 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 1FduVL-0006JK-0H; Wed, 10 May 2006 15:37:51 -0400 Received: from 72.115.85.42 by webmail.pas.earthlink.net with HTTP; Wed, 10 May 2006 15:37:50 -0400 Message-ID: <6674058.1147289870919.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Date: Wed, 10 May 2006 15:37:50 -0400 (EDT) From: "Scott G. Kelly" To: "Pat Calhoun (pacalhou)" , capwap Subject: RE: RE: [Capwap] to mux or not to mux? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff7102b50d7fa6660b10dca0c9065f805d524350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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: Cc: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hi Pat, >> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >> >Currently deployed Internet gear uses these standardized >> techniques to implement QoS, and we've heard no compelling >> arguments as to why these standards are insufficient for our purposes. > >I disagree with your assessment, and don't believe we have rough >consensus. > >A packet is received by the AP. The AP will have to mark the outer >header to replicate the inner header. The AP doesn't have all of the >complex QoS policies that are required to determine how to deal with the >packet - so the best it can do is replication. The edge device will have >to police, and optionally remark. It may have a separate set of policies >for data vs. control, because the admin knows that control is more >important. > >I honestly don't see how the edge device does this job without knowing >the difference between a data packet and a control packet. Actually, I don't agree that the WTP can't enforce QoS policies - that's an implementation choice, but it's also beside the point. Your earlier arguments seemed to indicate that intermediate devices need the UDP header to apply some sort of "QoS ACLs". We saw in discussion on this list that this is not the case. This current comment suggests that some "edge device" may need to re-mark packets. Since these packets are tunneled to the AC, the AC must be the edge device we're talking about here, and if this is true, I'm not understanding is why the AC can't look at a mux header to make the decision. Modern NPUs can easily scan 64 bytes into the packet, and many can go as far as you like. Are you saying your hardware has some limitation which precludes this? 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 May 10 15:54:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdul5-0003vu-3O for capwap-archive@lists.ietf.org; Wed, 10 May 2006 15:54:07 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdul3-00067z-JR for capwap-archive@lists.ietf.org; Wed, 10 May 2006 15:54:07 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3D1A54300E0 for ; Wed, 10 May 2006 12:54:05 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B5B32430059 for ; Wed, 10 May 2006 12:53:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A588C1448010 for ; Wed, 10 May 2006 12:53:41 -0700 (PDT) Received: from mgw-ext11.nokia.com (mgw-ext11.nokia.com [131.228.20.170]) by hermes.tigertech.net (Postfix) with ESMTP id 5F9501448004 for ; Wed, 10 May 2006 12:53:37 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4AJoPDD023591; Wed, 10 May 2006 22:50:25 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 May 2006 22:50:25 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 May 2006 14:50:22 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: [Capwap] to mux or not to mux? Date: Wed, 10 May 2006 12:50:20 -0700 Message-ID: <8A76136424391244A5CF016533708537018B48CA@mvebe101.NOE.Nokia.com> In-Reply-To: <6674058.1147289870919.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Capwap] to mux or not to mux? Thread-Index: AcZ0aWKahPNUUwuCSkyCDig6i2rFKwAALDOw From: To: , , X-OriginalArrivalTime: 10 May 2006 19:50:22.0197 (UTC) FILETIME=[F9256250:01C6746A] 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.2 tagged_above=-999.0 required=7.0 tests=NO_REAL_NAME X-Spam-Level: Cc: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.2 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Colleagues, It seems we are wanting to take QoS seriously ;^) Several issues to consider: 1) The QoS of the STA's packet should influence the QoS of the packet encapsulating it 2) Any device in the path that is honoring QoS marks (as opposed to ignoring them) or performing remarking is effectively enforcing a security policy and a QoS policy 3) In some media, there might not be a one to one correspondence between CAPWAP packets and mobile node packets, correct? If so, and we assign different QoS to the encapsulating packet than is assigned to the packet(s) within, we may cause ordering problems. Best Regards, Michael -----Original Message----- From: ext Scott G. Kelly [mailto:s.kelly@ix.netcom.com]=20 Sent: Wednesday, May 10, 2006 12:38 PM To: Pat Calhoun (pacalhou); capwap Subject: RE: RE: [Capwap] to mux or not to mux? Hi Pat, >> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >> >Currently deployed Internet gear uses these standardized >> techniques to implement QoS, and we've heard no compelling arguments=20 >> as to why these standards are insufficient for our purposes. > >I disagree with your assessment, and don't believe we have rough=20 >consensus. > >A packet is received by the AP. The AP will have to mark the outer=20 >header to replicate the inner header. The AP doesn't have all of the=20 >complex QoS policies that are required to determine how to deal with=20 >the packet - so the best it can do is replication. The edge device will >have to police, and optionally remark. It may have a separate set of=20 >policies for data vs. control, because the admin knows that control is=20 >more important. > >I honestly don't see how the edge device does this job without knowing=20 >the difference between a data packet and a control packet. Actually, I don't agree that the WTP can't enforce QoS policies - that's an implementation choice, but it's also beside the point. Your earlier arguments seemed to indicate that intermediate devices need the UDP header to apply some sort of "QoS ACLs". We saw in discussion on this list that this is not the case.=20 This current comment suggests that some "edge device" may need to re-mark packets. Since these packets are tunneled to the AC, the AC must be the edge device we're talking about here, and if this is true, I'm not understanding is why the AC can't look at a mux header to make the decision. Modern NPUs can easily scan 64 bytes into the packet, and many can go as far as you like. Are you saying your hardware has some limitation which precludes this? 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 Wed May 10 17:11:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdvxs-0005nw-So for capwap-archive@lists.ietf.org; Wed, 10 May 2006 17:11:24 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdvxr-0001X2-CB for capwap-archive@lists.ietf.org; Wed, 10 May 2006 17:11:24 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 51BBD4300D0 for ; Wed, 10 May 2006 14:11:22 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4E357430059 for ; Wed, 10 May 2006 14:10:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3F23739801A for ; Wed, 10 May 2006 14:10:58 -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 1DFAD398015 for ; Wed, 10 May 2006 14:10:54 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 10 May 2006 14:10:54 -0700 X-IronPort-AV: i="4.05,111,1146466800"; d="scan'208"; a="274737706:sNHT39809368" 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 k4ALAsjT004697 for ; Wed, 10 May 2006 14:10: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 k4ALAsB9018332 for ; Wed, 10 May 2006 14:10: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, 10 May 2006 14:10:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: [Capwap] to mux or not to mux? Date: Wed, 10 May 2006 14:10:57 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC01800B08@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Capwap] to mux or not to mux? Thread-Index: AcZ0aVQ+rYfKdTRrQC+DhtfSayegbAAC5WJQ From: "Bob O'Hara (boohara)" To: "capwap" X-OriginalArrivalTime: 10 May 2006 21:10:54.0061 (UTC) FILETIME=[392951D0:01C67476] DKIM-Signature: a=rsa-sha1; q=dns; l=3281; t=1147295454; x=1148159454; c=relaxed/simple; s=sjdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=boohara@cisco.com; z=From:=22Bob=20O'Hara=20\(boohara\)=22=20 |Subject:RE=3A=20RE=3A=20[Capwap]=20to=20mux=20or=20not=20to=20mux?; X=v=3Dcisco.com=3B=20h=3DQ4PJ/H8eC3vQYMWtiBURpDOoxfE=3D; b=VYGQbySFGgPaMDvffG1YANuoc/OtMVz1Tnfz0m2Lsi7h4z57udb7huvoPVHLTDG7/CEvRQxb brjgxafh4LYjrax1uiimHoGRzvM+KAMSrBesyuOnzNNiQVxNtvM0jett; 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: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 The issue is that the AC is not generally the edge device, i.e., the first device that encounters a packet sent from the WTP. We are not mandating (and, in fact, cannot mandate) that the AC live in the wiring closet and connect directly to the WTPs. Therefore, the packets from the WTPs pass through an arbitrary number of layer 2 and layer 3 devices before arriving at the AC. =20 It is at one or more, possibly every one, of these existing intermediate devices that the QoS ACLs are currently applied. By hiding the distinction between data and control inside the mux header, we immediately prevent all of those existing devices from applying QoS to the CAPWAP protocol control and data transmissions, differentially. =20 As has been pointed out in previous postings, there are valid reasons for desiring to apply this differential QoS to control and data. The mux header prevents this and therefore is not a viable solution for CAPWAP. If we persist on this path, we will wind up with a protocol that will find little acceptance. -Bob =20 -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com]=20 Sent: Wednesday, May 10, 2006 12:38 PM To: Pat Calhoun (pacalhou); capwap Subject: RE: RE: [Capwap] to mux or not to mux? Hi Pat, >> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com]=20 >> >Currently deployed Internet gear uses these standardized=20 >> techniques to implement QoS, and we've heard no compelling=20 >> arguments as to why these standards are insufficient for our purposes. > >I disagree with your assessment, and don't believe we have rough >consensus.=20 > >A packet is received by the AP. The AP will have to mark the outer >header to replicate the inner header. The AP doesn't have all of the >complex QoS policies that are required to determine how to deal with the >packet - so the best it can do is replication. The edge device will have >to police, and optionally remark. It may have a separate set of policies >for data vs. control, because the admin knows that control is more >important. > >I honestly don't see how the edge device does this job without knowing >the difference between a data packet and a control packet. Actually, I don't agree that the WTP can't enforce QoS policies - that's an implementation choice, but it's also beside the point. Your earlier arguments seemed to indicate that intermediate devices need the UDP header to apply some sort of "QoS ACLs". We saw in discussion on this list that this is not the case.=20 This current comment suggests that some "edge device" may need to re-mark packets. Since these packets are tunneled to the AC, the AC must be the edge device we're talking about here, and if this is true, I'm not understanding is why the AC can't look at a mux header to make the decision. Modern NPUs can easily scan 64 bytes into the packet, and many can go as far as you like. Are you saying your hardware has some limitation which precludes this? 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 Wed May 10 20:09:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdyjx-0003Tk-KI for capwap-archive@lists.ietf.org; Wed, 10 May 2006 20:09:13 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdyju-0000mM-Mz for capwap-archive@lists.ietf.org; Wed, 10 May 2006 20:09:13 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A29954300ED for ; Wed, 10 May 2006 17:09:01 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id C1C58430096 for ; Wed, 10 May 2006 17:08:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A0541398012 for ; Wed, 10 May 2006 17:08:29 -0700 (PDT) Received: from mail.u4eatech.com (blackhole.u4eatech.com [195.188.241.2]) by zoidberg.tigertech.net (Postfix) with ESMTP id E72E3398021 for ; Wed, 10 May 2006 17:08:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.u4eatech.com (Postfix) with ESMTP id 1956F360970; Thu, 11 May 2006 00:47:21 +0100 (BST) Received: FROM mail.u4eatech.com ([127.0.0.1]) BY localhost WITH ESMTP ; Thu, 11 May 2006 00:47:21 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.u4eatech.com (Postfix) with ESMTP id E3364360964; Thu, 11 May 2006 00:47:20 +0100 (BST) Received: from mail.u4eatech.com ([127.0.0.1]) by localhost (mail.u4eatech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25948-20; Thu, 11 May 2006 00:47:16 +0100 (BST) Received: from [192.168.1.69] (unknown [61.173.134.98]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.u4eatech.com (Postfix) with ESMTP id 5D2CD36095B; Thu, 11 May 2006 00:47:13 +0100 (BST) In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC01800B08@xmb-sjc-237.amer.cisco.com> References: <17B8C6DE4E228348B4939BDA6B05A9DC01800B08@xmb-sjc-237.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v749.3) Message-Id: <4736A2EE-56B6-4FE1-86BE-9B4290F6E7F8@u4eatech.com> From: Philip Rakity Subject: Re: [Capwap] to mux or not to mux? Date: Wed, 10 May 2006 17:07:56 -0700 To: Bob O'Hara (boohara) X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: amavisd-new at u4eatech.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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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="===============2045243466==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 --===============2045243466== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-17--652331133; protocol="application/pkcs7-signature" --Apple-Mail-17--652331133 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Bob, Good summary. One point I am a little confused about is how NAT is handled when we use different ports etc. I would have thought that the devices a long the way would need to be changed to handle this. Another ALG. Did I miss understand something? regards, Philip On May 10, 2006, at 2:10 PM, Bob O'Hara (boohara) wrote: > > > The issue is that the AC is not generally the edge device, i.e., the > first device that encounters a packet sent from the WTP. We are not > mandating (and, in fact, cannot mandate) that the AC live in the > wiring > closet and connect directly to the WTPs. Therefore, the packets from > the WTPs pass through an arbitrary number of layer 2 and layer 3 > devices > before arriving at the AC. > > It is at one or more, possibly every one, of these existing > intermediate > devices that the QoS ACLs are currently applied. By hiding the > distinction between data and control inside the mux header, we > immediately prevent all of those existing devices from applying QoS to > the CAPWAP protocol control and data transmissions, differentially. > > As has been pointed out in previous postings, there are valid reasons > for desiring to apply this differential QoS to control and data. The > mux header prevents this and therefore is not a viable solution for > CAPWAP. If we persist on this path, we will wind up with a protocol > that will find little acceptance. > > -Bob > > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > Sent: Wednesday, May 10, 2006 12:38 PM > To: Pat Calhoun (pacalhou); capwap > Subject: RE: RE: [Capwap] to mux or not to mux? > > Hi Pat, > >>> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >>>> Currently deployed Internet gear uses these standardized >>> techniques to implement QoS, and we've heard no compelling >>> arguments as to why these standards are insufficient for our > purposes. >> >> I disagree with your assessment, and don't believe we have rough >> consensus. >> >> A packet is received by the AP. The AP will have to mark the outer >> header to replicate the inner header. The AP doesn't have all of the >> complex QoS policies that are required to determine how to deal with > the >> packet - so the best it can do is replication. The edge device will > have >> to police, and optionally remark. It may have a separate set of > policies >> for data vs. control, because the admin knows that control is more >> important. >> >> I honestly don't see how the edge device does this job without >> knowing >> the difference between a data packet and a control packet. > > Actually, I don't agree that the WTP can't enforce QoS policies - > that's > an implementation choice, but it's also beside the point. > > Your earlier arguments seemed to indicate that intermediate devices > need > the UDP header to apply some sort of "QoS ACLs". We saw in > discussion on > this list that this is not the case. > > This current comment suggests that some "edge device" may need to > re-mark packets. Since these packets are tunneled to the AC, the AC > must be the edge device we're talking about here, and if this is true, > I'm not understanding is why the AC can't look at a mux header to make > the decision. Modern NPUs can easily scan 64 bytes into the packet, > and > many can go as far as you like. > > Are you saying your hardware has some limitation which precludes this? > > 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 > Philip Rakity prakity@u4eatech.com This message is hereby marked U4EA CONFIDENTIAL, is intended only for the use of the individual or individuals to which it is addressed and shall notbe disclose or made available to any other party except with the prior written consent of the sender. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender of this E-Mail. --Apple-Mail-17--652331133 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDrjCCA6ow ggMToAMCAQICASUwDQYJKoZIhvcNAQEEBQAwfzEiMCAGA1UEAxMZZmx5aW5nbW9ua2V5LnU0ZWF0 ZWNoLmNvbTEaMBgGA1UEChMRVTRFQSBUZWNobm9sb2dpZXMxHjAcBgkqhkiG9w0BCQEWD2l0QHU0 ZWF0ZWNoLmNvbTELMAkGA1UEBhMCVUsxEDAOBgNVBAcTB0JyaXN0b2wwHhcNMDYwNDA1MDkyMjEz WhcNMDcwNDA1MDkyMjEzWjB+MQswCQYDVQQGEwJVSzEQMA4GA1UEBxMHQnJpc3RvbDEaMBgGA1UE ChMRVTRFQSBUZWNobm9sb2dpZXMxFjAUBgNVBAMTDVBoaWxpcCBSYWtpdHkxKTAnBgkqhkiG9w0B CQEWGnBoaWxpcC5yYWtpdHlAdTRlYXRlY2guY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDQqH0Lm5zoXgKWrNJPMAz+nMbEHTt2d55kT/NeZqdXZdywassH//vkdDH1CAZk+JNfG6IshRSr qDnqDAArwL8SOLpeJ2oF7YL37qwpA9c3y56Z2ZHjzGzBdX8demzNsEG3nEFTBS1ARyCQAfopCImz TrYPfa6taYdEF/Mj4CTXBwIDAQABo4IBNTCCATEwCQYDVR0TBAIwADAsBglghkgBhvhCAQ0EHxYd T3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFJCsX1sNMwH6ufp/ILfRKmb+ 6JJMMIGzBgNVHSMEgaswgaiAFPGFe7eBejo0WsmvQrqEg8SqkA3VoYGEpIGBMH8xIjAgBgNVBAMT GWZseWluZ21vbmtleS51NGVhdGVjaC5jb20xGjAYBgNVBAoTEVU0RUEgVGVjaG5vbG9naWVzMR4w HAYJKoZIhvcNAQkBFg9pdEB1NGVhdGVjaC5jb20xCzAJBgNVBAYTAlVLMRAwDgYDVQQHEwdCcmlz dG9sggkAmTQcGtijWKcwIQYDVR0RBBowGIIWYmxhY2tob2xlQHU0ZWF0ZWNoLmNvbTANBgkqhkiG 9w0BAQQFAAOBgQCUG90QVWCMOOheb3O77NopRh8Iy9FN9R81+N3MzqpaLM090eoLSUsrIhyw9/Tp ExGHM7FBBTntfO4S8+qnpC1EOQA7YCilwT7+paHXObZDoID2m9piVBdTm+16xwshUshrGya5eGUz TEoo7vpWkZJfSJ/6Kjc0K01NOqUQjM5bFDGCAr4wggK6AgEBMIGEMH8xIjAgBgNVBAMTGWZseWlu Z21vbmtleS51NGVhdGVjaC5jb20xGjAYBgNVBAoTEVU0RUEgVGVjaG5vbG9naWVzMR4wHAYJKoZI hvcNAQkBFg9pdEB1NGVhdGVjaC5jb20xCzAJBgNVBAYTAlVLMRAwDgYDVQQHEwdCcmlzdG9sAgEl MAkGBSsOAwIaBQCgggGPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA2MDUxMTAwMDc1N1owIwYJKoZIhvcNAQkEMRYEFNQbqPwL4M/e0oxwWohEy1PC90jBMIGVBgkr BgEEAYI3EAQxgYcwgYQwfzEiMCAGA1UEAxMZZmx5aW5nbW9ua2V5LnU0ZWF0ZWNoLmNvbTEaMBgG A1UEChMRVTRFQSBUZWNobm9sb2dpZXMxHjAcBgkqhkiG9w0BCQEWD2l0QHU0ZWF0ZWNoLmNvbTEL MAkGA1UEBhMCVUsxEDAOBgNVBAcTB0JyaXN0b2wCASUwgZcGCyqGSIb3DQEJEAILMYGHoIGEMH8x IjAgBgNVBAMTGWZseWluZ21vbmtleS51NGVhdGVjaC5jb20xGjAYBgNVBAoTEVU0RUEgVGVjaG5v bG9naWVzMR4wHAYJKoZIhvcNAQkBFg9pdEB1NGVhdGVjaC5jb20xCzAJBgNVBAYTAlVLMRAwDgYD VQQHEwdCcmlzdG9sAgElMA0GCSqGSIb3DQEBAQUABIGAXqUNP8821K/Jk+dWi+qOR2WCSdwWpxp2 r+WuDxipYEvIf+jF3wpdfKwlvCQDjoXQDTTb2coOBP7zr09Jo6pMg/e9P0UV8AflsfUXVrlsWEum WHBAZakP+NajKV9qVCLNu+SKdEOGLErhMs+TPnSBuwwGguxp/tokcEFssY/iTTgAAAAAAAA= --Apple-Mail-17--652331133-- --===============2045243466== 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 --===============2045243466==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 10 20:29:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdz43-0006n8-KQ for capwap-archive@lists.ietf.org; Wed, 10 May 2006 20:29:59 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdz42-0001L7-6d for capwap-archive@lists.ietf.org; Wed, 10 May 2006 20:29:59 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CDEB34300E8 for ; Wed, 10 May 2006 17:29:57 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 28068430096 for ; Wed, 10 May 2006 17:29:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1968C144800D for ; Wed, 10 May 2006 17:29:38 -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 798931448002 for ; Wed, 10 May 2006 17:29:35 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 10 May 2006 17:29:35 -0700 X-IronPort-AV: i="4.05,111,1146466800"; d="scan'208"; a="274833310:sNHT31429568" 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 k4B0TZd5007370; Wed, 10 May 2006 17:29:35 -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 k4B0TZB7025596; Wed, 10 May 2006 17:29: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, 10 May 2006 17:29:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] some questions Date: Wed, 10 May 2006 17:29:34 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201DF4920@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] some questions Thread-Index: AcZzpwh0u0I1NNP8R4W4pb2TbUnFWAA6k9PwAAAmu8A= From: "Pat Calhoun (pacalhou)" To: "capwap" , "Annarita Levanti" X-OriginalArrivalTime: 11 May 2006 00:29:34.0920 (UTC) FILETIME=[FA8C0C80:01C67491] DKIM-Signature: a=rsa-sha1; q=dns; l=976; t=1147307375; x=1148171375; c=relaxed/simple; s=sjdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pcalhoun@cisco.com; z=From:=22Pat=20Calhoun=20\(pacalhou\)=22=20 |Subject:RE=3A=20[Capwap]=20some=20questions; X=v=3Dcisco.com=3B=20h=3DNLWG/I7cVzmNPjQyKDNAJppjbhA=3D; b=KNjSd08/qMUYbjXWV9GmyQN5L6nDVQF9mR6ezDU49wDbUKU6mqCJDN9u4ZzEgGFd/oVegEpR H3De8x2v5cRb6d2mzjlt+Pp1Jv1NM2tOI0QT98UdzovHGdCL3LknngPX; 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: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 =09 > Reading the new version of capwap, in particular IEEE 802.11 binding I > don't understand what can be considered as > "802.11 Action frame" and, referred to the split mac, if a WTP can=20 > forward to AC also data packets, that is 802.11 payloads of mobile users, or also other 802.11 traffic. An 802.11 action frame is a management frame that is defined in the 802.11 standard. In the split MAC case, the action frames are forwarded to the AC - just like the other management frames. > I think maybe a WTP could forward beacons of others WTP to its AC, in=20 > this way the AC can know which access point are listening from the WTP > and, for example, can assign a different frequency to the WTP in order to reduce interference in the network. Well, one could do this, but I think this could be a tad overwhelming for the AC as beacons are generated every 100ms.=20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 _________________________________________________________________ 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 May 11 06:59:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe8tX-0001fq-5Q for capwap-archive@lists.ietf.org; Thu, 11 May 2006 06:59:47 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe8tU-0002fO-KE for capwap-archive@lists.ietf.org; Thu, 11 May 2006 06:59:47 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6EEA5430113 for ; Thu, 11 May 2006 03:59:33 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 9E5C4430058 for ; Thu, 11 May 2006 03:59:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8C00D398027 for ; Thu, 11 May 2006 03:59:12 -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 6F412398009 for ; Thu, 11 May 2006 03:59:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=RxnYzIggyAg2A2gdQyXQY62VM6ASs5gyDOEKxhePdDTVjK4MmEdFVZj9GBLAWwfM; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.53] (helo=elwamui-wigeon.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Fe8st-0007Eh-UR; Thu, 11 May 2006 06:59:07 -0400 Received: from 72.115.3.63 by webmail.pas.earthlink.net with HTTP; Thu, 11 May 2006 06:59:07 -0400 Message-ID: <30850614.1147345147626.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Date: Thu, 11 May 2006 06:59:07 -0400 (EDT) From: "Scott G. Kelly" To: "Bob O'Hara (boohara)" , capwap Subject: RE: RE: [Capwap] to mux or not to mux? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710d04ff0864ef9aea5ea47f168ad4bddcb350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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: Cc: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Hi Bob, I have some questions which I've inlined below... Bob O'Hara wrote: >The issue is that the AC is not generally the edge device, i.e., the >first device that encounters a packet sent from the WTP. We are not >mandating (and, in fact, cannot mandate) that the AC live in the wiring >closet and connect directly to the WTPs. Therefore, the packets from >the WTPs pass through an arbitrary number of layer 2 and layer 3 devices >before arriving at the AC. > >It is at one or more, possibly every one, of these existing intermediate >devices that the QoS ACLs are currently applied. By hiding the >distinction between data and control inside the mux header, we >immediately prevent all of those existing devices from applying QoS to >the CAPWAP protocol control and data transmissions, differentially. > >As has been pointed out in previous postings, there are valid reasons >for desiring to apply this differential QoS to control and data. The >mux header prevents this and therefore is not a viable solution for >CAPWAP. If we persist on this path, we will wind up with a protocol >that will find little acceptance. It's been suggested that control traffic should in some cases have a higher priority than some other traffic, and I'm not disagreeing with this. Since the AC and/or WTP generate all control traffic, they are at liberty to apply the appropriate QoS markings for achieving this, so I see no problem so far. Also, we seem to allow that data packets flowing between the AC and WTP will have been somehow subjected to the network's QoS policy (and accordingly marked) before beginning traversal of the AC/WTP link. This being the case, I don't see a problem, so maybe I'm missing something here (and if so, maybe you can enlighten me). There seem to be a couple of underlying assertions here: 1) Data traffic traversing the link between the AC and WTP will have QoS markings. That is, either the endpoints or the AC/WTP will apply these markings with the goal of realizing some sort of traffic engineering policy. 2) there will be middleboxes between the AC and WTP that optionally alter QoS markings enroute (this is surprising to me, but let's see where it takes us) 3) for some reason, these middleboxes cannot see anything past the UDP header 4) these middleboxes must distinguish between capwap control and data somehow, i.e. they will remap QoS for data differently than they remap QoS for control traffic Keeping in mind that the AC and WTP can apply whatever markings the administrator deems appropriate for control traffic, there are a few things that confuse me about all of this. First, as a consequence of (3), we must blindly apply a uniform mapping function to all data traffic. That is, since we can't tell anything other than that it is data (since we can't look beyond the udp header), we must do a 1 to 1 mapping from the initial marking value to a new marking value, one which entirely ignores the encapsulated application. This is effectively a reversible coordinate shift, in that we are either promoting or demoting data traffic en masse at any given point in time. Second, in such a universe it is not clear to me why the control traffic (which presumably has been suitably marked by the AC or WTP) would be subject to a different (re)mapping function than the data traffic. If all the traffic must make its way to the AC, and you are blindly remapping data traffic QoS, why would this remapping not also apply (blindly) to control traffic? And if control traffic is not to be remapped, why can't this be accomplished by simply not remapping traffic above a certain prioirity, and setting the control traffic markings accordingly? In any event, if you could explain some of the use cases you envision and show how they would encounter problems, perhaps this would all be more clear. I don't know about anyone else here, but I'm having a really hard time understanding what we are trying to achieve with this selective remapping. 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 May 11 20:35:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeLcx-0004GS-1V for capwap-archive@lists.ietf.org; Thu, 11 May 2006 20:35:31 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeLcu-00079P-Ff for capwap-archive@lists.ietf.org; Thu, 11 May 2006 20:35:31 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5284143009F for ; Thu, 11 May 2006 17:35:17 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 0958E43006D for ; Thu, 11 May 2006 17:34:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E3011144800F for ; Thu, 11 May 2006 17:34:44 -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 791791448008 for ; Thu, 11 May 2006 17:34:41 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 11 May 2006 17:34:41 -0700 X-IronPort-AV: i="4.05,117,1146466800"; d="scan'208"; a="1804824283:sNHT59541928" 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 k4C0YeOY017618 for ; Thu, 11 May 2006 17:34:40 -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 k4C0YdBB012912 for ; Thu, 11 May 2006 17:34:40 -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); Thu, 11 May 2006 17:34:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: [Capwap] to mux or not to mux? Date: Thu, 11 May 2006 17:34:42 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC0185C698@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Capwap] to mux or not to mux? Thread-Index: AcZ0aWKahPNUUwuCSkyCDig6i2rFKwAALDOwADxobEA= From: "Bob O'Hara (boohara)" To: X-OriginalArrivalTime: 12 May 2006 00:34:39.0442 (UTC) FILETIME=[DA782B20:01C6755B] DKIM-Signature: a=rsa-sha1; q=dns; l=3500; t=1147394080; x=1148258080; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=boohara@cisco.com; z=From:=22Bob=20O'Hara=20\(boohara\)=22=20 |Subject:RE=3A=20RE=3A=20[Capwap]=20to=20mux=20or=20not=20to=20mux?; X=v=3Dcisco.com=3B=20h=3DQ4PJ/H8eC3vQYMWtiBURpDOoxfE=3D; b=Mh8iqJsz+gjsU/L/kIsuFqw1kTFHAg5A0XTJ7n+xUFDr1inqVogV0j1NxwaqTeO96bLOEQNA 5jgEGOs21GGkBfR1tJY7G2UhkT1Xt5ISxwFHj1ObRfPGuIaBFyaeoF89; 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: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Michael,=20 You make several good points. In particular, point number three would be very troublesome. -Bob =20 -----Original Message----- From: Michael.G.Williams@nokia.com [mailto:Michael.G.Williams@nokia.com] Sent: Wednesday, May 10, 2006 12:50 PM To: scott@hyperthought.com; Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: RE: [Capwap] to mux or not to mux? Colleagues, It seems we are wanting to take QoS seriously ;^) Several issues to consider: 1) The QoS of the STA's packet should influence the QoS of the packet encapsulating it 2) Any device in the path that is honoring QoS marks (as opposed to ignoring them) or performing remarking is effectively enforcing a security policy and a QoS policy 3) In some media, there might not be a one to one correspondence between CAPWAP packets and mobile node packets, correct? If so, and we assign different QoS to the encapsulating packet than is assigned to the packet(s) within, we may cause ordering problems. Best Regards, Michael -----Original Message----- From: ext Scott G. Kelly [mailto:s.kelly@ix.netcom.com]=20 Sent: Wednesday, May 10, 2006 12:38 PM To: Pat Calhoun (pacalhou); capwap Subject: RE: RE: [Capwap] to mux or not to mux? Hi Pat, >> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >> >Currently deployed Internet gear uses these standardized >> techniques to implement QoS, and we've heard no compelling arguments=20 >> as to why these standards are insufficient for our purposes. > >I disagree with your assessment, and don't believe we have rough=20 >consensus. > >A packet is received by the AP. The AP will have to mark the outer=20 >header to replicate the inner header. The AP doesn't have all of the=20 >complex QoS policies that are required to determine how to deal with=20 >the packet - so the best it can do is replication. The edge device will >have to police, and optionally remark. It may have a separate set of=20 >policies for data vs. control, because the admin knows that control is=20 >more important. > >I honestly don't see how the edge device does this job without knowing=20 >the difference between a data packet and a control packet. Actually, I don't agree that the WTP can't enforce QoS policies - that's an implementation choice, but it's also beside the point. Your earlier arguments seemed to indicate that intermediate devices need the UDP header to apply some sort of "QoS ACLs". We saw in discussion on this list that this is not the case.=20 This current comment suggests that some "edge device" may need to re-mark packets. Since these packets are tunneled to the AC, the AC must be the edge device we're talking about here, and if this is true, I'm not understanding is why the AC can't look at a mux header to make the decision. Modern NPUs can easily scan 64 bytes into the packet, and many can go as far as you like. Are you saying your hardware has some limitation which precludes this? 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 Thu May 11 20:37:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeLen-0004vD-A6 for capwap-archive@lists.ietf.org; Thu, 11 May 2006 20:37:25 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeLek-0007I0-Lv for capwap-archive@lists.ietf.org; Thu, 11 May 2006 20:37:25 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 53E7C4300DD for ; Thu, 11 May 2006 17:37:22 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3452543006D for ; Thu, 11 May 2006 17:36:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 26A03398030 for ; Thu, 11 May 2006 17:36:50 -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 CAC07398012 for ; Thu, 11 May 2006 17:36:47 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 11 May 2006 17:36:47 -0700 X-IronPort-AV: i="4.05,117,1146466800"; d="scan'208"; a="1804825065:sNHT115182768" 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 k4C0aiMO021796 for ; Thu, 11 May 2006 17:36:47 -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 k4C0aiB7025966 for ; Thu, 11 May 2006 17:36:44 -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); Thu, 11 May 2006 17:36:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] to mux or not to mux? Date: Thu, 11 May 2006 17:36:47 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC0185C699@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] to mux or not to mux? Thread-Index: AcZ0jwaQKctmcmGBRq+44rW/2bH4/gAzOjlg From: "Bob O'Hara (boohara)" To: "capwap" X-OriginalArrivalTime: 12 May 2006 00:36:44.0050 (UTC) FILETIME=[24BDD720:01C6755C] DKIM-Signature: a=rsa-sha1; q=dns; l=5113; t=1147394207; x=1148258207; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=boohara@cisco.com; z=From:=22Bob=20O'Hara=20\(boohara\)=22=20 |Subject:RE=3A=20[Capwap]=20to=20mux=20or=20not=20to=20mux?; X=v=3Dcisco.com=3B=20h=3D6m7+j/qnd12pCi7zrePOsNhdAEk=3D; b=W1Yw8FqCESTkSnc8Wa2xWMl/7IOijP7PJKyHxs/lXh90v3MD0D8A0j1Wa5NbcgB5Lwe3qzHl x5AO+Rl41jvjlam2vSxpab1oORpYc3HI7UnjoFUGDw1aGlcrXTsrM8Fu; 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: X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 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.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Philip, NAT would certainly introduce a complication. But, expecting QoS to be maintained over the general internet without an SLA from your service provider is a bit of pie in the sky, today. -Bob =20 -----Original Message----- From: Philip Rakity [mailto:philip.rakity@u4eatech.com]=20 Sent: Wednesday, May 10, 2006 5:08 PM To: Bob O'Hara (boohara) Cc: capwap Subject: Re: [Capwap] to mux or not to mux? Bob, Good summary. One point I am a little confused about is how NAT is handled when we =20 use different ports etc. I would have thought that the devices a =20 long the way would need to be changed to handle this. Another ALG. =20 Did I miss understand something? regards, Philip On May 10, 2006, at 2:10 PM, Bob O'Hara (boohara) wrote: > > > The issue is that the AC is not generally the edge device, i.e., the > first device that encounters a packet sent from the WTP. We are not > mandating (and, in fact, cannot mandate) that the AC live in the =20 > wiring > closet and connect directly to the WTPs. Therefore, the packets from > the WTPs pass through an arbitrary number of layer 2 and layer 3 =20 > devices > before arriving at the AC. > > It is at one or more, possibly every one, of these existing =20 > intermediate > devices that the QoS ACLs are currently applied. By hiding the > distinction between data and control inside the mux header, we > immediately prevent all of those existing devices from applying QoS to > the CAPWAP protocol control and data transmissions, differentially. > > As has been pointed out in previous postings, there are valid reasons > for desiring to apply this differential QoS to control and data. The > mux header prevents this and therefore is not a viable solution for > CAPWAP. If we persist on this path, we will wind up with a protocol > that will find little acceptance. > > -Bob > > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > Sent: Wednesday, May 10, 2006 12:38 PM > To: Pat Calhoun (pacalhou); capwap > Subject: RE: RE: [Capwap] to mux or not to mux? > > Hi Pat, > >>> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >>>> Currently deployed Internet gear uses these standardized >>> techniques to implement QoS, and we've heard no compelling >>> arguments as to why these standards are insufficient for our > purposes. >> >> I disagree with your assessment, and don't believe we have rough >> consensus. >> >> A packet is received by the AP. The AP will have to mark the outer >> header to replicate the inner header. The AP doesn't have all of the >> complex QoS policies that are required to determine how to deal with > the >> packet - so the best it can do is replication. The edge device will > have >> to police, and optionally remark. It may have a separate set of > policies >> for data vs. control, because the admin knows that control is more >> important. >> >> I honestly don't see how the edge device does this job without =20 >> knowing >> the difference between a data packet and a control packet. > > Actually, I don't agree that the WTP can't enforce QoS policies - =20 > that's > an implementation choice, but it's also beside the point. > > Your earlier arguments seemed to indicate that intermediate devices =20 > need > the UDP header to apply some sort of "QoS ACLs". We saw in =20 > discussion on > this list that this is not the case. > > This current comment suggests that some "edge device" may need to > re-mark packets. Since these packets are tunneled to the AC, the AC > must be the edge device we're talking about here, and if this is true, > I'm not understanding is why the AC can't look at a mux header to make > the decision. Modern NPUs can easily scan 64 bytes into the packet, =20 > and > many can go as far as you like. > > Are you saying your hardware has some limitation which precludes this? > > 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 > Philip Rakity prakity@u4eatech.com This message is hereby marked U4EA CONFIDENTIAL, is intended only for =20 the use of the individual or individuals to which it is addressed and =20 shall notbe disclose or made available to any other party except with =20 the prior written consent of the sender. If the reader of this =20 message is not the intended recipient, you are hereby notified that =20 any dissemination, distribution or copying of this message is =20 strictly prohibited. If you have received this communication in =20 error, please notify us immediately by replying to the sender of this =20 E-Mail. _________________________________________________________________ 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 May 15 10:56:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfeUf-0003NR-39 for capwap-archive@lists.ietf.org; Mon, 15 May 2006 10:56:21 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfeUb-0006gX-Sz for capwap-archive@lists.ietf.org; Mon, 15 May 2006 10:56:21 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id ADE98430146 for ; Mon, 15 May 2006 07:56:06 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7A1E1430067 for ; Mon, 15 May 2006 07:55:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 565841448006 for ; Mon, 15 May 2006 07:55:39 -0700 (PDT) Received: from mgw-ext12.nokia.com (mgw-ext12.nokia.com [131.228.20.171]) by hermes.tigertech.net (Postfix) with ESMTP id D647E1448015 for ; Mon, 15 May 2006 07:55:35 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4FEtVsP006155; Mon, 15 May 2006 17:55:32 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 May 2006 17:55:32 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 May 2006 09:55:24 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 15 May 2006 07:55:26 -0700 Message-ID: <8A76136424391244A5CF016533708537018F8164@mvebe101.NOE.Nokia.com> In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC0185C698@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Capwap] to mux or not to mux? Thread-Index: AcZ0aWKahPNUUwuCSkyCDig6i2rFKwAALDOwADxobEAAtKXAUA== From: To: , X-OriginalArrivalTime: 15 May 2006 14:55:24.0124 (UTC) FILETIME=[985681C0:01C6782F] 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.2 tagged_above=-999.0 required=7.0 tests=NO_REAL_NAME X-Spam-Level: Subject: Re: [Capwap] to mux or not to mux? X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.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: 5d7a7e767f20255fce80fa0b77fb2433 Hi Bob, Are we intending to fully support wireless connection from WTP to AC with a variety of wireless media? If so the QoS issue is broader, and would include... - remarking/re-acquiring QoS reservations at L2 on that "backhaul" link - elevated priority and transmission order for management frames - link aggregation For example it's likely the "backhaul" will need to "dis-aggregate" from the STA and "re-aggregate" upstream if we are talking about a general solution that would support .11n capabilities, or two radios. Best Regards, Michael -----Original Message----- From: ext Bob O'Hara (boohara) [mailto:boohara@cisco.com] Sent: Thursday, May 11, 2006 5:35 PM To: capwap@frascone.com Subject: RE: RE: [Capwap] to mux or not to mux? Michael, You make several good points. In particular, point number three would be very troublesome. -Bob -----Original Message----- From: Michael.G.Williams@nokia.com [mailto:Michael.G.Williams@nokia.com] Sent: Wednesday, May 10, 2006 12:50 PM To: scott@hyperthought.com; Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: RE: [Capwap] to mux or not to mux? Colleagues, It seems we are wanting to take QoS seriously ;^) Several issues to consider: 1) The QoS of the STA's packet should influence the QoS of the packet encapsulating it 2) Any device in the path that is honoring QoS marks (as opposed to ignoring them) or performing remarking is effectively enforcing a security policy and a QoS policy 3) In some media, there might not be a one to one correspondence between CAPWAP packets and mobile node packets, correct? If so, and we assign different QoS to the encapsulating packet than is assigned to the packet(s) within, we may cause ordering problems. Best Regards, Michael -----Original Message----- From: ext Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: Wednesday, May 10, 2006 12:38 PM To: Pat Calhoun (pacalhou); capwap Subject: RE: RE: [Capwap] to mux or not to mux? Hi Pat, >> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >> >Currently deployed Internet gear uses these standardized >> techniques to implement QoS, and we've heard no compelling arguments >> as to why these standards are insufficient for our purposes. > >I disagree with your assessment, and don't believe we have rough >consensus. > >A packet is received by the AP. The AP will have to mark the outer >header to replicate the inner header. The AP doesn't have all of the >complex QoS policies that are required to determine how to deal with >the packet - so the best it can do is replication. The edge device will >have to police, and optionally remark. It may have a separate set of >policies for data vs. control, because the admin knows that control is >more important. > >I honestly don't see how the edge device does this job without knowing >the difference between a data packet and a control packet. Actually, I don't agree that the WTP can't enforce QoS policies - that's an implementation choice, but it's also beside the point. Your earlier arguments seemed to indicate that intermediate devices need the UDP header to apply some sort of "QoS ACLs". We saw in discussion on this list that this is not the case. This current comment suggests that some "edge device" may need to re-mark packets. Since these packets are tunneled to the AC, the AC must be the edge device we're talking about here, and if this is true, I'm not understanding is why the AC can't look at a mux header to make the decision. Modern NPUs can easily scan 64 bytes into the packet, and many can go as far as you like. Are you saying your hardware has some limitation which precludes this? 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 Mon May 15 18:01:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffl8Y-0006oQ-Vp for capwap-archive@lists.ietf.org; Mon, 15 May 2006 18:01:58 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffl8W-0007Ti-Dk for capwap-archive@lists.ietf.org; Mon, 15 May 2006 18:01:58 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 655194300E1 for ; Mon, 15 May 2006 15:01:47 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 30D9143006C for ; Mon, 15 May 2006 15:01:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1C47D39804E for ; Mon, 15 May 2006 15:01:28 -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 8F8FA39801B for ; Mon, 15 May 2006 15:01:24 -0700 (PDT) Received: from [209.86.224.49] (helo=elwamui-sweet.atl.sa.earthlink.net) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1Ffl7z-0002VQ-Ku for capwap@frascone.com; Mon, 15 May 2006 18:01:23 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Mon, 15 May 2006 18:01:23 -0400 Message-ID: <8111726.1147730483589.JavaMail.root@elwamui-sweet.atl.sa.earthlink.net> Date: Mon, 15 May 2006 18:01:23 -0400 (EDT) From: "Scott G. Kelly" To: capwap Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710722e9e317eb8cbd708352bdf6d15564f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.49 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] mux redux 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: 0bc60ec82efc80c84b8d02f4b0e4de22 We've been going around in circles on this mux header discussion, and we need to close on it. Many of us are working on implementations right now, and we need this decided in order to to get on with it. This is becoming tiresome, but we must reach a conclusion. The only ones to object to using a single UDP channel here have been Pat, Bob, and Nancy. The technical benefits of mux'ing over one UDP channel have been clearly established, and are not in dispute. The only arguments still standing against this approach have all been based on the following assertions: (1) middleboxes must be able to alter capwap QoS markings in transit (2) these middleboxes must alter capwap data packet markings differently than capwap control packet markings (3) these middleboxes cannot see beyond the UDP header, and must make their decisions based on UDP header ACLs It seems clear that this whole QoS discussion is a red herring, because the assertions above, taken together, are simply not accurate. While it has been convincingly argued that control and data traffic should be treated differently, we have yet to hear why the current QoS standards are not up to this task. When this question is asked, it is met with silence. We have widely implemented standards in place for providing QoS functionality, and these standards do not include the use of UDP header ACLs. Rather, they include L2 and L3 packet markings. Nobody has made a convincing argument as to why these standards fall short of our needs. Absent persuasive arguments, contrary claims are simply not compelling. So far, a number of us have posted to the list in support of the mux header, and a few people who coincidentally all work together have argued forcefully, though unconvincingly, against this approach. Of course, ideally we are all here as independent, individual contributors, but it nevertheless does not serve us well to ignore the realities. I think, based on the discussion we've seen here, that we have rough consensus, with representatives of one product approach (and vendor) not agreeing, and representatives of various other product approaches (and vendors) roughly agreeing. It's not unanimous, but I think we have more yeas than nays - and I think that constitutes "rough" consensus. I think we should note the objections, accept the mux header, and move on. --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 maralyn@kunstsammlung.de Mon May 15 18:40:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fflja-0002eq-Pi for capwap-archive@ietf.org; Mon, 15 May 2006 18:40:14 -0400 Received: from [196.202.56.27] (helo=kunstsammlung.de) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FfljY-0000r0-SR for capwap-archive@ietf.org; Mon, 15 May 2006 18:40:14 -0400 Message-ID: <000001c6786f$e6d30590$2d40a8c0@fvn81> Reply-To: "Maralyn Garside" From: "Maralyn Garside" To: capwap-archive@ietf.org Subject: Re: your VtAGmRA Date: Mon, 15 May 2006 15:35:43 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C67835.3A769E90" 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: 0.6 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C67835.3A769E90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 P X A V C L V r a m A I e I o n b L A v A z a i I L i G a x e U I t R c n M S ra A =20 =20 =20 =20 http://www.faduspister.com =20 =20 =20 =20 =20 worthy of many imperishable songs. But, why O People?-and here the=20 Master rose to his feet and spoke very loud and clear =13 why do I get=20 all your blame? For what fault am I to be deposed? Who aroused the=20 dragon from his slumber, I might ask? Who obtained of us rich gifts and=20 ample help, and led us to believe that old songs could come true? Who=20 played on our soft hearts and our pleasant fancies? What sort of gold=20 ------=_NextPart_000_0001_01C67835.3A769E90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
P
X
A
= V
C
L
= V
r
a
m
= A
I
e
= I
o
n
b
= L
A
v
= A
z
a
i
= I
L
i
= G
a
x
e
= U
I
t
= R
c

n
= M
S
ra
= A



 
=
 
 
 
 
 
 
 
 
worthy of many imperishable songs. But, why O People?-and here the =
Master rose to his feet and spoke very loud and clear =80=93 why do = I get
all your blame? For what fault am I to be deposed? Who aroused = the
dragon from his slumber, I might ask? Who obtained of us rich = gifts and
ample help, and led us to believe that old songs could = come true? Who
played on our soft hearts and our pleasant fancies? = What sort of gold
------=_NextPart_000_0001_01C67835.3A769E90-- From aludrabivens@chaney.net Mon May 15 21:13:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffo7d-0006TD-Ld for capwap-archive@ietf.org; Mon, 15 May 2006 21:13:13 -0400 Received: from [61.175.194.78] (helo=chaney.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ffo7b-0007fk-0y for capwap-archive@ietf.org; Mon, 15 May 2006 21:13:13 -0400 Message-ID: <000001c67885$53c8a640$5fd1a8c0@qwa35> Reply-To: "Aludra Bivens" From: "Aludra Bivens" To: capwap-archive@ietf.org Subject: Re: my cdredit Date: Mon, 15 May 2006 18:09:05 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6784A.A769CE40" 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: b84f8c8fba0e1389e5eb998b64078964 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6784A.A769CE40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D h ea d r H v om h e O t wn m er, Your c f re i di r t doesn't ma q tter to us! If you O z WN e r t ea z l e q st m at c e and want I v MM r EDIAT z E c u as h h to s d pen e d ANY way you like, or simply wish to L h OW x ER your mont t hly pa v ym c ent p s by a third or mo b re, here are the d z ea a ls o we h v ave T f OD x AY: $ 49 k 0 , 0 z 00 a u s lo s w a u s 3 , 6 m 5 % $ 3 n 70 , 0 l 00 a d s lo j w a w s 3 , 9 l 0 % $ 49 e 0 , 00 w 0 a s s lo k w a f s 3 , 2 x 0 % $ 25 q 0 , 00 c 0 a c s l o ow a q s 3 , 3 r 5 % $ 20 g 0 , 00 e 0 a d s lo k w a a s 3 , 5 k 5 % V a is z it ou j r s z it w e =20 Aludra Bivens , A y ppr i ov o al Ma p na g ge c r _____ =20 Good-bye then, and really good-bye! said Gandalf, and he turned his horse and rode down into the West. But he could not resist the temptation to have the last word. Before he had passed quite out of hearing he turned and put his hands to his mouth and called to them. ------=_NextPart_000_0001_01C6784A.A769CE40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D h ea d r H v om h e O t wn m er,

Your c f re i di r t doesn't ma q tter to us!

If you O z WN e r t ea z l e q st m at c e and want
I v MM r EDIAT z E c u as h h to s d pen e d ANY=20 way you like,
or simply wish to L h OW x ER your mont t hly pa v ym c ent p s
=20 by a third or mo b re,
here are the d z ea a ls o we h v ave T f OD x AY:

$ 49 k 0 , 0 z 00 a u s lo s w a u s 3 , 6 m 5 %
$ 3 n 70 , 0 l 00 a d s lo j w a w s 3 , 9 l 0 %
$ 49 e 0 , 00 w 0 a s s lo k w a f s 3 , 2 x 0 %
$ 25 q 0 , 00 c 0 a c s l o ow a q s 3 , 3 r 5 %
$ 20 g 0 , 00 e 0 a d s lo k w a a s 3 , 5 k 5 %

V a is z it ou j r s z it w e

Aludra Bivens , A y ppr i ov o al Ma p na g ge c r


Good-bye then, and really = good-bye! said Gandalf, and he turned his
horse and rode down into the West. But he could not resist the
temptation to have the last word. Before he had passed quite out of
hearing he turned and put his hands to his mouth and called to = them.
------=_NextPart_000_0001_01C6784A.A769CE40-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue May 16 03:54:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfuNn-0001Bu-2U for capwap-archive@lists.ietf.org; Tue, 16 May 2006 03:54:19 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfuNk-0006oZ-KL for capwap-archive@lists.ietf.org; Tue, 16 May 2006 03:54:19 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 61F584300E8 for ; Tue, 16 May 2006 00:54:05 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E6CCF4300C6 for ; Tue, 16 May 2006 00:53:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D04FB4306F5 for ; Tue, 16 May 2006 00:53:44 -0700 (PDT) Received: from il.marvell.com (shoshil.marvell.com [199.203.130.250]) by hermes.tigertech.net (Postfix) with ESMTP id 6BB7B4306E2 for ; Tue, 16 May 2006 00:53:41 -0700 (PDT) Received: from msilexch01.marvell.com (msilexch01.il.marvell.com [10.4.5.104]) by il.marvell.com (8.13.1/8.13.1) with ESMTP id k4G7rc5k029127 for ; Tue, 16 May 2006 10:53:39 +0300 (IDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 May 2006 10:53:38 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] mux redux Thread-Index: AcZ4ayNczb3lQAVBSWm2ez2t1gro7gATcc3w From: "David Melman" 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.0 tagged_above=-999.0 required=7.0 tests= 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: bdc523f9a54890b8a30dd6fd53d5d024 I support keeping the separation of data and control based on the standard UDP header port, rather than adding a CAPWAP specific mux header after the UDP header. As already been stated, classification engines today typically support the standard UDP header fields. By keeping the separation of data and control in the standard UDP header, it allows standard based classification, and independent policy to be applied to each type of traffic. QoS is just one type of policy, but of course, many other policies can be applied independently to data and control traffic. There is definitely value in *not* making the mux CAPWAP specific. David -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: Tuesday, May 16, 2006 1:01 AM To: capwap Subject: [Capwap] mux redux Importance: Low We've been going around in circles on this mux header discussion, and we need to close on it. Many of us are working on implementations right now, and we need this decided in order to to get on with it. This is becoming tiresome, but we must reach a conclusion. The only ones to object to using a single UDP channel here have been Pat, Bob, and Nancy. The technical benefits of mux'ing over one UDP channel have been clearly established, and are not in dispute. The only arguments still standing against this approach have all been based on the following assertions: (1) middleboxes must be able to alter capwap QoS markings in transit (2) these middleboxes must alter capwap data packet markings differently than capwap control packet markings (3) these middleboxes cannot see beyond the UDP header, and must make their decisions based on UDP header ACLs It seems clear that this whole QoS discussion is a red herring, because the assertions above, taken together, are simply not accurate. While it has been convincingly argued that control and data traffic should be treated differently, we have yet to hear why the current QoS standards are not up to this task. When this question is asked, it is met with silence. We have widely implemented standards in place for providing QoS functionality, and these standards do not include the use of UDP header ACLs. Rather, they include L2 and L3 packet markings. Nobody has made a convincing argument as to why these standards fall short of our needs. Absent persuasive arguments, contrary claims are simply not compelling. So far, a number of us have posted to the list in support of the mux header, and a few people who coincidentally all work together have argued forcefully, though unconvincingly, against this approach. Of course, ideally we are all here as independent, individual contributors, but it nevertheless does not serve us well to ignore the realities. I think, based on the discussion we've seen here, that we have rough consensus, with representatives of one product approach (and vendor) not agreeing, and representatives of various other product approaches (and vendors) roughly agreeing. It's not unanimous, but I think we have more yeas than nays - and I think that constitutes "rough" consensus. I think we should note the objections, accept the mux header, and move on. --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 May 16 08:43:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffytg-0001ca-0a for capwap-archive@lists.ietf.org; Tue, 16 May 2006 08:43:32 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffytd-0004a7-Hq for capwap-archive@lists.ietf.org; Tue, 16 May 2006 08:43:31 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 636F043011F for ; Tue, 16 May 2006 05:43:20 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C9B2A430071 for ; Tue, 16 May 2006 05:42:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B2F10430BB6 for ; Tue, 16 May 2006 05:42:58 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [216.148.227.153]) by hermes.tigertech.net (Postfix) with ESMTP id 06429430BBA for ; Tue, 16 May 2006 05:42:55 -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 <20060516124254m1300f90ade>; Tue, 16 May 2006 12:42:55 +0000 Message-ID: <4469C8CE.6040909@hyperthought.com> Date: Tue, 16 May 2006 05:42:54 -0700 From: Scott G Kelly User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Melman References: In-Reply-To: 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] 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: e1b0e72ff1bbd457ceef31828f216a86 Hi David, David Melman wrote: > I support keeping the separation of data and control based on the > standard UDP header port, rather than adding a CAPWAP specific mux > header after the UDP header. > > As already been stated, classification engines today typically support > the standard UDP header fields. By keeping the separation of data and > control in the standard UDP header, it allows standard based > classification, and independent policy to be applied to each type of > traffic. QoS is just one type of policy, but of course, many other > policies can be applied independently to data and control traffic. > There is definitely value in *not* making the mux CAPWAP specific. We've seen that QoS policy is properly applied using standard QoS markings, and not UDP headers. Can you give any explicit use cases and justification for other forms of differential treatment of the tightly-bound capwap control and data channels? Thanks, Scott > > David > > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > Sent: Tuesday, May 16, 2006 1:01 AM > To: capwap > Subject: [Capwap] mux redux > Importance: Low > > We've been going around in circles on this mux header discussion, and we > need to close on it. Many of us are working on implementations right > now, and we need this decided in order to to get on with it. > > This is becoming tiresome, but we must reach a conclusion. > > The only ones to object to using a single UDP channel here have been > Pat, Bob, and Nancy. The technical benefits of mux'ing over one UDP > channel have been clearly established, and are not in dispute. The only > arguments still standing against this approach have all been based on > the following assertions: > > (1) middleboxes must be able to alter capwap QoS markings in transit > > (2) these middleboxes must alter capwap data packet markings differently > than capwap control packet markings > > (3) these middleboxes cannot see beyond the UDP header, and must make > their decisions based on UDP header ACLs > > It seems clear that this whole QoS discussion is a red herring, because > the assertions above, taken together, are simply not accurate. While it > has been convincingly argued that control and data traffic should be > treated differently, we have yet to hear why the current QoS standards > are not up to this task. When this question is asked, it is met with > silence. > > We have widely implemented standards in place for providing QoS > functionality, and these standards do not include the use of UDP header > ACLs. Rather, they include L2 and L3 packet markings. Nobody has made a > convincing argument as to why these standards fall short of our needs. > Absent persuasive arguments, contrary claims are simply not compelling. > > So far, a number of us have posted to the list in support of the mux > header, and a few people who coincidentally all work together have > argued forcefully, though unconvincingly, against this approach. Of > course, ideally we are all here as independent, individual contributors, > but it nevertheless does not serve us well to ignore the realities. > > I think, based on the discussion we've seen here, that we have rough > consensus, with representatives of one product approach (and vendor) not > agreeing, and representatives of various other product approaches (and > vendors) roughly agreeing. It's not unanimous, but I think we have more > yeas than nays - and I think that constitutes "rough" consensus. I think > we should note the objections, accept the mux header, and move on. > > > --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 May 16 11:18:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg1JL-0001nc-Su for capwap-archive@lists.ietf.org; Tue, 16 May 2006 11:18:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg1JJ-0003Uv-0k for capwap-archive@lists.ietf.org; Tue, 16 May 2006 11:18:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D29904300E3 for ; Tue, 16 May 2006 08:17:59 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 5C8C6430076 for ; Tue, 16 May 2006 08:17:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 48D84398048 for ; Tue, 16 May 2006 08:17:23 -0700 (PDT) Received: from maili.marvell.com (host2.marvell.com [65.219.4.2]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6036C398049 for ; Tue, 16 May 2006 08:17:19 -0700 (PDT) Received: from msiexch01.marvell.com (msiexch01.marvell.com [10.68.76.102]) by maili.marvell.com (Postfix) with ESMTP id B42201A13D; Tue, 16 May 2006 08:17:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 May 2006 08:17:18 -0700 Message-ID: <9C9B2DC3D78A6142AC8D10C896695286014F261F@msiexch01.marvell.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] mux redux Thread-Index: AcZ45kwH65UyR8x1Sv+E2CDi5e/e0gAFM4V+ From: "Nafea Bshara" To: "Scott G Kelly" , "David Melman" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.505 tagged_above=-999 required=7 tests=HTML_20_30, HTML_MESSAGE X-Spam-Level: Cc: capwap 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: multipart/mixed; boundary="===============0792792695==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 1a2f5df4c6f30e0d5df43748fb095119 This is a multi-part message in MIME format. --===============0792792695== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C678FB.D250622F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C678FB.D250622F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 hi Scott =20 there will be multiple entities in the network between the WTP and the = AC that may need to inspect, prioritize or re-direct control and data = separately, whether for security, differential treatment or redirection =20 as very simple, yet realistic example, is the hardware makeup of the AC = itself - typically made of control plane and data plane engine and a = unit infront, which is typically a multi-port MAC or Switch that is = responsible on splitting the traffic =20 most, if not all, of these network elements deployed knows how to do = QoS/ACL based on UDP ports, not sure whether they can handle undefined = headers yet =20 let me ask you the opposite question - why not to have different UDP = ports ? =20 -Nafea ________________________________ From: Scott G Kelly [mailto:scott@hyperthought.com] Sent: Tue 5/16/2006 5:42 AM To: David Melman Cc: capwap Subject: Re: [Capwap] mux redux Hi David, David Melman wrote: > I support keeping the separation of data and control based on the > standard UDP header port, rather than adding a CAPWAP specific mux > header after the UDP header. > > As already been stated, classification engines today typically support > the standard UDP header fields. By keeping the separation of data and > control in the standard UDP header, it allows standard based > classification, and independent policy to be applied to each type of > traffic. QoS is just one type of policy, but of course, many other > policies can be applied independently to data and control traffic. > There is definitely value in *not* making the mux CAPWAP specific. We've seen that QoS policy is properly applied using standard QoS markings, and not UDP headers. Can you give any explicit use cases and justification for other forms of differential treatment of the tightly-bound capwap control and data channels? Thanks, Scott > > David > > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > Sent: Tuesday, May 16, 2006 1:01 AM > To: capwap > Subject: [Capwap] mux redux > Importance: Low > > We've been going around in circles on this mux header discussion, and = we > need to close on it. Many of us are working on implementations right > now, and we need this decided in order to to get on with it. > > This is becoming tiresome, but we must reach a conclusion. > > The only ones to object to using a single UDP channel here have been > Pat, Bob, and Nancy. The technical benefits of mux'ing over one UDP > channel have been clearly established, and are not in dispute. The = only > arguments still standing against this approach have all been based on > the following assertions: > > (1) middleboxes must be able to alter capwap QoS markings in transit > > (2) these middleboxes must alter capwap data packet markings = differently > than capwap control packet markings > > (3) these middleboxes cannot see beyond the UDP header, and must make > their decisions based on UDP header ACLs > > It seems clear that this whole QoS discussion is a red herring, = because > the assertions above, taken together, are simply not accurate. While = it > has been convincingly argued that control and data traffic should be > treated differently, we have yet to hear why the current QoS standards > are not up to this task. When this question is asked, it is met with > silence. > > We have widely implemented standards in place for providing QoS > functionality, and these standards do not include the use of UDP = header > ACLs. Rather, they include L2 and L3 packet markings. Nobody has made = a > convincing argument as to why these standards fall short of our needs. > Absent persuasive arguments, contrary claims are simply not = compelling. > > So far, a number of us have posted to the list in support of the mux > header, and a few people who coincidentally all work together have > argued forcefully, though unconvincingly, against this approach. Of > course, ideally we are all here as independent, individual = contributors, > but it nevertheless does not serve us well to ignore the realities. > > I think, based on the discussion we've seen here, that we have rough > consensus, with representatives of one product approach (and vendor) = not > agreeing, and representatives of various other product approaches (and > vendors) roughly agreeing. It's not unanimous, but I think we have = more > yeas than nays - and I think that constitutes "rough" consensus. I = think > we should note the objections, accept the mux header, and move on. > > > --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 ------_=_NextPart_001_01C678FB.D250622F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [Capwap] mux redux=0A= =0A= =0A=
=0A=
 
=0A=
hi = Scott
=0A=
 
=0A=
there will be multiple = entities in the =0A= network between the WTP and the AC that may need to inspect, prioritize = or =0A= re-direct control and data separately, whether for security, = differential =0A= treatment or redirection
=0A=
 
=0A=
as very simple, yet realistic = example, is =0A= the hardware makeup of the AC itself - typically made of control plane = and data =0A= plane engine and a unit infront, which is typically a multi-port MAC or = Switch =0A= that is responsible on splitting the traffic
=0A=
 
=0A=
most, if not all, = of these network =0A= elements deployed knows how to do QoS/ACL based on UDP ports, not sure = whether =0A= they can handle undefined headers yet
=0A=
 
=0A=
let me ask you the opposite = question - why =0A= not to have different UDP ports ?
=0A=
 
=0A=
-Nafea
=0A=

=0A=
=0A= From: Scott G Kelly =0A= [mailto:scott@hyperthought.com]
Sent: Tue 5/16/2006 5:42 =0A= AM
To: David Melman
Cc: capwap
Subject: = Re: =0A= [Capwap] mux redux

=0A=
=0A=

Hi David,

David Melman wrote:
> I support = keeping =0A= the separation of data and control based on the
> standard UDP = header =0A= port, rather than adding a CAPWAP specific mux
> header after the = UDP =0A= header.
>
> As already been stated, classification engines = today =0A= typically support
> the standard UDP header fields.  By = keeping the =0A= separation of data and
> control in the standard UDP header, it = allows =0A= standard based
> classification, and independent policy to be = applied to =0A= each type of
> traffic.  QoS is just one type of policy, but = of =0A= course, many other
> policies can be applied independently to data = and =0A= control traffic.
> There is definitely value in *not* making the = mux =0A= CAPWAP specific.

We've seen that QoS policy is properly applied = using =0A= standard QoS
markings, and not UDP headers. Can you give any explicit = use =0A= cases and
justification for other forms of differential treatment of =0A= the
tightly-bound capwap control and data =0A= channels?

Thanks,

Scott


>
> =0A= David
>
> -----Original Message-----
> From: Scott G. = Kelly =0A= [mailto:s.kelly@ix.netcom.com]> =0A= Sent: Tuesday, May 16, 2006 1:01 AM
> To: capwap
> Subject: = [Capwap] =0A= mux redux
> Importance: Low
>
> We've been going = around in =0A= circles on this mux header discussion, and we
> need to close on = it. Many =0A= of us are working on implementations right
> now, and we need this = decided =0A= in order to to get on with it.
>
> This is becoming = tiresome, but we =0A= must reach a conclusion.
>
> The only ones to object to = using a =0A= single UDP channel here have been
> Pat, Bob, and Nancy. The = technical =0A= benefits of mux'ing over one UDP
> channel have been clearly = established, =0A= and are not in dispute. The only
> arguments still standing = against this =0A= approach have all been based on
> the following =0A= assertions:
>
> (1) middleboxes must be able to alter capwap = QoS =0A= markings in transit
>
> (2) these middleboxes must alter = capwap data =0A= packet markings differently
> than capwap control packet =0A= markings
>
> (3) these middleboxes cannot see beyond the UDP = header, =0A= and must make
> their decisions based on UDP header = ACLs
>
> =0A= It seems clear that this whole QoS discussion is a red herring, = because
> =0A= the assertions above, taken together, are simply not accurate. While = it
> =0A= has been convincingly argued that control and data traffic should = be
> =0A= treated differently, we have yet to hear why the current QoS = standards
> =0A= are not up to this task. When this question is asked, it is met = with
> =0A= silence.
>
> We have widely implemented standards in place = for =0A= providing QoS
> functionality, and these standards do not include = the use =0A= of UDP header
> ACLs. Rather, they include L2 and L3 packet = markings. =0A= Nobody has made a
> convincing argument as to why these standards = fall =0A= short of our needs.
> Absent persuasive arguments, contrary claims = are =0A= simply not compelling.
>
> So far, a number of us have = posted to the =0A= list in support of the mux
> header, and a few people who = coincidentally =0A= all work together have
> argued forcefully, though unconvincingly, = against =0A= this approach. Of
> course, ideally we are all here as = independent, =0A= individual contributors,
> but it nevertheless does not serve us = well to =0A= ignore the realities.
>
> I think, based on the discussion = we've =0A= seen here, that we have rough
> consensus, with representatives of = one =0A= product approach (and vendor) not
> agreeing, and representatives = of =0A= various other product approaches (and
> vendors) roughly agreeing. = It's =0A= not unanimous, but I think we have more
> yeas than nays - and I = think =0A= that constitutes "rough" consensus. I think
> we should note the =0A= objections, accept the mux header, and move on.
>
>
> =0A= --Scott
>
> =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
> =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_01C678FB.D250622F-- --===============0792792695== 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 --===============0792792695==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue May 16 11:35:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg1aH-00074W-CH for capwap-archive@lists.ietf.org; Tue, 16 May 2006 11:35:41 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg1aF-0005Ov-Qb for capwap-archive@lists.ietf.org; Tue, 16 May 2006 11:35:41 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7324F4300E1 for ; Tue, 16 May 2006 08:35:39 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6C5A4430076 for ; Tue, 16 May 2006 08:35:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5A84A39800F for ; Tue, 16 May 2006 08:35:16 -0700 (PDT) Received: from maili.marvell.com (host2.marvell.com [65.219.4.2]) by zoidberg.tigertech.net (Postfix) with ESMTP id 54E4139801A for ; Tue, 16 May 2006 08:35:14 -0700 (PDT) Received: from rdlnexch03.marvell.com (rdlnexch03.marvell.com [10.6.1.22]) by maili.marvell.com (Postfix) with ESMTP id 4347F1A14A; Tue, 16 May 2006 08:35:13 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 May 2006 18:35:02 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] mux redux Thread-Index: AcZ45lDQUwFcC0rjQeqd5BhNN69q/QAFwEgg From: "Tal Anker" To: "Scott G Kelly" , "David Melman" 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] 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: f49c97ce49302a02285a2d36a99eef8c Hi Scott, There are examples for both approaches - muxing using special mux header or using UDP/TCP ports... For instance the BFD protocol suit (Bidirectional failure detection) uses different udp ports for its various protocols (Control, Echo), FTP uses different data and control ports (TCP) etc. There is no clear cut here for the Mux approach... not to mention the simplification for the HW engine that will reside in the AC and will have to dispatch packets either to be processed at the control plane (CPU) or to be switched/routed (data plane). The simplification comes from the fact that most HW switching elements already have engines that classify packets based on the famous five/six tupple ... - Tal -----Original Message----- From: Scott G Kelly [mailto:scott@hyperthought.com] Sent: Tuesday, May 16, 2006 3:43 PM To: David Melman Cc: capwap Subject: Re: [Capwap] mux redux Importance: Low Hi David, David Melman wrote: > I support keeping the separation of data and control based on the > standard UDP header port, rather than adding a CAPWAP specific mux > header after the UDP header. > > As already been stated, classification engines today typically support > the standard UDP header fields. By keeping the separation of data and > control in the standard UDP header, it allows standard based > classification, and independent policy to be applied to each type of > traffic. QoS is just one type of policy, but of course, many other > policies can be applied independently to data and control traffic. > There is definitely value in *not* making the mux CAPWAP specific. We've seen that QoS policy is properly applied using standard QoS markings, and not UDP headers. Can you give any explicit use cases and justification for other forms of differential treatment of the tightly-bound capwap control and data channels? Thanks, Scott > > David > > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > Sent: Tuesday, May 16, 2006 1:01 AM > To: capwap > Subject: [Capwap] mux redux > Importance: Low > > We've been going around in circles on this mux header discussion, and we > need to close on it. Many of us are working on implementations right > now, and we need this decided in order to to get on with it. > > This is becoming tiresome, but we must reach a conclusion. > > The only ones to object to using a single UDP channel here have been > Pat, Bob, and Nancy. The technical benefits of mux'ing over one UDP > channel have been clearly established, and are not in dispute. The only > arguments still standing against this approach have all been based on > the following assertions: > > (1) middleboxes must be able to alter capwap QoS markings in transit > > (2) these middleboxes must alter capwap data packet markings differently > than capwap control packet markings > > (3) these middleboxes cannot see beyond the UDP header, and must make > their decisions based on UDP header ACLs > > It seems clear that this whole QoS discussion is a red herring, because > the assertions above, taken together, are simply not accurate. While it > has been convincingly argued that control and data traffic should be > treated differently, we have yet to hear why the current QoS standards > are not up to this task. When this question is asked, it is met with > silence. > > We have widely implemented standards in place for providing QoS > functionality, and these standards do not include the use of UDP header > ACLs. Rather, they include L2 and L3 packet markings. Nobody has made a > convincing argument as to why these standards fall short of our needs. > Absent persuasive arguments, contrary claims are simply not compelling. > > So far, a number of us have posted to the list in support of the mux > header, and a few people who coincidentally all work together have > argued forcefully, though unconvincingly, against this approach. Of > course, ideally we are all here as independent, individual contributors, > but it nevertheless does not serve us well to ignore the realities. > > I think, based on the discussion we've seen here, that we have rough > consensus, with representatives of one product approach (and vendor) not > agreeing, and representatives of various other product approaches (and > vendors) roughly agreeing. It's not unanimous, but I think we have more > yeas than nays - and I think that constitutes "rough" consensus. I think > we should note the objections, accept the mux header, and move on. > > > --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 Tue May 16 15:04:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4q7-0003Gq-5W for capwap-archive@lists.ietf.org; Tue, 16 May 2006 15:04:15 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg4q4-0007bG-JX for capwap-archive@lists.ietf.org; Tue, 16 May 2006 15:04:15 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0CA97430112 for ; Tue, 16 May 2006 12:04:10 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 88631430077 for ; Tue, 16 May 2006 12:03:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 75F8F398038 for ; Tue, 16 May 2006 12:03:37 -0700 (PDT) Received: from germanium.prioritynetworks.net (germanium.prioritynetworks.net [128.64.162.100]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8E48A398049 for ; Tue, 16 May 2006 12:03:22 -0700 (PDT) Received: from [192.168.1.211] (68-191-245-50.dhcp.athn.ga.charter.com [68.191.245.50]) by germanium.prioritynetworks.net (Postfix) with ESMTP id 0F3D7E29C for ; Tue, 16 May 2006 15:03:14 -0400 (EDT) Message-ID: <446A21B1.6020601@sysnetinc.com> Date: Tue, 16 May 2006 15:02:09 -0400 From: Chris Stradtman User-Agent: Mail/News 1.5 (X11/20060309) MIME-Version: 1.0 To: capwap References: <4469C8CE.6040909@hyperthought.com> In-Reply-To: <4469C8CE.6040909@hyperthought.com> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=-0.001 tagged_above=-999 required=7 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: 8fbbaa16f9fd29df280814cb95ae2290 Scott G Kelly wrote: > Hi David, > > David Melman wrote: > >> I support keeping the separation of data and control based on the >> standard UDP header port, rather than adding a CAPWAP specific mux >> header after the UDP header. >> >> As already been stated, classification engines today typically support >> the standard UDP header fields. By keeping the separation of data and >> control in the standard UDP header, it allows standard based >> classification, and independent policy to be applied to each type of >> traffic. QoS is just one type of policy, but of course, many other >> policies can be applied independently to data and control traffic. >> There is definitely value in *not* making the mux CAPWAP specific. >> > > We've seen that QoS policy is properly applied using standard QoS > markings, and not UDP headers. Can you give any explicit use cases and > justification for other forms of differential treatment of the > tightly-bound capwap control and data channels? > > Thanks, > > Scott > > > >> David >> >> -----Original Message----- >> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >> Sent: Tuesday, May 16, 2006 1:01 AM >> To: capwap >> Subject: [Capwap] mux redux >> Importance: Low >> >> We've been going around in circles on this mux header discussion, and we >> need to close on it. Many of us are working on implementations right >> now, and we need this decided in order to to get on with it. >> >> This is becoming tiresome, but we must reach a conclusion. >> >> The only ones to object to using a single UDP channel here have been >> Pat, Bob, and Nancy. The technical benefits of mux'ing over one UDP >> channel have been clearly established, and are not in dispute. The only >> arguments still standing against this approach have all been based on >> the following assertions: >> >> (1) middleboxes must be able to alter capwap QoS markings in transit >> >> (2) these middleboxes must alter capwap data packet markings differently >> than capwap control packet markings >> >> (3) these middleboxes cannot see beyond the UDP header, and must make >> their decisions based on UDP header ACLs >> >> It seems clear that this whole QoS discussion is a red herring, because >> the assertions above, taken together, are simply not accurate. While it >> has been convincingly argued that control and data traffic should be >> treated differently, we have yet to hear why the current QoS standards >> are not up to this task. When this question is asked, it is met with >> silence. >> >> We have widely implemented standards in place for providing QoS >> functionality, and these standards do not include the use of UDP header >> ACLs. Rather, they include L2 and L3 packet markings. Nobody has made a >> convincing argument as to why these standards fall short of our needs. >> Absent persuasive arguments, contrary claims are simply not compelling. >> >> So far, a number of us have posted to the list in support of the mux >> header, and a few people who coincidentally all work together have >> argued forcefully, though unconvincingly, against this approach. Of >> course, ideally we are all here as independent, individual contributors, >> but it nevertheless does not serve us well to ignore the realities. >> >> I think, based on the discussion we've seen here, that we have rough >> consensus, with representatives of one product approach (and vendor) not >> agreeing, and representatives of various other product approaches (and >> vendors) roughly agreeing. It's not unanimous, but I think we have more >> yeas than nays - and I think that constitutes "rough" consensus. I think >> we should note the objections, accept the mux header, and move on. >> >> >> --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 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". Chris Stradtman 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 chel@elfrie.de Tue May 16 22:49:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgC69-00036x-L6 for capwap-archive@ietf.org; Tue, 16 May 2006 22:49:17 -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 1FgC69-0001Yz-HW for capwap-archive@ietf.org; Tue, 16 May 2006 22:49:17 -0400 Received: from [81.198.32.13] (helo=elfrie.de) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FgC66-0007HK-Jc for capwap-archive@ietf.org; Tue, 16 May 2006 22:49:15 -0400 Message-ID: <000001c6795b$f5bd0c30$6456a8c0@ceo94> Reply-To: "Chelle Bond" From: "Chelle Bond" To: capwap-archive@ietf.org Subject: Re: the crred Date: Tue, 16 May 2006 19:45:29 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C67921.495E3430" 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.8 (++++) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C67921.495E3430 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0002_01C67921.495E3430" ------=_NextPart_001_0002_01C67921.495E3430 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable go to the web site =20 =20 =20 =20 =20 ----- Original Message -----=20 did not mean to. They surprised us at night in a pass which we had to cross, we were coming out of the Lands over West into these countries-it is a long tale. Then you had better come inside and tell me some of it, if it wont take all day, said the man leading the way through a dark door that opened out of the courtyard into the house. Following him they found themselves in a wide hall with a fire-place in the middle. Though it was summer there was a wood-fire burning and the smoke was rising to the blackened rafters in search of the way out through an opening in the roof. They passed through this dim hall, lit only by the fire and the hole above it, and came through another smaller door into a sort of veranda propped on wooden posts made of single tree-trunks. It faced south and was still warm and filled with the light of the westering sun which slanted into it, and fell golden on the garden full of flowers that came right up to the steps. Here they sat on wooden benches while Gandalf began his tale, and =09 ------=_NextPart_001_0002_01C67921.495E3430 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
 
 
 
----- Original Message -----
did not mean to. They surprised us at night in a pass which we had = to
cross, we were coming out of the Lands over West into these = countries-it
is a long tale.
Then you had better come inside and tell me some of it, if it = wont
take all day, said the man leading the way through a dark door that
opened out of the courtyard into the house.
Following him they found themselves in a wide hall with a = fire-place
in the middle. Though it was summer there was a wood-fire burning = and
the smoke was rising to the blackened rafters in search of the way = out
through an opening in the roof. They passed through this dim hall, = lit
only by the fire and the hole above it, and came through another = smaller
door into a sort of veranda propped on wooden posts made of single
tree-trunks. It faced south and was still warm and filled with the = light
of the westering sun which slanted into it, and fell golden on the
garden full of flowers that came right up to the steps.
Here they sat on wooden benches while Gandalf began his tale, = and
------=_NextPart_001_0002_01C67921.495E3430-- ------=_NextPart_000_0001_01C67921.495E3430 Content-Type: image/gif; name="dethronement33.gif" Content-Transfer-Encoding: base64 Content-ID: <000101c6795b$f5b6026e$6456a8c0@ceo94> R0lGODdhOwHwAMIAAAAAAAAAAP///wAA//8AAMnS9+uA2gAAACwAAAAAOwHwAAAD/li63P7OGEir mjbrzTnuYJh9YmmeaMpI6to25BvG8Sw/dZnb7377uAnNBCTedDBUEddZboa8ljM1vVhdlWVVsz1S upGot5CDgsBM8jiZxZoh2rUKTf0+5eoIRohv9z1YYlcLdH95hoR2iH4rLIeAPYsjYzuFcnyLPpZ4 Enszm4KSc2WikKWnSCRbjoigiaWkFp6ZjKgnroFqVat1imxhsEiPtoPEpsM/yKOySmnAxpB0uL/Q XLnMItON2L5wzjLahjXha9PS1cXetcTkfePo3Kjn8K/i6+zC9M5d7U36wfis/fPCL9StgZL63Zmi UF/BMwgj9iKoTKJFgc8uarx2/kdWrI0gMXak1/CgQWocNTIUtWtSPXhoSqJME+cbyEoz4+WbkzJS tm45y7mU6bKVugs4bf70+Yccq6CUhnIqGjBdT6L+doqs8/RiyZpGjmjyWuihFKth0SZcWq4rz5BQ t1KdeK9WzESWgGDVs3ejE1xYAwgOYEDwyIoODF8hjPhq3abI+v77ezMAocFjFFsRjAlx58NZfUp2 KNdoYwaMSWiWsVpBayukkkoJN2t0NdtZnXA+hLnAYMuof7u2zDgx8OALhPMx3Lvwcd+EnxtfrVmx BMzCg1cn/vwNXItl1SIfxBx49eTlgdcoPl6xYSG945tXLx39cPv3L2TvDT0//v9ruH3H1lEmvAYd dfX1t9osnP2G3XPv9ZefghDWhyB+8UnoX4UaZnSbgKX1xIGB2U04WGETGKhGhPZdaOJx5Y0no4bp cdehexCmmOBLt/BC4I8wHSOeBiQ6uN9xKKpIxmsx4kcjjNz9VphxMjLnGoXtGRndjrT5qJSHQdLS 4XD/OekbfBWweJ+LT7Yo3XocrkmmjRhaRkN9s/TgJY9fBDiXO2NiSaWbaapHqJPbHXoNmweSOaGE 1s34ip9AVtrMkCGaBAeCUKLWaKNKaogBjo8muqGng7bmIpuR0hkcUXdlmtYmThXq4HTbxRgqk1Cq 2umLZWpnoZ2nmnlroCp+/kbXSeD8QqtYINrST6RJPMtnaJp+Ga09lkILmgoLhmHtW5d2SxtcsoEZ 1Smt9UOpurIOCF5FY8WV1ikreetXMvu6AicKye70wWv58vvntt2OSN2UyybMI6mBbrrjad2M6qoy 72Rgqi8+sLdGqJABXOEHMun1AMQgrzCxLmLoGDG8Fmwc4m4n/VtVCfIRiynMQKHk3KA2edxzCE0e 7IzMpaWM8Y9Kk+sFxAeyd2F5Oxz5pGY6NrjmsTAYiZ6vDM85X9TClujmfNI5mHWDRyZapHBmL4Yk zSf+GnJm/EE9NdZAR5llnRY/mpjFY7cJaacnfiqpdo7S+LXL+v2tOBam/hJ8o52VrzxJS3hDDPne hQJ9+eWfTwy6ooKOB/niZPz8IgR6D8yhkqUjF4OLYefRtB3vGr5k4VuH3gCj73WHOfCiF506hXnP PSwcYcvste+nBwG1hKrFeezqRvh7gswMV2/zjFoSp1rgL4++9/Re04zsxKxsnDmiWqb/e6lIGtsr Zq5jq69OvjsccsK1ODbJ7oAChN3sFoiYB+nueQqkH/5eJ7gKdm2CVEIf4+w3NKboRHrIU94jeDUj DSZQSdUTlGoGaCi+pU9+IQQe0iz4QAwOr4XmYR1EjJE9yX3KgcLzzZiwhj750HBDhTNVitqEtXCh 0G7uCZ/e4nSldiVi/n4ns84Ujwgo1qStTHC7mAKBWLblNClXOyJj3Lh2rAW9iWw3lKBrfoZGOLYR T1d80K7UmJ3+raV3PEuFPC4hL23Fa1nzaEa6GgbAs4iokI9kpNMAYhPO7UxWlDmkvSIBmMc48n+U DKRduthIQ+Kjk0LqoFbmBcpJQlIoFGEJI1TxrUsirFz+y0eedqjKmwyJZJG8FsWYJaBYlWuXudyk J9ditIKJkpemWRclkZnKZkkymWLyILeKiTDvDcSZpfwkMTUJy2feUpjQqJVQbOMntwwTXaTUpiub xc6boTNMQXGEQgBZznCe02GhrEslqIlKeJITm7a8WzxxKdCjZGyZ/vOMpj9XGcxXTtSayjQnRnvJ E9wEyGStPCgj+XnNSynrn/e66D0RQtJvVhSlRjMlTAlJUZV6oKXoOClHETpTjfo0oSKV1krl2UXJ aCMvKRVpERpijqGKk1tG3ahTaxpSiWa0Hg/dpsF2alFI7lOrETWXVGE5rijgFKKpPGtQuXrTkJVV YcCEy+6CpjkKzBWtE0KqNKfK075m8aq2mKEheyiCgAHCO4/Sq63qJ7bLqM2uX6xQXccqOLXGkYsV vauZAKus8QFVoySk4ByH5UYq0hQt1HonZYO4uyVolosr+Qhm8QrZy9ZJdHB0bOPi+S+trah5V9Pc Hc/0tTTWz2xx/sOVFsFYIikGi3rFSe7WfGXEyBVXY6ZF3W5zexnR7nU6oy3Wf643vK99qnZ/bVx1 n6heDfZqjgEUbfGQZ95GLdFRD5IdZhmlXQryir9UjRkDUdfEySoPwP1LYZFYqIsFQ8ePEfyhDfWX DhwlOLvDI2wcHQypuPaRXGhQ8MUW1LEtjRjDS6IwgNVnPMcakWtUCmN+uGdD51gteihGj35jnKDM ebg7ICbaAtsnWSnlYLmXm16GVcxY2zJPSsMpItqeayUhWphtyYPilGWn5L+asL+HM9IeaOzNwg74 gputcItbZeBO7UGMEQ7eoNBb3w3P6T7UHJ2eJzfXFYvwhxzy/sRrI9mFFCZHw0FMHYTj3Coav8TQ GKwyDXOGnxL78Go6jLPgyBtAai26qpq+HncQ3WMcXcyPpXaSc7iXvzqFENBj286RnUe+LKs3V05e mQthuEHF2djJHOxqrvdH36iZzoH/fSJyiU0NPjbvjFM2lJNzZ+z0AmvEWXyu7eQ23i6PCcK+6imI vjITd9FUneJGKWKnclqmfjfd2cpmOqIKUIxYlrbwjim7+VrLAFcznf0uaUjyLFOokPupk0kqM9eK r4AXvJ/5Vu2k/P1vbbUUnOG0ZMQVblO2TmSR8JZtxz2u75EL863jJGpGCS5LnYgc30xoKsUtvnGJ Y2MvIF3H/rkO68E9/XvnIf9svDcJ8pnzO+UvXe3Da6707iF8kCr3H0Pubc9B6nRbR0Wkw5kOFJ8f hOocp2jRE9mWd29V4jJ/OtZLGR6SN8Hc8l6qS2Eq96Vn9adtTUY7uen2D532nnG1+bvftfdYcp3h V3CnsAEI9n2fXSUBjQxS8C74pMOc8ivPibt92XIRvXytQF98yXmkWL+SJPKfF7rRKw4mUIBTr143 PUMlUnSzgxWwFSOrVQ2/dcdbHmBQrzdVbjfZouD86KxfeuVXD/xQMxdka4Twr+9FskH/tGrSve5v l62qx/c97KovW2RvW6z0NvF+5QdH8YNqM20TzMFSq3o5/lNPJOJcKTkJlLMF9/bmEx9BaAt3f/tn XOYXXfk2djhjf+XVH6jmf7bGIlNCM5/WWKOlInVkIjumXDrWNKFlbX9DbfKGdCcHTXa2gFrEYGnG gPC1MCq4JEdmXhECf0kEJV8mgNjRf9iVbc+3KjkUfKKHfJVCRwvYYZvhgJelIw3oOtdxdYdiaTxI JvclYA+GKe7Haee1G1WWfcpncrj3dDYGI1VCH0YoIyiSYqjDMHASRtq2PKQiY2OkRyAYCO5DYRn0 O+FzOHHQeLSghmxUN3tWQtdxZsRlbaZGZQ6YhS+DZMYGPzo2bOmFCfdFKnm4OUwHZxY4hmbSCbnT JI72/ofTt2Hao4DS5UY3tDKBQ2qpVmHFAhbMUHq25w+WmIortomdcGafNjW6xWNhiDahFoVTmBiq c2isY4Hkp3csQ4K8RzQp1oF0SF1mGIMyZB7Yx4vnlyoxlIvgBSpuZo0qYz4mkoI2WGyfxITfh4wK Ex1x9onaR4Y7WIpA4IYwtoseQ4pvGGYuJCy2tSVlY1eluH5ABUz0J4I3sH53h1vHsG5id3nNYH2v CH72lnwjkkuWRn1dODT8FIe3N3neFxq7AAr+mHoM2Rhp9w8A+HtEJ3wBmHe7J3vnBnBh9UvNJFRN l4zmyIU3l5FAKFOaoId4Ny2dB5EQUZINk3OI5xkz/kkXYNAOpFWI+nhni5Vh1KUzXjR49YeO1hOV uDKEWSeQKLd87MOLETCDwLBFF2ZdA6k5bdcBUdRjLIBF5YdHatdx7QAGiChEaYaFGNaAoqI8GPk9 dXVwdglfcRQ4rCJDW0iTKZmDugZBsyiIB1Ziz3aJ6wiNwqiDzJYTzHhgv+Ie0HN4IhOYxkF81/iA A9aJgclHxYAy0diIQ4iaKHGPIkZ+XMKToFZbpSZt3hWHsVlg9fcy+vWEEtYYfwZZb8RiYSgn3KV4 G0eXVUgedlOGpImCZqlcUWI5bBhrZESd1cYFxWlqf7gfCUSOERdiieOImQiAu5ljmVOeoPg3OSSZ /oLpbZvCBkSWaWIZfvg5dxrTgnRYKrMmndfpgdTVW6Fol1CGZlHWa2lyd5rJj/m3fKr3VTulG9hz nOQjlYKpfwH6gEU4DA16a7iZofyZiJmWfsSYfgKHksTEiiZIhH9YflkziG5phbCGPTI4YexxPoQT X8XIZwUKO/ohjj+Zk9SAkOgUj+yZiGWSYODWjsRJJzaGfeuIP1VDR9HGJ81lj1kJpC7mj5GXogYH mpgHjoc5ekPHV38hlLPHUrU5WCHqBkJWk5ZXd723eKmxprQZEYGnomZIaCNgDhoHlMLTlZ6pUIcZ C5kEA4AqqJw1po5aqDlFEyFCp39alEYqeYzq/pB6+jSaqklkBzQY53RKoZyPSk44RQ7H9kB8o4Vr 04+uGnavNS6dEY9d+qpcljZrWqb5yXil5G3NATVS9AWraTghqWnZZEbbVZnr9aNi6nvw0heUipwQ 4qIaSkDu06Ar9pkNt0Ip6Jg7dh43kxSw8kEKiCqeU4aM0paOiYn7SIF9A1ze1a7biRcGqYusiTJ+ hyk4JWn4l39LyF9LCKAfCowu6Co3mn9084L4ZTdIgWi2iUO/5R9nOqfGJ5MD1JrIwwKb+CarRmDs GpamKbCMYWpLlBTDqaiT8zBFU5YK4pR9ZUylSqTIUCJU5J0INiWEua5PmiRa2KBWWjwnxTbV/mmK KUhY9OiUNjKBEAWzFVlvRceHNHsrLGIgT8GJG/quYpNqLLiMVUQshOU68umBrwBCDnqC5ch8nVoF sRhBbJZFv0lrfpZdhkg6LQtHqFiKvel89ukf0eqsPpgm71OA2HihHRKBKIaL3XpqxJI4zRmkoHmi eSUp2bqZfxmCCfeeEES4QwRtxYiXY7SwRTuDO2aa8WG44ChqpsuNXMqADDmX4EGr1+acHbhGzNWX ZMOUsHOrcjO4rhpdWshdU1g+LkuwjwOmPTUqPOBaXqqrmVqnIFCsNtm057S8efCO1HtL2hCrZwtx fxuRdkq9U8emJkmmGUcaLom9FEOqp0dv/sxLc7nxd0EwFeOqBRfZihMrvSNBcBq3eX3npeJpTWUW bEhHS6YHmPp7kPD7U0vpjlKzhsMbNdmTWpoCMkRpkoSDQuooZi62ZKCxp7lqWV+5W6HFXsTquzP2 FilTwbeAl7IoWJ57f4GamNBQlzX7RdtGuGyml2eJSeUCscTLo6wLhglVePDAr1iruXfLm9k6r7Ab XHKkpJEJl92Yg9Mpm+NWxOVKiFajakxGCDirnjDIsI57Qlq2HmF8Gd6hpsaSwUkULfxkxAoKuokL oBHosGz7l4cIloaCfX50dfxDnDgAr1nowPppDNk3hx4roCOGhGRKZGs4sgXqhsf4hfMV/imWZr3O x5k0yneLkKUSHGW8GZ2JrMVZ+1dPiLlh0MBB2hyJZqxHdJ//JBmKuyiYozIn00OxGZaSu2Cn/MB4 tmn3CKqu/EIoir9Rx6fAJ2uhM4+z9rYie8sXO8eFCckE2CIl1K+JJYARY0WnKaQye8ydWrYPis1u ubCrE0WA47aO68JiiT6ka7Mm7GUIQmdivBk9isyIqQh9e46cIrW0O7vtqLvKoBxXqsWrSmszC0RY RpzEN6VN7KGEvJImFb3Y/DRAFlMsmqukp8LdAL1ewRYZ47rNCqGLQ3VmoZE9cL2czJFHWbKlKsH1 +6jq2wRqXJTmuw8tvdFHqXlOE5Cy/kSo3zEaPhd6pRHA0PpKsbdQccm9Q9i+XnioHs1LrsdKlju+ pLrA+JjVT/qqG+i85Ntu8kqdF9zPTQ3WhlqR7hTCgOZfqVrClVZ8WxDVJuGdYjuA3/il+Zx4uUTD zxy3fd1iO4wO6pmKlwWuGq2QCSwQcPzXw7hAztzIUdu4ucVrOnirxQefvNHC2jxMPo3PTD0Ji53I bRudOatD70U3mo2wGYgqwVvP9dpYY52LnKlMnS1uQvi54sNhKnS1y4yh9ipeBohdSpuNAoah/BGs U3ZJeRqzWl3YgqibOrvEUlKdJabDNaK0jsyBbeaB00cnd7Xc41vcNjxBfi3ag62s/rBbPO7ZtYwW bQnS0FL42gbqzdv72ZhXNd+ps6JcrYT9i8m6JkYbiXO7Wdpmx/VKO8Vs0/b9dAY73vytyHpZ3shp 16ziXHqrnqsdyN1BuhErwIe9kXpyf96d2uOs0GLI1p/b2pkI3K9yuvDs4vgjlfHXOqYzxjW91PkK 2tx3R1iZj//xhVytg60dLOfMXPZp4s91wYX9axeseJHl2wqXJ2plSSqdtwFY21W94hQx1a1XyBuw vFMg1/fbkB0k5gcTewUJ4gMJEbpR5QrJvimQwt4H5z8Rw4REKQXVpnr+kuynSM374Ti5opxHe3I6 qoXOk0DdS3B3TkmN4xeFbmqu/uDMPeli9eaRynEe3NMdBeg5ntf7bFP11G/8S9Isd3qOflVjUS95 PXNcftbv+9GnHt5OTQRbCamz7tk83LwjeeffbC+1Z+tZ8KkCGeg8ZTKZ7tWSHunSQsAKfnEvaezG S4n41L3zxnr/O+3g1+r13eurzm7OlKgusOu2jhUzfXilzlWxAc6Mbqb6ilfgHc5O2xTHNxfafn3x zu6qvucHiOsDbMwiOXEdJO6VjpijLsO/vueXGmSVJ9TbbpFCwqJJmZD8fulLu6tD6reBCvHD/nvv fpLHm+UPv/EkzZKbStFsOq7AnvLLuXsH/3GcrvJmze4/GAppztm69PIwT+a37n7xMfdMiZToQT1w Il/Vdp7sOc/tsr4vKRUeHf8tvVPz8H7FSx+T40npUe8wTY/sPTnxVn8WzG6xHHXShV71tgT0YN/1 lPfpZ5v1OP/NlvUGJTPzWp/0Rq/zj8D2CMyVeJ/Yx0jofBrAJD/yqkXUO53P185DbmfUXSf471T0 Vx/4vHf44vvn35DvfT/mp275hc/rQQfyWM4RcS/zeG0Sks/3fB70YQX1dN/wkP71IB/tSL/gCCXl Q8/1jB+mfdKQ5R7iCfcMjX7uLvf4Jn8YNMBO0DrlOL35leRwgL9Qu/8Di+7vZnfsiB3yuQ4BCQAA Ow== ------=_NextPart_000_0001_01C67921.495E3430-- From fausticors@fr.ooelfv.at Wed May 17 22:52:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgYcR-00089I-HV for capwap-archive@ietf.org; Wed, 17 May 2006 22:52:07 -0400 Received: from 66-81-214-119.nocal.dialup.o1.com ([66.81.214.119] helo=fr.ooelfv.at) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FgYcO-0005qi-Jd for capwap-archive@ietf.org; Wed, 17 May 2006 22:52:07 -0400 Message-ID: <000001c67a25$817e6240$2921a8c0@zlg31> Reply-To: "Faustine Corson" From: "Faustine Corson" To: capwap-archive@ietf.org Subject: Re: your good crdit Date: Wed, 17 May 2006 19:48:13 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C679EA.D51F8A40" 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: 8e9fbe727bc2159b431d624c595c1eab This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C679EA.D51F8A40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D u ea f r H p om p e O k wne h r, Your c a re y di t t does n n't ma e tter to us! If you O p WN r r d ea d l e d st y at o e and w u ant I p MM i EDIA w TE c j as z h to s g pen s d ANY w x ay you li n ke, or sim e ply w g ish to L n OW l ER your m l onthly p t aym r ent w s by a th x ird or mor e e, he a re ar o e the d j ea l ls o we h l ave T x ODA p Y: $ p 490 , 00 h 0 a c s lo g w a x s 3 , 6 z 4 % $ m 370 , 00 y 0 a d s lo y w a b s 3 , 8 x 9 % $ v 490 , 00 r 0 a r s lo k w a i s 3 , 1 y 9 % $2 w 50 , 00 p 0 a u s lo k w a e s 3 , 3 k 4 % $2 h 00 , 0 t 00 a h s l f ow a b s 3 , 5 d 4 % Your c m re o di h t does c n't m k atter to u w s! g c et ma h tc h hed with l g en j der a s =20 Faustine Corson , A j ppr y ova c l M k ana b ge n r =20 ----- Original Message -----=20 mighty little left for supper, and less for breakfast. There they all sat glum and wet and muttering, while Oin and Gloin went on trying to light the fire, and quarrelling about it. Bilbo was sadly reflecting that adventures are not all pony-rides in May-sunshine, when Balin, who =09 ------=_NextPart_000_0001_01C679EA.D51F8A40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D u ea f r H p om p e O k wne h r,

Your c a re y di t t does n n't ma e tter to us!

If you O p WN r r d ea d l e d st y at o e and w u ant
I p MM i EDIA w TE c j as z h to s g pen s d ANY=20 w x ay you li n ke,
or sim e ply w g ish to L n OW l ER your m l onthly p t aym r ent w s
=20 by a th x ird or mor e e,
he a re ar o e the d j ea l ls o we h l ave T x ODA p Y:

$ p 490 , 00 h 0 a c s lo g w a x s 3 , 6 z 4 %
$ m 370 , 00 y 0 a d s lo y w a b s 3 , 8 x 9 %
$ v 490 , 00 r 0 a r s lo k w a i s 3 , 1 y 9 %
$2 w 50 , 00 p 0 a u s lo k w a e s 3 , 3 k 4 %
$2 h 00 , 0 t 00 a h s l f ow a b s 3 , 5 d 4 %

Your c m re o di h t does c n't m k atter to u w s!

g c et ma h tc h hed with l g en j der a s

Faustine Corson , A j ppr y ova c l M k ana b ge n r
 
----- Original Message -----
mighty little left for supper, and less for breakfast. There they = all
sat glum and wet and muttering, while Oin and Gloin went on trying = to
light the fire, and quarrelling about it. Bilbo was sadly reflecting
that adventures are not all pony-rides in May-sunshine, when Balin, = who
------=_NextPart_000_0001_01C679EA.D51F8A40-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu May 18 12:24:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FglII-0003bl-1Y for capwap-archive@lists.ietf.org; Thu, 18 May 2006 12:24:10 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FglIE-00041h-Um for capwap-archive@lists.ietf.org; Thu, 18 May 2006 12:24:10 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 974334300EE for ; Thu, 18 May 2006 09:23:55 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 925854300AA for ; Thu, 18 May 2006 09:23:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 82AFF398055 for ; Thu, 18 May 2006 09:23:28 -0700 (PDT) Received: from smtpauth07.mail.atl.earthlink.net (smtpauth07.mail.atl.earthlink.net [209.86.89.67]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4BCA739804A for ; Thu, 18 May 2006 09:23:25 -0700 (PDT) Received: from [209.86.224.38] (helo=elwamui-lapwing.atl.sa.earthlink.net) by smtpauth07.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1FglHY-0000uy-D7 for capwap@frascone.com; Thu, 18 May 2006 12:23:24 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Thu, 18 May 2006 12:23:24 -0400 Message-ID: <26137307.1147969404359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> Date: Thu, 18 May 2006 09:23:24 -0700 (GMT-07:00) From: "Scott G. Kelly" To: capwap Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff7108af5cc19dff7b3c52ff6a2668e217926350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.38 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] cost/benefit analysis: mux 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: 7a0494a0224ca59418dd8f92694c1fdb We've been discussing whether to use separate UDP ports for capwap control/data vs multiplexing these onto one UDP channel. It's been pointed out to me that this debate has led us deep into the weeds, and that in the process, some important big picture points are probably being missed. With that in mind, I set out to objectively summarize the design trade-offs in an open-minded way. I did a pretty detailed analysis on my own during the Dallas IETF as a result of Sue Hares' numerous comments on the capwap state machine. It seemed very clear to me that the mux header was the simpler (and therefore better) of the two approaches by far, but at that time we had no indications as to why folks would prefer the multi-port approach to the single port approach. We've since seen that at least one vendor and their supplier have a switch architecture in mind that takes advantage of the multi-port approach. We've also heard some QoS arguments, but these seem far less concrete. In any event, we need to do an objective cost-benefits analysis, and decide one way or the other, and we also want to be sure to document this process so that those coming late to the party understand how we got to where they find us. That's the purpose of this effort. I'm trying to make this as succinct as possible, but we have to capture the salient points, so that will constrain the lower bound on the size of this note. Still, this is as concise as I can make it while still fairly evaluating our options. We've been discussing two options, but I think there are actually 3: 1) use multiple ports with separate data and control channels, and somehow manage these as a unit, potentially across firewalls and/or NATs (what's in the draft now) 2) use a single UDP channel (and server port), and multiplex discovery, control and data channels over this one session (the mux header proposal) 3) 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. Option 3 has never been discussed (and personally, I don't like it), but I think we have to give everything a fair hearing, so there it is. Also, it's important to note that the IPsec group was faced with a nearly identical problem - traversing NAT with two independent datagram channels - so it is instructive to look at how it was ultimately solved, keeping in mind that backward-compatibility was a hard requirement for them, but not for us. In order to summarize the various costs/benefits in a manageable way, I've approached this like a capwap session walk-through, addressing the issues as they are encountered during session establishment. That's what's below, with a separate section devoted to each issue, and subsections under them, one for each of the transport options described above. 1. Differentiating Discovery Messages If we are encrypting the control channel, we need to be able to differentiate discovery messages (currently a type of control message) from other control channel messages, as discovery messages are not secured. 1.1 Option (1) - multi-port Assume we have one port for the control channel and one for data. The first implication we encounter relates to discovery messages - either they need their own port, or we need to modify the discovery message header so as to render it precisely unambiguous when compared to DTLS. Currently, there is some ambiguity. Here's the first few words of the latest proposed capwap header, which would be at the head of the discovery message: 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 |W|F|L|M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment ID | Frag Offset |Rsv-2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Here's the DTLS record header, which will be present after dtls negotiation starts: 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 | protocol version | epoch +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ epoch, cont | (6 byte sequence #) /-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The type will be from TLS; the ClientHello is 0x16, or 00010110 (other tls types of interest are similar), and the dtls protocol version will be 0xFEFF, and any dtls version changes will just decrement the first version byte (FE, FD, FC, etc). This translates to the following bits: 1 6 F E F F 0001 0110 1111 1110 1111 1111 Putting this into the capwap 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|0 1 1 0 1|1 1 1 1|1|1|0|1|1 1 1 1 1 1 1 |VERSION| RID | HLEN |W|F|L|M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or, VERSION..: 0001 RID......: 01101 (13) HLEN.....: 1111 (15) W........: 1 F........: 1 L........: 1 M........: 0 Changing DTLS types will just effect the RID. Obviously, there's some ambiguity here. We have three choices: (a) carefully check every incoming packet against capwap state; if dtls is expected, treat the packet as dtls; otherwise, treat it as discovery and in either case, if anything looks "funny" or questionable (i.e. reserved bits are set), treat it as an error. Note that this does not allow you to push packets directly into your dtls engine; instead, you have to de-mux them first. Also, it doesn't quite feel deterministic (if discovery messages are sent once dtls is established, they will erroneously be treated as bogus dtls messages), and it means the reserved bits can never be used in a way that might result in ambiguity. (b) modify the capwap header to be sure this *never* happens, e.g. by adding a "magic cookie" to the beginning which will never match a dtls packet. This feels pretty hacky, but would probably work - but it requires per-packet de-muxing checks, and adds bytes to the capwap header - that is, it is a pseudo mux header. (c) use a different UDP port for discovery; requires yet another firewall rule, but since per-packet disambiguation would be costly in some ways, this is the most logical approach. So, looks like multi-port works best with three ports, not two. 1.2 Option (2) Mux header Assume we have a tri-valued mux header (discovery, control, data). One firewall rule for capwap, no header type ambiguities. Very simple - no other special considerations for discovery. 1.3 Option (3), multi-port with special nat-t mechanism Recall that in this scenario, once NAT is detected, the two channels are bundled together over one port - that would occur post-discovery, so this is equivalent to option (1) for discovery. 2. NAT detection In some (but not all) cases, we must detect and adapt to NATs along the AC-WTP path. 2.1 Option (1), multi-port If we use separate UDP ports, we must either add code to detect the presence of NAT(s) in the WTP-AC path, or we must assume they are always there. If we assume they are always there, we have to deal with NAT-T processing even when we don't need it. If we don't assume this, we have to support multiple code paths. Yuk. So, how do we do NAT detection? The WTP transmits its IP address in either a discover or join message. The AC compares this with the address in the packet header, and informs the WTP if they are different. If we do it in the discover, the WTP has to indicate that NAT-T is required in the JOIN request. 2.2 Option (2), mux header If we use a mux header, we don't need NAT detection, or any other special processing relating to NATs. 2.3 Option (3), multi-port with special nat-t mechanism Same as option (1), except that behavior is different once NATs are detected. 3. Channel Binding We must be able to unambiguously identify which data channel goes with which control channel, and manage these as a unit - this is what is meant by channel binding. 3.1 Option (1), multi-port Assume the control channel is established, and the heartbeat (echo req/reply) is running there. Using our handy-dandy NAT detection scheme, the WTP and AC learned that one or more NATs are inline. So, the AC has to give the WTP a unique session identifier (should probably be the session ID from the control channel). Someone suggested using a BSSID, but this is 802.11-specific, and we'd need additional solutions for other radio types, so it's not a good approach. Assuming the session ID is used, the WTP has to initiate a data channel "connection" containing this session ID, and then a heartbeat has to start over this channel to keep NAT bindings in place along the path Note that this connection does not necessarily have the same IP as the control channel (L3/4 switching, load balancing, multihomed NAT device, etc), and this must be taken into account. Also note that a NAT'd channel can "fail" rather arbitrarily and unpredictably. For example, there is no standard way to handle resource contention on NAT devices. Some simply drop new session requests, and others toss out an existing one to make room for the new one. Hence, behavior will not be deterministic, and we must expect and plan for random channel failures, including the inability to establish a data channel once we have a control channel in place. More error handling and control session teardown/recovery in this case. If the data channel heartbeat fails, one approach is to tear down the control channel and restart from scratch, even if it is still working. An acknowledged error message could be sent over the existing control channel prior to teardown, but then you must set a timer in case it is not acknowledged, and deal with this somehow. A better alternative is to instead maintain the working control channel and establish a new data channel, binding it to the existing control channel, but this would require coordination to minimize STA downtime (is there some way to shift associated STAs to the new channel without loss of connectivity?), and we have to handle error conditions (i.e. what if we can't establish a new data channel?) Also, you must decide which side detects the failure and deals with it, and/or how to deal with race conditions and collisions if both sides detect it and react more or less simultaneously. Okay, that was data channel failure - if instead the control channel fails, the WTP must be the one to reinitiate a new control channel (it is effectively re-joining, and currently the AC can't initiate a join, and besides, it is behind a NAT). Then, it must tell the AC to tear down the old data channel and clean up any STA associations with that channel (or, the AC must track the WTPs original non-NAT'd IP as part of its session context, and clean up automagically). In the meantime, the same STAs may be reassociating over the new data channel. More mucking around with error conditions, housekeeping, etc. 3.2 Option (2), mux header If the UDP channel goes away (i.e. NAT binding fails somewhere along the path), the whole session, data and control, times out as a unit. Both sides detect this and clean up both control and data as a unit (it's one single session, and no tear-down messages are required). If the WTP detects it first and rejoins before the AC cleans up the old session, the AC needs to detect this. 3.3 Option (3), multi-port with special nat-t mechanism Similar to option (2) if there is NAT. If not, it's more like option (1), and the channels shouldn't usually fail. Still, we must detect/handle it if one or both do fail. 3.4 Summarizing Channel Bindings We have to be able to manage channels as a unit, and detect when one fails. If we use separate ports, this task is much more complex than if channels are multiplexed over one port. Also, channel failure is more likely for multiple port approaches. If we assume random NAT failures with equal likelihood for either channel (which seems entirely reasonable), channel failure is twice as likely with two ports as it is with the mux header. The mux header approach requires no special channel binding - it's implicit. That entirely eliminates all associated complexity. 4. Keepalives/heartbeats This ties in closely to the channel binding, but deserves it's own section. Note that for any NAT traversal scenario, we need to keep the NAT channel open, and this requires periodic heartbeats. Also note that due to channel binding requirements, if we have independent control and data channels (separate ports), it is possible for the data channel to fail independently of the control channel, hence we must detect this - we need a data channel heartbeat. 4.1 Option (1), multi-port We must manage heartbeats over both channels. If one fails, this requires potentially asymmetric repairs as described in section 3.1. Note that this is independent of NAT; since it is always possible to lose one channel and not the other, implementations must be prepared to deal with this. 4.2 Option (2) - mux header The existing control channel echo req/rsp serves as an implicit heartbeat - no additonal effort required. 4.3 Option (3), multi-port with special nat-t mechanism Same as (1) - note that we need heartbeats on the separate data channel with or without NAT. 5. Intermediate firewall configuration Firewalls between the AC and WTP must be configured to permit capwap through. One rule per AC for mux vs three rules per AC for the multi-port approach, and maybe with an additional rule if we use a 4th port for NAT traversal. 6. Summarizing There is no question that using a mux header is far simpler than either of the multi-port approaches. Simpler means more likely to interoperate, and also more likely to be correctly implemented, which has both operational and security implications, though they are difficult to precisely quantify. Also, it is clear from this analysis that the two-port approach requires a data channel heartbeat (and all associated processing complexity) regardless of whether NATs are present or not. By far, channel binding and multi-channel maintenance are the largest issues here, and especially when NATs are in the picture. The question we have to answer is this: is there some value in the multiport approach that makes it worth it to take on all this complexity and the associated operational and interop issues? I'm going to stop short of offering an opinion here, although I definitely have one. I think this will work better if this note remains objective. You can hear my opinions in follow-ups :-) --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 May 18 13:32:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgmMk-0003d6-2g for capwap-archive@lists.ietf.org; Thu, 18 May 2006 13:32:50 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgmMh-0007JM-SQ for capwap-archive@lists.ietf.org; Thu, 18 May 2006 13:32:50 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CBA014300C9 for ; Thu, 18 May 2006 10:32:46 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7591B4300AA for ; Thu, 18 May 2006 10:32:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 58D121448003 for ; Thu, 18 May 2006 10:32:17 -0700 (PDT) Received: from smtp106.plus.mail.mud.yahoo.com (smtp106.plus.mail.mud.yahoo.com [68.142.206.239]) by hermes.tigertech.net (Postfix) with SMTP id D30D61448007 for ; Thu, 18 May 2006 10:32:13 -0700 (PDT) Received: (qmail 76494 invoked from network); 18 May 2006 17:32:12 -0000 Received: from unknown (HELO MICHAELV-LT.WaveCompass.com) (mvakulenko@84.108.65.224 with login) by smtp106.plus.mail.mud.yahoo.com with SMTP; 18 May 2006 17:32:10 -0000 Message-Id: <7.0.1.0.0.20060518193629.0473be58@yahoo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 18 May 2006 20:32:41 +0200 To: "Scott G. Kelly" From: Michael Vakulenko In-Reply-To: <26137307.1147969404359.JavaMail.root@elwamui-lapwing.atl.s a.earthlink.net> References: <26137307.1147969404359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> 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.1 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: capwap Subject: Re: [Capwap] cost/benefit analysis: mux 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.1 (/) X-Scan-Signature: 441f623df000f14368137198649cb083 Scott, Your analysis is very impressive. Its complexity and length of this email thread probably indicates that no single approach (mux or multiport) works well for all product architectures and deployment scenarios. I suggest rather simple way to resolve this. Let's allow AC decide which UDP port shall be used for data messages and configure WTP accordingly. I.e., control connection is always established on a pre-defined well-known port. Following that the AC will configure the WTP to use certain UDP port for data messages. This can be done in Join Response message. The port can be the same as the well-known control port or different, depending on AC architecture or network considerations. Impact on WTP implementation is negligible (software only), impact on draft specification is negligible (additional message element). Benefits are many, including flexibility in AC vendor differentiation and supported network deployment scenarios. -- Michael V. www.WaveCompass.com At 06:23 PM 5/18/2006, Scott G. Kelly wrote: >We've been discussing whether to use separate UDP ports for capwap >control/data vs multiplexing these onto one UDP channel. It's been >pointed out to me that this debate has led us deep into the weeds, >and that in the process, some important big picture points are >probably being missed. With that in mind, I set out to objectively >summarize the design trade-offs in an open-minded way. > >I did a pretty detailed analysis on my own during the Dallas IETF as >a result of Sue Hares' numerous comments on the capwap state >machine. It seemed very clear to me that the mux header was the >simpler (and therefore better) of the two approaches by far, but at >that time we had no indications as to why folks would prefer the >multi-port approach to the single port approach. We've since seen >that at least one vendor and their supplier have a switch >architecture in mind that takes advantage of the multi-port >approach. We've also heard some QoS arguments, but these seem far >less concrete. > >In any event, we need to do an objective cost-benefits analysis, and >decide one way or the other, and we also want to be sure to document >this process so that those coming late to the party understand how >we got to where they find us. That's the purpose of this effort. I'm >trying to make this as succinct as possible, but we have to capture >the salient points, so that will constrain the lower bound on the >size of this note. Still, this is as concise as I can make it while >still fairly evaluating our options. > >We've been discussing two options, but I think there are actually 3: > >1) use multiple ports with separate data and control channels, and >somehow manage these as a unit, potentially across firewalls and/or >NATs (what's in the draft now) > >2) use a single UDP channel (and server port), and multiplex >discovery, control and data channels over this one session (the mux >header proposal) > >3) 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. > >Option 3 has never been discussed (and personally, I don't like it), >but I think we have to give everything a fair hearing, so there it >is. Also, it's important to note that the IPsec group was faced with >a nearly identical problem - traversing NAT with two independent >datagram channels - so it is instructive to look at how it was >ultimately solved, keeping in mind that backward-compatibility was a >hard requirement for them, but not for us. > >In order to summarize the various costs/benefits in a manageable >way, I've approached this like a capwap session walk-through, >addressing the issues as they are encountered during session >establishment. That's what's below, with a separate section devoted >to each issue, and subsections under them, one for each of the >transport options described above. > > >1. Differentiating Discovery Messages > >If we are encrypting the control channel, we need to be able to >differentiate discovery messages (currently a type of control >message) from other control channel messages, as discovery messages >are not secured. > >1.1 Option (1) - multi-port > >Assume we have one port for the control channel and one for data. >The first implication we encounter relates to discovery messages - >either they need their own port, or we need to modify the discovery >message header so as to render it precisely unambiguous when >compared to DTLS. Currently, there is some ambiguity. > >Here's the first few words of the latest proposed capwap header, >which would be at the head of the discovery message: > > 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 |W|F|L|M| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Fragment ID | Frag Offset |Rsv-2| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Here's the DTLS record header, which will be present after dtls > negotiation starts: > > 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 | protocol version | epoch > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ > epoch, cont | (6 byte sequence #) > /-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >The type will be from TLS; the ClientHello is 0x16, or 00010110 >(other tls types of interest are similar), and the dtls protocol >version will be 0xFEFF, and any dtls version changes will just >decrement the first version byte (FE, FD, FC, etc). This translates >to the following bits: > > 1 6 F E F F > 0001 0110 1111 1110 1111 1111 > >Putting this into the capwap 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 1|0 1 1 0 1|1 1 1 1|1|1|0|1|1 1 1 1 1 1 1 > |VERSION| RID | HLEN |W|F|L|M| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >or, > >VERSION..: 0001 >RID......: 01101 (13) >HLEN.....: 1111 (15) >W........: 1 >F........: 1 >L........: 1 >M........: 0 > >Changing DTLS types will just effect the RID. Obviously, there's >some ambiguity here. We have three choices: > >(a) carefully check every incoming packet against capwap state; if >dtls is expected, treat the packet as dtls; otherwise, treat it as >discovery and in either case, if anything looks "funny" or >questionable (i.e. reserved bits are set), treat it as an error. >Note that this does not allow you to push packets directly into your >dtls engine; instead, you have to de-mux them first. Also, it >doesn't quite feel deterministic (if discovery messages are sent >once dtls is established, they will erroneously be treated as bogus >dtls messages), and it means the reserved bits can never be used in >a way that might result in ambiguity. > >(b) modify the capwap header to be sure this *never* happens, e.g. >by adding a "magic cookie" to the beginning which will never match a >dtls packet. This feels pretty hacky, but would probably work - but >it requires per-packet de-muxing checks, and adds bytes to the >capwap header - that is, it is a pseudo mux header. > >(c) use a different UDP port for discovery; requires yet another >firewall rule, but since per-packet disambiguation would be costly >in some ways, this is the most logical approach. > >So, looks like multi-port works best with three ports, not two. > > >1.2 Option (2) Mux header > >Assume we have a tri-valued mux header (discovery, control, data). >One firewall rule for capwap, no header type ambiguities. Very >simple - no other special considerations for discovery. > > >1.3 Option (3), multi-port with special nat-t mechanism > >Recall that in this scenario, once NAT is detected, the two channels >are bundled together over one port - that would occur >post-discovery, so this is equivalent to option (1) for discovery. > > >2. NAT detection > >In some (but not all) cases, we must detect and adapt to NATs along >the AC-WTP path. > >2.1 Option (1), multi-port > >If we use separate UDP ports, we must either add code to detect the >presence of NAT(s) in the WTP-AC path, or we must assume they are >always there. If we assume they are always there, we have to deal >with NAT-T processing even when we don't need it. If we don't assume >this, we have to support multiple code paths. Yuk. > >So, how do we do NAT detection? The WTP transmits its IP address in >either a discover or join message. The AC compares this with the >address in the packet header, and informs the WTP if they are >different. If we do it in the discover, the WTP has to indicate that >NAT-T is required in the JOIN request. > > >2.2 Option (2), mux header > >If we use a mux header, we don't need NAT detection, or any other >special processing relating to NATs. > > >2.3 Option (3), multi-port with special nat-t mechanism > >Same as option (1), except that behavior is different once NATs are detected. > > >3. Channel Binding > >We must be able to unambiguously identify which data channel goes >with which control channel, and manage these as a unit - this is >what is meant by channel binding. > > >3.1 Option (1), multi-port > >Assume the control channel is established, and the heartbeat (echo >req/reply) is running there. Using our handy-dandy NAT detection >scheme, the WTP and AC learned that one or more NATs are inline. So, >the AC has to give the WTP a unique session identifier (should >probably be the session ID from the control channel). Someone >suggested using a BSSID, but this is 802.11-specific, and we'd need >additional solutions for other radio types, so it's not a good >approach. Assuming the session ID is used, the WTP has to initiate a >data channel "connection" containing this session ID, and then a >heartbeat has to start over this channel to keep NAT bindings in >place along the path > >Note that this connection does not necessarily have the same IP as >the control channel (L3/4 switching, load balancing, multihomed NAT >device, etc), and this must be taken into account. > >Also note that a NAT'd channel can "fail" rather arbitrarily and >unpredictably. For example, there is no standard way to handle >resource contention on NAT devices. Some simply drop new session >requests, and others toss out an existing one to make room for the >new one. Hence, behavior will not be deterministic, and we must >expect and plan for random channel failures, including the inability >to establish a data channel once we have a control channel in place. >More error handling and control session teardown/recovery in this case. > >If the data channel heartbeat fails, one approach is to tear down >the control channel and restart from scratch, even if it is still >working. An acknowledged error message could be sent over the >existing control channel prior to teardown, but then you must set a >timer in case it is not acknowledged, and deal with this somehow. > >A better alternative is to instead maintain the working control >channel and establish a new data channel, binding it to the existing >control channel, but this would require coordination to minimize STA >downtime (is there some way to shift associated STAs to the new >channel without loss of connectivity?), and we have to handle error >conditions (i.e. what if we can't establish a new data channel?) > >Also, you must decide which side detects the failure and deals with >it, and/or how to deal with race conditions and collisions if both >sides detect it and react more or less simultaneously. > >Okay, that was data channel failure - if instead the control channel >fails, the WTP must be the one to reinitiate a new control channel >(it is effectively re-joining, and currently the AC can't initiate a >join, and besides, it is behind a NAT). Then, it must tell the AC to >tear down the old data channel and clean up any STA associations >with that channel (or, the AC must track the WTPs original non-NAT'd >IP as part of its session context, and clean up automagically). In >the meantime, the same STAs may be reassociating over the new data >channel. More mucking around with error conditions, housekeeping, etc. > > >3.2 Option (2), mux header > >If the UDP channel goes away (i.e. NAT binding fails somewhere along >the path), the whole session, data and control, times out as a unit. >Both sides detect this and clean up both control and data as a unit >(it's one single session, and no tear-down messages are required). >If the WTP detects it first and rejoins before the AC cleans up the >old session, the AC needs to detect this. > >3.3 Option (3), multi-port with special nat-t mechanism > >Similar to option (2) if there is NAT. If not, it's more like option >(1), and the channels shouldn't usually fail. Still, we must >detect/handle it if one or both do fail. > > >3.4 Summarizing Channel Bindings > >We have to be able to manage channels as a unit, and detect when one >fails. If we use separate ports, this task is much more complex than >if channels are multiplexed over one port. Also, channel failure is >more likely for multiple port approaches. > >If we assume random NAT failures with equal likelihood for either >channel (which seems entirely reasonable), channel failure is twice >as likely with two ports as it is with the mux header. > >The mux header approach requires no special channel binding - it's >implicit. That entirely eliminates all associated complexity. > > >4. Keepalives/heartbeats > >This ties in closely to the channel binding, but deserves it's own >section. Note that for any NAT traversal scenario, we need to keep >the NAT channel open, and this requires periodic heartbeats. Also >note that due to channel binding requirements, if we have >independent control and data channels (separate ports), it is >possible for the data channel to fail independently of the control >channel, hence we must detect this - we need a data channel heartbeat. > >4.1 Option (1), multi-port > >We must manage heartbeats over both channels. If one fails, this >requires potentially asymmetric repairs as described in section 3.1. >Note that this is independent of NAT; since it is always possible to >lose one channel and not the other, implementations must be prepared >to deal with this. > > >4.2 Option (2) - mux header > >The existing control channel echo req/rsp serves as an implicit >heartbeat - no additonal effort required. > > >4.3 Option (3), multi-port with special nat-t mechanism > >Same as (1) - note that we need heartbeats on the separate data >channel with or without NAT. > > >5. Intermediate firewall configuration > >Firewalls between the AC and WTP must be configured to permit capwap >through. One rule per AC for mux vs three rules per AC for the >multi-port approach, and maybe with an additional rule if we use a >4th port for NAT traversal. > > >6. Summarizing > >There is no question that using a mux header is far simpler than >either of the multi-port approaches. Simpler means more likely to >interoperate, and also more likely to be correctly implemented, >which has both operational and security implications, though they >are difficult to precisely quantify. > >Also, it is clear from this analysis that the two-port approach >requires a data channel heartbeat (and all associated processing >complexity) regardless of whether NATs are present or not. > >By far, channel binding and multi-channel maintenance are the >largest issues here, and especially when NATs are in the picture. >The question we have to answer is this: is there some value in the >multiport approach that makes it worth it to take on all this >complexity and the associated operational and interop issues? > >I'm going to stop short of offering an opinion here, although I >definitely have one. I think this will work better if this note >remains objective. You can hear my opinions in follow-ups :-) > > >--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 May 18 15:58:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgoeB-0000FK-Rt for capwap-archive@lists.ietf.org; Thu, 18 May 2006 15:58:59 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgobf-0000bd-7p for capwap-archive@lists.ietf.org; Thu, 18 May 2006 15:56:25 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E6E744300CB for ; Thu, 18 May 2006 12:56:13 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id ED87B430071 for ; Thu, 18 May 2006 12:55:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DCA781448003 for ; Thu, 18 May 2006 12:55:54 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4F5A31448006 for ; Thu, 18 May 2006 12:55: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 k4IJtofD019404; Thu, 18 May 2006 12:55:50 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k4IJtogT019401; Thu, 18 May 2006 12:55:50 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 18 May 2006 12:55:50 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Scott G. Kelly" In-Reply-To: <26137307.1147969404359.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> 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] cost/benefit analysis: mux 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: bb8f917bb6b8da28fc948aeffb74aa17 HI, Very good message. I'm glad you wrote up the issue with the discovery message. Here is a question for you: What is the difference between 1) a LOCAL MAC WTP that tunnels all of the data traffic for WTP clients (the STAs) over a tunnel that just happens to terminate at the AC, and 2) a SPLIT MAC WTP that uses separate transport addresses for control and WTP client data traffic They look the same to me except for the following: 1) the AC has to configure the LOCAL MAC WTP as to the VLAN tag, and Qos markings of STA data traffic. Where with SPLIT MAC, this is done by the AC. 2) the status and statistics of STA data traffic must be sent periodically by the WTP to the AC for LOCAL MAC WTPs, where with SPLIT MAC WTPs, the AC counts this directly. Of course in the SPLIT MAC WTP case where separate transport addresses are used, then it is a "local matter" how the configuration and intrumentation values are done on the 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 May 18 16:12:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgoqs-0002Dt-EF for capwap-archive@lists.ietf.org; Thu, 18 May 2006 16:12:06 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgoqq-0002N3-WE for capwap-archive@lists.ietf.org; Thu, 18 May 2006 16:12:06 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 941DE4300CD for ; Thu, 18 May 2006 13:12:04 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 6F414430071 for ; Thu, 18 May 2006 13:11:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 27C6C1448006 for ; Thu, 18 May 2006 13:11:45 -0700 (PDT) Received: from smtpauth07.mail.atl.earthlink.net (smtpauth07.mail.atl.earthlink.net [209.86.89.67]) by hermes.tigertech.net (Postfix) with ESMTP id 965F91448003 for ; Thu, 18 May 2006 13:11:41 -0700 (PDT) Received: from [209.86.224.38] (helo=elwamui-lapwing.atl.sa.earthlink.net) by smtpauth07.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1FgoqS-0007m0-EQ; Thu, 18 May 2006 16:11:40 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Thu, 18 May 2006 16:11:40 -0400 Message-ID: <23852468.1147983100398.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> Date: Thu, 18 May 2006 13:11:40 -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: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff71037423e29db0484d36e07b7e9b441afc9350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.38 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] cost/benefit analysis: mux 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: 4d87d2aa806f79fed918a62e834505ca Hi David, Comments inline... David T. Perkins wrote: > >HI, > >Very good message. I'm glad you wrote up the issue with the discovery >message. > >Here is a question for you: > >What is the difference between > 1) a LOCAL MAC WTP that tunnels all of the data traffic for WTP > clients (the STAs) over a tunnel that just happens to terminate > at the AC, and > 2) a SPLIT MAC WTP that uses separate transport addresses for > control and WTP client data traffic I'm not sure I understand what you mean. By definition, with local MAC the WTP does not tunnel data traffic to the AC at all. In this case, as far as the network is concerned, the WTP is effectively a router at the WLAN/LAN boundary (with respect to STAs), and it only has a control channel with the AC - no data channel. In split MAC architectures, if the LAN-bound data traffic is tunneled by the WTP to somewhere other than the AC on which the control channel terminates, there has to be signalling in the backend to tell that "somewhere other than the AC" when to expect data and from which WTP(s). Not sure if this answers your questions. Scott > >They look the same to me except for the following: > 1) the AC has to configure the LOCAL MAC WTP as to > the VLAN tag, and Qos markings of STA data traffic. > Where with SPLIT MAC, this is done by the AC. > 2) the status and statistics of STA data traffic > must be sent periodically by the WTP to the AC > for LOCAL MAC WTPs, where with SPLIT MAC WTPs, > the AC counts this directly. >Of course in the SPLIT MAC WTP case where separate >transport addresses are used, then it is a "local >matter" how the configuration and intrumentation >values are done on the 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 alonzoi@mail.ltc.edu.tw Fri May 19 12:21:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh7it-0003b4-J1 for capwap-archive@ietf.org; Fri, 19 May 2006 12:21:07 -0400 Received: from adsl-ull-233-92.48-151.net24.it ([151.48.92.233] helo=mail.ltc.edu.tw) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fh7ir-0001mh-0F for capwap-archive@ietf.org; Fri, 19 May 2006 12:21:07 -0400 Message-ID: <000001c67b5f$bb348a10$accea8c0@scn26> Reply-To: "Alonzo Grizzell" From: "Alonzo Grizzell" To: capwap-archive@ietf.org Subject: Re: test AmMBBtEN Date: Fri, 19 May 2006 09:17:31 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C67B25.0EDA6D00" 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.4 (+++) X-Scan-Signature: 25620135586de10c627e3628c432b04a This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C67B25.0EDA6D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 X ^ N A X V / A G R A S O M ^ M E R / D / A C / A L / S A M B / E N P R O Z ^ C V A L / U M L E V / T R A =20 http://www.manilipasonuk.com =20 =20 =20 =20 =20 moment before and cowered down in fright. Smaug was still to be reckoned with. It does not do to leave a live dragon out of your calculations, if you live near him. Dragons may not have much real use for all their=20 wealth, but they know it to an ounce as a rule, especially after long=20 possession; and Smaug was no exception. He had passed from an uneasy=20 dream (in which a warrior, altogether insignificant in size but provided ------=_NextPart_000_0001_01C67B25.0EDA6D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
X ^ N A X
V / A G R A
S O M ^
M E R / D / A
C / A L / S
A M B / E N
P R O Z ^ C
V A L / U M
L E V / T R A
 
http://www.manilipasonuk.com
 
 
 
 
 
moment before and cowered down in = fright. Smaug was still to be reckoned
with. It does not do to leave = a live dragon out of your calculations, if
you live near him. = Dragons may not have much real use for all their
wealth, but they = know it to an ounce as a rule, especially after long
possession; and = Smaug was no exception. He had passed from an uneasy
dream (in which = a warrior, altogether insignificant in size but provided =
------=_NextPart_000_0001_01C67B25.0EDA6D00-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon May 22 10:13:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiB9n-0001pW-Pk for capwap-archive@lists.ietf.org; Mon, 22 May 2006 10:13:15 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiB9m-0002LZ-0B for capwap-archive@lists.ietf.org; Mon, 22 May 2006 10:13:15 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 45BBE4300FF for ; Mon, 22 May 2006 07:13:13 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2DFB8430082 for ; Mon, 22 May 2006 07:12:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 12ACC144801C for ; Mon, 22 May 2006 07:12:49 -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 56A65144801A for ; Mon, 22 May 2006 07:12:47 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 22 May 2006 07:12:46 -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 k4MECk0Y021192 for ; Mon, 22 May 2006 07:12:46 -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 k4MEChBB002429 for ; Mon, 22 May 2006 07:12:46 -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, 22 May 2006 07:12:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 May 2006 07:12:44 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201ECEB8A@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Resolution for Issue 77: Update figure 1 to depict a generic CAPWAP architecture Thread-Index: AcZ9qcuzg8hv6kLhSZ+tiNNF/qTktw== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 22 May 2006 14:12:45.0126 (UTC) FILETIME=[CBF2A660:01C67DA9] 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: [Capwap] Proposed Resolution for Issue 77: Update figure 1 to depict a generic CAPWAP architecture X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.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 All, Here is my proposed resolution for the above mentioned issue. While the original issue submitted included a proposed resolution, it was a combined figure that attempted to show all possible modes of operation, which I found confusing. Instead, I prefer to have a separate figure (and text) to discuss local MAC. Comments appreciated. 1. Introduction [...] CAPWAP assumes a network configuration consisting of multiple WTPs communicating via the Internet Protocol (IP) to an AC. WTPs are viewed as remote RF interfaces controlled by the AC. The CAPWAP protocol supports two modes of operation: split and local MAC. The Split MAC mode is one where all L2 wireless data and management frames are encapsulated via the CAPWAP protocol and exchanged between the AC and the WTP. In the example of 802.11, as shown in Figure 1, the 802.11 frames received from a mobile node (STA) are directly encapsulated by the WTP and forwarded to the AC. +-+ 802.11 frames +-+ | |--------------------------------| | | | +-+ | | | |--------------| |---------------| | | | 802.11 PHY/ | | CAPWAP | | | | MAC sublayer | | | | +-+ +-+ +-+ STA WTP AC Figure 1: Representative CAPWAP Architecture for Split MAC The Local MAC mode of operation diffs from Split MAC as it allows for the data frames to be either locally bridged, or tunneled as 802.3 frames. The latter implies that the WTP performs the 802 bridging function. In either case, however, the management frames are processed locally by the WTP, and then forwarded to the AC. Figure 2 provides an example using the IEEE 802.11 binding, where a station transmits an 802.11 frame, which is encapsulated as 802.3 and forwarded to the AC. +-+ 802.11 frames +-+ 802.3 frames +-+ | |---------------| |--------------| | | | | | | | | |---------------| |--------------| | | | 802.11 PHY/ | | CAPWAP | | | | MAC sublayer | | | | +-+ +-+ +-+ STA WTP AC Figure 2: Representative CAPWAP Architecture for Local MAC [...] 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 May 22 11:45:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiCas-0008LO-CL for capwap-archive@lists.ietf.org; Mon, 22 May 2006 11:45:18 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiCaq-0007A7-RD for capwap-archive@lists.ietf.org; Mon, 22 May 2006 11:45:18 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4EA7F4300D7 for ; Mon, 22 May 2006 08:45:16 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id ED95B43005A for ; Mon, 22 May 2006 08:44:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C759B144802C for ; Mon, 22 May 2006 08:44:50 -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 85ACC144802B for ; Mon, 22 May 2006 08:44:47 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 22 May 2006 08:44:47 -0700 X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208"; a="323089080:sNHT33387940" 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 k4MFikNO010934 for ; Mon, 22 May 2006 08:44:46 -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 k4MFikB7009103 for ; Mon, 22 May 2006 08:44: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); Mon, 22 May 2006 08:44:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 May 2006 08:44:46 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201ECEBD6@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Resolution for Issue 118: Change AC Descriptor SW/HW version formats Thread-Index: AcZ9tqcBTWJHrcwsRaioyrUaYnZ0HQ== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 22 May 2006 15:44:46.0816 (UTC) FILETIME=[A721AE00:01C67DB6] 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: [Capwap] Proposed Resolution for Issue 118: Change AC Descriptor SW/HW version 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: 67c1ea29f88502ef6a32ccec927970f0 Below is my proposed text for issue. Note that I made an additional change to the draft to the WTP Descriptor section, which had the new format, but still required 32 bits for the HW, SW and boot version numbers. These fields are now variable length. Comments welcomed. 4.4.1. AC Descriptor The AC payload message element is used by the AC to communicate it's current state. The 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stations | Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Active WTPs | Max WTPs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security | R-MAC Field |Wireless Field | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=5 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1 for AC Descriptor Length: 18 Stations: The number of mobile stations currently associated with the AC Limit: The maximum number of stations supported by the AC Active WTPs: The number of WTPs currently attached to the AC Max WTPs: The maximum number of WTPs supported by the AC Security: A 8 bit bit mask specifying the authentication credential type supported by the AC. The following values are supported (see Section 2.4.4): 1 - X.509 Certificate Based 2 - Pre-Shared Secret R-MAC Field: The AC supports the optional Radio MAC Address field in the CAPWAP transport Header (see Section 4.1). Wireless Field: The AC supports the optional Wireless Specific Information field in the CAPWAP transport Header (see Section 4.1). Reserved: MUST be set to zero. Vendor Identifier: A 32-bit value containing the IANA assigned "SMI Network Management Private Enterprise Codes" Type: Vendor specific encoding of AC information. The following values are supported. The Hardware and Software Version values MUST be included. 4 - Hardware Version: The AC's hardware version number. 5 - Software Version: The AC's Firmware version number. Length: Length of vendor specific encoding of AC information. Value: Vendor specific encoding of AC information. [...] 4.4.34. WTP Descriptor [...] Vendor Identifier: A 32-bit value containing the IANA assigned "SMI Network Management Private Enterprise Codes" Type: The following values are supported. The Hardware Version, Software Version, and Boot Version values MUST be included. 0 - WTP Model Number: The WTP Model Number MUST be included in the WTP Board Data message element. 1 - WTP Serial Number: The WTP Serial Number MUST be included in the WTP Board Data message element. 2 - Board ID: A hardware identifier, which MAY be included in the WTP Board Data mesage element. 3 - Board Revision A revision number of the board, which MAY be included in the WTP Board Data message element. 4 - Hardware Version: The WTP's hardware version number. 5 - Software Version: The WTP's Firmware version number. 6 - Boot Version: The WTP's boot loader's version number. Length: Length of vendor specific encoding of WTP information. Value: Vendor specific encoding of WTP information. 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 May 22 11:55:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiCkv-0004t9-I0 for capwap-archive@lists.ietf.org; Mon, 22 May 2006 11:55:41 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiCku-0007W8-1T for capwap-archive@lists.ietf.org; Mon, 22 May 2006 11:55:41 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9A8804300D5 for ; Mon, 22 May 2006 08:55:39 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3EA5E43005A for ; Mon, 22 May 2006 08:55:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 40756398059 for ; Mon, 22 May 2006 08:55:15 -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 5E84D398024 for ; Mon, 22 May 2006 08:55:11 -0700 (PDT) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 22 May 2006 08:54:48 -0700 X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208"; a="280653243:sNHT2538700338" 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 k4MFsntH028410 for ; Mon, 22 May 2006 08:54:49 -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 k4MFsnJj003820 for ; Mon, 22 May 2006 08:54:49 -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, 22 May 2006 08:54:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 May 2006 08:54:46 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201ECEBE4@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Resolution for Issue 83: RADIUS protocol handling for CAPWAP local and split MAC modes Thread-Index: AcZ9uAxuEKM2OwOOQO6ZRBee07VqMQ== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 22 May 2006 15:54:46.0485 (UTC) FILETIME=[0C8FE850:01C67DB8] 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: [Capwap] Proposed Resolution for Issue 83: RADIUS protocol handling for CAPWAP local and split MAC modes X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.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 All, I believe that there has been significant discussion around issue 83, and in the end the general consensus appeared to be to reject this request. However, I believe that by adding a single sentence in two place, we've eliminated the possibility for mis-understanding where the AAA (e.g., RADIUS) client resides. The new sentences are at the bottom of both block of text (which are included for context). 11.1.1. Split MAC [...] 802.11i 802.1X/EAP AC RSNA Key Management AC 802.11 Encryption/Decryption WTP/AC Figure 4: Mapping of 802.11 Functions for Split MAC Architecture 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 IEEE 802.11 services, including the beacon and probe response frames, are handled on the WTP. All remaining IEEE 802.11 MAC management frames are supported on the AC, including the Association Request which allows the AC to be involved in the access policy enforcement portion of the IEEE 802.11 protocol. The IEEE 802.1X and IEEE 802.11i key management function are also located on the AC. This implies that the AAA client also <==== NEW SENTENCE!!!!! resides on the AC. [...] 11.1.2. Local MAC [...] 802.11i 802.1X/EAP AC RSNA Key Management AC 802.11 Encryption/Decryption WTP Figure 6: Mapping of 802.11 Functions for Local AP Architecture Given the Distribution and Integration Services exist on the WTP, client data frames are not forwarded to the AC, with the exception listed in the following paragraphs. 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. The IEEE 802.1X and RSNA Key Management function resides in the AC. Therefore, the WTP MUST forward all IEEE 802.1X/RSNA Key Management frames to the AC and forward the associated responses to the station. This implies that the AAA client also resides on the AC. <==== NEW SENTENCE!!!!!! 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 May 22 12:20:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiD9L-0007B3-K1 for capwap-archive@lists.ietf.org; Mon, 22 May 2006 12:20:55 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiD9K-0008Jl-4j for capwap-archive@lists.ietf.org; Mon, 22 May 2006 12:20:55 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2CD414300D6 for ; Mon, 22 May 2006 09:20:53 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 2A65C43005A for ; Mon, 22 May 2006 09:20:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2FC06398048 for ; Mon, 22 May 2006 09:20: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 6ED8D39803D for ; Mon, 22 May 2006 09:20:29 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 22 May 2006 09:20:29 -0700 X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208"; a="1810513830:sNHT94469092" 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 k4MGKTbg017644 for ; Mon, 22 May 2006 09:20:29 -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 k4MGKTB9024683 for ; Mon, 22 May 2006 09:20:29 -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, 22 May 2006 09:20:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 May 2006 09:20:28 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201ECEC05@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Resolution for Issue 66: Unclear how Clear Config Indication is acknowledged Thread-Index: AcZ9u6PU2tHfm9WWTdapMX6FsoTaUQ== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 22 May 2006 16:20:28.0950 (UTC) FILETIME=[A3F16360:01C67DBB] 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: Subject: [Capwap] Proposed Resolution for Issue 66: Unclear how Clear Config Indication is acknowledged X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.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: d8ae4fd88fcaf47c1a71c804d04f413d All, The author of this issue had a point that the AC had no way to know whether the WTP had reset its configuration back to manufacturing defaults. There was an assumption made that the acknowledgement layer would provide the explicit ack, but this is a clear violation of layers. So I've changed the message from an indication to a req/response, consistent with the rest of the protocol. Below are my changes, which are few, but I am including context as well. 2.3. CAPWAP State Machine Definition [...] Run to Run (n): This is the normal state of operation. WTP: This is the WTP's normal state of operation. There are many events that result this state transition: [...] Clear Config Request: The WTP receives a Clear Config Request <==== CHANGED!!! message (see Section 8.8). The WTP MUST reset its configuration back to manufacturer defaults. [...] AC: This is the AC's normal state of operation: [...] Clear Config Response: The AC receives a Clear Config Response <==== NEW!!! message (see Section 8.9). [...] 4.3.1.1. Message Type [...] The valid values for base CAPWAP Message Types are given in the table below: [...] Data Transfer Response 22 Clear Config Request 24 <==== CHANGED!!! Clear Config Response 25 <==== NEW!!! Mobile Config Request 26 [...] 8.8. Clear Config Request <==== CHANGED text in section!!! The Clear Config Request message is used to reset a WTP's configuration. The Clear Config Request message is sent by an AC to request that a WTP reset its configuration to the manufacturing default configuration. The Clear Config Request message is sent while in the Run CAPWAP state. The Clear Config Request message carries no message elements. When a WTP receives a Clear Config Request message it resets its configuration to the manufacturing default configuration. 8.9. Clear Config Response <==== NEW SECTION!!! The Clear Config Response message is sent by the WTP after receiving a Clear Config request and resetting its configuration parameters back to the manufacturing default values. The Clear Config Request message carries the message elements. o Result Code, see Section 4.4.29 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 May 22 12:30:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiDIv-0002HI-BM for capwap-archive@lists.ietf.org; Mon, 22 May 2006 12:30:49 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiDIt-0000Et-RD for capwap-archive@lists.ietf.org; Mon, 22 May 2006 12:30:49 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6710C4300D0 for ; Mon, 22 May 2006 09:30:47 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C9AF443005A for ; Mon, 22 May 2006 09:30:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A53991448021 for ; Mon, 22 May 2006 09:30: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 DE9261448009 for ; Mon, 22 May 2006 09:30:21 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 22 May 2006 09:30:21 -0700 X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208"; a="280677707:sNHT30536384" 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 k4MGULbE025565 for ; Mon, 22 May 2006 09:30:21 -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 k4MGULBD005849 for ; Mon, 22 May 2006 09:30:21 -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, 22 May 2006 09:30:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 May 2006 09:30:20 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201ECEC1B@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Resolution for Issue 117: Global SSID Suppression Thread-Index: AcZ9vQS+k8ysZTCzRTePTLDzHC1y4A== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 22 May 2006 16:30:21.0453 (UTC) FILETIME=[051A2BD0:01C67DBD] 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: [Capwap] Proposed Resolution for Issue 117: Global SSID Suppression X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.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: 79899194edc4f33a41f49410777972f8 The submitter of this issue was correct that given that there is a per-WLAN flag in the "IEEE 802.11 Add WLAN" message element, there I no need for the IEEE 802.11 Broadcast Probe Mode". Any WTP that was relying on this knob to determine whether any of the WLANs had their individual broadcast suppression flag enabled, could run a separate boolean independent of the protocol, based on what it receives from the various WLAN configurations. Consequently, this message element is being removed from the draft in the -02 version. 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 May 22 12:35:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiDN9-0002dZ-Cd for capwap-archive@lists.ietf.org; Mon, 22 May 2006 12:35:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiDN5-0000UQ-Pt for capwap-archive@lists.ietf.org; Mon, 22 May 2006 12:35:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7059A4300DC for ; Mon, 22 May 2006 09:35:07 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 971EF43005A for ; Mon, 22 May 2006 09:34:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9A56C39804E for ; Mon, 22 May 2006 09:34:41 -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 08D80398051 for ; Mon, 22 May 2006 09:34:38 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-3.cisco.com with ESMTP; 22 May 2006 09:34:03 -0700 X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208,217"; a="428313020:sNHT17403059276" 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 k4MGY32f031907 for ; Mon, 22 May 2006 09:34:03 -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 k4MGY3sF019228 for ; Mon, 22 May 2006 09:34:03 -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, 22 May 2006 09:34:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 May 2006 09:34:02 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201ECEC22@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 107: Broadcast Probe Mode and Supress SSID Configuration Thread-Index: AcZ9vYjWajoPyYlXTMiSErUZDo7eAA== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 22 May 2006 16:34:02.0992 (UTC) FILETIME=[89265700:01C67DBD] 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.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: [Capwap] Issue 107: Broadcast Probe Mode and Supress SSID Configuration X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.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="===============0995419148==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d This is a multi-part message in MIME format. --===============0995419148== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67DBD.8918D0E5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67DBD.8918D0E5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 Not being sure who created this issue to begin with, I will ask the group as a whole. I believe that this issue is no longer valid since the IEEE 802.11 Broadcast Probe Mode message element has been removed. Any issues in simply closing this issue, or was there a different request in this issue that was not covered by issue 117? =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C67DBD.8918D0E5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
Not = being sure who=20 created this issue to begin with, I will ask the group as a whole. I = believe=20 that this issue is no longer valid since the IEEE 802.11 Broadcast Probe = Mode=20 message element has been removed. Any issues in simply closing this = issue, or=20 was there a different request in this issue that was not covered by = issue=20 117?
 

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

 
------_=_NextPart_001_01C67DBD.8918D0E5-- --===============0995419148== 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 --===============0995419148==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon May 22 13:53:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEbI-00089T-Rt for capwap-archive@lists.ietf.org; Mon, 22 May 2006 13:53:52 -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 1FiCUg-0006aQ-IG for capwap-archive@lists.ietf.org; Mon, 22 May 2006 11:38:54 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FiCFK-0003Qd-M2 for capwap-archive@lists.ietf.org; Mon, 22 May 2006 11:23:05 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5B6B74300DF for ; Mon, 22 May 2006 08:23:01 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 54B8243005A for ; Mon, 22 May 2006 08:22:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3A06B1448025 for ; Mon, 22 May 2006 08:22:36 -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 650CC1448023 for ; Mon, 22 May 2006 08:22:33 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 22 May 2006 08:22:31 -0700 X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208"; a="280632475:sNHT77597840" 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 k4MFMVwY008229 for ; Mon, 22 May 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-5.cisco.com (8.12.10/8.12.6) with ESMTP id k4MFMVHc010075 for ; Mon, 22 May 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, 22 May 2006 08:22:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 May 2006 08:22:31 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201ECEBC9@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Resolution for Issue 120: Issues with new CAPWAP header format AND Issue 119: Add encapsulated data type in CAPWAP data header Thread-Index: AcZ9s4sPT9w4VvU1TGGrfhiZJsRv8w== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 22 May 2006 15:22:31.0447 (UTC) FILETIME=[8B308A70:01C67DB3] 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] Proposed Resolution for Issue 120: Issues with new CAPWAP header format AND Issue 119: Add encapsulated data type in CAPWAP data header X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.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.3 (--) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e All, Please see issues 120 and 119 for the various issues with the new header text in the -01 draft. Below are my proposed changes, which I would like to get some comments on. 4.1. CAPWAP Transport Header All CAPWAP protocol messages are encapsulated using a common header format, regardless of the CAPWAP control or CAPWAP Data transport used to carry the messages. However, certain flags are not applicable for a given transport. Refer to the specific transport section in order to determine which flags are valid. Note that the optional fields defined in this section MUST be present in the precise order shown below. 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 | WBID |T|F|L|W|M| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment ID | Frag Offset |Rsvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Radio MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Wireless Specific Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version: A 4 bit field which contains the version of CAPWAP used in this packet. The value for this draft is 0. 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. HLEN: A 5 bit field containing the length of the CAPWAP transport header in 4 byte words (Similar to IP header length). This length includes the optional headers. WBID: A 5 bit field which is the wireless binding identifier. The identifier will indicate the type of wireless packet type associated with the radio. The following values are defined: 1 - IEEE 802.11 T: The Type 'T' bit indicates the format of the frame being transported in the payload (see Section 11.4). 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. F: The Fragment 'F' bit indicates whether this packet is a fragment. When this bit is one (1), the packet is a fragment and MUST be combined with the other corresponding fragments to reassemble the complete information exchanged between the WTP and AC. L: The 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 the last fragment. When this bit is 0, the packet is not 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 header is present. M: The M bit is used to indicate that the Radio MAC Address optional header is present. This is used to communicate the MAC address of the receiving radio when the native wireless packet. This field MUST NOT be set to one in packets sent by the AC to the WTP. Flags: A set of reserved bits for future flags in the CAPWAP header. All implementations complying with version zero of this protocol MUST set these bits to zero. Fragment ID: An 16 bit 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 Fragment ID wraps to zero after the maximum value has been used to identify a set of fragments. Fragment Offset: A 13 bit field that indicates where in the payload will this 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. Note the CAPWAP protocol does not allow for overlapping fragments. For instance, fragment 0 would include offset 0 with a payload length of 1000, while fragment 1 include offset 900 with a payload length of 600. Reserved: The 3-bit Reserved field is reserved and set to 0 in this version of the CAPWAP protocol. Radio MAC Address: This optional field contains the MAC address of the radio receiving the packet. This is useful 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 assumes 4 byte alignment, this field MUST be padded with zeroes (0x00) if it is not 4 byte aligned. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | MAC Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: The number of bytes in the MAC Address field. The length field is present since new IEEE technologies are using 48 byte MAC addresses. MAC Address: The MAC Address 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 byte alignment, this field MUST be padded with zeroes (0x00) if it is not 4 byte aligned. 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 bindings section (see Section 11.4. Payload: This field contains the header for a CAPWAP Data Message or CAPWAP Control Message, followed by the data associated with that message. [...] 11.4. Technology Specific Bindings All CAPWAP transports have the following IEEE 802.11 specific bindings: [...] Optional Wireless Specific Information The optional CAPWAP header field (see Section 4.1) is only used with CAPWAP data frames, and it serves two purposes, depending upon the direction of the frame. For packets from the WTP to the AC, the field uses the format described in the "IEEE 802.11 Frame Info" field (see below). However, for frames sent by the AC to the WTP, the format used is described in described in the "Destination WLANs" field (also defined below). [...] 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 May 22 14:36:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiFGh-0007BO-04 for capwap-archive@lists.ietf.org; Mon, 22 May 2006 14:36:39 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiFGe-00061V-Fa for capwap-archive@lists.ietf.org; Mon, 22 May 2006 14:36:38 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B24804300CC for ; Mon, 22 May 2006 11:36:34 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7CE30430064 for ; Mon, 22 May 2006 11:36:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 654801448021 for ; Mon, 22 May 2006 11:36:08 -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 52A50144801D for ; Mon, 22 May 2006 11:36:05 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 22 May 2006 11:36:05 -0700 X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208,217"; a="428342506:sNHT52636672" 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 k4MIa4CT006240 for ; Mon, 22 May 2006 11:36:04 -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 k4MIa4B9014118 for ; Mon, 22 May 2006 11:36:04 -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, 22 May 2006 11:36:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 May 2006 11:36:03 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201ECECEA@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Error in remove capability field in Add/Update WLAN Thread-Index: AcZ9zpRQQ3T5JnKYQe2Woz0XsfGSuw== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 22 May 2006 18:36:04.0627 (UTC) FILETIME=[952F2E30:01C67DCE] 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: Subject: [Capwap] Error in remove capability field in Add/Update WLAN X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.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="===============1620475687==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is a multi-part message in MIME format. --===============1620475687== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67DCE.9512E81B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67DCE.9512E81B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 It appears that in making a change in the -01 to introduce the IEEE 802.11 Information Element, we removed the capability field and instead stated that the Power Capability Information Field is to be included in the message. The issue is that the original intent of the capability field was to include the contents of the capability information field, not the information element. The information field does not have an IE, and therefore MUST be added back to the Add/Update WLAN message element. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C67DCE.9512E81B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
It = appears that in=20 making a change in the -01 to introduce the IEEE 802.11 Information = Element, we=20 removed the capability field and instead stated that the Power=20 Capability Information Field is to be included in the message. The = issue is=20 that the original intent of the capability field was to include the = contents of=20 the capability information field, not the information element. The = information=20 field does not have an IE, and therefore MUST be added back to the = Add/Update=20 WLAN message element.
 

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

 
------_=_NextPart_001_01C67DCE.9512E81B-- --===============1620475687== 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 --===============1620475687==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon May 22 14:39:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiFJL-0008Dm-CW for capwap-archive@lists.ietf.org; Mon, 22 May 2006 14:39:23 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiFJJ-00069f-RF for capwap-archive@lists.ietf.org; Mon, 22 May 2006 14:39:23 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 708174300D6 for ; Mon, 22 May 2006 11:39:21 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 2FE38430082 for ; Mon, 22 May 2006 11:38:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2EAE5398052 for ; Mon, 22 May 2006 11:38:55 -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 A732539801E for ; Mon, 22 May 2006 11:38:52 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 22 May 2006 11:38:48 -0700 X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208,217"; a="1810610843:sNHT6304166326" 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 k4MIcmO0004680 for ; Mon, 22 May 2006 11:38:48 -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 k4MIcmJj025267 for ; Mon, 22 May 2006 11:38:48 -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, 22 May 2006 11:38:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 May 2006 11:38:47 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201ECECEE@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Error in remove capability field in Add/Update WLAN Thread-Index: AcZ9zpRQQ3T5JnKYQe2Woz0XsfGSuwAAFy3Q From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 22 May 2006 18:38:48.0027 (UTC) FILETIME=[F6940AB0:01C67DCE] 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: Subject: Re: [Capwap] Error in remove capability field in Add/Update WLAN X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.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="===============1788520138==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 This is a multi-part message in MIME format. --===============1788520138== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67DCE.F6824227" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67DCE.F6824227 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Issue 123 created to track this issue =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Pat Calhoun (pacalhou)=20 Sent: Monday, May 22, 2006 11:36 AM To: capwap Subject: [Capwap] Error in remove capability field in Add/Update WLAN =09 =09 All, =20 It appears that in making a change in the -01 to introduce the IEEE 802.11 Information Element, we removed the capability field and instead stated that the Power Capability Information Field is to be included in the message. The issue is that the original intent of the capability field was to include the contents of the capability information field, not the information element. The information field does not have an IE, and therefore MUST be added back to the Add/Update WLAN message element. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C67DCE.F6824227 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Issue=20 123 created to track this issue
 

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

 

From: Pat Calhoun (pacalhou) =
Sent:=20 Monday, May 22, 2006 11:36 AM
To: capwap
Subject: = [Capwap]=20 Error in remove capability field in Add/Update = WLAN

All,
 
It = appears that in=20 making a change in the -01 to introduce the IEEE 802.11 Information = Element,=20 we removed the capability field and instead stated that the Power=20 Capability Information Field is to be included in the message. = The issue=20 is that the original intent of the capability field was to include the = contents of the capability information field, not the information = element. The=20 information field does not have an IE, and therefore MUST be added = back to the=20 Add/Update WLAN message element.
 

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

 
------_=_NextPart_001_01C67DCE.F6824227-- --===============1788520138== 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 --===============1788520138==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon May 22 15:15:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiFsg-0005V8-RY for capwap-archive@lists.ietf.org; Mon, 22 May 2006 15:15:55 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiFse-0007pG-Rl for capwap-archive@lists.ietf.org; Mon, 22 May 2006 15:15:54 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B55AA4300AB for ; Mon, 22 May 2006 12:15:51 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 499A643005A for ; Mon, 22 May 2006 12:15:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id EF97139800B for ; Mon, 22 May 2006 12:15:07 -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 74BFF39803B for ; Mon, 22 May 2006 12:15:03 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 22 May 2006 12:15:04 -0700 X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208"; a="428347377:sNHT46508852" 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 k4MJF21l011770 for ; Mon, 22 May 2006 12:15:02 -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 k4MJF2BD012362 for ; Mon, 22 May 2006 12:15:02 -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, 22 May 2006 12:15:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 May 2006 12:15:01 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201ECED1E@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Text for Issue 18: use MIB variable names instead Thread-Index: AcZ91AYZJKf9jvRLSmCDGyKh9lZGrg== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 22 May 2006 19:15:02.0583 (UTC) FILETIME=[06B6F470:01C67DD4] 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: [Capwap] Proposed Text for Issue 18: use MIB variable names instead X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.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: efc5d1db3729b4b7031f1bb5f5a30ae3 All, This issue has been opened for quite some time, and I finally got around to handling it. Note that when this issue was first raised, I stated that we should not adopt the names to the MIB elements, but did agree that references would be useful. In doing this, I used the soon to be 802.11-2006 specification, and found a few issues that I have fixed. Please note that given the breath of the changes here, I am only including context and the proposed changes. Unfortunately, this change touches many parts of the text, so this e-mail will be quite lengthy. Other than references to MIB values, the following have changed significantly: - 11.10.9. It was used by the WTP to report MIC failures, but the 802.11i specification actually includes many other failures that need to be reported. - 11.10.14. This section was missing some statistics that were added as part of the 802.11e specification. As usual, comments are welcomed. [...] 11.10.2. IEEE 802.11 Antenna [...] Diversity: An 8-bit value specifying whether the antenna is to provide receive diversity. The value of this field is the same as the IEEE 802.11 dot11DiversitySelectionRx MIB element (see [6]). The following values are supported: [...] Antenna Count: An 8-bit value specifying the number of Antenna Selection fields. This value should be the same as the one found in the IEEE 802.11 dot11CurrentTxAntenna MIB element (see [6]). [...] 11.10.5. IEEE 802.11 Direct Sequence Control [...] Current Channel: This attribute contains the current operating frequency channel of the DSSS PHY. This value comes from the IEEE 802.11 dot11CurrentChannel MIB element (see [6]). Current CCA: The current CCA method in operation, whose value can be found in the IEEE 802.11 dot11CCAModeSupported MIB element (see [6]). Valid values are: [...] Energy Detect Threshold: The current Energy Detect Threshold being used by the DSSS PHY. The value can be found in the IEEE 802.11 dot11EDThreshold MIB element (see [6]). [...] 11.10.7. IEEE 802.11 MAC Operation [...] RTS Threshold: This attribute indicates the number of octets in an MPDU, below which an RTS/CTS handshake MUST NOT be performed. An RTS/CTS handshake MUST be performed at the beginning of any frame exchange sequence where the MPDU is of type Data or Management, the MPDU has an individual address in the Address1 field, and the length of the MPDU is greater than this threshold. Setting this attribute to be larger than the maximum MSDU size MUST have the effect of turning off the RTS/CTS handshake for frames of Data or Calhoun, Editor, et al. Expires November 23, 2006 [Page 111] Internet-Draft CAPWAP Protocol Specification May 2006 Management type transmitted by this STA. Setting this attribute to zero MUST have the effect of turning on the RTS/CTS handshake for all frames of Data or Management type transmitted by this STA. The default value of this attribute MUST be 2347. The value of this field comes from the IEEE 802.11 dot11RTSThreshold MIB element (see [6]). Short Retry: This attribute indicates the maximum number of transmission attempts of a frame, the length of which is less than or equal to RTSThreshold, that MUST be made before a failure condition is indicated. The default value of this attribute MUST be 7. The value of this field comes from the IEEE 802.11 dot11ShortRetryLimit MIB element (see [6]). Long Retry: This attribute indicates the maximum number of transmission attempts of a frame, the length of which is greater than dot11RTSThreshold, that MUST be made before a failure condition is indicated. The default value of this attribute MUST be 4. The value of this field comes from the IEEE 802.11 dot11LongRetryLimit MIB element (see [6]). Fragmentation Threshold: This attribute specifies the current maximum size, in octets, of the MPDU that MAY be delivered to the PHY. An MSDU MUST be broken into fragments if its size exceeds the value of this attribute after adding MAC headers and trailers. An MSDU or MMPDU MUST be fragmented when the resulting frame has an individual address in the Address1 field, and the length of the frame is larger than this threshold. The default value for this attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the attached PHY and MUST never exceed the lesser of 2346 or the aMPDUMaxLength of the attached PHY. The value of this attribute MUST never be less than 256. The value of this field comes from the IEEE 802.11 dot11FragmentationThreshold MIB element (see [6]). Tx MSDU Lifetime: This attribute speficies the elapsed time in TU, after the initial transmission of an MSDU, after which further attempts to transmit the MSDU MUST be terminated. The default value of this attribute MUST be 512. The value of this field comes from the IEEE 802.11 dot11MaxTransmitMSDULifetime MIB element (see [6]). Rx MSDU Lifetime: This attribute specifies the elapsed time in TU, after the initial reception of a fragmented MMPDU or MSDU, after which further attempts to reassemble the MMPDU or MSDU MUST be terminated. The default value MUST be 512. The value of this field comes from the IEEE 802.11 dot11MaxReceiveLifetime MIB element (see [6]). [...] 11.10.8. IEEE 802.11 MIC Countermeasures The MIC Countermeasures message element is sent by the WTP to the AC to indicate the occurrence of a MIC failure. See the IEEE 802.11 dot11RSNATKIPCounterMeasuresInvoked MIB element (see [6]) for more info. [...] 11.10.9. IEEE 802.11 RSNA Error Report From Mobile The RSN Error Report From Mobile message element is sent by an AC to an WTP to send RSN error reports to the AC. The WTP does not need to transmit any reports that do not include any failures. The fields from this message element comes from the IEEE 802.11 Dot11RSNAStatsEntry table (see [6]). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client MAC Address | BSSID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSSID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | WLAN ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TKIP ICV Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TKIP Local MIC Failures | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TKIP Remote MIC Failures | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CCMP Replays | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CCMP Decrypt Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TKIP Replays | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1032 for IEEE 802.11 RSNA Error Report From Mobile Length: 14 Client MAC Address: The Client MAC Address of the station. BSSID: The BSSID on which the failures are being reported on. Radio ID: The Radio Identifier, typically refers to some interface index on the WTP WLAN ID: The WLAN ID on which the RSNA failures are being reported. TKIP ICV Errors: A 32-bit value representing the number of TKIP ICV errors encountered when decrypting packets from the station. The value of this field comes from the IEEE 802.11 dot11RSNAStatsTKIPICVErrors MIB element (see [6]). TKIP Local MIC Failures: A 32-bit value representing the number of MIC failures encountered when checking the integrity of packets received from the station. The value of this field comes from the IEEE 802.11 dot11RSNAStatsTKIPLocalMICFailures MIB element (see [6]). TKIP Remote MIC Failures: A 32-bit value representing the number of MIC failures reported by the station encountered (possibly via the EAPOL-Key frame). The value of this field comes from the IEEE 802.11 dot11RSNAStatsTKIPRemoteMICFailures MIB element (see [6]). CCMP Replays: A 32-bit value representing the number of CCMP MPDUs discarded by the replay detection mechanism. The value of this field comes from the IEEE 802.11 dot11RSNACCMPReplays MIB element (see [6]). CCMP Decrypt Errors: A 32-bit value representing the number of CCMP MDPUs discarded by the decryption algorithm. The value of this field comes from the IEEE 802.11 dot11RSNACCMPDecryptErrors MIB element (see [6]). TKIP Replays: A 32-bit value representing the number of TKIP Replays detected in frames received from the station. The value of this field comes from the IEEE 802.11 dot11RSNAStatsTKIPReplays MIB element (see [6]). [...] 11.10.10. IEEE 802.11 Mobile [...] Supported Rates: The variable length field containing the supported rates to be used with the mobile station, as found in the IEEE 802.11 dot11OperationalRateSet MIB element (see [6]). [...] 11.10.12. IEEE 802.11 Multi-domain Capability [...] First Channnel #: This attribute indicates the value of the lowest channel number in the subband for the associated domain country string. The value of this field comes from the IEEE 802.11 dot11FirstChannelNumber MIB element (see [6]). Number of Channels: This attribute indicates the value of the total number of channels allowed in the subband for the associated domain country string. The value of this field comes from the IEEE 802.11 dot11NumberofChannels MIB element (see [6]). Max Tx Power Level: This attribute indicates the maximum transmit power, in dBm, allowed in the subband for the associated domain country string. The value of this field comes from the IEEE 802.11 dot11MaximumTransmitPowerLevel MIB element (see [6]). [...] 11.10.13. IEEE 802.11 OFDM Control [...] Current Channel: This attribute contains the current operating frequency channel of the OFDM PHY. The value of this field comes from the IEEE 802.11 dot11CurrentFrequency MIB element (see [6]). Band Supported: The capability of the OFDM PHY implementation to operate in the three U-NII bands. The value of this field comes from the IEEE 802.11 dot11FrequencyBandsSupported MIB element (see [6]), coded as an integer value of a three bit field as follows: capable of operating in the lower (5.15-5.25 GHz) U-NII band capable of operating in the middle (5.25-5.35 GHz) U-NII band capable of operating in the upper (5.725-5.825 GHz) U-NII band For example, for an implementation capable of operating in the lower and mid bands this attribute would take the value TI Threshold: The Threshold being used to detect a busy medium (frequency). CCA MUST report a busy medium upon detecting the RSSI above this threshold. The value of this field comes from the IEEE 802.11 dot11TIThreshold MIB element (see [6]). [...] 11.10.14. IEEE 802.11 Rate Set [...] Rate Set: The AC generates the Rate Set that the WTP is to include in it's Beacon and Probe messages. The length of this field is between 2 and 8 bytes. The value of this field comes from the IEEE 802.11 dot11OperationalRateSet MIB element (see [6]). [...] 11.10.15. IEEE 802.11 Statistics [...] | Discarded QoS Fragment Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Associated Station Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QoS CF Polls Received Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QoS CF Polls Unused Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QoS CF Polls Unusable Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [...] Tx Fragment Count: A 32-bit value representing the number of fragmented frames transmitted. The value of this field comes from the IEEE 802.11 dot11TransmittedFragmentCount MIB element (see [6]). Multicast Tx Count: A 32-bit value representing the number of multicast frames transmitted. The value of this field comes from the IEEE 802.11 dot11MulticastTransmittedFrameCount MIB element (see [6]). Failed Count: A 32-bit value representing the transmit excessive retries. The value of this field comes from the IEEE 802.11 dot11FailedCount MIB element (see [6]). Retry Count: A 32-bit value representing the number of transmit retries. The value of this field comes from the IEEE 802.11 dot11RetryCount MIB element (see [6]). Multiple Retry Count: A 32-bit value representing the number of transmits that required more than one retry. The value of this field comes from the IEEE 802.11 dot11MultipleRetryCount MIB element (see [6]). Frame Duplicate Count: A 32-bit value representing the duplicate frames received. The value of this field comes from the IEEE 802.11 dot11FrameDuplicateCount MIB element (see [6]). RTS Success Count: A 32-bit value representing the number of successfully transmitted Ready To Send (RTS). The value of this field comes from the IEEE 802.11 dot11RTSSuccessCount MIB element (see [6]). RTS Failure Count: A 32-bit value representing the failed transmitted RTS. The value of this field comes from the IEEE 802.11 dot11RTSFailureCount MIB element (see [6]). ACK Failure Count: A 32-bit value representing the number of failed acknowledgements. The value of this field comes from the IEEE 802.11 dot11ACKFailureCount MIB element (see [6]). Rx Fragment Count: A 32-bit value representing the number of fragmented frames received. The value of this field comes from the IEEE 802.11 dot11ReceivedFragmentCount MIB element (see [6]). Multicast RX Count: A 32-bit value representing the number of multicast frames received. The value of this field comes from the IEEE 802.11 dot11MulticastReceivedFrameCount MIB element (see [6]). FCS Error Count: A 32-bit value representing the number of FCS failures. The value of this field comes from the IEEE 802.11 dot11FCSErrorCount MIB element (see [6]). Decryption Errors: A 32-bit value representing the number of Decryption errors that occurred on the WTP. Note that this field is only valid in cases where the WTP provides encryption/ decryption services. The value of this field comes from the IEEE 802.11 dot11WEPUndecryptableCount MIB element (see [6]). Discarded QoS Fragment Count: A 32-bit value representing the number of discarded QoS fragments received. The value of this field comes from the IEEE 802.11 dot11QoSDiscardedFragmentCount MIB element (see [6]). Associated Station Count: A 32-bit value representing the number of number of associated stations. The value of this field comes from the IEEE 802.11 dot11AssociatedStationCount MIB element (see [6]). QoS CF Polls Received Count: A 32-bit value representing the number of (+)CF-Polls received. The value of this field comes from the IEEE 802.11 dot11QosCFPollsReceivedCount MIB element (see [6]). QoS CF Polls Unused Count: A 32-bit value representing the number of (+)CF-Polls that have been received, but not used. The value of this field comes from the IEEE 802.11 dot11QosCFPollsUnusedCount MIB element (see [6]). QoS CF Polls Unusable Count: A 32-bit value representing the number of (+)CF-Polls that have been received, but could not be used due to the TXOP size being smaller than the timethat is required for one frame exchange sequence. The value of this field comes from the IEEE 802.11 dot11QosCFPollsUnusableCount MIB element (see [6]). [...] 11.10.18. IEEE 802.11 Tx Power Level The Tx power level message element is sent by the WTP and contains the different power levels supported. The values found in this message element are found in the IEEE 802.11 Dot11PhyTxPowerEntry MIB table (see (see [6]). [...] Num Levels: The number of power level attributes. The value of this field comes from the IEEE 802.11 dot11NumberSupportedPowerLevels MIB element (see [6]). Power Level: Each power level fields contains a supported power level, in mW. The value of this field comes from the corresponding IEEE 802.11 dot11TxPowerLevel[n] MIB element (see [6]). [...] 11.10.21. IEEE 802.11 WTP Quality of Service [...] CWMin: The Contention Window minimum value for the QoS transmit queue. The value of this field comes from the IEEE 802.11 dot11EDCATableCWMin MIB element (see [6]). CWMax: The Contention Window maximum value for the QoS transmit queue. The value of this field comes from the IEEE 802.11 dot11EDCATableCWMax MIB element (see [6]). AIFS: The Arbitration Inter Frame Spacing to use for the QoS transmit queue. The value of this field comes from the IEEE 802.11 dot11EDCATableAIFSN MIB element (see [6]). [...] 11.10.23. IEEE 802.11 WTP Radio Configuration [...] DTIM Period: This attribute specifies the number of beacon intervals that elapse between transmission of Beacons frames containing a TIM element whose DTIM Count field is 0. This value is transmitted in the DTIM Period field of Beacon frames. The value of this field comes from the IEEE 802.11 dot11DTIMPeriod MIB element (see [6]). Beacon Period: This attribute specifies the number of TU that a station uses for scheduling Beacon transmissions. This value is transmitted in Beacon and Probe Response frames. The value of this field comes from the IEEE 802.11 dot11BeaconPeriod MIB element (see [6]). Country Code: This attribute identifies the country in which the station is operating. The value of this field comes from the IEEE 802.11 dot11CountryString MIB element (see [6]). Special attention is required with use of this field, as implementations which take action based on this field could violate regulatory requirements. Some regulatory bodies do permit configuration of the country code under certain restrictions, such as the FCC, when WTPs are certified as Software Defined Radios. [...] 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 May 22 15:20:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiFwz-0005r3-CI for capwap-archive@lists.ietf.org; Mon, 22 May 2006 15:20:21 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiFwx-0007y0-S6 for capwap-archive@lists.ietf.org; Mon, 22 May 2006 15:20:21 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 79A444300D8 for ; Mon, 22 May 2006 12:20:19 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D94B943005A for ; Mon, 22 May 2006 12:19:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C6CCF144800C for ; Mon, 22 May 2006 12:19:55 -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 066001448006 for ; Mon, 22 May 2006 12:19:52 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 22 May 2006 12:19:53 -0700 X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208"; a="1810640507:sNHT32084340" 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 k4MJJqgH013123 for ; Mon, 22 May 2006 12:19:52 -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 k4MJJlsP021135 for ; Mon, 22 May 2006 12:19:52 -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, 22 May 2006 12:19:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 May 2006 12:19:49 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201ECED27@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Text for Issue 123: Error in remove capability field in Add/Update WLAN Thread-Index: AcZ91LGHbJFCcdkvTQOYAeSWNJ4cnw== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 22 May 2006 19:19:49.0720 (UTC) FILETIME=[B1DC9580:01C67DD4] Authentication-Results: sj-dkim-7.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] Proposed Text for Issue 123: Error in remove capability field in Add/Update WLAN X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.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 As previously mentioned, there was a misunderstanding in the capability field, as folks were under the impression this was the Power Capability Information Element, when it was really the Capability Information Field, of which no IE exists. This field needed to be added back in the IEEE 802.11 Add WLAN and IEEE 802.11 Update WLAN message elements, which I am including below. Comments welcomed. 11.10.1. IEEE 802.11 Add WLAN The Add WLAN message element is used by the AC to define a wireless LAN on the WTP. The inclusion of this message element MUST also include IEEE 802.11 Information Element message elements, containing the following 802.11 IEs: Power Capability information 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | WLAN ID | Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encryption Policy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [...] Capability: A 16-bit value containing the capabilities information field to be advertised by the WTP within the Probe and Beacon messages. [...] 11.10.20. IEEE 802.11 Update WLAN The Update WLAN message element is used by the AC to define a wireless LAN on the WTP. The inclusion of this message element MUST also include the IEEE 802.11 Information Element message element, containing the following 802.11 IEs: Power Capability information 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | WLAN ID | Capability | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encryption Policy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Index | Shared Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [...] Capability: A 16-bit value containing the capabilities information field to be advertised by the WTP within the Probe and Beacon messages. [...] 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 May 22 15:33:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiG9S-0003Dh-8S for capwap-archive@lists.ietf.org; Mon, 22 May 2006 15:33:14 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiG9P-0008TT-PP for capwap-archive@lists.ietf.org; Mon, 22 May 2006 15:33:14 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6CA6A4300D2 for ; Mon, 22 May 2006 12:33:11 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 5C95143005A for ; Mon, 22 May 2006 12:32:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 303CE39803B for ; Mon, 22 May 2006 12:32:50 -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 81A0D39803E for ; Mon, 22 May 2006 12:32:46 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 22 May 2006 12:32:46 -0700 X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208"; a="1810648514:sNHT448172384" 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 k4MJWjp4018020 for ; Mon, 22 May 2006 12:32:45 -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 k4MJWjHe018280 for ; Mon, 22 May 2006 12:32:45 -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, 22 May 2006 12:32:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 May 2006 12:32:44 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201ECED44@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 90: Using 802.3 for tunnelling in Split-MAC mode Thread-Index: AcZ91n/J2g4cRk6WTfOkjNrtPlkmqQ== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 22 May 2006 19:32:45.0324 (UTC) FILETIME=[80285CC0:01C67DD6] 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: [Capwap] Issue 90: Using 802.3 for tunnelling in Split-MAC 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: 97adf591118a232206bdb5a27b217034 All, I'd like to re-open the discussion around the use of 802.3 tunneling. When the original proponents of encapsulating 802.3 came forth, they requested that local MAC support both local bridging and 802.3. Consequently, the split MAC mode only supports the native frame format (e.g., IEEE 802.11 supports 802.11 frame formats). Puneet raised an issue that he believes that Split MAC must support 802.3 as well, and not to support any tunneling in local MAC mode. Puneet, correct me if I am incorrect here. Well, the issue here is that including an 802.3 frame in CAPWAP is NOT split MAC. Many fields are lost in the translation (e.g., four address field, 802.11e UP field). From memory, the folks that are asking for the optional BSSID in the CAPWAP header to be optional also appears to be the ones that are favoring this issue (90). However, if one removes the BSSID field, how would the AC even know which BSSID an 802.1X is being run against? The AC would lose all such information, and it's not clear how we could support multiple SSIDs per WTP. Also not clear how IAPP frame formats would be handled, as these would also lose their BSSID context, which is important. With that I would like to reopen this conversation. 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 May 22 16:40:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiHCc-0001xD-5M for capwap-archive@lists.ietf.org; Mon, 22 May 2006 16:40:34 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiHCX-0003oR-Cf for capwap-archive@lists.ietf.org; Mon, 22 May 2006 16:40:34 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4A2964300E4 for ; Mon, 22 May 2006 13:40:24 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7A08343005A for ; Mon, 22 May 2006 13:39:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 62DF7144800F for ; Mon, 22 May 2006 13:39:57 -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 34096144801D for ; Mon, 22 May 2006 13:39:53 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 22 May 2006 13:39:53 -0700 X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208"; a="280856443:sNHT74698764" 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 k4MKdrxR026454 for ; Mon, 22 May 2006 13:39:53 -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 k4MKdhKH029412 for ; Mon, 22 May 2006 13:39:52 -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, 22 May 2006 13:39:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 May 2006 13:39:49 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201ECEDA6@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Text for Issue 116: Encryption Policy should use RSNA IE Thread-Index: AcZ93973d6YIxwXlRAyQuWrdDHUGdg== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 22 May 2006 20:39:51.0163 (UTC) FILETIME=[DFBEA4B0:01C67DDF] Authentication-Results: sj-dkim-7.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] Proposed Text for Issue 116: Encryption Policy should use RSNA IE X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.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: bc6181926481d86059e678c9f7cb8b34 All, Below is the proposed text for issue 116, which is to replace the encryption policy flags to instead rely on the RSN Information Element. Comments welcomed. 11.1.1. Split MAC This section shows the division of labor between the WTP and the AC in a Split MAC architecture. Figure 4 shows the clear separation of functionality among CAPWAP components. [...] o If the WTP is providing encryption/decryption services, once the client has completed the IEEE 802.11i key exchange, the AC transmits another Add Mobile request to the WTP, stating the security policy to enforce for the client (in this case AES-CCMP), as well as the encryption key to use. If encryption/decryption is handled in the AC, the IEEE 802.11 Add Mobile Station request would not include the RSN Information Element. [...] 11.10.1. IEEE 802.11 Add WLAN [...] If present, the RSN information element is sent along with the IEEE 802.11 Add WLAN in order to instruct the WTP on the usage of the Key field. Note that ACs MAY include additional information elements as they see fit. The message element uses 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | WLAN ID | Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Index | Key Status | Key Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QoS | Auth Type | MAC Mode | Tunnel Mode | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Suppress SSID | SSID ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: 1024 for IEEE 802.11 Add WLAN Length: >= 49 Radio ID: An 8-bit value representing the radio. WLAN ID: An 8-bit value specifying the WLAN Identifier. Capability: A 16-bit value containing the capabilities information field to be advertised by the WTP within the Probe and Beacon messages. Key-Index: The Key Index associated with the key. Key Status: A 1 byte value that specifies the state and usage of the key that has been included. The following values describe the key usage and its status: 0 - A value of zero, with the inclusion of the RSN Information Element means that the WLAN uses per-station encryption keys, and therefore the key in the 'Key' field is only used for multicast traffic. 1 - When set to one, the WLAN employs a shared WEP key, also known as a static WEP key, and uses the encryption key for both unicast and multicast traffic for all stations. 2 - The value of 2 indicates that the AC will begin rekeying the GTK with the STA's in the BSS. It is only valid when IEEE 802.11i is enabled as the security policy for the BSS. 3 - The value of 3 indicates that the AC has completed rekeying the GTK and broadcast packets no longer need to be duplicated and transmitted with both GTK's. Key Length: A 16-bit value representing the length of the Key field. Key: A 32 byte Session Key to use to provide data privacy. For static WEP keys, which is true when the 'Key Status' bit is set to one, this key is used for both unicast and multicast traffic. For encryption schemes that employ a separate encryption key for unicast and multicast traffic, the key included hereonly applies to multicast data, and the cipher suite is specified in an accompanied RSN Information Element. In these scenarios, the key, and cipher information, is communicated via the Add Mobile Station (Section 4.4.8). [...] 11.10.11. IEEE 802.11 Mobile Session Key The Mobile Session Key Payload message element is sent when the AC determines that encryption of a mobile station must be performed in the WTP. This message element MUST NOT be present without the IEEE 802.11 Mobile (see Section 11.10.10) message element, and MUST NOT be sent if the WTP had not specifically advertised support for the requested encryption scheme. The RSN information element MUST sent along with the IEEE 802.11 Mobile Session Key in order to instruct the WTP on the usage of the Key field. The AKM field of the RSM information element is used by the WTP to identify the authentication protocol. If the IEEE 802.11 Mobile Session Key message element's AKM-Only bit is set, the WTP MUST drop all IEEE 802.11 packets that are not part of the AKM (e.g., EAP). Note that AKM-Only is MAY be set while an encryption key is in force, requiring that the AKM packets be encrypted. Once the mobile station has successfully completed authentication via the AKM, the AC must send a new Add Mobile message element to remove the AKM-Only restriction, and optionally push the session key down to 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address |A|C| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pairwise TSC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pairwise TSC | Pairwise RSC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pairwise RSC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key... +-+-+-+-+-+-+-+- [...] 11.10.20. IEEE 802.11 Update WLAN The Update WLAN message element is used by the AC to define a wireless LAN on the WTP. The inclusion of this message element MUST also include the IEEE 802.11 Information Element message element, containing the following 802.11 IEs: Power Capability information element WPA information element RSN information element EDCA Parameter Set information element QoS Capability information element WMM information element The message element uses 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | WLAN ID | Capability | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Index | Key Status | Key Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1043 for IEEE 802.11 Update WLAN Length: 43 Radio ID: An 8-bit value representing the radio. WLAN ID: An 8-bit value specifying the WLAN Identifier. Capability: A 16-bit value containing the capabilities information field to be advertised by the WTP within the Probe and Beacon messages. Key-Index: The Key Index associated with the key. Key Status: A 1 byte value that specifies the state and usage of the key that has been included. The following values describe the key usage and its status: 0 - A value of zero, with the inclusion of the RSN Information Element means that the WLAN uses per-station encryption keys, and therefore the key in the 'Key' field is only used for multicast traffic. 1 - When set to one, the WLAN employs a shared WEP key, also known as a static WEP key, and uses the encryption key for both unicast and multicast traffic for all stations. 2 - The value of 2 indicates that the AC will begin rekeying the GTK with the STA's in the BSS. It is only valid when IEEE 802.11i is enabled as the security policy for the BSS. 3 - The value of 3 indicates that the AC has completed rekeying the GTK and broadcast packets no longer need to be duplicated and transmitted with both GTK's. Key Length: A 16-bit value representing the length of the Key field. Key: A 32 byte Session Key to use to provide data privacy. For static WEP keys, which is true when the 'Key Status' bit is set to one, this key is used for both unicast and multicast traffic. For encryption schemes that employ a separate encryption key for unicast and multicast traffic, the key included hereonly applies to multicast data, and the cipher suite is specified in an accompanied RSN Information Element. In these scenarios, the key, and cipher information, is communicated via the Add Mobile Station (Section 4.4.8). [...] 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 May 23 03:20:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiRCB-0004o7-RD for capwap-archive@lists.ietf.org; Tue, 23 May 2006 03:20:47 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiRCA-0008Bi-EU for capwap-archive@lists.ietf.org; Tue, 23 May 2006 03:20:47 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9C9F643011E for ; Tue, 23 May 2006 00:20:43 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 60BDE43005A for ; Tue, 23 May 2006 00:20:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 52A15398036 for ; Tue, 23 May 2006 00:20:23 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2A78139803D for ; Tue, 23 May 2006 00:20:19 -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 k4N7KGgZ011517 for ; Tue, 23 May 2006 16:20:16 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k4N7KIX15263 for ; Tue, 23 May 2006 16:20:18 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with SMTP id k4N7KKg03325 for ; Tue, 23 May 2006 16:20: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, 23 May 2006 15:07:55 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDE6A87B@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Terminology section Thread-Index: AcZ+OLs9cTLmGbUDRXyoZix20i6UBw== From: "Saravanan Govindan" To: 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: [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.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue May 23 03:21:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiRCv-0004pu-Mv for capwap-archive@lists.ietf.org; Tue, 23 May 2006 03:21:33 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiRCu-0008DQ-7N for capwap-archive@lists.ietf.org; Tue, 23 May 2006 03:21:33 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D25B0430158 for ; Tue, 23 May 2006 00:21:31 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7024643005A for ; Tue, 23 May 2006 00:20:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6B519398036 for ; Tue, 23 May 2006 00:20:24 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1AB8239802B for ; Tue, 23 May 2006 00:20:19 -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 k4N7KFPI011462; Tue, 23 May 2006 16:20:15 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k4N7KHX15234; Tue, 23 May 2006 16:20:17 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with ESMTP id k4N7KFg03198; Tue, 23 May 2006 16:20:16 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 23 May 2006 15:13:00 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDE6A884@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution for Issue 77: Update figure 1 todepict a generic CAPWAP architecture Thread-Index: AcZ9qcuzg8hv6kLhSZ+tiNNF/qTktwAj5kbg From: "Saravanan Govindan" To: "Pat Calhoun (pacalhou)" , "capwap" 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] Proposed Resolution for Issue 77: Update figure 1 todepict a generic CAPWAP architecture X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.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: b280b4db656c3ca28dd62e5e0b03daa8 I am ok with this. Saravanan -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Monday, May 22, 2006 10:13 PM To: capwap Subject: [Capwap] Proposed Resolution for Issue 77: Update figure 1 todepict a generic CAPWAP architecture All, Here is my proposed resolution for the above mentioned issue. While the original issue submitted included a proposed resolution, it was a combined figure that attempted to show all possible modes of operation, which I found confusing. Instead, I prefer to have a separate figure (and text) to discuss local MAC. Comments appreciated. 1. Introduction [...] CAPWAP assumes a network configuration consisting of multiple WTPs communicating via the Internet Protocol (IP) to an AC. WTPs are viewed as remote RF interfaces controlled by the AC. The CAPWAP protocol supports two modes of operation: split and local MAC. The Split MAC mode is one where all L2 wireless data and management frames are encapsulated via the CAPWAP protocol and exchanged between the AC and the WTP. In the example of 802.11, as shown in Figure 1, the 802.11 frames received from a mobile node (STA) are directly encapsulated by the WTP and forwarded to the AC. +-+ 802.11 frames +-+ | |--------------------------------| | | | +-+ | | | |--------------| |---------------| | | | 802.11 PHY/ | | CAPWAP | | | | MAC sublayer | | | | +-+ +-+ +-+ STA WTP AC Figure 1: Representative CAPWAP Architecture for Split MAC The Local MAC mode of operation diffs from Split MAC as it allows for the data frames to be either locally bridged, or tunneled as 802.3 frames. The latter implies that the WTP performs the 802 bridging function. In either case, however, the management frames are processed locally by the WTP, and then forwarded to the AC. Figure 2 provides an example using the IEEE 802.11 binding, where a station transmits an 802.11 frame, which is encapsulated as 802.3 and forwarded to the AC. +-+ 802.11 frames +-+ 802.3 frames +-+ | |---------------| |--------------| | | | | | | | | |---------------| |--------------| | | | 802.11 PHY/ | | CAPWAP | | | | MAC sublayer | | | | +-+ +-+ +-+ STA WTP AC Figure 2: Representative CAPWAP Architecture for Local MAC [...] 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 May 23 03:26:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiRHN-0006wi-Q2 for capwap-archive@lists.ietf.org; Tue, 23 May 2006 03:26:09 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiRHM-0008Pm-DP for capwap-archive@lists.ietf.org; Tue, 23 May 2006 03:26:09 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 164634300D5 for ; Tue, 23 May 2006 00:26:08 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 708ED43005A for ; Tue, 23 May 2006 00:25:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5DA0B398036 for ; Tue, 23 May 2006 00:25:48 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id A809C39802B for ; Tue, 23 May 2006 00:25:45 -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 k4N7Ph0c017831 for ; Tue, 23 May 2006 16:25:43 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k4N7PiU17515 for ; Tue, 23 May 2006 16:25:44 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with SMTP id k4N7Pkg09821 for ; Tue, 23 May 2006 16:25:46 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 23 May 2006 15:23:33 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDE6A893@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification of Issue 43: IEEE 802.11i Considerations Thread-Index: AcZ+Oup4Yl7n1/sYSBWg74th71H5ng== From: "Saravanan Govindan" To: "capwap" 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: [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: 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue May 23 04:29:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiSH9-0004mK-9v for capwap-archive@lists.ietf.org; Tue, 23 May 2006 04:29:59 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiSH6-0002OB-Rk for capwap-archive@lists.ietf.org; Tue, 23 May 2006 04:29:59 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CAACA4300B2 for ; Tue, 23 May 2006 01:29:55 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B498743005A for ; Tue, 23 May 2006 01:29:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4DCBA43076F for ; Tue, 23 May 2006 01:29: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 562984306D0 for ; Tue, 23 May 2006 01:29:30 -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 k4N8TTko003362 for ; Tue, 23 May 2006 17:29:29 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k4N8TUX17923 for ; Tue, 23 May 2006 17:29:30 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with SMTP id k4N8TUg23970 for ; Tue, 23 May 2006 17:29: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, 23 May 2006 16:27:17 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDE6A8CA@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification for Echo Request update Thread-Index: AcZ+Q89IeXzfJ815Q22PDKut4r/iRg== 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 X-Spam-Level: Subject: [Capwap] Clarification for Echo Request update X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.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: cab78e1e39c4b328567edb48482b6a69 All, I want to propose an update to the text for Issue 45 on combining messages. In addition to the recent updates, I think it is important to clarify the design choice behind the changes. In Section 9.5 "WTP Event Request" of Specifications v01, I propose the following; 9.5. WTP Event Request WTP Event Request message is used by a WTP to send information to its AC. The WTP Event Request message may be sent periodically, or sent in response to an asynchronous event on the WTP. For example, a WTP MAY collect statistics and use the WTP Event Request message to transmit the statistics to the AC. [PROPOSED TEXT] WTP Event Request messages together with other control messages from a WTP indicate operational capacity of that WTP. This presumes that a WTP capable of sending periodic control messages (such as statistics) or irregular control messages (such as errors) is operational. In the case where regular control messages are not sent, an operational WTP sends the Echo Request message to indicate operational readiness. ----XXXX---- 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue May 23 04:54:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiSfC-0004GK-BV for capwap-archive@lists.ietf.org; Tue, 23 May 2006 04:54:50 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiSf7-0003bb-Vd for capwap-archive@lists.ietf.org; Tue, 23 May 2006 04:54:50 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A18EE4300E3 for ; Tue, 23 May 2006 01:54:45 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B0212430064 for ; Tue, 23 May 2006 01:54:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9826A43080A for ; Tue, 23 May 2006 01:54:25 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 94766430808 for ; Tue, 23 May 2006 01:54:22 -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 k4N8sJjl011319 for ; Tue, 23 May 2006 17:54:19 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k4N8sLU27678 for ; Tue, 23 May 2006 17:54:21 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with SMTP id k4N8sLV29035 for ; Tue, 23 May 2006 17:54:21 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 23 May 2006 16:52:16 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDE6A8E9@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Statistics for WTP Event Request Thread-Index: AcZ+R07cmlDLpT7dQpWCv7PLiigaSw== 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 X-Spam-Level: Subject: [Capwap] 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: 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: d6b246023072368de71562c0ab503126 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue May 23 13:10:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiaOj-0006KR-TO for capwap-archive@lists.ietf.org; Tue, 23 May 2006 13:10:21 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiaOi-0000Ub-EU for capwap-archive@lists.ietf.org; Tue, 23 May 2006 13:10:21 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5FFB84300C6 for ; Tue, 23 May 2006 10:10:11 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E08F143005F for ; Tue, 23 May 2006 10:09:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C9CA239803B for ; Tue, 23 May 2006 10:09: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 5B89039804F for ; Tue, 23 May 2006 10:09:40 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 23 May 2006 10:09:40 -0700 X-IronPort-AV: i="4.05,161,1146466800"; d="scan'208"; a="1811363938:sNHT26555700" 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 k4NH9dkd010432; Tue, 23 May 2006 10:09: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 k4NH9dB7017167; Tue, 23 May 2006 10:09: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); Tue, 23 May 2006 10:09:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 May 2006 10:09:38 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201ECF0F5@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Terminology section Thread-Index: AcZ+OLs9cTLmGbUDRXyoZix20i6UBwAUtbng From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , X-OriginalArrivalTime: 23 May 2006 17:09:39.0093 (UTC) FILETIME=[ACC73C50:01C67E8B] 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] 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: 538aad3a3c4f01d8b6a6477ca4248793 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue May 23 13:11:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiaPm-0006Xs-Uw for capwap-archive@lists.ietf.org; Tue, 23 May 2006 13:11:26 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiaPl-0000Wk-Gm for capwap-archive@lists.ietf.org; Tue, 23 May 2006 13:11:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 29DF54300A2 for ; Tue, 23 May 2006 10:11:25 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 20DFE430082 for ; Tue, 23 May 2006 10:11:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 01961144801F for ; Tue, 23 May 2006 10:11:03 -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 4D8441448012 for ; Tue, 23 May 2006 10:11:00 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 23 May 2006 10:11:01 -0700 X-IronPort-AV: i="4.05,161,1146466800"; d="scan'208"; a="428482657:sNHT35990082" 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 k4NHAxTQ023738; Tue, 23 May 2006 10:10:59 -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 k4NHAxB9021447; Tue, 23 May 2006 10:10:59 -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, 23 May 2006 10:10:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 May 2006 10:10:59 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201ECF0F8@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Statistics for WTP Event Request Thread-Index: AcZ+R07cmlDLpT7dQpWCv7PLiigaSwARIbWQ From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , "capwap" X-OriginalArrivalTime: 23 May 2006 17:10:59.0503 (UTC) FILETIME=[DCB4D3F0:01C67E8B] 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] 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: 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 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue May 23 13:14:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiaT5-00072z-FB for capwap-archive@lists.ietf.org; Tue, 23 May 2006 13:14:52 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiaT3-0000ho-12 for capwap-archive@lists.ietf.org; Tue, 23 May 2006 13:14:51 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id AB138430097 for ; Tue, 23 May 2006 10:14:48 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D831E4300EC for ; Tue, 23 May 2006 10:13:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BD6301448018 for ; Tue, 23 May 2006 10:13:04 -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 167061448022 for ; Tue, 23 May 2006 10:13:01 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 23 May 2006 10:13: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 k4NHD1Jw026710; Tue, 23 May 2006 10:13: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 k4NHCuBL020644; Tue, 23 May 2006 10:13: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, 23 May 2006 10:13:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 May 2006 10:12:59 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201ECF0FC@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Thread-Index: AcZ+Oup4Yl7n1/sYSBWg74th71H5ngAUSppw From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , "capwap" X-OriginalArrivalTime: 23 May 2006 17:13:00.0122 (UTC) FILETIME=[2499D3A0:01C67E8C] 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] 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: 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 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue May 23 13:15:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiaTr-00079B-68 for capwap-archive@lists.ietf.org; Tue, 23 May 2006 13:15:39 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiaTo-0000kx-NJ for capwap-archive@lists.ietf.org; Tue, 23 May 2006 13:15:39 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5C4284300EF for ; Tue, 23 May 2006 10:15:36 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4426D430110 for ; Tue, 23 May 2006 10:14:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id EC215398030 for ; Tue, 23 May 2006 10:14:01 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4163F398050 for ; Tue, 23 May 2006 10:13:58 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 23 May 2006 10:13:58 -0700 X-IronPort-AV: i="4.05,161,1146466800"; d="scan'208"; a="323226503:sNHT35306428" 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 k4NHDvIK027783; Tue, 23 May 2006 10:13:57 -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 k4NHDvB9021567; Tue, 23 May 2006 10:13:57 -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, 23 May 2006 10:13:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 May 2006 10:13:57 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201ECF0FD@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification for Echo Request update Thread-Index: AcZ+Q89IeXzfJ815Q22PDKut4r/iRgASHAcQ From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , "capwap" X-OriginalArrivalTime: 23 May 2006 17:13:57.0472 (UTC) FILETIME=[46C8BE00:01C67E8C] 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] Clarification for Echo Request update X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.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 I have re-opened issue 45 and included your suggestion. 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:27 AM > To: capwap > Subject: [Capwap] Clarification for Echo Request update > > All, > > I want to propose an update to the text for Issue 45 on > combining messages. > > In addition to the recent updates, I think it is important to > clarify the design choice behind the changes. > > In Section 9.5 "WTP Event Request" of Specifications v01, I > propose the following; > > > 9.5. WTP Event Request > > WTP Event Request message is used by a WTP to send > information to its > AC. The WTP Event Request message may be sent > periodically, or sent > in response to an asynchronous event on the WTP. For > example, a WTP > MAY collect statistics and use the WTP Event Request message to > transmit the statistics to the AC. > > [PROPOSED TEXT] > > WTP Event Request messages together with other control > messages from > a > WTP indicate operational capacity of that WTP. This > presumes that a WTP > capable of sending periodic control messages (such as > statistics) or > > irregular control messages (such as errors) is > operational. In the case > where regular control messages are not sent, an > operational WTP sends the > Echo Request message to indicate operational readiness. > > ----XXXX---- > > 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 Tue May 23 13:36:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiaoB-0008Cz-OT for capwap-archive@lists.ietf.org; Tue, 23 May 2006 13:36:39 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiaoA-0001u0-A9 for capwap-archive@lists.ietf.org; Tue, 23 May 2006 13:36:39 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id EFC54430082 for ; Tue, 23 May 2006 10:36:37 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D14DF43005F for ; Tue, 23 May 2006 10:36:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B61251448014 for ; Tue, 23 May 2006 10:36:17 -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 09F221448010 for ; Tue, 23 May 2006 10:36:14 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 23 May 2006 10:36:14 -0700 X-IronPort-AV: i="4.05,161,1146466800"; d="scan'208"; a="281492376:sNHT27638588" 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 k4NHaEHI011394 for ; Tue, 23 May 2006 10:36:14 -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 k4NHaEB7010165 for ; Tue, 23 May 2006 10:36: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); Tue, 23 May 2006 10:36:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 May 2006 10:36:13 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC018C0188@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New issues: readability/ease of use/lack of specification Thread-Index: AcZ+j2MRjznWasC+S92VYh4C1IEbTw== From: "Bob O'Hara (boohara)" To: "capwap" X-OriginalArrivalTime: 23 May 2006 17:36:14.0079 (UTC) FILETIME=[6376C8F0:01C67E8F] 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: [Capwap] New issues: readability/ease of use/lack of 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: 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: a7d6aff76b15f3f56fcb94490e1052e4 The -01 draft is a significant improvement over the -00 draft. However, I find it very difficult to easily find some information in the document. Following are some editorial and technical comments. 1. Please include a table of message element type values for the base CAPWAP message elements in section 4.4. 2. Please include a table of message element type values for the 802.11 binding-specific elements in section 11.10. 3. Please describe how the binding-specific message element type values are derived. It appears that the 802.11 type values begin arbitrarily at 1024. Are the values for this field to be IANA controlled, or are they able to be identified deterministically? 4. Please identify in which messages the nine additional message elements in section 11.10 may appear, since they are not listed in the table in section 11.9.3. 5. In 11.7, the Message Type Value for the two 802.11-specific messages is given. However, I don't see anywhere that describes how these values were determined. Please add a description of the derivation of the message type values. 6. 11.8 says there are no 802.11-specific data message bindings. I think that the data packet containing an 802.11-encapsulated frame should go here, along with its complete description. -Bob Bob O'Hara Cisco Systems - WNBU Phone: +1 408 853 5513 Mobile: +1 408 218 4025 _________________________________________________________________ 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 May 23 14:02:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FibDW-00081K-Qa for capwap-archive@lists.ietf.org; Tue, 23 May 2006 14:02:50 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FibDV-00031T-9q for capwap-archive@lists.ietf.org; Tue, 23 May 2006 14:02:50 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A907E4300D5 for ; Tue, 23 May 2006 11:02:48 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 27FAE43005F for ; Tue, 23 May 2006 11:02:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EF7BE1448026 for ; Tue, 23 May 2006 11:02:19 -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 86A011448024 for ; Tue, 23 May 2006 11:02:16 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id s11so1797065wxc for ; Tue, 23 May 2006 11:02:15 -0700 (PDT) Received: by 10.70.10.11 with SMTP id 11mr6670529wxj; Tue, 23 May 2006 11:02:15 -0700 (PDT) Received: by 10.70.133.19 with HTTP; Tue, 23 May 2006 11:02:15 -0700 (PDT) Message-ID: <5bfe7a820605231102u1946d82dga161a58a7dda9cb1@mail.gmail.com> Date: Tue, 23 May 2006 11:02:15 -0700 From: "Dorothy Stanley" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201ECF0F8@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A201ECF0F8@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: Saravanan Govindan , capwap Subject: Re: [Capwap] 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="===============1633387427==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 --===============1633387427== Content-Type: multipart/alternative; boundary="----=_Part_178189_9132422.1148407335429" ------=_Part_178189_9132422.1148407335429 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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_178189_9132422.1148407335429 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Issue 84, "Piggybacking statistical information in Echo Request/respon= se 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<= br> Echo message as transport for statistics, but the question of additional us= eful
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
requ= est.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco = Systems



> -----Original Message-----
> From: Sarava= nan Govindan [mailto: Saravanan.Govindan@s= g.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 pro= pose 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:<= br>> http:= //lists.frascone.com/mailman/listinfo/capwap
>
> Archives:= =20 http://lists.frascon= e.com/pipermail/capwap
>
_____________________________________= ____________________________
To unsubscribe or modify your subscription = options, please visit:
http://li= sts.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/piperma= il/capwap

------=_Part_178189_9132422.1148407335429-- --===============1633387427== 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 --===============1633387427==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue May 23 14:47:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fibuf-00079z-1A for capwap-archive@lists.ietf.org; Tue, 23 May 2006 14:47:25 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fibud-0004zR-Ic for capwap-archive@lists.ietf.org; Tue, 23 May 2006 14:47:25 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id F0F9B430097 for ; Tue, 23 May 2006 11:47:22 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8908D43005F for ; Tue, 23 May 2006 11:47:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 760071448008 for ; Tue, 23 May 2006 11:47:01 -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 B3E2A1448023 for ; Tue, 23 May 2006 11:46:57 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 23 May 2006 11:46:57 -0700 X-IronPort-AV: i="4.05,161,1146466800"; d="scan'208"; a="281534694:sNHT27057748" 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 k4NIkvEi012001 for ; Tue, 23 May 2006 11:46:57 -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 k4NIktsr014596 for ; Tue, 23 May 2006 11:46:57 -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, 23 May 2006 11:46:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 May 2006 11:46:56 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201ECF1A3@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New issues: readability/ease of use/lack of specification Thread-Index: AcZ+j2MRjznWasC+S92VYh4C1IEbTwACd00Q From: "Pat Calhoun (pacalhou)" To: "Bob O'Hara (boohara)" , "capwap" X-OriginalArrivalTime: 23 May 2006 18:46:56.0713 (UTC) FILETIME=[44455B90:01C67E99] 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-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 issues: readability/ease of use/lack of 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: 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 Issue 124 has been created. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Bob O'Hara (boohara) > Sent: Tuesday, May 23, 2006 10:36 AM > To: capwap > Subject: [Capwap] New issues: readability/ease of use/lack of > specification > > The -01 draft is a significant improvement over the -00 > draft. However, I find it very difficult to easily find some > information in the document. Following are some editorial > and technical comments. > > 1. Please include a table of message element type values for > the base CAPWAP message elements in section 4.4. > > 2. Please include a table of message element type values for > the 802.11 binding-specific elements in section 11.10. > > 3. Please describe how the binding-specific message element > type values are derived. It appears that the 802.11 type > values begin arbitrarily at 1024. Are the values for this > field to be IANA controlled, or are they able to be > identified deterministically? > > 4. Please identify in which messages the nine additional > message elements in section 11.10 may appear, since they are > not listed in the table in section 11.9.3. > > 5. In 11.7, the Message Type Value for the two > 802.11-specific messages is given. However, I don't see > anywhere that describes how these values were determined. > Please add a description of the derivation of the message type values. > > 6. 11.8 says there are no 802.11-specific data message > bindings. I think that the data packet containing an > 802.11-encapsulated frame should go here, along with its > complete description. > > > -Bob > > Bob O'Hara > Cisco Systems - WNBU > > Phone: +1 408 853 5513 > Mobile: +1 408 218 4025 > > _________________________________________________________________ > 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 comtem@tripplite.com Tue May 23 15:15:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FicLR-0000Ax-EP for capwap-archive@ietf.org; Tue, 23 May 2006 15:15:05 -0400 Received: from 216.red-213-96-11.staticip.rima-tde.net ([213.96.11.216] helo=tripplite.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FicLP-0005sZ-SB for capwap-archive@ietf.org; Tue, 23 May 2006 15:15:05 -0400 Message-ID: <000001c67e9d$268abe70$7beba8c0@rjj45> Reply-To: "Comgan Templeton" From: "Comgan Templeton" To: capwap-archive@ietf.org Subject: redemptio 845 Date: Tue, 23 May 2006 12:14:44 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C67E62.7A2BE670" 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.5 (++++) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C67E62.7A2BE670 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 A M B / E N V A L / U M=20 X ^ N A X C / A L / S=20 S O M ^ M E R / D / A L E V / T R A P R O Z ^ C V / A G R A=20 =20 http://www.jensadertion.com =20 Well! Here we are! said Thorin. And I suppose we ought to thank=20 our stars and Mr. Baggins. I am sure he has a right to expect it, though I wish he could have arranged a more comfortable journey. Still-all very much at your service once more, Mr. Baggins. No doubt we shall feel=20 properly grateful, when we are fed and recovered. In the meanwhile what=20 next? I suggest Lake-town, said Bilbo, What else is there? Nothing=20 ------=_NextPart_000_0001_01C67E62.7A2BE670 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
A M B / E N
V A L / U M
X ^ N A X
C / A L / S
S O M ^
M E R / D / A
L E V / T R A
P R O Z ^ C
V / A G R A
 





Well! Here we are! said Thorin. And = I suppose we ought to thank
our stars and Mr. Baggins. I am sure he = has a right to expect it, though
I wish he could have arranged a = more comfortable journey. Still-all very
much at your service once = more, Mr. Baggins. No doubt we shall feel
properly grateful, when we = are fed and recovered. In the meanwhile what
next? I suggest = Lake-town, said Bilbo, What else is there? Nothing =
------=_NextPart_000_0001_01C67E62.7A2BE670-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue May 23 16:43:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fidj4-00070O-1s for capwap-archive@lists.ietf.org; Tue, 23 May 2006 16:43:34 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fidj2-0002zI-Kj for capwap-archive@lists.ietf.org; Tue, 23 May 2006 16:43:34 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6D1B74300D6 for ; Tue, 23 May 2006 13:43:21 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 0D37643005F for ; Tue, 23 May 2006 13:43:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E6EE01448004 for ; Tue, 23 May 2006 13:43:00 -0700 (PDT) Received: from trpz.com (mail1.trpz.com [66.7.225.38]) by hermes.tigertech.net (Postfix) with ESMTP id 1BBA91448008 for ; Tue, 23 May 2006 13:42:57 -0700 (PDT) Received: from [127.0.0.1] ([192.168.12.194]) by trpz.com (8.13.5/8.11.6) with ESMTP id k4NJdOum026283; Tue, 23 May 2006 12:39:28 -0700 Message-ID: <447373C5.8000408@trapezenetworks.com> Date: Tue, 23 May 2006 13:42:45 -0700 From: Jim Murphy User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <4FF84B0BC277FF45AA27FE969DD956A201ECED44@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201ECED44@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] Issue 90: Using 802.3 for tunnelling in Split-MAC 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: 538aad3a3c4f01d8b6a6477ca4248793 Pat Calhoun (pacalhou) wrote: > All, > > I'd like to re-open the discussion around the use of 802.3 tunneling. > When the original proponents of encapsulating 802.3 came forth, they > requested that local MAC support both local bridging and 802.3. > Consequently, the split MAC mode only supports the native frame format > (e.g., IEEE 802.11 supports 802.11 frame formats). > > Puneet raised an issue that he believes that Split MAC must support > 802.3 as well, and not to support any tunneling in local MAC mode. > Puneet, correct me if I am incorrect here. > > Well, the issue here is that including an 802.3 frame in CAPWAP is NOT > split MAC. Many fields are lost in the translation (e.g., four address > field, 802.11e UP field). From memory, the folks that are asking for the > optional BSSID in the CAPWAP header to be optional also appears to be > the ones that are favoring this issue (90). However, if one removes the > BSSID field, how would the AC even know which BSSID an 802.1X is being > run against? The AC would lose all such information, and it's not clear > how we could support multiple SSIDs per WTP. Also not clear how IAPP > frame formats would be handled, as these would also lose their BSSID > context, which is important. > 802.1X frames come after the station has been associated. Therefore the station mac address is know at the AC along with its BSSID mapping. The source address of the 802.1X frame is used to map the frame to the SSID. Thanks, Jim > With that I would like to reopen this conversation. > > > 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 May 23 21:30:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiiD5-0000Wh-3i for capwap-archive@lists.ietf.org; Tue, 23 May 2006 21:30:51 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiiD3-0007gZ-MW for capwap-archive@lists.ietf.org; Tue, 23 May 2006 21:30:51 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8F36243004F for ; Tue, 23 May 2006 18:30:40 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 73F6943004F for ; Tue, 23 May 2006 18:30:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 64108398032 for ; Tue, 23 May 2006 18:30:17 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5676B398024 for ; Tue, 23 May 2006 18:30:14 -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 k4O1UDAu027865; Wed, 24 May 2006 10:30:13 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k4O1UDw19691; Wed, 24 May 2006 10:30:13 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/phillies) with SMTP id k4O1UCn11933; Wed, 24 May 2006 10:30:12 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 24 May 2006 09:28:06 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDE6A95B@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Terminology section Thread-Index: AcZ+OLs9cTLmGbUDRXyoZix20i6UBwAUtbngABGomzA= From: "Saravanan Govindan" To: "Pat Calhoun (pacalhou)" , 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] 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.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue May 23 21:35:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiiHd-0002Mw-CO for capwap-archive@lists.ietf.org; Tue, 23 May 2006 21:35:33 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiiHa-0007og-JV for capwap-archive@lists.ietf.org; Tue, 23 May 2006 21:35:33 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 39B104300A7 for ; Tue, 23 May 2006 18:35:30 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 470B343004F for ; Tue, 23 May 2006 18:34:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 324AF144800F for ; Tue, 23 May 2006 18:34:54 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 177D81448009 for ; Tue, 23 May 2006 18:34:51 -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 k4O1Yopp019031; Wed, 24 May 2006 10:34:50 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k4O1Yo022666; Wed, 24 May 2006 10:34:50 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with SMTP id k4O1YoV26570; Wed, 24 May 2006 10:34:50 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 24 May 2006 09:32:46 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDE6A95C@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Statistics for WTP Event Request Thread-Index: AcZ+ksLzl8cVexZLRbyDo8Rs4tEuFQAP+erw From: "Saravanan Govindan" To: "Dorothy Stanley" , "Pat Calhoun (pacalhou)" 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 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.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="===============1445243374==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 This is a multi-part message in MIME format. --===============1445243374== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67ED1.F5A00453" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67ED1.F5A00453 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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.=20 =20 Saravanan =20 =20 =20 =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Wednesday, May 24, 2006 2:02 AM To: Pat Calhoun (pacalhou) Cc: Saravanan Govindan; capwap Subject: Re: [Capwap] Statistics for WTP Event Request =20 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=20 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.=20 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 >=20 > 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=20 > 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 > > _________________________________________________________________=20 > 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:=20 http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap=20 =20 ------_=_NextPart_001_01C67ED1.F5A00453 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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.f= rascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone= .com/pipermail/capwap
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.f= rascone.com/mailman/listinfo/capwap

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

 

------_=_NextPart_001_01C67ED1.F5A00453-- --===============1445243374== 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 --===============1445243374==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue May 23 22:04:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiijU-0004JD-AU for capwap-archive@lists.ietf.org; Tue, 23 May 2006 22:04:20 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiijS-0000TK-AI for capwap-archive@lists.ietf.org; Tue, 23 May 2006 22:04:20 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A84B74300AB for ; Tue, 23 May 2006 19:04:17 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 444B443004F for ; Tue, 23 May 2006 19:03:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2C134144801A for ; Tue, 23 May 2006 19:03:31 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by hermes.tigertech.net (Postfix) with ESMTP id 0CC58144800D for ; Tue, 23 May 2006 19:03:26 -0700 (PDT) Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 23 May 2006 19:03:17 -0700 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id EE83B2B0; Tue, 23 May 2006 19:03:16 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id C5A022AF; Tue, 23 May 2006 19:03:16 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DPF52215; Tue, 23 May 2006 19:03:16 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 4EFD520501; Tue, 23 May 2006 19:03:16 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 May 2006 19:03:15 -0700 Message-ID: <8954613CA6BB3242A1531D916A527A41D369D1@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [Capwap] Issue 90: Using 802.3 for tunnelling in Split-MAC mode Thread-Index: AcZ+qY9eBE/iPvgDTma+W0PjAONvjQAKyV/Q From: "Puneet Agarwal" To: "Jim Murphy" , "Pat Calhoun (pacalhou)" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006052312; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230362E34343733424337362E303030372D412D; ENG=IBF; TS=20060524020318; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006052312_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 686D616F0HW21917834-01-01 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: Cc: capwap Subject: Re: [Capwap] Issue 90: Using 802.3 for tunnelling in Split-MAC 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: multipart/mixed; boundary="===============1520757307==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0c3d807a9e67fb2ae2b97f891ffd2e4e This is a multi-part message in MIME format. --===============1520757307== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67ED6.3869928B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67ED6.3869928B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Pat, Your recollection is correct. There is need to support Split MAC with 802.3 payload. I have cut and pasted the text from the original email on this subject. As you can see from the description, the 802.11 MAC functions are being distributed between the WTP and the AC (hence Split MAC) with the caveat that the Integration service is being done at the WTP. "**********************CUT and PASTE START ***************************************** From: Puneet Agarwal [mailto:pagarwal@broadcom.com]=20 Sent: Thursday, March 23, 2006 2:08 PM To: capwap@frascone.com Subject: [Capwap] Data tunneling between WTP <->AC =20 Hi All, =20 One of the recommendations of the evaluation team was to have a mode to tunnel 802.3 frames between WTP and AC. It seems that that requirement was interpreted as tunneling 802.3 frames for local MAC. However after talking to various folks at IETF 65 (dallas), it seems the intent was to tunnel 802.3 frames in the split MAC (and not local MAC). =20 Hence I would propose the following: =20 (a) Delete the tunneling of 802.3 frames between AC<->WTP for Local MAC and replace it with (b). (b) Add tunneling 802.3 frames between AC <-> WTP for Split MAC. Following the notation in section 11.1.1, a new variant of Split MAC should be defined (based on recommendation of the eval team) as follows. I have marked the changes wrt the draft-00's section 11.1.1 with * (note: section 11.1.1 remains unchanged - this proposal is an addition to and not a replacement for section 11.1.1): =20 Function Location ------------- ------------- Distribution Service AC Integration Service *WTP* Beacon Generation WTP Probe Response WTP Power Mgmt/Packet Buffering WTP Fragmentation/Defragmentation WTP Assoc/Disassoc/Reassoc AC =20 802.11e Classifying AC Scheduling *WTP* (I don't understand why section 11.1.1 shows .11e scheduling at AC) Queuing WTP =20 802.11i 802.1X/EAP AC Key Management AC 802.11 Encryption/Decryption *WTP* =20 Thanks. =20 -Puneet ********************CUT and PASTE END ***************************************"=20 Thanks. -Puneet -----Original Message----- From: Jim Murphy [mailto:jmurphy@trapezenetworks.com]=20 Sent: Tuesday, May 23, 2006 1:43 PM To: Pat Calhoun (pacalhou) Cc: capwap Subject: Re: [Capwap] Issue 90: Using 802.3 for tunnelling in Split-MAC mode Pat Calhoun (pacalhou) wrote: > All, > =20 > I'd like to re-open the discussion around the use of 802.3 tunneling. > When the original proponents of encapsulating 802.3 came forth, they=20 > requested that local MAC support both local bridging and 802.3. > Consequently, the split MAC mode only supports the native frame format > (e.g., IEEE 802.11 supports 802.11 frame formats). >=20 > Puneet raised an issue that he believes that Split MAC must support > 802.3 as well, and not to support any tunneling in local MAC mode. > Puneet, correct me if I am incorrect here. >=20 > Well, the issue here is that including an 802.3 frame in CAPWAP is NOT > split MAC. Many fields are lost in the translation (e.g., four address > field, 802.11e UP field). From memory, the folks that are asking for=20 > the optional BSSID in the CAPWAP header to be optional also appears to > be the ones that are favoring this issue (90). However, if one removes > the BSSID field, how would the AC even know which BSSID an 802.1X is=20 > being run against? The AC would lose all such information, and it's=20 > not clear how we could support multiple SSIDs per WTP. Also not clear=20 > how IAPP frame formats would be handled, as these would also lose=20 > their BSSID context, which is important. >=20 802.1X frames come after the station has been associated. Therefore the station mac address is know at the AC along with its BSSID mapping. The source address of the 802.1X frame is used to map the frame to the SSID. Thanks, Jim > With that I would like to reopen this conversation. > =20 >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit Cisco Systems=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 _________________________________________________________________ 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_01C67ED6.3869928B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable RE: [Capwap] Issue 90: Using 802.3 for tunnelling in Split-MAC = mode

Hi = Pat,

Your recollection = is correct. There is need to support Split MAC with 802.3 = payload.

I have cut and = pasted the text from the original email on this subject. As you can see from the description, the = 802.11 MAC functions are being distributed between the WTP and the AC = (hence Split MAC) with the caveat that the Integration service is being = done at the WTP.

"**********************CUT and PASTE START = *****************************************
From: Puneet = Agarwal [mailto:pagarwal@broadcom.com]
Sent: Thursday, = March 23, 2006 2:08 PM
To: = capwap@frascone.com
Subject: [Capwap] = Data tunneling between WTP <->AC

 

Hi = All,

 

One of the = recommendations of the evaluation team was to have a mode to tunnel = 802.3 frames between WTP and AC. It seems that that requirement was = interpreted as tunneling 802.3 frames for local MAC. However after = talking to various folks at IETF 65 (dallas), it seems the intent was to = tunnel 802.3 frames in the split MAC (and not local = MAC).

 

Hence I would = propose the following:

 

(a) Delete the = tunneling of 802.3 frames between AC<->WTP for Local MAC and = replace it with (b).

(b) Add tunneling = 802.3 frames between AC <-> WTP for Split MAC. Following the = notation in section 11.1.1, a new variant of Split MAC should be defined = (based on recommendation of the eval team) as follows. I have marked the = changes wrt the draft-00's section 11.1.1 with * (note: section 11.1.1 = remains unchanged - this proposal is an addition to and not a = replacement for section 11.1.1):

 

        = Function           = ;            =         Location

        = -------------          =             &= nbsp;        = -------------
         &nbs= p;  Distribution = Service           =             = AC
         &nbs= p;  Integration = Service           =             = *WTP*
         &nbs= p;  Beacon = Generation          &nb= sp;            = WTP
         &nbs= p;  Probe = Response           = ;            =     WTP
         &nbs= p;  Power Mgmt/Packet = Buffering        WTP
         &nbs= p;  Fragmentation/Defragmentation      = WTP
         &nbs= p;  = Assoc/Disassoc/Reassoc        &nb= sp;     AC

 

       = 802.11e
         &nbs= p;  = Classifying          &n= bsp;           &nb= sp;        AC
         &nbs= p;  = Scheduling          &nb= sp;           &nbs= p;        *WTP* (I don't understand = why section 11.1.1 shows .11e scheduling at AC)

         &nbs= p;  = Queuing           =             &= nbsp;           = WTP

 

       = 802.11i
         &nbs= p;  = 802.1X/EAP          &nb= sp;           &nbs= p;         AC
         &nbs= p;  Key = Management          &nb= sp;           &nbs= p; AC
         &nbs= p;  802.11 Encryption/Decryption      = *WTP*

 

Thanks.

 

-Puneet

********************CUT and PASTE END = ***************************************"

Thanks.

-Puneet

-----Original = Message-----
From: Jim Murphy = [mailto:jmurphy@trapezenetworks.com]
Sent: Tuesday, = May 23, 2006 1:43 PM
To: Pat Calhoun = (pacalhou)
Cc: = capwap
Subject: Re: = [Capwap] Issue 90: Using 802.3 for tunnelling in Split-MAC = mode



Pat Calhoun = (pacalhou) wrote:
> = All,
>  =
> I'd like to = re-open the discussion around the use of 802.3 tunneling.
> When the = original proponents of encapsulating 802.3 came forth, they =
> requested = that local MAC support both local bridging and 802.3.
> = Consequently, the split MAC mode only supports the native frame format =
> (e.g., IEEE = 802.11 supports 802.11 frame formats).
> =
> Puneet = raised an issue that he believes that Split MAC must = support
> 802.3 as = well, and not to support any tunneling in local MAC mode.
> Puneet, = correct me if I am incorrect here.
> =
> Well, the = issue here is that including an 802.3 frame in CAPWAP is NOT =
> split MAC. = Many fields are lost in the translation (e.g., four address =
> field, = 802.11e UP field). From memory, the folks that are asking for =
> the optional = BSSID in the CAPWAP header to be optional also appears to
> be the ones = that are favoring this issue (90). However, if one removes =
> the BSSID = field, how would the AC even know which BSSID an 802.1X is =
> being run = against? The AC would lose all such information, and it's
> not clear = how we could support multiple SSIDs per WTP. Also not clear =
> how IAPP = frame formats would be handled, as these would also lose
> their BSSID = context, which is important.
> =

802.1X frames come = after the station has been associated. Therefore the station mac address = is know at the AC along with its BSSID mapping.

The source address = of the 802.1X frame is used to map the frame to the SSID.

Thanks,

Jim

> With that I = would like to reopen this conversation.
>  =
> =
> Pat = Calhoun
> CTO, = Wireless Networking Business Unit Cisco Systems
> = _________________________________________________________________<= /SPAN>
> 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_01C67ED6.3869928B-- --===============1520757307== 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 --===============1520757307==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 24 11:31:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FivKn-0006EP-4M for capwap-archive@lists.ietf.org; Wed, 24 May 2006 11:31:41 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FivKl-0004r6-AK for capwap-archive@lists.ietf.org; Wed, 24 May 2006 11:31:41 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A8F9D4300CC for ; Wed, 24 May 2006 08:31:36 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id EC98B43008F for ; Wed, 24 May 2006 08:30:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D09AE398044 for ; Wed, 24 May 2006 08:30:58 -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 D6523398031 for ; Wed, 24 May 2006 08:30:55 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 24 May 2006 08:30:55 -0700 X-IronPort-AV: i="4.05,167,1146466800"; d="scan'208,217"; a="1812011288:sNHT452653606" 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 k4OFUtYe023072; Wed, 24 May 2006 08:30:55 -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 k4OFUsHc020852; Wed, 24 May 2006 08:30:54 -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, 24 May 2006 08:30:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 24 May 2006 08:30:53 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201ECF4AB@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution for Issue 77: Update figure 1 to depict a generic CAPWAP architecture Thread-Index: AcZ/Rn7usMQrsUZHRlinNPM6t3S0zQAAIEJg From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" X-OriginalArrivalTime: 24 May 2006 15:30:54.0854 (UTC) FILETIME=[0C11DA60:01C67F47] 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 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 77: Update figure 1 to depict a generic CAPWAP architecture X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.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="===============0751047133==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 This is a multi-part message in MIME format. --===============0751047133== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67F47.0BDF9237" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67F47.0BDF9237 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree. those are good changes. I will include them. =20 Thanks, Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Wednesday, May 24, 2006 8:27 AM To: Pat Calhoun (pacalhou) Cc: capwap Subject: Re: [Capwap] Proposed Resolution for Issue 77: Update figure 1 to depict a generic CAPWAP architecture =09 =09 Pat, =09 Overall - Fine by me also, a couple of suggested edits: =09 Change "split and local MAC" to "Split and Local MAC" Change "The Split MAC mode is one where" to "In Split MAC Mode" =09 Below Figure 1, delete "diffs from Split MAC as it" =09 Change "In either case, however, the management frames are processed locally by the WTP" =09 to In either case, the L2 wireless management frames are processed locally by the WTP" =09 Dorothy =09 =09 On 5/22/06, Pat Calhoun (pacalhou) wrote:=20 All, =09 Here is my proposed resolution for the above mentioned issue. While the original issue submitted included a proposed resolution, it was a combined figure that attempted to show all possible modes of operation,=20 which I found confusing. Instead, I prefer to have a separate figure (and text) to discuss local MAC. =09 Comments appreciated. =09 1. Introduction [...] =09 CAPWAP assumes a network configuration consisting of multiple WTPs=20 communicating via the Internet Protocol (IP) to an AC. WTPs are viewed as remote RF interfaces controlled by the AC. The CAPWAP protocol supports two modes of operation: split and local MAC. The Split MAC mode is one where all L2 wireless data and management=20 frames are encapsulated via the CAPWAP protocol and exchanged between the AC and the WTP. In the example of 802.11, as shown in Figure 1, the 802.11 frames received from a mobile node (STA) are directly=20 encapsulated by the WTP and forwarded to the AC. =09 +-+ 802.11 frames +-+ | |--------------------------------| | | | +-+ | | | |--------------| |---------------| | | | 802.11 PHY/ | | CAPWAP | | | | MAC sublayer | | | | +-+ +-+ +-+ STA WTP AC =09 Figure 1: Representative CAPWAP Architecture for Split MAC =09 The Local MAC mode of operation diffs from Split MAC as it allows for the data frames to be either locally bridged, or tunneled as 802.3 frames. The latter implies that the WTP performs the 802 bridging function. In either case, however, the management frames are processed locally by the WTP, and then forwarded to the AC. Figure 2=20 provides an example using the IEEE 802.11 binding, where a station transmits an 802.11 frame, which is encapsulated as 802.3 and forwarded to the AC. =09 +-+ 802.11 frames +-+ 802.3 frames +-+=20 | |---------------| |--------------| | | | | | | | | |---------------| |--------------| | | | 802.11 PHY/ | | CAPWAP | | | | MAC sublayer | | | | +-+ +-+ +-+ STA WTP AC =09 Figure 2: Representative CAPWAP Architecture for Local MAC [...] =09 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =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_01C67F47.0BDF9237 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 agree. those are good changes. I will include them.
 
Thanks,

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

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Wednesday, May 24, = 2006 8:27=20 AM
To: Pat Calhoun (pacalhou)
Cc:=20 capwap
Subject: Re: [Capwap] Proposed Resolution for Issue = 77:=20 Update figure 1 to depict a generic CAPWAP = architecture

Pat,

Overall - Fine by me also, a couple of = suggested=20 edits:

Change "split and local MAC" to "Split and Local = MAC"
Change=20 "The Split MAC mode is one where" to "In Split MAC Mode"

Below = Figure=20 1, delete "diffs from Split MAC as it"

Change "In either case, = however,=20 the management frames are
   processed locally by the=20 WTP"

to
In either case, the L2 wireless management frames=20 are
   processed locally by the = WTP"

Dorothy

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

Here=20 is my proposed resolution for the above mentioned issue. While=20 the
original issue submitted included a proposed resolution, it = was=20 a
combined figure that attempted to show all possible modes of = operation,=20
which I found confusing. Instead, I prefer to have a separate=20 figure
(and text) to discuss local MAC.

Comments=20 = appreciated.

1.  Introduction
[...]

 &nbs= p;=20 CAPWAP assumes a network configuration consisting of multiple WTPs=20
   communicating via the Internet Protocol (IP) to an=20 AC.  WTPs are
   viewed as remote RF = interfaces=20 controlled by the AC.  The CAPWAP
   protocol = supports two modes of operation: split and local=20 MAC.  The
   Split MAC mode is one where all = L2=20 wireless data and management
   frames are = encapsulated via=20 the CAPWAP protocol and exchanged between
   the AC and = the=20 WTP.  In the example of 802.11, as shown in Figure=20 1,
   the 802.11 frames received from a mobile node = (STA) are=20 directly
   encapsulated by the WTP and forwarded to = the=20 = AC.

          &n= bsp;   +-+        = =20 802.11=20 = frames          +-+
=             &= nbsp; |=20 |--------------------------------|=20 = |
           &n= bsp;  |=20 = |            =   +-+         &nbs= p;    =20 |=20 = |
           &n= bsp;  |=20 |--------------| |---------------|=20 = |
           &n= bsp;  |=20 |  802.11 PHY/ | |    =20 CAPWAP    |=20 = |
           &n= bsp;  |=20 | MAC sublayer |=20 = |            =   =20 |=20 = |
           &n= bsp;  +-+         =      +-+      &nbs= p;       =20 = +-+
           =    STA        &nbs= p;     WTP      &n= bsp;         AC

 = ; =20 Figure 1: Representative CAPWAP Architecture for Split=20 MAC

   The Local MAC mode of operation diffs from = Split MAC=20 as it allows for
   the data frames to be either = locally=20 bridged, or tunneled as 802.3
   frames.  The = latter=20 implies that the WTP performs the 802 bridging
  =20 function.  In either case, however, the management frames=20 are
   processed locally by the WTP, and then forwarded = to the=20 AC.  Figure 2
   provides an example using = the IEEE=20 802.11 binding, where a station
   transmits an 802.11 = frame,=20 which is encapsulated as 802.3 and
   forwarded to the=20 = AC.

          &n= bsp;   +-+=20 802.11 frames +-+ 802.3 frames +-+=20 =
           &nb= sp;  |=20 |---------------| |--------------|=20 = |
           &n= bsp;  |=20 = |            =   =20 |=20 = |            =   |=20 = |
           &n= bsp;  |=20 |---------------| |--------------|=20 = |
           &n= bsp;  |=20 |  802.11 PHY/  | |    =20 CAPWAP   |=20 = |
           &n= bsp;  |=20 | MAC sublayer  |=20 = |            =   |=20 = |
           &n= bsp;  +-+         =      =20 = +-+           &nbs= p;  +-+
        &nbs= p;     STA      &n= bsp;       =20 = WTP           &nbs= p;  =20 AC

   Figure 2: Representative CAPWAP Architecture = for=20 Local MAC
[...]

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco=20 = Systems
______________________________________________________________= ___=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_01C67F47.0BDF9237-- --===============0751047133== 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 --===============0751047133==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 24 11:59:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fivlk-0008GP-NA for capwap-archive@lists.ietf.org; Wed, 24 May 2006 11:59:32 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fivlj-0006R3-2d for capwap-archive@lists.ietf.org; Wed, 24 May 2006 11:59:32 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 97106430103 for ; Wed, 24 May 2006 08:59:30 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 594F7430093 for ; Wed, 24 May 2006 08:59:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 307FC1448004 for ; Wed, 24 May 2006 08:59:01 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.198]) by hermes.tigertech.net (Postfix) with ESMTP id 972A0144801A for ; Wed, 24 May 2006 08:58:58 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id s11so2012446wxc for ; Wed, 24 May 2006 08:58:57 -0700 (PDT) Received: by 10.70.8.15 with SMTP id 15mr7903054wxh; Wed, 24 May 2006 08:58:57 -0700 (PDT) Received: by 10.70.133.19 with HTTP; Wed, 24 May 2006 08:58:57 -0700 (PDT) Message-ID: <5bfe7a820605240858s70b423b2k1c85f441face3032@mail.gmail.com> Date: Wed, 24 May 2006 08:58:57 -0700 From: "Dorothy Stanley" To: "Saravanan Govindan" 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: capwap Subject: Re: [Capwap] Clarification for Echo Request update - Issue 45 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.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="===============1963245880==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.0 (+) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff --===============1963245880== Content-Type: multipart/alternative; boundary="----=_Part_192194_28556630.1148486337707" ------=_Part_192194_28556630.1148486337707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Saravanan, all, Agree that documenting the design choice is a good idea. I suggest that a better place for the proposed text is in section 7, Contro= l Channel Management, since the "operational" indication can come via control message= s other than just WTP Event Request. Section 7 defines the Echo Request and Response messages. Propose to change the first (and only) paragraph in Section 7 From: "The Control Channel Management messages are used by the WTP and AC to maintain a control communication channel." To "The Control Channel Management messages are used by the WTP and AC to maintain a control communication channel. CAPWAP control messages, such as the WTP Event Request message sent from the WTP to the AC indicate to the AC that the WTP is operational. When such control messages are not being sent, the Echo Request and Echo Response messages are used to maintain the contro= l communication channel. Dorothy On 5/23/06, Saravanan Govindan wrote: > > All, > > I want to propose an update to the text for Issue 45 on combining > messages. > > In addition to the recent updates, I think it is important to clarify > the design choice behind the changes. > > In Section 9.5 "WTP Event Request" of Specifications v01, I propose the > following; > > > 9.5. WTP Event Request > > WTP Event Request message is used by a WTP to send information to its > AC. The WTP Event Request message may be sent periodically, or sent > in response to an asynchronous event on the WTP. For example, a WTP > MAY collect statistics and use the WTP Event Request message to > transmit the statistics to the AC. > > [PROPOSED TEXT] > > WTP Event Request messages together with other control messages from > a > WTP indicate operational capacity of that WTP. This presumes that a > WTP > capable of sending periodic control messages (such as statistics) or > > irregular control messages (such as errors) is operational. In the > case > where regular control messages are not sent, an operational WTP sends > the > Echo Request message to indicate operational readiness. > > ----XXXX---- > > 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 > ------=_Part_192194_28556630.1148486337707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Saravanan, all,

Agree that documenting the design choice is a good idea.

I suggest that a better place for the proposed text is in section 7, Contro= l Channel
Management, since the "operational" indication can come via contr= ol messages
other than just WTP Event Request. Section 7 defines the Echo Request and R= esponse messages.

Propose to change the first (and only) paragraph in Section 7

From:

"The Control Channel Management messages are used by the WTP and AC to=
maintain a control communication channel."

To

"The Control Channel Management messages are used by the WTP and AC to=
maintain a control communication channel. CAPWAP control messages, such as = the
WTP Event Request message sent from the WTP to the AC indicate to the AC th= at the
WTP is operational. When such control messages are not being sent,
the Echo Request and Echo Response messages are used to maintain the contro= l
communication channel.


Dorothy

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

I wan= t to propose an update to the text for Issue 45 on combining
messages.
In addition to the recent updates, I think it is important to clarifythe design choice behind the changes.

In Section 9.5 "WTP Eve= nt Request" of Specifications v01, I propose the
following;


   9.5.  WTP Event Request

   = WTP Event Request message is used by a WTP to send information to its
&n= bsp;  AC.  The WTP Event Request message may be sent periodi= cally, or sent
   in response to an asynchronous event on the = WTP.  For example, a WTP
   MAY collect statistics and use the WTP Event Request messa= ge to
   transmit the statistics to the AC.

  = ; [PROPOSED TEXT]

   WTP Event Request messages together w= ith other control messages from
a
   WTP indicate operational capacity of that WTP. This presum= es that a
WTP
   capable of sending periodic control messag= es (such as statistics) or

   irregular control messages (= such as errors) is operational. In the
case
   where regular control messages are not sent, an op= erational WTP sends
the
   Echo Request message to indicate= operational readiness.

   ----XXXX----

Comments?
Saravanan

____________________________________________________= _____________
To unsubscribe or modify your subscription options, please visit:
http://lists.fr= ascone.com/mailman/listinfo/capwap

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

------=_Part_192194_28556630.1148486337707-- --===============1963245880== 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 --===============1963245880==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 24 12:05:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fivrx-0002gU-0x for capwap-archive@lists.ietf.org; Wed, 24 May 2006 12:05:57 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fivrv-0006oA-AS for capwap-archive@lists.ietf.org; Wed, 24 May 2006 12:05:57 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BE2494300D4 for ; Wed, 24 May 2006 09:05:54 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 9F2E943008F for ; Wed, 24 May 2006 09:05:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1FEF7398035 for ; Wed, 24 May 2006 09:05:02 -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 C82B7398045 for ; Wed, 24 May 2006 09:04:58 -0700 (PDT) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 24 May 2006 09:04:56 -0700 X-IronPort-AV: i="4.05,167,1146466800"; d="scan'208,217"; a="282220022:sNHT127909568" 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 k4OG4uhW030634; Wed, 24 May 2006 09:04:56 -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 k4OG4usF002912; Wed, 24 May 2006 09:04: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); Wed, 24 May 2006 09:04:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 24 May 2006 09:04:55 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201ECF4EC@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification for Echo Request update - Issue 45 Thread-Index: AcZ/SxP7m0vWJ7BJQ2KSOMOXEKlilQAALWzw From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "Saravanan Govindan" X-OriginalArrivalTime: 24 May 2006 16:04:56.0449 (UTC) FILETIME=[CCF48710:01C67F4B] Authentication-Results: sj-dkim-6.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.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] Clarification for Echo Request update - Issue 45 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.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="===============1357887632==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 This is a multi-part message in MIME format. --===============1357887632== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67F4B.CCC15B75" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67F4B.CCC15B75 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: Wednesday, May 24, 2006 8:59 AM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification for Echo Request update - Issue 45 =09 =09 Saravanan, all, =09 Agree that documenting the design choice is a good idea. =09 I suggest that a better place for the proposed text is in section 7, Control Channel Management, since the "operational" indication can come via control messages=20 other than just WTP Event Request. Section 7 defines the Echo Request and Response messages. =09 Propose to change the first (and only) paragraph in Section 7 =09 From: =09 "The Control Channel Management messages are used by the WTP and AC to maintain a control communication channel." =09 To =09 "The Control Channel Management messages are used by the WTP and AC to maintain a control communication channel. CAPWAP control messages, such as the WTP Event Request message sent from the WTP to the AC indicate to the AC that the=20 WTP is operational. When such control messages are not being sent, the Echo Request and Echo Response messages are used to maintain the control communication channel. =09 =09 Dorothy =09 =09 On 5/23/06, Saravanan Govindan wrote:=20 All, =09 I want to propose an update to the text for Issue 45 on combining messages. =09 In addition to the recent updates, I think it is important to clarify the design choice behind the changes. =09 In Section 9.5 "WTP Event Request" of Specifications v01, I propose the following; =09 =09 9.5. WTP Event Request =09 WTP Event Request message is used by a WTP to send information to its AC. The WTP Event Request message may be sent periodically, or sent in response to an asynchronous event on the WTP. For example, a WTP=20 MAY collect statistics and use the WTP Event Request message to transmit the statistics to the AC. =09 [PROPOSED TEXT] =09 WTP Event Request messages together with other control messages from a=20 WTP indicate operational capacity of that WTP. This presumes that a WTP capable of sending periodic control messages (such as statistics) or =09 irregular control messages (such as errors) is operational. In the=20 case where regular control messages are not sent, an operational WTP sends the Echo Request message to indicate operational readiness. =09 ----XXXX---- =09 Comments? =09 Saravanan =09 =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_01C67F4B.CCC15B75 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: Wednesday, May 24, = 2006 8:59=20 AM
To: Saravanan Govindan
Cc: = capwap
Subject:=20 Re: [Capwap] Clarification for Echo Request update - Issue=20 45

Saravanan, all,

Agree that documenting the design = choice is=20 a good idea.

I suggest that a better place for the proposed = text is in=20 section 7, Control Channel
Management, since the "operational" = indication=20 can come via control messages
other than just WTP Event Request. = Section 7=20 defines the Echo Request and Response messages.

Propose to = change the=20 first (and only) paragraph in Section 7

From:

"The = Control=20 Channel Management messages are used by the WTP and AC to
maintain = a=20 control communication channel."

To

"The Control Channel=20 Management messages are used by the WTP and AC to
maintain a = control=20 communication channel. CAPWAP control messages, such as the
WTP = Event=20 Request message sent from the WTP to the AC indicate to the AC that = the=20
WTP is operational. When such control messages are not being = sent,
the=20 Echo Request and Echo Response messages are used to maintain the=20 control
communication channel.


Dorothy

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

I=20 want to propose an update to the text for Issue 45 on=20 combining
messages.

In addition to the recent updates, I = think it=20 is important to clarify
the design choice behind the = changes.

In=20 Section 9.5 "WTP Event Request" of Specifications v01, I propose=20 the
following;


   9.5.  WTP Event=20 Request

   WTP Event Request message is used by a = WTP to=20 send information to its
   AC.  The WTP Event = Request=20 message may be sent periodically, or sent
   in = response to an=20 asynchronous event on the WTP.  For example, a WTP=20
   MAY collect statistics and use the WTP Event = Request=20 message to
   transmit the statistics to the=20 AC.

   [PROPOSED TEXT]

   WTP = Event=20 Request messages together with other control messages from
a=20
   WTP indicate operational capacity of that WTP. This = presumes that a
WTP
   capable of sending periodic = control=20 messages (such as statistics) or

   irregular = control=20 messages (such as errors) is operational. In the =
case
  =20 where regular control messages are not sent, an operational WTP=20 sends
the
   Echo Request message to indicate = operational=20 readiness.

  =20 = ----XXXX----

Comments?

Saravanan

___________________= ______________________________________________=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_01C67F4B.CCC15B75-- --===============1357887632== 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 --===============1357887632==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 24 12:27:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiwCW-0003QX-Qd for capwap-archive@lists.ietf.org; Wed, 24 May 2006 12:27:12 -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 1FivKM-0004oc-Ld for capwap-archive@lists.ietf.org; Wed, 24 May 2006 11:31:14 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FivGf-00046R-Vh for capwap-archive@lists.ietf.org; Wed, 24 May 2006 11:27:29 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 718C84300FE for ; Wed, 24 May 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 935EF430093 for ; Wed, 24 May 2006 08:26:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4DD89144802E for ; Wed, 24 May 2006 08:26:52 -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 3E4DE1448029 for ; Wed, 24 May 2006 08:26:48 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id s19so643935wxc for ; Wed, 24 May 2006 08:26:48 -0700 (PDT) Received: by 10.70.116.10 with SMTP id o10mr7863171wxc; Wed, 24 May 2006 08:26:47 -0700 (PDT) Received: by 10.70.133.19 with HTTP; Wed, 24 May 2006 08:26:47 -0700 (PDT) Message-ID: <5bfe7a820605240826x4908c7dcs5d152e42fa4f98cc@mail.gmail.com> Date: Wed, 24 May 2006 08:26:47 -0700 From: "Dorothy Stanley" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201ECEB8A@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A201ECEB8A@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 for Issue 77: Update figure 1 to depict a generic CAPWAP architecture X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.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="===============0220348749==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -1.4 (-) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd --===============0220348749== Content-Type: multipart/alternative; boundary="----=_Part_191508_12078427.1148484407679" ------=_Part_191508_12078427.1148484407679 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Pat, Overall - Fine by me also, a couple of suggested edits: Change "split and local MAC" to "Split and Local MAC" Change "The Split MAC mode is one where" to "In Split MAC Mode" Below Figure 1, delete "diffs from Split MAC as it" Change "In either case, however, the management frames are processed locally by the WTP" to In either case, the L2 wireless management frames are processed locally by the WTP" Dorothy On 5/22/06, Pat Calhoun (pacalhou) wrote: > > All, > > Here is my proposed resolution for the above mentioned issue. While the > original issue submitted included a proposed resolution, it was a > combined figure that attempted to show all possible modes of operation, > which I found confusing. Instead, I prefer to have a separate figure > (and text) to discuss local MAC. > > Comments appreciated. > > 1. Introduction > [...] > > CAPWAP assumes a network configuration consisting of multiple WTPs > communicating via the Internet Protocol (IP) to an AC. WTPs are > viewed as remote RF interfaces controlled by the AC. The CAPWAP > protocol supports two modes of operation: split and local MAC. The > Split MAC mode is one where all L2 wireless data and management > frames are encapsulated via the CAPWAP protocol and exchanged between > the AC and the WTP. In the example of 802.11, as shown in Figure 1, > the 802.11 frames received from a mobile node (STA) are directly > encapsulated by the WTP and forwarded to the AC. > > +-+ 802.11 frames +-+ > | |--------------------------------| | > | | +-+ | | > | |--------------| |---------------| | > | | 802.11 PHY/ | | CAPWAP | | > | | MAC sublayer | | | | > +-+ +-+ +-+ > STA WTP AC > > Figure 1: Representative CAPWAP Architecture for Split MAC > > The Local MAC mode of operation diffs from Split MAC as it allows for > the data frames to be either locally bridged, or tunneled as 802.3 > frames. The latter implies that the WTP performs the 802 bridging > function. In either case, however, the management frames are > processed locally by the WTP, and then forwarded to the AC. Figure 2 > provides an example using the IEEE 802.11 binding, where a station > transmits an 802.11 frame, which is encapsulated as 802.3 and > forwarded to the AC. > > +-+ 802.11 frames +-+ 802.3 frames +-+ > | |---------------| |--------------| | > | | | | | | > | |---------------| |--------------| | > | | 802.11 PHY/ | | CAPWAP | | > | | MAC sublayer | | | | > +-+ +-+ +-+ > STA WTP AC > > Figure 2: Representative CAPWAP Architecture for Local MAC > [...] > > 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_191508_12078427.1148484407679 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Pat,

Overall - Fine by me also, a couple of suggested edits:

Change "split and local MAC" to "Split and Local MAC" Change "The Split MAC mode is one where" to "In Split MAC Mo= de"

Below Figure 1, delete "diffs from Split MAC as it"

Change "In either case, however, the management frames are
   processed locally by the WTP"

to
In either case, the L2 wireless management frames are
   processed locally by the WTP"

Dorothy

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

Here is my proposed resolution for the above mentioned issue. W= hile the
original issue submitted included a proposed resolution, it was= a
combined figure that attempted to show all possible modes of operatio= n,
which I found confusing. Instead, I prefer to have a separate figure(and text) to discuss local MAC.

Comments appreciated.

1.&nb= sp; Introduction
[...]

   CAPWAP assumes a network= configuration consisting of multiple WTPs
   communicating via the Internet Protocol (IP) to an AC.&nbs= p; WTPs are
   viewed as remote RF interfaces controlled = by the AC.  The CAPWAP
   protocol supports two mode= s of operation: split and local MAC.  The
   Split M= AC mode is one where all L2 wireless data and management
   frames are encapsulated via the CAPWAP protocol and exchan= ged between
   the AC and the WTP.  In the example o= f 802.11, as shown in Figure 1,
   the 802.11 frames received = from a mobile node (STA) are directly
   encapsulated by the WTP and forwarded to the AC.

&n= bsp;            = ; +-+         802.11 frames          +-+
&n= bsp;            = ; | |--------------------------------| |
    &n= bsp;         | |            &n= bsp; +-+          &n= bsp;    | |
           &n= bsp;  | |--------------| |---------------| |
   = ;           | |  802.11 PHY/ | |     CAPWAP    | |
      &n= bsp;       | | MAC sublayer | |            &n= bsp;  | |
           &n= bsp;  +-+         &n= bsp;    +-+       &n= bsp;       +-+
           &n= bsp;  STA         &n= bsp;    WTP       &n= bsp;        AC

   = Figure 1: Representative CAPWAP Architecture for Split MAC

 &nb= sp; The Local MAC mode of operation diffs from Split MAC as it allows for   the data frames to be either locally bridged, or tunneled as= =20 802.3
   frames.  The latter implies that the WTP pe= rforms the 802 bridging
   function.  In either case= , however, the management frames are
   processed locally by t= he WTP, and then forwarded to the AC.  Figure 2
   provides an example using the IEEE 802.11 binding, where a= station
   transmits an 802.11 frame, which is encapsulated a= s 802.3 and
   forwarded to the AC.

   &= nbsp;          +-+ 802.11= frames +-+ 802.3 frames +-+
            = ;  | |---------------| |--------------| |
   &n= bsp;          | |            &n= bsp;  | |            &n= bsp; | |
           &nbs= p;  | |---------------| |--------------| |
   &= nbsp;          | |  802.11 PHY/  | |     CAPWAP   | |
        &= nbsp;     | | MAC sublayer  | |            &n= bsp; | |
           &nbs= p;  +-+         &nbs= p;     +-+            =   +-+
         &n= bsp;    STA       &n= bsp;       WTP            =    AC

   Figure 2: Representative CAPWAP Architecture for Loc= al MAC
[...]

Pat Calhoun
CTO, Wireless Networking Business Uni= t
Cisco Systems
_____________________________________________________= ____________
To unsubscribe or modify your subscription options, please visit:
http://lists.fr= ascone.com/mailman/listinfo/capwap

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

------=_Part_191508_12078427.1148484407679-- --===============0220348749== 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 --===============0220348749==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 24 12:29:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiwF3-0003fB-4b for capwap-archive@lists.ietf.org; Wed, 24 May 2006 12:29:49 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiwF1-00089I-B4 for capwap-archive@lists.ietf.org; Wed, 24 May 2006 12:29:49 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D1ACB4300F5 for ; Wed, 24 May 2006 09:29:46 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id F210343008F for ; Wed, 24 May 2006 09:28:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C7500144802D for ; Wed, 24 May 2006 09:28:50 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.205]) by hermes.tigertech.net (Postfix) with ESMTP id 727C71448028 for ; Wed, 24 May 2006 09:28:47 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id s19so655027wxc for ; Wed, 24 May 2006 09:28:46 -0700 (PDT) Received: by 10.70.111.19 with SMTP id j19mr2338213wxc; Wed, 24 May 2006 09:28:46 -0700 (PDT) Received: by 10.70.133.19 with HTTP; Wed, 24 May 2006 09:28:46 -0700 (PDT) Message-ID: <5bfe7a820605240928r42d3c2c8u74f72a6e831134ae@mail.gmail.com> Date: Wed, 24 May 2006 09:28:46 -0700 From: "Dorothy Stanley" To: "David T. Perkins" 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=FROM_ENDS_IN_NUMS, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: [Capwap] Issue 85 - Proposed Resolution/wasRe: Proposal for updated 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="===============0603909179==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 --===============0603909179== Content-Type: multipart/alternative; boundary="----=_Part_192819_28860812.1148488126376" ------=_Part_192819_28860812.1148488126376 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, 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. Proposed resolution for Issue 85: - Issue 85 changes 1 and 3 have been incorporated into the -01 state machine. - Issue 85 changes 2&4 - introduce explicit start states for the WTP and th= e AC. Propose to reject, as a single state with the accompanying text is sufficient - 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. Comments? Thanks, Dorothy On 3/20/06, David T. Perkins wrote: > > HI, > > Below is a proposal for an updated state machine: > > /-------------\ > | 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+----------+ > > > 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)" > 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 > 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", > 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" > to "Config1" to "Image Data". The results are: > States: > Config1 - image version determination for the WTP > Config2 - the "complete" initial configuration of > a WTP > 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 > 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 > 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. > > 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_192819_28860812.1148488126376 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All,

Issue 85 is listed below.  Apart from the initial posting, there has b= een
no follow-up discussion. Issue 85 provided comments on the draft-00 state m= achine.

Proposed resolution for Issue 85:

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

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

- Issue 85 change 5 Proposes 2 config states, one for image version determi= nation, 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 1= 08, which addresses configuration as a whole.

Comments?

Thanks,

Dorothy

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

Below is a proposal for an updated state machine:

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


Changes:
1) Removed the "C" in all s= tates
2) Renamed state "Idle" to "WTP start"
3) R= emoved transition "t" from "Run" to "WTP start(Idl= e)"
4) Added state "AC start" and "x1" and "x2&quo= t;
   States:
     WTP-Start - the &quo= t;start state" for WTPs
     AC-Start - the &qu= ot;start state for ACs
   Transitions:
     x1 - AC-Start to AC-Start - the AC recieves a Disc= over
          request mes= sage and responds with a Discovery
      &= nbsp;   response message
     x2 - AC= -Start to DTLS-Init - the AC does this transition
   &nbs= p;      when it receives a ClientHello from a= WTP
5) Added start "Config1", renamed state "Configure&q= uot; to "Config2",
   moved transition "2" from "DTLS-Complete&qu= ot; to "Configure"
   to "Config1" to &quo= t;Config2", added transition "x3", and
   moved= transition "4" from "DTL-Complete" to "Image Data= "
   to "Config1" to "Image Data". The resu= lts are:
   States:
     Config1 - imag= e version determination for the WTP
     Config2 - t= he "complete" initial configuration of
    = ;           a WTP
   Transitions:
     x3 - the DTLS ses= sion is established transition to
      &n= bsp;   state where the AC determines
   &n= bsp;      the WTP physical configuration, and= the list of
          = ;images available on the WTP, and the image that
          the WTP is = running.
     2 - The AC determined that the image t= hat the WTP is
         running = is appropriate and proceeds to a state
     &nb= sp;   to set the initial configuration of the WTP.
  = ;   4 - The AC determined that either that the WTP needs
         a new image, or that t= he WTP needs to be running
       &nb= sp; a different image. Thus, it proceeds to a state
   &n= bsp;     to put (if needed) a new image on the WTP and<= br>         set it to be used after= the WTP resets.

Regards,
/david t. perkins

______________________________= ___________________________________
To unsubscribe or modify your subscr= iption options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.co= m/pipermail/capwap

------=_Part_192819_28860812.1148488126376-- --===============0603909179== 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 --===============0603909179==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 24 14:23:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiy0b-0002PW-MP for capwap-archive@lists.ietf.org; Wed, 24 May 2006 14:23:01 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiy0W-0005q0-DA for capwap-archive@lists.ietf.org; Wed, 24 May 2006 14:23:01 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 04C464300CD for ; Wed, 24 May 2006 11:22:47 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7D18F430082 for ; Wed, 24 May 2006 11:21:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4C087144802D for ; Wed, 24 May 2006 11:21:58 -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 BED631448009 for ; Wed, 24 May 2006 11:21:55 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id s11so2034963wxc for ; Wed, 24 May 2006 11:21:54 -0700 (PDT) Received: by 10.70.8.15 with SMTP id 15mr8061243wxh; Wed, 24 May 2006 11:21:53 -0700 (PDT) Received: by 10.70.133.19 with HTTP; Wed, 24 May 2006 11:21:53 -0700 (PDT) Message-ID: <5bfe7a820605241121g2efe49ffkb33a349365b7cdde@mail.gmail.com> Date: Wed, 24 May 2006 11:21:53 -0700 From: "Dorothy Stanley" To: "Saravanan Govindan" 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 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="===============0718302221==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 52005c17383d4e3f609075a067e11971 --===============0718302221== Content-Type: multipart/alternative; boundary="----=_Part_194328_3103699.1148494913345" ------=_Part_194328_3103699.1148494913345 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 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? 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 < =3D=3DNe= w connection with an AC has failed due to software related reasons. HW Failure Count: The number of times that a CAPWAP protocol <=3D=3DNew connection with an AC has failed due to hardware related reasons. Other Failure Count: The number of times that a CAPWAP protocol <=3D=3D= 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 <=3D= =3DNew connection with an AC has failed for unknown reasons. Last Failure Type: The failure type of the most recent WTP failure. Th= e following values are <=3D=3D 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 <=3D=3DNew The WTP Operational Statistics message element is sent by the WTP to th= e 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: <=3D=3D= 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 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 th= e > 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_194328_3103699.1148494913345 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Saravanan, all,

Agreed.

This mail discusses the Issue 84 proposed statistics, and proposes addition= al statistics.

-------------------Issue 84---------------------------- 
<snip> introduce a "Statistics" message element w=
ith 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

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
br>     |          WTP Load             |     WTP Transmit Queue        |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |    Channel Interference       |          Congestion           |<=
br>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Type: TBD

WTP Load: A 16-bit value specifying the load (fram=
es/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 Interferenc=
e: A 16-bit value specifying SINR (dB) monitored by the WTP.

Congest=
ion: 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? g= oing 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 q= ueues, or an
aggregate of all wireless transmit queues?

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 th= is 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 ele= ment, 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            &n= bsp;      1            &n= bsp;      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-
     |          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 d= ue to a WTP
      crash.  A value of 65535 implies that t= his information is not
      available on the WTP.

   AC Initiated Count:  The number of reboots that have occu= rred at
      the request of a CAPWAP protocol message, su= ch as a change in
      configuration that required a reboot or an e= xplicit 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 pr= otocol
      connection with an AC has failed due to link= failure.

   SW Failure Count:  The number of times that a CAPWAP prot= ocol < =3D=3DNew
      connection with an AC has failed due to soft= ware related reasons.

   HW Failure Count:  The number of times that a CAPWAP prot= ocol <=3D=3DNew
      connection with an AC has failed due to hard= ware related reasons.

   Other Failure Count:  The number of times that a CAPWAP p= rotocol <=3D=3DNew
      connection with an AC has failed due to know= n reasons, other than AC initiated,
     link, SW or HW failure.

   Unknown Failure Count:  The number of times that a CAPWAP= protocol <=3D=3DNew
      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 <=3D=3D 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           = ;            &n= bsp;  <=3D=3DNew

   The WTP  Operational Statistics message element is sent b= y the WTP to the
   AC to provide statistics realted to the operation of the WTP.<= br>
      0            &n= bsp;      1            &n= bsp;      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-
     | Wireless Link Frames/Sec |     &n= bsp;    (Expect more fields to be added...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++++++

   Type:  TBD for WTP  Operational  Statistics

   Length:  xx

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

Proposed New message element:           &= nbsp;           &nbs= p;            &= nbsp;  <=3D=3DNew

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            &n= bsp;      1            &n= bsp;      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-
     |   Radio ID      |Last Fail Type  |       Reset Count       = ;          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-
     |     SW Failure Count             |        HW Failure Count          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++= +++++++
     |      Other  Failure Count         |   Unknown Failure Count       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++= +++++++
     |   Config Update Count    &nb= sp;       |    Channel Change Count      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+
     |   Band Change Count     &nbs= p;      |    Current Noise Floor            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+


   Type:  TBD for WTP  Radio Statistics

   Length:  20

   Radio ID:  The radio ID of the radio to which the statist= ics apply.

   Last Failure Type:  The failure type of the most recent r= adio 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 rea= sons.

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

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

   Config Update Count:  The number of times that the radio<= br>        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 nois= e floor
       of the radio receiver in units of dBm.=
------------------------------------------------------------

On 5/23/06, Saravan= an 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 c= ase, new message elements can be defined for the chosen stats.

 

Saravanan

 

 

 

 

 

Issue 84, "Piggybacking statistical information in Echo Request/response is rela= ted 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<= br> Echo message as transport for statistics, but the question of additional us= eful
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) <pca= lhoun@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://lis= ts.frascone.com/pipermail/capwap

 


------=_Part_194328_3103699.1148494913345-- --===============0718302221== 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 --===============0718302221==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 24 14:33:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiyAa-0007Gp-74 for capwap-archive@lists.ietf.org; Wed, 24 May 2006 14:33:20 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiyAY-0006mA-Ne for capwap-archive@lists.ietf.org; Wed, 24 May 2006 14:33:20 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4230D4300F2 for ; Wed, 24 May 2006 11:33:18 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id A8462430082 for ; Wed, 24 May 2006 11:32:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 95FF0144801A for ; Wed, 24 May 2006 11:32:50 -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 20485144802E for ; Wed, 24 May 2006 11:32:46 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id s11so2036660wxc for ; Wed, 24 May 2006 11:32:46 -0700 (PDT) Received: by 10.70.12.16 with SMTP id 16mr8078843wxl; Wed, 24 May 2006 11:32:39 -0700 (PDT) Received: by 10.70.133.19 with HTTP; Wed, 24 May 2006 11:32:39 -0700 (PDT) Message-ID: <5bfe7a820605241132xfc7cee6tf4310f35507015be@mail.gmail.com> Date: Wed, 24 May 2006 11:32:39 -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_60_70, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: [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: multipart/mixed; boundary="===============0650124771==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc --===============0650124771== Content-Type: multipart/alternative; boundary="----=_Part_194432_24887118.1148495559657" ------=_Part_194432_24887118.1148495559657 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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? > > > > > > ------=_Part_194432_24887118.1148495559657 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All,

I would like to develop text to resolve Issue 105, but need some more infor= mation 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:

 <= /p>

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?


=


------=_Part_194432_24887118.1148495559657-- --===============0650124771== 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 --===============0650124771==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 24 15:10:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiykX-0001Op-Ty for capwap-archive@lists.ietf.org; Wed, 24 May 2006 15:10:29 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiykW-0000To-9Y for capwap-archive@lists.ietf.org; Wed, 24 May 2006 15:10:29 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A50F84300D2 for ; Wed, 24 May 2006 12:10:27 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B990D430082 for ; Wed, 24 May 2006 12:09:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 96E551448025 for ; Wed, 24 May 2006 12:09:56 -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 EC5E61448035 for ; Wed, 24 May 2006 12:09:53 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id s11so2042036wxc for ; Wed, 24 May 2006 12:09:53 -0700 (PDT) Received: by 10.70.80.11 with SMTP id d11mr8122441wxb; Wed, 24 May 2006 12:09:53 -0700 (PDT) Received: by 10.70.133.19 with HTTP; Wed, 24 May 2006 12:09:53 -0700 (PDT) Message-ID: <5bfe7a820605241209x29544ef5q5562ce8d238d003f@mail.gmail.com> Date: Wed, 24 May 2006 12:09:53 -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=0.8 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_10_20, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Proposed Resolution to Issue 97: Discovery Type Definition 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="===============0238279737==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.8 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 --===============0238279737== Content-Type: multipart/alternative; boundary="----=_Part_194852_24073085.1148497793292" ------=_Part_194852_24073085.1148497793292 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 bee= n 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 elem= ent 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. - T= he 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 disco= very 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 bee= n 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_194852_24073085.1148497793292 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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
+-+-+-+-+-+-+-+-+
 | D=
iscovery 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 - Broadcast1 - 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 knowled=
ge 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 t=
o discover potential ACs.

The current definition is below:


The Discovery message element is used to configure a WTP to operate in aspecific mode.
 0
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
 | Discov=
ery Type|
 +-+-+-+-+-+-+-+-+

Type: 58 for Discovery Type


 Length: 1
Discovery Type: An 8-bit value indicating how the AC was disc=
overed.
The following values are supported:
 0 - Broadcast
1 - Con=
figured

Comments:
1. The statement that " The Discovery mess=
age element is used to configure a WTP

to operate in a specific mode." seems inconsistent
with its inc=
lusion in the Discovery Request message.
2. Discovery Type: An 8-bit val=
ue 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 l=
ike this
would be part of WTP configuration, rather than being included =
in the discovery

request message.
3. What is the purpose/value of including "Dis=
covery 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 knowled=
ge of the AC
The following values are supported:
 0 - Unknown
1 - =
 Configured

------=_Part_194852_24073085.1148497793292-- --===============0238279737== 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 --===============0238279737==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 24 15:27:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiz0w-0000c1-M3 for capwap-archive@lists.ietf.org; Wed, 24 May 2006 15:27:27 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiz0v-0001Qx-7S for capwap-archive@lists.ietf.org; Wed, 24 May 2006 15:27:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6EE724300EA for ; Wed, 24 May 2006 12:27:24 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 466BD430082 for ; Wed, 24 May 2006 12:27:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 35D82398025 for ; Wed, 24 May 2006 12:27:00 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8B200398041 for ; Wed, 24 May 2006 12:26:58 -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 k4OJQwu5020524; Wed, 24 May 2006 12:26:58 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k4OJQvNh020516; Wed, 24 May 2006 12:26:57 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 24 May 2006 12:26:57 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Dorothy Stanley In-Reply-To: <5bfe7a820605241209x29544ef5q5562ce8d238d003f@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 to Issue 97: Discovery Type Definition 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: 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: 932cba6e0228cc603da43d861a7e09d8 HI, 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. 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. Regards, /david t. perkins On Wed, 24 May 2006, Dorothy Stanley wrote: > 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 Wed May 24 21:03:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj4Fp-0005sS-00 for capwap-archive@lists.ietf.org; Wed, 24 May 2006 21:03:09 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj4Fn-0007ax-Jh for capwap-archive@lists.ietf.org; Wed, 24 May 2006 21:03:08 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9135F4300E2 for ; Wed, 24 May 2006 18:03:06 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1946C430082 for ; Wed, 24 May 2006 18:02:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0277939801F for ; Wed, 24 May 2006 18:02:42 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0C0A0398013 for ; Wed, 24 May 2006 18:02: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/bulls) with ESMTP id k4P12dR9004922 for ; Thu, 25 May 2006 10:02:39 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k4P12du05669 for ; Thu, 25 May 2006 10:02:39 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with SMTP id k4P12c524420 for ; Thu, 25 May 2006 10:02:38 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 25 May 2006 09:00:32 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDE6AAED@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification of protocol goals Thread-Index: AcZ/l7/vR1jdAqKyTDC/ZVAyrz3e/w== From: "Saravanan Govindan" To: "capwap" 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: [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.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 24 21:35:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj4kj-0006L2-Lp for capwap-archive@lists.ietf.org; Wed, 24 May 2006 21:35:05 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj4ki-00014P-6J for capwap-archive@lists.ietf.org; Wed, 24 May 2006 21:35:05 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 91B484300DC for ; Wed, 24 May 2006 18:35:03 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E80BD430082 for ; Wed, 24 May 2006 18:34:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D8569398036 for ; Wed, 24 May 2006 18:34:38 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id EC58A398027 for ; Wed, 24 May 2006 18:34:34 -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 k4P1YXtI024637; Thu, 25 May 2006 10:34:33 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k4P1YXu19320; Thu, 25 May 2006 10:34:33 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with SMTP id k4P1YXV02808; Thu, 25 May 2006 10:34:33 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 25 May 2006 09:32:28 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDE6AAFE@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Terminology section Thread-Index: AcZ+OLs9cTLmGbUDRXyoZix20i6UBwAUtbngABGomzAAGo9vkAAXwKDA From: "Saravanan Govindan" To: "Pat Calhoun (pacalhou)" , "capwap" 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] 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.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 24 23:41:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj6ii-0000GI-Th for capwap-archive@lists.ietf.org; Wed, 24 May 2006 23:41:08 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj6ig-0008AW-EZ for capwap-archive@lists.ietf.org; Wed, 24 May 2006 23:41:08 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 453064300DF for ; Wed, 24 May 2006 20:40:55 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2643B430067 for ; Wed, 24 May 2006 20:40:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 10A5E1448007 for ; Wed, 24 May 2006 20:40:29 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5E5D71448005 for ; Wed, 24 May 2006 20:40: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 k4P3eQ1p026039; Wed, 24 May 2006 20:40:26 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k4P3eQJP026035; Wed, 24 May 2006 20:40:26 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 24 May 2006 20:40:26 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Saravanan Govindan In-Reply-To: <5F09D220B62F79418461A978CA0921BDE6AAFE@pslexc01.psl.local> 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] 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: 0ff9c467ad7f19c2a6d058acd7faaec8 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 Thu May 25 01:21:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj8HQ-0004TO-2G for capwap-archive@lists.ietf.org; Thu, 25 May 2006 01:21:04 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj83c-0006GI-G9 for capwap-archive@lists.ietf.org; Thu, 25 May 2006 01:06:51 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7075A4300CD for ; Wed, 24 May 2006 22:06:47 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C82B5430058 for ; Wed, 24 May 2006 22:06:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AD715144800B for ; Wed, 24 May 2006 22:06:22 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 92B921448009 for ; Wed, 24 May 2006 22:06:20 -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 k4P569Ni026519; Thu, 25 May 2006 14:06:09 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k4P569D10754; Thu, 25 May 2006 14:06:09 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with SMTP id k4P56B510111; Thu, 25 May 2006 14:06:11 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 25 May 2006 13:04:09 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDE6ABAD@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Terminology section Thread-Index: AcZ/rLKBNdClEvOUQemwL3Va7VswfAADNwPg From: "Saravanan Govindan" To: "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.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO 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.1 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Hi David, Can you please clarify why you think references to previous Informational documents are inappropriate? Saravanan -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Thursday, May 25, 2006 11:40 AM 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 Thu May 25 09:35:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjFzi-0008W4-T4 for capwap-archive@lists.ietf.org; Thu, 25 May 2006 09:35:18 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjFzh-00016J-DX for capwap-archive@lists.ietf.org; Thu, 25 May 2006 09:35:18 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4AD5A4300E0 for ; Thu, 25 May 2006 06:35:12 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1EE72430058 for ; Thu, 25 May 2006 06:34:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0E8FA398041 for ; Thu, 25 May 2006 06:34:50 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.152]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4887A398036 for ; Thu, 25 May 2006 06:34: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 (rwcrmhc12) with ESMTP id <20060525133442m1200q16qfe>; Thu, 25 May 2006 13:34:43 +0000 Message-ID: <4475B272.5040509@hyperthought.com> Date: Thu, 25 May 2006 06:34:42 -0700 From: Scott G Kelly User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Saravanan Govindan References: <5F09D220B62F79418461A978CA0921BDE6AAFE@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BDE6AAFE@pslexc01.psl.local> 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] 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: 3fbd9b434023f8abfcb1532abaec7a21 Hi Saravanan, I'm not sure I agree that we need to copy the terms from the security considerations, because their meaning seems quite clear right where they are used (and they are only used in that one instance). Also, your definitions lack required precision. Protected data (in the context referred to in 13.1, i.e. wrapped in DTLS), in addition to being encrypted, provides for data integrity assurance and data origin authentication. Also, unprotected data may be exchanged between unauthenticated as well as authenticated peers (e.g. a discovery message is "unprotected data"). I don't think we should constrain the definitions of these terms in the suggested ways, and I think that if there is going to be a terminology section, there should be some clear admission criteria - otherwise, we stand to gain a fat dictionary at the front of the document which isn't meeting any clear need. Scott 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 Thu May 25 09:49:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjGDi-0007rt-Ou for capwap-archive@lists.ietf.org; Thu, 25 May 2006 09:49:46 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjGDg-0002wU-Ui for capwap-archive@lists.ietf.org; Thu, 25 May 2006 09:49:46 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7F5D94300B3 for ; Thu, 25 May 2006 06:49:44 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 6562F4300EC for ; Thu, 25 May 2006 06:46:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 390BD430DB0 for ; Thu, 25 May 2006 06:46:25 -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 279F9430DA4 for ; Thu, 25 May 2006 06:46:22 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id s19so725520wxc for ; Thu, 25 May 2006 06:46:22 -0700 (PDT) Received: by 10.70.40.11 with SMTP id n11mr212771wxn; Thu, 25 May 2006 06:46:22 -0700 (PDT) Received: by 10.70.133.19 with HTTP; Thu, 25 May 2006 06:46:22 -0700 (PDT) Message-ID: <5bfe7a820605250646o556a1b83l473b5c6bf2b9dc3b@mail.gmail.com> Date: Thu, 25 May 2006 06:46:22 -0700 From: "Dorothy Stanley" To: "David T. Perkins" In-Reply-To: MIME-Version: 1.0 References: <5bfe7a820605241209x29544ef5q5562ce8d238d003f@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 Subject: Re: [Capwap] Proposed Resolution to Issue 97: Discovery Type Definition 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="===============1527597392==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.0 (+) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb --===============1527597392== Content-Type: multipart/alternative; boundary="----=_Part_204417_16967919.1148564782122" ------=_Part_204417_16967919.1148564782122 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline David, 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. 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. Dorothy On 5/24/06, David T. Perkins wrote: > > HI, > > 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. > > 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. > > Regards, > /david t. perkins > > On Wed, 24 May 2006, Dorothy Stanley wrote: > > 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_204417_16967919.1148564782122 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline David,

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.

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.

Dorothy

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

I think that this problem description and proposed resolution ar= e
premature. A complete description and solution is needed on the
boo= t process. I feel that the current draft is not there yet,
since the mod= el is not well described.

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

Regards,
/david t. perkins

On Wed, 24 May 2006, Dorothy S= tanley wrote:
> All,
>
> Issue 97 is listed below, togeth= er with a proposed resolution.
>
> Comments please.
>
> Thanks,
>
> Dorothy
> -------------
>
&= gt; 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 - Broadca= st
> 1 - Configured
>
> to
>
> The Discovery = Type message element is used to indicate that the WTP has been
> conf= igured with the AC address
> to which the corresponding Discovery Request message is sent.
&= gt;  0
>  0 1 2 3 4 5 6 7
> +-+-+-+-+-+-+-+= -+
>  | Discovery Type|
>  +-+-+-+-+-+-+-+-= +
>
> Type: 19 for Discovery Type
>
>  Length: 1
> Discovery Type: An 8-bit valu= e indicating WTP knowledge of the AC
> The following values are suppo= rted:
>  0 - Unknown
> 1 -  Configured
&= gt;
>
>
>
>
>
>
>
>
>
>
>
> Is= sue 97:
>
> Section 5.1.1 Defines the Discovery Type message el= ement. This message element
> is included in the
> Discovery Re= quest message, sent by WTPs to discover potential ACs.
>
> The current definition is below:
>
> The Disco= very message element is used to configure a WTP to operate in a
> spe= cific mode.
>  0
>  0 1 2 3 4 5 6 7
>= +-+-+-+-+-+-+-+-+
>  | Discovery Type|
>  +-+-+-+-+-+-+-+-+<= br>>
> Type: 58 for Discovery Type
>
>  Leng= th: 1
> Discovery Type: An 8-bit value indicating how the AC was disc= overed.
> The following values are supported:
>  0 - Broadcast
> 1 - Configured
>
> Co= mments:
> 1. The statement that " The Discovery message element = is used to configure a WTP
> to operate in a specific mode." see= ms inconsistent
> with its inclusion in the Discovery Request message.
> 2. Di= scovery 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 messag= e 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 WT= P 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 Di= scovery 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 Ty= pe|
>  +-+-+-+-+-+-+-+-+
>
> Type: 58 for Discovery Type
>
>  Len= gth: 1
> Discovery Type: An 8-bit value indicating WTP knowledge of t= he AC
> The following values are supported:
>  0 - Un= known
> 1 -  Configured
>


------=_Part_204417_16967919.1148564782122-- --===============1527597392== 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 --===============1527597392==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu May 25 10:46:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjH6G-00065G-Jo for capwap-archive@lists.ietf.org; Thu, 25 May 2006 10:46:08 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjH6F-0007fa-2a for capwap-archive@lists.ietf.org; Thu, 25 May 2006 10:46:08 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 07FE44300D6 for ; Thu, 25 May 2006 07:46:06 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2B14E430058 for ; Thu, 25 May 2006 07:45:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 12DBF430E93 for ; Thu, 25 May 2006 07:45: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 1B9A0430E81 for ; Thu, 25 May 2006 07:45:17 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 25 May 2006 07:45:17 -0700 X-IronPort-AV: i="4.05,173,1146466800"; d="scan'208"; a="1812720147:sNHT35201414" 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 k4PEjH5M014777; Thu, 25 May 2006 07:45:17 -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 k4PEjHHc025170; Thu, 25 May 2006 07:45: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); Thu, 25 May 2006 07:45:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 25 May 2006 07:45:15 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201ECF86F@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Terminology section Thread-Index: AcZ/rPwCFF7q1gKBR1CeeP5wj7xbTAAXMcvQ From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" , "Saravanan Govindan" X-OriginalArrivalTime: 25 May 2006 14:45:16.0882 (UTC) FILETIME=[D6863B20:01C68009] 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 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: e472ca43d56132790a46d9eefd95f0a5 Do people agree with David's position that the CAPWAP protocol spec should stand on its own, and therefore should not require the user to refer to terminology defined in the objectives I-D? 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 Thu May 25 11:42:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjHyh-00030m-Qv for capwap-archive@lists.ietf.org; Thu, 25 May 2006 11:42:23 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjHyd-0004Gz-AB for capwap-archive@lists.ietf.org; Thu, 25 May 2006 11:42:23 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 87F554300E6 for ; Thu, 25 May 2006 08:42:12 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B6FA8430058 for ; Thu, 25 May 2006 08:41:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A3849398046 for ; Thu, 25 May 2006 08:41:47 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C5CBE39804C for ; Thu, 25 May 2006 08:41: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 k4PFfhC5017890; Thu, 25 May 2006 08:41:43 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k4PFfgnc017887; Thu, 25 May 2006 08:41:42 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 25 May 2006 08:41:42 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Saravanan Govindan In-Reply-To: <5F09D220B62F79418461A978CA0921BDE6ABAD@pslexc01.psl.local> 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] 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: 2a76bcd37b1c8a21336eb0a1ea6bbf48 HI, I believe that having RFC4118 and the Objectives I-D as normative references is inappropriate. For me, specifications that are complete, consistent, and have minimal dependencies on other documents are easier to understand, write code, and use for deployment. Regards, /david t. perkins On Thu, 25 May 2006, Saravanan Govindan wrote: > Hi David, > > Can you please clarify why you think references to previous > Informational documents are inappropriate? > > Saravanan > > > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Thursday, May 25, 2006 11:40 AM > 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 Thu May 25 11:50:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjI6h-0005qb-DC for capwap-archive@lists.ietf.org; Thu, 25 May 2006 11:50:39 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjI6g-0004nG-0M for capwap-archive@lists.ietf.org; Thu, 25 May 2006 11:50:39 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3449E4300FC for ; Thu, 25 May 2006 08:50:37 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id DFE17430058 for ; Thu, 25 May 2006 08:50:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D29E039804C for ; Thu, 25 May 2006 08:50:16 -0700 (PDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.200.83]) by zoidberg.tigertech.net (Postfix) with ESMTP id DB245398058 for ; Thu, 25 May 2006 08:50:11 -0700 (PDT) Received: from ceili (c-66-30-121-250.hsd1.ma.comcast.net[66.30.121.250]) by comcast.net (sccrmhc13) with SMTP id <2006052515500901300bki5je>; Thu, 25 May 2006 15:50:10 +0000 From: "Margaret Wasserman" To: "'David T. Perkins'" , "'Saravanan Govindan'" Date: Thu, 25 May 2006 11:50:07 -0400 Message-ID: <059b01c68012$e6126650$0202a8c0@corp.devicescape.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: Thread-Index: AcaAEc91om0u89XcTyWDXJpZClvmlgAAJaSQ 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] 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: 2409bba43e9c8d580670fda8b695204a Hi All, > I believe that having RFC4118 and the Objectives I-D as > normative references is inappropriate. > > For me, specifications that are complete, consistent, and > have minimal dependencies on other documents are easier to > understand, write code, and use for deployment. I agree with David's points, but this is not just a matter or taste and/or a matter to be decided by rough consensus of the WG. For CAPWAP to be published as a Standards-Track specification, it cannot have normative dependencies on Informational documents. Referencing Informational RFCs from Standards-Track RFCs is called a "down reference" and it is only allowed in the IETF under certain specific conditions, none of which would seem to apply here. 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 Thu May 25 13:21:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjJWN-0008GM-7i for capwap-archive@lists.ietf.org; Thu, 25 May 2006 13:21:15 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjJWL-0003g3-R4 for capwap-archive@lists.ietf.org; Thu, 25 May 2006 13:21:15 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 912E34300C5 for ; Thu, 25 May 2006 10:21:12 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E2161430058 for ; Thu, 25 May 2006 10:20:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id AC7BD398023 for ; Thu, 25 May 2006 10:20:46 -0700 (PDT) Received: from mgw-ext11.nokia.com (mgw-ext11.nokia.com [131.228.20.170]) by zoidberg.tigertech.net (Postfix) with ESMTP id A73A7398014 for ; Thu, 25 May 2006 10:20:42 -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 k4PHKYYu026584; Thu, 25 May 2006 20:20:36 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 May 2006 20:20:32 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 May 2006 12:20:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 25 May 2006 10:20:27 -0700 Message-ID: <893AE265F4ADF94AB7FB26D31A788E41021EB1C4@mvebe101.NOE.Nokia.com> In-Reply-To: <059b01c68012$e6126650$0202a8c0@corp.devicescape.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Terminology section Thread-Index: AcaAEc91om0u89XcTyWDXJpZClvmlgAAJaSQAALxHqA= From: To: , , X-OriginalArrivalTime: 25 May 2006 17:20:30.0531 (UTC) FILETIME=[85E44930:01C6801F] 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] 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.2 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Hi Margaret, We worked on publishing the Objectives draft in conjunction with the ADs and this was approved by the IESG. Obviously, the remaining work in CAPWAP is dependent on the Objectives we have already published. This was the purpose of the Objectives draft. What would you recommend we do in this situation? Re-write the objectives within the specification and then refer to the Objectives draft for further information? We are just trying to write a readable protocol document here. There should be a reasonable way to do this in a manner that is appropriate in the IETF. Best Regards, Dorothy -----Original Message----- From: ext Margaret Wasserman [mailto:mrw@lilacglade.org] Sent: Thursday, May 25, 2006 8:50 AM To: 'David T. Perkins'; 'Saravanan Govindan' Cc: 'capwap' Subject: Re: [Capwap] Terminology section Hi All, > I believe that having RFC4118 and the Objectives I-D as normative > references is inappropriate. > > For me, specifications that are complete, consistent, and have minimal > dependencies on other documents are easier to understand, write code, > and use for deployment. I agree with David's points, but this is not just a matter or taste and/or a matter to be decided by rough consensus of the WG. For CAPWAP to be published as a Standards-Track specification, it cannot have normative dependencies on Informational documents. Referencing Informational RFCs from Standards-Track RFCs is called a "down reference" and it is only allowed in the IETF under certain specific conditions, none of which would seem to apply here. 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 Thu May 25 13:33:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjJiO-0007NY-7K for capwap-archive@lists.ietf.org; Thu, 25 May 2006 13:33:40 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjJiN-0005Sw-As for capwap-archive@lists.ietf.org; Thu, 25 May 2006 13:33:40 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BEA324300B7 for ; Thu, 25 May 2006 10:33:38 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E48BF430058 for ; Thu, 25 May 2006 10:33:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1048643118A for ; Thu, 25 May 2006 10:33:00 -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 4DB4A431198 for ; Thu, 25 May 2006 10:32:55 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id s19so762323wxc for ; Thu, 25 May 2006 10:32:54 -0700 (PDT) Received: by 10.70.48.11 with SMTP id v11mr456684wxv; Thu, 25 May 2006 10:32:53 -0700 (PDT) Received: by 10.70.133.19 with HTTP; Thu, 25 May 2006 10:32:53 -0700 (PDT) Message-ID: <5bfe7a820605251032v1864c3b9i47b747b9412fa40@mail.gmail.com> Date: Thu, 25 May 2006 10:32:53 -0700 From: "Dorothy Stanley" To: "Bob O'Hara (boohara)" In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC018C0188@xmb-sjc-237.amer.cisco.com> MIME-Version: 1.0 References: <17B8C6DE4E228348B4939BDA6B05A9DC018C0188@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.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 Subject: Re: [Capwap] New issues: readability/ease of use/lack of 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="===============1593790710==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.7 (/) X-Scan-Signature: e95407604bef3289cd27cb4f3b3a35b4 --===============1593790710== Content-Type: multipart/alternative; boundary="----=_Part_208050_26872908.1148578373706" ------=_Part_208050_26872908.1148578373706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Bob, Glad that you found the -01 draft a significant improvement. Proposed resolutions to Issue 124 are inline below. Thanks, Dorothy On 5/23/06, Bob O'Hara (boohara) wrote: > > The -01 draft is a significant improvement over the -00 draft. However, > I find it very difficult to easily find some information in the > document. Following are some editorial and technical comments. > > 1. Please include a table of message element type values for the base > CAPWAP message elements in section 4.4. Proposed Resolution: Insert a tablet at the end of Section 4.4, just prior to 4.4.1 The following CAPWAP protocol message elements are defined: [Include the list - the 01 elements, plus changes due to issue resolution, with type values] 2. Please include a table of message element type values for the 802.11 > binding-specific elements in section 11.10. Proposed resolution: Insert a table in Section 10.10, just prior to 11.10.1 The follwoing IEEE 802.11 specific message elements are defined: [Include the list - the -01 values, plus any changes per issue resolution, with type values] 3. Please describe how the binding-specific message element type values > are derived. It appears that the 802.11 type values begin arbitrarily > at 1024. Are the values for this field to be IANA controlled, or are > they able to be identified deterministically? The resolution of Issue 91 (Duplicate message element values) renumbered the CAPWAP message elements to begin with 1, and The IEEE 802.11 message element values to begin with 1024. The next wireless type would begin at 2048. The definition of values is to be done in the CAPWAP document(s). Proposed resolution: At the end of section 4.4, prior to the table being added by comment #1 above, change from Where Type (16 bit) identifies the character of the information carried in the Value field and Length (16 bits) indicates the number of bytes in the Value field. to Where Type (16 bit) identifies the character of the information carried in the Value field and Length (16 bits) indicates the number of bytes in the Value field. Type field values are allocated as follows: Usage Type Values CAPWAP Protocol Message Elements 1-1023 IEEE 802.11 Message Elements 1024-2047 Reserved for Future Use 2048 = - 65024 and delete text describing IANA allocation of message element values. 4. Please identify in which messages the nine additional message > elements in section 11.10 may appear, since they are not listed in the > table in section 11.9.3. The table in 11.9.3 lists the message elements that may be included in the various configuration related messages. Section 11.7.1 includes the message elements which can be included in the IEEE 802.11 WLAN Config Request message: IEEE 802.11 Add WLAN IEEE 802.11 Delete WLAN IEEE 802.11 Update WLAN IEEE 802.11 Information Element Section 11.7.2 lists the message elements that may be included in the IEEE 802.11 WLAN Config Response: IEEE 802.11 Assigned WTP BSSID Section 11.9.1 lists the message elements that may be included in the Mobile Config Request message: IEEE 802.11 Mobile IEEE 802.11 Mobile Session Key Station QOS Profile Section 11.9.2 lists the message elements that may be included in the WTP Event Request message: IEEE 802.11 MIC Countermeasures IEEE 802.11 Statistics IEEE 802.11 Radio Fail Alarm Indication Between all of these sections, each message element is included in at least one message. There is one message element listed in the section 11.9.3 table that is not defined: IEEE 802.11 WTP Mode and Type. This seems to be CAPWAP level information rather than 802.11 specific. Proposed change: Delete the IEEE 802.11 WTP Mode and Type row in the 11.9.3 table 5. In 11.7, the Message Type Value for the two 802.11-specific messages > is given. However, I don't see anywhere that describes how these values > were determined. Please add a description of the derivation of the > message type values. Please see the description in section 4.3.1.1 (extracted below). Is this sufficient, or is additional description required? 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 =3D IANA Enterprise Number * 256 + Message Type Value 6. 11.8 says there are no 802.11-specific data message bindings. I > think that the data packet containing an 802.11-encapsulated frame > should go here, along with its complete description. There is some descriptive text in Section 11.4, Transport Specific Bindings, which describes the patload encapsulation. Is this text sufficient? If not, what addtional information is needed? Perhaps a figure should be added to this section? -Bob > > Bob O'Hara > Cisco Systems - WNBU > > Phone: +1 408 853 5513 > Mobile: +1 408 218 4025 > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_208050_26872908.1148578373706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Bob,

Glad that you found the -01 draft a significant improvement. Proposed
resolutions to Issue 124 are inline below.

Thanks,

Dorothy

On 5/23/06, Bob O'Hara (boohara) <boohara@cisco.com> wrote:
The -01 draft is a significant improvement over the -00 draft.  H= owever,
I find it very difficult to easily find some information in the<= br>document.  Following are some editorial and technical comments= .

1. Please include a table of message element type values for the b= ase
CAPWAP message elements in section 4.4.

Proposed Resolution: Insert a tablet at the end of Section 4.4, just prior = to
4.4.1

The following CAPWAP protocol message elements are defined:
[Include the list - the 01 elements, plus changes due to issue resolution, = with type values]


2. Plea= se include a table of message element type values for the 802.11
binding= -specific elements in section=20 11.10.

Proposed resolution:  Insert a table in Section 10.10, just
prior to 11.10.1

The follwoing IEEE 802.11 specific message elements are defined:
[Include the list - the -01 values, plus any changes per issue resolution, = with type values]

3. Plea= se describe how the binding-specific message element type values
are der= ived.  It appears that the=20 802.11 type values begin arbitrarily
at 1024.  Are the values = for this field to be IANA controlled, or are
they able to be identified = deterministically?

The resolution of Issue 91 (Duplicate message element values)
renumbered the CAPWAP message elements to begin with 1, and
The IEEE 802.11 message element values to begin with 1024.
The next wireless type would begin at 2048. The
definition of values is to be done in the CAPWAP document(s).

Proposed resolution: At the end of section 4.4, prior
to the table being added by comment #1 above, change from

   Where Type (16 bit) identifies the character of the informatio= n
   carried in the Value field and Length (16 bits) indicates the = number
   of bytes in the Value field.

to

   Where Type (16 bit) identifies the character of the informatio= n
   carried in the Value field and Length (16 bits) indicates the = number
   of bytes in the Value field. Type field values are allocated a= s follows:


            &nb= sp;            =       Usage             &nb= sp;                         Type Values

         CAPWAP Protocol Message Elements           &= nbsp;    1-1023
         IEEE 802.11 Message Elements           &= nbsp;           &nbs= p; 1024-2047
         Reserved for Future Use            =             &nb= sp;             2048 - 65024

and delete text describing IANA allocation of message element values.

4. Please ide= ntify in which messages the nine additional message
elements in section= =20 11.10 may appear, since they are not listed in the
table in section 11.9= .3.

The table in 11.9.3 lists the message elements that may be included in
the various configuration related messages.

Section 11.7.1 includes the message elements which can be included in the IEEE 802.11 WLAN Config Request message:
IEEE 802.11 Add WLAN
IEEE 802.11 Delete WLAN
IEEE 802.11 Update WLAN
IEEE 802.11 Information Element

Section 11.7.2 lists the message elements that may be included in
the IEEE 802.11 WLAN Config Response:
IEEE 802.11 Assigned WTP BSSID

Section 11.9.1 lists the message elements that may be included in the
Mobile Config Request message:
IEEE 802.11 Mobile
IEEE 802.11 Mobile Session Key
Station QOS Profile

Section 11.9.2 lists the message elements that may be included
in the WTP Event Request message:
IEEE 802.11 MIC Countermeasures
IEEE 802.11 Statistics
IEEE 802.11 Radio Fail Alarm Indication

Between all of these sections, each message element is included in
at least one message. There is  one message element listed in the
section 11.9.3 table that is not defined:
IEEE 802.11 WTP Mode and Type. This seems to be CAPWAP
level information rather than 802.11 specific.

Proposed change:
Delete the IEEE 802.11 WTP Mode and Type row in the 11.9.3 table

5. In 1= 1.7, the Message Type Value for the two 802.11-specific messages
is give= n.  However, I don't see anywhere that describes how these values
were determined.  Please add a description of the derivation = of the
message type values.

6. 11.8= says there are no 802.11-specific data message bindings.  I
t= hink that the data packet containing an=20 802.11-encapsulated frame
should go here, along with its complete descri= ption.

There is some descriptive text in Section 11.4, Transport
Specific Bindings, which describes the patload encapsulation.

Is this text sufficient? If not, what addtional information is needed?
Perhaps a figure should be added to this section?

-Bob
Bob O'Hara
Cisco Systems - WNBU

Phone:  +1 408 85= 3 5513
Mobile: +1 408 218 4025

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

Archives: http://lists.frascone.co= m/pipermail/capwap

------=_Part_208050_26872908.1148578373706-- --===============1593790710== 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 --===============1593790710==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu May 25 13:39:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjJnj-0002GX-32 for capwap-archive@lists.ietf.org; Thu, 25 May 2006 13:39:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjJnh-00063X-Il for capwap-archive@lists.ietf.org; Thu, 25 May 2006 13:39:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1E5A8430112 for ; Thu, 25 May 2006 10:39:08 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id F1499430058 for ; Thu, 25 May 2006 10:38:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 71B4E4311A9 for ; Thu, 25 May 2006 10:38:40 -0700 (PDT) Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.200.84]) by hermes.tigertech.net (Postfix) with ESMTP id 47E83431186 for ; Thu, 25 May 2006 10:38:36 -0700 (PDT) Received: from ceili (c-66-30-121-250.hsd1.ma.comcast.net[66.30.121.250]) by comcast.net (sccrmhc14) with SMTP id <2006052517383401400knijue>; Thu, 25 May 2006 17:38:35 +0000 From: "Margaret Wasserman" To: , , Date: Thu, 25 May 2006 13:38:32 -0400 Message-ID: <05f501c68022$0b7e5570$0202a8c0@corp.devicescape.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <893AE265F4ADF94AB7FB26D31A788E41021EB1C4@mvebe101.NOE.Nokia.com> Thread-Index: AcaAEc91om0u89XcTyWDXJpZClvmlgAAJaSQAALxHqAAAIc+UA== 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] 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: a87a9cdae4ac5d3fbeee75cd0026d632 Hi Dorothy, Informative references are okay, the requirement is that you avoid _Normative_ references to an Informational document from a Standards-Track document. So, you shouldn't need to restate all of the objectives in the protocol specification. If you want to give readers a pointer to the objectives document and/or indicate how a particular feature relates to the objectives, you can simply include an Informative reference to the objectives document. Informative references are appropriate when the reader may want to look at another document for background information or wider understanding. However, you need to avoid Normative references to the objectives document. In other words, it should be possible to understand and implement the CAPWAP specification without reading the objectives document. It isn't possible to read and understand a document without knowing how the terminology is defined, a reference to the objectives document for the terminology definitions would be a Normative reference. To avoid a Normative reference to the objectives document, you would simply include the same terminology definitions in the protocol specification. You can even mention that they originally came from the objective document, if you like, which would then be an Informative reference. Does that make sense? Margaret > -----Original Message----- > From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] > Sent: Thursday, May 25, 2006 1:20 PM > To: mrw@lilacglade.org; dperkins@dsperkins.com; > Saravanan.Govindan@sg.panasonic.com > Cc: capwap@frascone.com; david.kessens@nokia.com; > dromasca@avaya.com; mmani@avaya.com > Subject: RE: [Capwap] Terminology section > > Hi Margaret, > > We worked on publishing the Objectives draft in conjunction > with the ADs and this was approved by the IESG. > Obviously, the remaining work in CAPWAP is dependent on the > Objectives we have already published. This was the purpose > of the Objectives draft. > > What would you recommend we do in this situation? Re-write > the objectives within the specification and then refer to the > Objectives draft for further information? > > We are just trying to write a readable protocol document > here. There should be a reasonable way to do this in a > manner that is appropriate in the IETF. > > Best Regards, > Dorothy > > > -----Original Message----- > From: ext Margaret Wasserman [mailto:mrw@lilacglade.org] > Sent: Thursday, May 25, 2006 8:50 AM > To: 'David T. Perkins'; 'Saravanan Govindan' > Cc: 'capwap' > Subject: Re: [Capwap] Terminology section > > > Hi All, > > > I believe that having RFC4118 and the Objectives I-D as normative > > references is inappropriate. > > > > For me, specifications that are complete, consistent, and > have minimal > > > dependencies on other documents are easier to understand, > write code, > > and use for deployment. > > I agree with David's points, but this is not just a matter or > taste and/or a matter to be decided by rough consensus of the WG. > > For CAPWAP to be published as a Standards-Track > specification, it cannot have normative dependencies on > Informational documents. Referencing Informational RFCs from > Standards-Track RFCs is called a "down reference" > and it is only allowed in the IETF under certain specific > conditions, none of which would seem to apply here. > > 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 Thu May 25 14:13:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjKKk-0002BZ-2W for capwap-archive@lists.ietf.org; Thu, 25 May 2006 14:13:18 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjKKe-0008W9-4x for capwap-archive@lists.ietf.org; Thu, 25 May 2006 14:13:18 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2FC9643010A for ; Thu, 25 May 2006 11:13:07 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E2EAF430097 for ; Thu, 25 May 2006 11:12:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D140C398052 for ; Thu, 25 May 2006 11:12:27 -0700 (PDT) Received: from mgw-ext12.nokia.com (mgw-ext12.nokia.com [131.228.20.171]) by zoidberg.tigertech.net (Postfix) with ESMTP id E84AD398014 for ; Thu, 25 May 2006 11:12:23 -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 k4PICI8w009010; Thu, 25 May 2006 21:12:20 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 May 2006 21:12:14 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 May 2006 13:12:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 25 May 2006 11:12:08 -0700 Message-ID: <893AE265F4ADF94AB7FB26D31A788E41021EB226@mvebe101.NOE.Nokia.com> In-Reply-To: <05f501c68022$0b7e5570$0202a8c0@corp.devicescape.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Terminology section Thread-Index: AcaAEc91om0u89XcTyWDXJpZClvmlgAAJaSQAALxHqAAAIc+UAABgD4Q From: To: X-OriginalArrivalTime: 25 May 2006 18:12:11.0424 (UTC) FILETIME=[BE2B0200:01C68026] 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] 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.2 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Hi Margaret, Of course. What specifically from the Objective document should we cut and paste into the Specification so that it is clear and easy to understand for you? -Dorothy -----Original Message----- From: ext Margaret Wasserman [mailto:mrw@lilacglade.org] Sent: Thursday, May 25, 2006 10:39 AM To: Gellert Dorothy (Nokia-ES/MtView); dperkins@dsperkins.com; Saravanan.Govindan@sg.panasonic.com Cc: capwap@frascone.com; Kessens David (Nokia-NET/MtView); dromasca@avaya.com; mmani@avaya.com Subject: RE: [Capwap] Terminology section Hi Dorothy, Informative references are okay, the requirement is that you avoid _Normative_ references to an Informational document from a Standards-Track document. So, you shouldn't need to restate all of the objectives in the protocol specification. If you want to give readers a pointer to the objectives document and/or indicate how a particular feature relates to the objectives, you can simply include an Informative reference to the objectives document. Informative references are appropriate when the reader may want to look at another document for background information or wider understanding. However, you need to avoid Normative references to the objectives document. In other words, it should be possible to understand and implement the CAPWAP specification without reading the objectives document. It isn't possible to read and understand a document without knowing how the terminology is defined, a reference to the objectives document for the terminology definitions would be a Normative reference. To avoid a Normative reference to the objectives document, you would simply include the same terminology definitions in the protocol specification. You can even mention that they originally came from the objective document, if you like, which would then be an Informative reference. Does that make sense? Margaret > -----Original Message----- > From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com] > Sent: Thursday, May 25, 2006 1:20 PM > To: mrw@lilacglade.org; dperkins@dsperkins.com; > Saravanan.Govindan@sg.panasonic.com > Cc: capwap@frascone.com; david.kessens@nokia.com; dromasca@avaya.com; > mmani@avaya.com > Subject: RE: [Capwap] Terminology section > > Hi Margaret, > > We worked on publishing the Objectives draft in conjunction with the > ADs and this was approved by the IESG. > Obviously, the remaining work in CAPWAP is dependent on the Objectives > we have already published. This was the purpose of the Objectives > draft. > > What would you recommend we do in this situation? Re-write the > objectives within the specification and then refer to the Objectives > draft for further information? > > We are just trying to write a readable protocol document here. There > should be a reasonable way to do this in a manner that is appropriate > in the IETF. > > Best Regards, > Dorothy > > > -----Original Message----- > From: ext Margaret Wasserman [mailto:mrw@lilacglade.org] > Sent: Thursday, May 25, 2006 8:50 AM > To: 'David T. Perkins'; 'Saravanan Govindan' > Cc: 'capwap' > Subject: Re: [Capwap] Terminology section > > > Hi All, > > > I believe that having RFC4118 and the Objectives I-D as normative > > references is inappropriate. > > > > For me, specifications that are complete, consistent, and > have minimal > > > dependencies on other documents are easier to understand, > write code, > > and use for deployment. > > I agree with David's points, but this is not just a matter or taste > and/or a matter to be decided by rough consensus of the WG. > > For CAPWAP to be published as a Standards-Track specification, it > cannot have normative dependencies on Informational documents. > Referencing Informational RFCs from Standards-Track RFCs is called a > "down reference" > and it is only allowed in the IETF under certain specific conditions, > none of which would seem to apply here. > > 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 Thu May 25 15:09:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjLCy-0006eh-5J for capwap-archive@lists.ietf.org; Thu, 25 May 2006 15:09:20 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjLCw-0005Sy-ER for capwap-archive@lists.ietf.org; Thu, 25 May 2006 15:09:20 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2071F4300CC for ; Thu, 25 May 2006 12:09:15 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7B141430054 for ; Thu, 25 May 2006 12:08:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2C9BB4312E3 for ; Thu, 25 May 2006 12:08:46 -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 19F044312DF for ; Thu, 25 May 2006 12:08:43 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id s19so777535wxc for ; Thu, 25 May 2006 12:08:43 -0700 (PDT) Received: by 10.70.95.12 with SMTP id s12mr581380wxb; Thu, 25 May 2006 12:08:43 -0700 (PDT) Received: by 10.70.133.19 with HTTP; Thu, 25 May 2006 12:08:43 -0700 (PDT) Message-ID: <5bfe7a820605251208n25220c39h6a6378bd9100ea22@mail.gmail.com> Date: Thu, 25 May 2006 12:08: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=0.7 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_00_10, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Issue 86 Comments on DTLS for CAPWAP Protocol: Proposed 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="===============0879243594==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.7 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab --===============0879243594== Content-Type: multipart/alternative; boundary="----=_Part_209350_1321871.1148584123132" ------=_Part_209350_1321871.1148584123132 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, Issue 86, copied below, comments on the -00 draft state machine operation. The updates made to the state machine in -01 appear to address all of the comments. Proposed resolution: Close issue 86, noting that the -01 state machine updates address these comments. Thanks, Dorothy * Discovery to DTLS-Init state description: - The AC state reflects that it is a meta state, which is not quite right= . Since there is a DTLS-complete, it is appropriate for the AC to enter this state as it is initiating a potential connection with the WTP. * The descriptions for the WTP actions for the DTLS-Init to Idle and DTLS-I= nit to Discovery seem too similar. What is the difference between an unsuccess= ful DTLS session establishment and a failed DTLS handshake? A similar conflict arises in the AC's descriptions. * The DTLS-Init to DTLS-Complete appears that it implies a successful DTLS session establishment and should be explicitly stated so....though I am not sure why there needs to be such a distinction unless a true capture of the DTLS state machine is warranted and these 2 states do not fully cover. - The explanation for WTP and AC needs to clarify how each party knows th= e DTLS session is live and is authorized to begin protected traffic. * Under which conditions does the AC goes from the DTLS-Init to Idle or Discovery? There's an inconsistancy between the figure and the text. That is, there are several events within the DTLS conversation at which the= AC may choose to fail and tear down the DTLS conversation. My suggestion is t= hat when these fail, they should go back to the Idle state. * The DTLS-Reset state doesn't seem to make sense or is inconsistant with t= he general LWAPP framework. What does it mean to be in a DTLS-Reset state? D= oes it mean a full DTLS session must be established? If so, then it is an effective Reset from the overall state machine standpoint.... - why does a new configuration warrant a DTLS-Reset? - why does an image update warrant a DTLS-Reset? - it seems that perhaps for both of the above, the WTP should go back to Idle or DTLS-Init again. - a Run to DTLS-Reset should force a full CAPWAP Reset, so why not merge = and retain the original Reset as is? * Why does a key refresh in the DTLS warrant a full state transition? What is implied by a DTLS-Rekey? ------=_Part_209350_1321871.1148584123132 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All,

Issue 86, copied below, comments on the -00 draft
state machine operation. The updates made to the state machine
in -01 appear to address all of the comments.

Proposed resolution: Close issue 86, noting that the -01 state machine
updates address these comments.

Thanks,

Dorothy

* Discovery to DTLS-Init state description:
  - The AC state reflec=
ts that it is a meta state, which is not quite right.  
Since there is a=
 DTLS-complete, it is appropriate for the AC to enter this 
state as it =
is initiating a potential connection with the WTP.


* The descriptions for the WTP actions for the DTLS-Init to Idle an=
d DTLS-Init 
to Discovery seem too similar.  What is the difference betw=
een an unsuccessful 
DTLS session establishment and a failed DTLS handsh=
ake?

A similar conflict arises in the AC's descriptions.

* The DTLS-I=
nit to DTLS-Complete appears that it implies a successful DTLS 
session =
establishment and should be explicitly stated so....though I am not 

sure why there needs to be such a distinction unless a true capture of the =

DTLS state machine is warranted and these 2 states do not fully cover.<=
br>  - The explanation for WTP and AC needs to clarify how each party knows=
 the=20

DTLS session is live and is authorized to begin protected traffic.  
* Under which conditions does the AC goes from the DTLS-Init to Idle o=
r 
Discovery? There's an inconsistancy between the figure and the text.

That is, there are several events within the DTLS conversation at which=
 the AC 
may choose to fail and tear down the DTLS conversation.  My sug=
gestion is that 
when these fail, they should go back to the Idle state.


* The DTLS-Reset state doesn't seem to make sense or is inconsistan=
t with the 
general LWAPP framework.  What does it mean to be in a DTLS-=
Reset state?  Does 
it mean a full DTLS session must be established?

If so, then it is an effective Reset from the overall state machine standpoint....
  - why does a new configuration warrant a DTLS-Reset?  - why does an image update warrant a DTLS-Reset?
  - it seems that p=
erhaps for both of the above, the WTP should go back to=20

Idle or DTLS-Init again.
  - a Run to DTLS-Reset should force a full=
 CAPWAP Reset, so why not merge and 
retain the original Reset as is?
* Why does a key refresh in the DTLS warrant a full state transition?

What is implied by a DTLS-Rekey?

------=_Part_209350_1321871.1148584123132-- --===============0879243594== 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 --===============0879243594==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu May 25 15:28:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjLVs-0002LG-OA for capwap-archive@lists.ietf.org; Thu, 25 May 2006 15:28:52 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjLVq-0006bN-Pn for capwap-archive@lists.ietf.org; Thu, 25 May 2006 15:28:52 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4E287430082 for ; Thu, 25 May 2006 12:28:50 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 783C1430054 for ; Thu, 25 May 2006 12:28:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 52AEB431310 for ; Thu, 25 May 2006 12:28:16 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.192]) by hermes.tigertech.net (Postfix) with ESMTP id 4508D431301 for ; Thu, 25 May 2006 12:28:14 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id s19so780261wxc for ; Thu, 25 May 2006 12:28:13 -0700 (PDT) Received: by 10.70.68.20 with SMTP id q20mr610587wxa; Thu, 25 May 2006 12:28:13 -0700 (PDT) Received: by 10.70.133.19 with HTTP; Thu, 25 May 2006 12:28:13 -0700 (PDT) Message-ID: <5bfe7a820605251228u6e10f678ma505aa9c083aee06@mail.gmail.com> Date: Thu, 25 May 2006 12:28:13 -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=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: Subject: [Capwap] Proposed Rsolution Issue 81: Minor edits and questions CAPWAP 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="===============1665403273==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 --===============1665403273== Content-Type: multipart/alternative; boundary="----=_Part_209478_16795138.1148585293568" ------=_Part_209478_16795138.1148585293568 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 th= e 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_209478_16795138.1148585293568 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 b=
efore sending further 
Discovery Request messages.

change to


If a Discovery Response .... equal to SilentInterval before returni=
ng 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 tw=
ice -- 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 t= he
   Sulking state and MUST wait for an interval equal to SilentInt= erval
   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 WT= P to
   communicate the encapsulation type, or tunneling modes of oper= ation
   which it supports to the AC.  A WTP that advertises suppo= rt for all
   types allows the AC to select which type will be used, based o= n 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 e= ncapsulation
      modes supported by the WTP.  The follow= ing values are supported:

      1 - Local Bridging:  Local Bridging all= ows the WTP to perform the
         bridging function.  T= his value MUST NOT be used when the WTP
         MAC Type is set to Split-M= AC.

      2 - 802.3 Bridging:  802.3 Bridging req= uires the WTP and AC to
         encapsulate all user paylo= ad as native IEEE 802.3 frames (see
         Section 4.2).  This v= alue MUST NOT be used when the WTP MAC
         Type is set to Split-MAC.<= br>
      4 - Native Bridging:  Native Bridging r= equires the WTP and AC to
         encapsulate all user paylo= ads as native wireless frames, as
         defined by the wireless bi= nding (see Section 4.2).

      7 - All:  The WTP is capable of support= ing all frame encapsulation
         types.

To:

4.4.36.  WTP Frame Encapsulation Type

   The WTP Frame EncapsultationType message element allows the WT= P to
   communicate the encapsulation type, or tunneling modes of oper= ation
   which it supports to the AC.  A WTP that advertises suppo= rt for all
   types allows the AC to select which type will be used, based o= n 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 e= ncapsulation
      modes supported by the WTP.  The follow= ing values are supported:

      1 - 802.3 Encapsulation:  802.3 Bridgin= g requires the WTP and AC to
         encapsulate all user paylo= ad as native IEEE 802.3 frames (see
         Section 4.2).  This v= alue MUST NOT be used when the WTP MAC
         Type is set to Split-MAC.<= br>
      2 - Native Encapsulation:  Native Bridg= ing requires the WTP and AC to
         encapsulate all user paylo= ads as native wireless frames, as
         defined by the wireless bi= nding (see Section 4.2).

      3 - All:  The WTP is capable of support= ing 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_209478_16795138.1148585293568-- --===============1665403273== 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 --===============1665403273==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu May 25 18:06:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjNyc-0006F5-VQ for capwap-archive@lists.ietf.org; Thu, 25 May 2006 18:06:42 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjNyb-0006Y3-Ez for capwap-archive@lists.ietf.org; Thu, 25 May 2006 18:06:42 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3DE13430082 for ; Thu, 25 May 2006 15:06:32 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id EF247430054 for ; Thu, 25 May 2006 15:06:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 871381448008 for ; Thu, 25 May 2006 15:06:05 -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 BF67F1448003 for ; Thu, 25 May 2006 15:06:03 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id s19so802774wxc for ; Thu, 25 May 2006 15:06:02 -0700 (PDT) Received: by 10.70.68.20 with SMTP id q20mr835064wxa; Thu, 25 May 2006 15:06:02 -0700 (PDT) Received: by 10.70.133.19 with HTTP; Thu, 25 May 2006 15:06:02 -0700 (PDT) Message-ID: <5bfe7a820605251506j4abc0468u8680ff56558549eb@mail.gmail.com> Date: Thu, 25 May 2006 15:06:02 -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=0.7 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_40_50, HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Issue 63 - Are all fields in the IEEE 802.11 Add Mobile required 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="===============1888048922==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.7 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 --===============1888048922== Content-Type: multipart/alternative; boundary="----=_Part_211610_8012022.1148594762722" ------=_Part_211610_8012022.1148594762722 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 11.7.1.1 of draft -00 is now section 11.10.11 in draft -01, and includes the following fields: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Association ID | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Capabilities | WLAN ID |Supported Rates +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Radio ID: An 8-bit value representing the radio Association ID: A 16-bit value specifying the IEEE 802.11 Association Identifier Flags: The Flags field MUST be set to zero Capabilities: A 16-bit field containing the IEEE 802.11 capabilities to use with the mobile. WLAN ID: An 8-bit value specifying the WLAN Identifier Supported Rates: The variable length field containing the supported rates to be used with the mobile station. The commenter is asking if all of the fields are needed in the Local MAC case. Proposed resolution: Yes, all fields are required. Comments please. Thanks, Dorothy ------=_Part_211610_8012022.1148594762722 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 11.7.1.1 of draft -00 is now sectio= n 11.10.11 in draft -01, and includes the following
fields:
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
     |    Radio ID   |        Association ID         |     Flags     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
     |          Capabilities         |   WLAN ID     |Supported Rates
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+

   Radio ID:  An 8-bit value representing the radio

   Association ID:  A 16-bit value specifying the IEEE 802.1= 1
      Association Identifier

   Flags:  The Flags field MUST be set to zero

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

   WLAN ID:  An 8-bit value specifying the WLAN Identifier
   Supported Rates:  The variable length field containing th= e supported
      rates to be used with the mobile station.

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

Proposed resolution:  Yes, all fields are required.

Comments please.

Thanks,

Dorothy
------=_Part_211610_8012022.1148594762722-- --===============1888048922== 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 --===============1888048922==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu May 25 20:30:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjQDu-0003vd-LA for capwap-archive@lists.ietf.org; Thu, 25 May 2006 20:30:38 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjQDq-00014C-2H for capwap-archive@lists.ietf.org; Thu, 25 May 2006 20:30:38 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3FD8543006B for ; Thu, 25 May 2006 17:30:29 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 67C84430054 for ; Thu, 25 May 2006 17:29:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 50F161448009 for ; Thu, 25 May 2006 17:29:53 -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 695221448004 for ; Thu, 25 May 2006 17:29:49 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id i75so2547113pye for ; Thu, 25 May 2006 17:29:48 -0700 (PDT) Received: by 10.35.12.13 with SMTP id p13mr362522pyi; Thu, 25 May 2006 17:29:48 -0700 (PDT) Received: by 10.35.41.20 with HTTP; Thu, 25 May 2006 17:29:48 -0700 (PDT) Message-ID: <26140d940605251729x1afc9a58xdce212758e35307c@mail.gmail.com> Date: Thu, 25 May 2006 20:29:48 -0400 From: "Michael Montemurro" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201ECF0FC@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A201ECF0FC@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 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="===============2096382714==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 --===============2096382714== Content-Type: multipart/alternative; boundary="----=_Part_39866_14704397.1148603388524" ------=_Part_39866_14704397.1148603388524 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The only text that I could identify that was missing here was information o= n 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) 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_39866_14704397.1148603388524 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
The only text that I could identify that was missing here was informat= ion 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) <pcalho= un@cisco.com> wrote:
I have re-opened issue 43, but i= t 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 Syst= ems



> -----Original Message-----
> From: Saravanan = Govindan [mailto:Sar= avanan.Govindan@sg.panasonic.com ]
> Sent: Tuesday, May 23, 2006 12:24 AM
> To: capwap
&g= t; Subject: [Capwap] Clarification of Issue 43: IEEE 802.11i
> Consid= erations
>
> All,
>
> I believe this issue 43 - als= o 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.
>
> Sar= avanan
>
> ____________________________________________________= _____________
> To unsubscribe or modify your subscription options, please visit:<= br>> http:= //lists.frascone.com/mailman/listinfo/capwap
>
> Archives:= =20 http://lists.frascon= e.com/pipermail/capwap
>
_____________________________________= ____________________________
To unsubscribe or modify your subscription = options, please visit:
http://li= sts.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/piperma= il/capwap

------=_Part_39866_14704397.1148603388524-- --===============2096382714== 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 --===============2096382714==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri May 26 03:00:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjWJR-0003q4-Gv for capwap-archive@lists.ietf.org; Fri, 26 May 2006 03:00:45 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjWJP-00043o-VP for capwap-archive@lists.ietf.org; Fri, 26 May 2006 03:00:45 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BE0E84300B2 for ; Fri, 26 May 2006 00:00:36 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7E906430054 for ; Fri, 26 May 2006 00:00:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 51D15398017 for ; Fri, 26 May 2006 00:00:11 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 54F9E39804C for ; Fri, 26 May 2006 00:00:06 -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 k4Q7026H000162; Fri, 26 May 2006 16:00:02 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k4Q705i06940; Fri, 26 May 2006 16:00:05 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/phillies) with ESMTP id k4Q702F00921; Fri, 26 May 2006 16:00:03 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 26 May 2006 14:58:03 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDE6ADC6@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Terminology section Thread-Index: AcZ//7jvG+jENdjuQXO1qUvTaG7vYAAhrEew From: "Saravanan Govindan" To: "Scott G Kelly" 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: 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.1 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Hi Scott, There was a similar term, if not the same, in the CAPWAP Objectives, for which IESG reviewers requested clarification. I am trying to learn from experience and define the security terms in advance. Having said this, I agree that having too many definitions is not in readers' interests. I think we can make a decision on this after getting more input on (any) other definitions. Saravanan -----Original Message----- From: Scott G Kelly [mailto:scott@hyperthought.com] Sent: Thursday, May 25, 2006 9:35 PM To: Saravanan Govindan Cc: Pat Calhoun (pacalhou); capwap Subject: Re: [Capwap] Terminology section Hi Saravanan, I'm not sure I agree that we need to copy the terms from the security considerations, because their meaning seems quite clear right where they are used (and they are only used in that one instance). Also, your definitions lack required precision. Protected data (in the context referred to in 13.1, i.e. wrapped in DTLS), in addition to being encrypted, provides for data integrity assurance and data origin authentication. Also, unprotected data may be exchanged between unauthenticated as well as authenticated peers (e.g. a discovery message is "unprotected data"). I don't think we should constrain the definitions of these terms in the suggested ways, and I think that if there is going to be a terminology section, there should be some clear admission criteria - otherwise, we stand to gain a fat dictionary at the front of the document which isn't meeting any clear need. Scott 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 Fri May 26 03:22:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjWeK-0005UH-7K for capwap-archive@lists.ietf.org; Fri, 26 May 2006 03:22:20 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjWeI-0005Xd-7z for capwap-archive@lists.ietf.org; Fri, 26 May 2006 03:22:20 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BAF864300CC for ; Fri, 26 May 2006 00:22:17 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E1107430054 for ; Fri, 26 May 2006 00:21:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C6628398014 for ; Fri, 26 May 2006 00:21:38 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id AC74539802D for ; Fri, 26 May 2006 00:21:35 -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 k4Q7LVgo028823; Fri, 26 May 2006 16:21:31 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k4Q7LXa16473; Fri, 26 May 2006 16:21:33 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with SMTP id k4Q7LYa11282; Fri, 26 May 2006 16:21:34 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 26 May 2006 15:19:24 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDE6ADD1@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Thread-Index: AcaAWzqj+YR3TBhwQ4qkf8FDvfX4hAAN/BqA From: "Saravanan Govindan" To: "Michael Montemurro" , "Pat Calhoun (pacalhou)" 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: 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="===============0093127092==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: ff67cea9f7df2d77f61a364cea0926e8 This is a multi-part message in MIME format. --===============0093127092== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68094.B7489C5C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68094.B7489C5C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 This is a copy-and-paste from previous email. =20 =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 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 My recommendation: =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 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, Saravanan =20 =20 =20 =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 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 =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, Mike =20 On 5/23/06, Pat Calhoun (pacalhou) 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 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=20 > still open. My suggestion is to update the 802.11 binding > section to reflect steps local-MAC and split-MAC cases. > > Saravanan > > _________________________________________________________________=20 > 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:=20 http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap=20 =20 ------_=_NextPart_001_01C68094.B7489C5C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
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.f= rascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone= .com/pipermail/capwap
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.f= rascone.com/mailman/listinfo/capwap

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

 

------_=_NextPart_001_01C68094.B7489C5C-- --===============0093127092== 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 --===============0093127092==-- From dioy@crvelect.com Fri May 26 08:29:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjbRX-0003hz-U0 for capwap-archive@ietf.org; Fri, 26 May 2006 08:29:27 -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 1Fjb8L-0007uh-J8 for capwap-archive@ietf.org; Fri, 26 May 2006 08:09:37 -0400 Received: from [86.108.99.178] (helo=crvelect.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FjaxK-0006TT-FC for capwap-archive@ietf.org; Fri, 26 May 2006 07:58:19 -0400 Message-ID: <000001c680bb$ae14db80$a8d4a8c0@xpx95> Reply-To: "Diodore Gillespie" From: "Diodore Gillespie" To: capwap-archive@ietf.org Subject: cide 8907 Date: Fri, 26 May 2006 04:58:19 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68081.01B60380" 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.1 (++++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68081.01B60380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 A m B / E N S O m & C i A L / S V A L / u M P R O z & C L e V / T R A X & n a x A m o x / c i I l / n V / a G R A T r & m a d o I M e R / D / A =20 http://www.tranuillote.com =20 Long days after they had climbed out of the valley and left the Last=20 Homely House miles behind, they were still going up and up and up. It=20 was a hard path and a dangerous path, a crooked way and a lonely and a=20 long. Now they could look back over the lands they had left, laid out=20 behind them far below. Far, far away in the West, where things were blue and faint, Bilbo knew there lay his own country of safe and comfortable=20 ------=_NextPart_000_0001_01C68081.01B60380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
A m B / E N
S O m &
C i A L / S
V A L / u M
P R O z & C
L e V / T R A
X & n a x
A m o x / c i I l / n
V / a G R A
T r & m a d o I
M e R / D / A
 





Long days after they had climbed out = of the valley and left the Last
Homely House miles behind, they were = still going up and up and up. It
was a hard path and a dangerous = path, a crooked way and a lonely and a
long. Now they could look = back over the lands they had left, laid out
behind them far below. = Far, far away in the West, where things were blue
and faint, Bilbo = knew there lay his own country of safe and comfortable =
------=_NextPart_000_0001_01C68081.01B60380-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri May 26 09:31:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjcPd-00022U-UR for capwap-archive@lists.ietf.org; Fri, 26 May 2006 09:31:33 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjcPc-0000E6-EL for capwap-archive@lists.ietf.org; Fri, 26 May 2006 09:31:33 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4BD9B4300CB for ; Fri, 26 May 2006 06:31:23 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 10203430064 for ; Fri, 26 May 2006 06:30:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EE50143144D for ; Fri, 26 May 2006 06:30:52 -0700 (PDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.192]) by hermes.tigertech.net (Postfix) with ESMTP id 6D6441448015 for ; Fri, 26 May 2006 06:30:49 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id s19so49336wxc for ; Fri, 26 May 2006 06:30:48 -0700 (PDT) Received: by 10.70.9.16 with SMTP id 16mr743709wxi; Fri, 26 May 2006 06:30:48 -0700 (PDT) Received: by 10.70.133.19 with HTTP; Fri, 26 May 2006 06:30:48 -0700 (PDT) Message-ID: <5bfe7a820605260630h31f797e7ucde881889b51400b@mail.gmail.com> Date: Fri, 26 May 2006 06:30:48 -0700 From: "Dorothy Stanley" To: "Saravanan Govindan" In-Reply-To: <5F09D220B62F79418461A978CA0921BDE6AAED@pslexc01.psl.local> MIME-Version: 1.0 References: <5F09D220B62F79418461A978CA0921BDE6AAED@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_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: 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="===============1766043778==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --===============1766043778== Content-Type: multipart/alternative; boundary="----=_Part_218772_20708492.1148650248382" ------=_Part_218772_20708492.1148650248382 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Saravanan, Fine by me. Dorothy On 5/24/06, Saravanan Govindan wrote: > > 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 > ------=_Part_218772_20708492.1148650248382 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Saravanan,

Fine by me.

Dorothy

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

One o= f 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, br= idging is not
centralized.

I suggest an update to this goal;

"1. To centralize major functions of a wireless network, such asconfiguration, authentication, policy enforcement and in some cases,
b= ridging and forwarding. "

Comments?

Saravanan


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

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

------=_Part_218772_20708492.1148650248382-- --===============1766043778== 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 --===============1766043778==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri May 26 09:43:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjcb0-00015Y-Ob for capwap-archive@lists.ietf.org; Fri, 26 May 2006 09:43:18 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjcaz-0001Tu-9P for capwap-archive@lists.ietf.org; Fri, 26 May 2006 09:43:18 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D31154300F8 for ; Fri, 26 May 2006 06:43:16 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 342B443006B for ; Fri, 26 May 2006 06:42:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1BB69144800C for ; Fri, 26 May 2006 06:42:49 -0700 (PDT) Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [204.127.192.84]) by hermes.tigertech.net (Postfix) with ESMTP id 74652431481 for ; Fri, 26 May 2006 06:42:46 -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 <20060526134245m1400koj03e>; Fri, 26 May 2006 13:42:45 +0000 Message-ID: <447705D4.1080907@hyperthought.com> Date: Fri, 26 May 2006 06:42:44 -0700 From: Scott G Kelly User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dorothy Stanley References: <5F09D220B62F79418461A978CA0921BDE6AAED@pslexc01.psl.local> <5bfe7a820605260630h31f797e7ucde881889b51400b@mail.gmail.com> In-Reply-To: <5bfe7a820605260630h31f797e7ucde881889b51400b@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.0 tagged_above=-999.0 required=7.0 tests= 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: 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 I also agree. Dorothy Stanley wrote: > Saravanan, > > Fine by me. > > Dorothy > > On 5/24/06, *Saravanan Govindan* > wrote: > > 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 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From lawrieomat@hefren.com Fri May 26 10:53:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjdhL-00006Z-Bt for capwap-archive@ietf.org; Fri, 26 May 2006 10:53:55 -0400 Received: from [211.222.88.24] (helo=hefren.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FjdhI-0003B5-N0 for capwap-archive@ietf.org; Fri, 26 May 2006 10:53:55 -0400 Message-ID: <000001c680d4$3577bee0$5d35a8c0@rlc39> Reply-To: "Matteo Lawrie" From: "Matteo Lawrie" To: capwap-archive@ietf.org Subject: babblemen pippinface credit Date: Fri, 26 May 2006 07:53:54 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68099.8918E6E0" 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: 2.5 (++) X-Scan-Signature: 3b8eea209b62bd15620865bc4fbef8cd This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68099.8918E6E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D j ea s r H z om r e O i wne x r, Your c f re v di m t doesn't matter to us! If you O v WN d r w ea c l e t st s at p e and want I u MME g DIA b TE c t as w h to s o pen d d ANY way you like, or simply wish to L o OW g ER your monthly pa a ym b ent t s by a third or more, here are the d v ea a ls g we have T i OD m AY: $ 4 z 90,00 c 0 as l v ow as 3 , 6 s 5 % $ 37 s 0,00 z 0 as lo a w as 3 , 9 k 0 % $ 49 e 0,0 t 00 as lo l w as 3 , 2 u 0 % $ 25 q 0,0 e 00 as lo f w as 3 , 3 q 5 % $ 2 m 00,0 q 00 as lo m w as 3 , 5 t 5 % V b is e it ou x r web s y it y e Matteo Lawrie , A m ppr y ov n al Ma n na a ge u r except the stone of the floor. Very slowly he got up and groped about on all fours, till he touched the wall of the tunnel; but neither up nor down it could he find anything: nothing at all, no sign of goblins, no sign of dwarves. His ------=_NextPart_000_0001_01C68099.8918E6E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D j ea s r H z om r e O i wne x r,

Your c f re v di m t doesn't matter to us!

If you O v WN d r w ea c l e t st s at p e and want
I u MME g DIA b TE c t as w h to s o pen d d ANY
way you like, or simply wish to
L o OW g ER your monthly pa a ym b ent t s
=20 by a third or more,
here are the d v ea a ls g we have T i OD m AY:

$ 4 z 90,00 c 0 as l v ow as 3 , 6 s 5 %
$ 37 s 0,00 z 0 as lo a w as 3 , 9 k 0 %
$ 49 e 0,0 t 00 as lo l w as 3 , 2 u 0 %
$ 25 q 0,0 e 00 as lo f w as 3 , 3 q 5 %
$ 2 m 00,0 q 00 as lo m w as 3 , 5 t 5 %

V b is e it ou x r web s y it y e

Matteo Lawrie , A m ppr y ov n al Ma n na a ge u r

except the stone of the floor.
Very slowly he got up and groped about on all fours, till he = touched
the wall of the tunnel; but neither up nor down it could he find
anything: nothing at all, no sign of goblins, no sign of dwarves. = His
------=_NextPart_000_0001_01C68099.8918E6E0-- From blomquachan@dynaflair.com Fri May 26 18:47:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjl65-0006yY-9U for capwap-archive@ietf.org; Fri, 26 May 2006 18:47: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 1Fjl65-00012X-7P for capwap-archive@ietf.org; Fri, 26 May 2006 18:47:57 -0400 Received: from 88-137-105-31.adslgp.cegetel.net ([88.137.105.31] helo=dynaflair.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Fjl5y-0006fk-90 for capwap-archive@ietf.org; Fri, 26 May 2006 18:47:53 -0400 Message-ID: <000001c68116$4cfb2970$f891a8c0@ckn94> Reply-To: "Achan Blomquist" From: "Achan Blomquist" To: capwap-archive@ietf.org Subject: calculato accurac Date: Fri, 26 May 2006 15:47:00 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C680DB.A09C5170" 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: a1dc446dc7ac353b90b60743d0e479e3 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C680DB.A09C5170 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D g ea u r H h om z e O i wne j r, Your c r re j di d t doesn't matter to us! If you O h WN f r k ea g l e u st d at x e and want I u MM e EDIAT c E c i as y h to s h pen d d ANY way you like, or simply wish to L t OW v ER your monthly p p aym h ent u s by a third or more, here are the d l ea y ls l we have T c OD l AY: $ 49 y 0,0 i 00 as l m ow as 3 , 6 w 5 % $ 37 p 0,0 c 00 as lo h w as 3 , 9 o 0 % $ 4 i 90,0 e 00 as l w ow as 3 , 2 b 0 % $ 2 u 50,0 a 00 as l a ow as 3 , 3 t 5 % $ 20 n 0,00 f 0 as lo o w as 3 , 5 j 5 % V z is d it o s ur web s e it o e =20 Achan Blomquist , A u ppr g ov u al Ma f na n ge z r a glow I seem to see coming right ahead down there? he thought. It was. As he went forward it grew and grew, till there was no doubt about it. It was a red light steadily getting redder and redder. Also it was now undoubtedly hot in the tunnel. Wisps of vapour floated up and past him ------=_NextPart_000_0001_01C680DB.A09C5170 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D g ea u r H h om z e O i wne j r,

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

If you O h WN f r k ea g l e u st d at x e and want
I u MM e EDIAT c E c i as y h to s h pen d d ANY
way you like, or simply wish to
L t OW v ER your monthly p p aym h ent u s
=20 by a third or more,
here are the d l ea y ls l we have T c OD l AY:

$ 49 y 0,0 i 00 as l m ow as 3 , 6 w 5 %
$ 37 p 0,0 c 00 as lo h w as 3 , 9 o 0 %
$ 4 i 90,0 e 00 as l w ow as 3 , 2 b 0 %
$ 2 u 50,0 a 00 as l a ow as 3 , 3 t 5 %
$ 20 n 0,00 f 0 as lo o w as 3 , 5 j 5 %

V z is d it o s ur web s e it o e

Achan Blomquist , A u ppr g ov u al Ma f na n ge z r

a = glow I seem to see coming right ahead down there? he thought. It = was.
As he went forward it grew and grew, till there was no doubt about = it.
It was a red light steadily getting redder and redder. Also it was = now
undoubtedly hot in the tunnel. Wisps of vapour floated up and past = him
------=_NextPart_000_0001_01C680DB.A09C5170-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat May 27 01:53:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjrkE-0000FV-DL for capwap-archive@lists.ietf.org; Sat, 27 May 2006 01:53:50 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjrfa-0005cV-Om for capwap-archive@lists.ietf.org; Sat, 27 May 2006 01:49:06 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CFB1C4300C6 for ; Fri, 26 May 2006 22:48:51 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 77071430064 for ; Fri, 26 May 2006 22:48:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4AC411448011 for ; Fri, 26 May 2006 22:48:24 -0700 (PDT) Received: from delta.hssblr.co.in (mail.flextronicssoftware.com [203.187.132.2]) by hermes.tigertech.net (Postfix) with ESMTP id 14B101448009 for ; Fri, 26 May 2006 22:48:21 -0700 (PDT) Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.13.6/8.13.6) with ESMTP id l4P5lceb020267 for ; Fri, 25 May 2007 11:17:43 +0530 Received: from cheux004.che.flextronics.com ([10.203.112.4]) by espion.blr.hss.hns.com (Lotus Domino Release 6.5.5) with ESMTP id 2006052711170474-18211 ; Sat, 27 May 2006 11:17:04 +0530 Received: from CHEW0248 ([10.203.113.158]) by cheux004.che.flextronics.com (8.13.6/8.13.5) with SMTP id k4R5WV2J020433 for ; Sat, 27 May 2006 11:02:42 +0530 From: Basker Ms To: "'capwap'" Date: Sat, 27 May 2006 11:17:31 +0530 Message-ID: <027901c68151$0c1d2ad0$9e71cb0a@asia.ad.flextronics.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal In-Reply-To: X-MIMETrack: Itemize by SMTP Server on Espion/BLR/HSS(Release 6.5.5|November 30, 2005) at 05/27/2006 11:17:04 AM, Serialize by Router on Espion/BLR/HSS(Release 6.5.5|November 30, 2005) at 05/27/2006 11:17:21 AM, Serialize complete at 05/27/2006 11:17:21 AM 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, HTML_TITLE_EMPTY X-Spam-Level: Subject: [Capwap] Selecting image for downloading to WTP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: Basker Ms List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1542390699==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 This is a multi-part message in MIME format. --===============1542390699== Content-Type: multipart/alternative; boundary="----=_NextPart_000_027A_01C6817F.25D566D0" This is a multi-part message in MIME format. ------=_NextPart_000_027A_01C6817F.25D566D0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" 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? Or is it that AC will always send the same image to all the WTP(s) in case of version mismatch? Regards, Basker Swaminathan ------=_NextPart_000_027A_01C6817F.25D566D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
All,

According to capwap spec-01, during the discovery = phase:
 
* WTP will send = *its* h/w and=20 s/w version (Section 4.4.34).
* AC will respond = with *its*=20 h/w and s/w version (4.4.1)
 
WTP enters Image Data = state when it=20 determines that its version = number=20
and the version = number advertised by the AC are = different.
 
Suppose, if the AC is = connected=20 with many WTPs from different vendors,
how the AC picks the = correct image=20 for downloading?
 
Or is it that = AC will always=20 send the same image to all the WTP(s)
in case of version=20 mismatch?
 
Regards,
Basker = Swaminathan
 
 

 
 
 
------=_NextPart_000_027A_01C6817F.25D566D0-- --===============1542390699== 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 --===============1542390699==-- From isioculley@c21arizonawest.com Sat May 27 03:35:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjtKe-0003US-84 for capwap-archive@ietf.org; Sat, 27 May 2006 03:35:33 -0400 Received: from 16.red-217-127-227.staticip.rima-tde.net ([217.127.227.16] helo=c21arizonawest.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FjtKc-0001ln-KK for capwap-archive@ietf.org; Sat, 27 May 2006 03:35:32 -0400 Message-ID: <000001c6815f$cf81e2f0$2c18a8c0@ney66> Reply-To: "Isiah Culley" From: "Isiah Culley" To: capwap-archive@ietf.org Subject: defamator untol Date: Sat, 27 May 2006 00:33:12 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68125.23230AF0" 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: 1c0c3d540ad9f95212b1c2a9a2cc2595 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68125.23230AF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D h ea r r H g om a e O x wne b r, Your c u re e di h t doesn't matter to us! If you O k WN c r w ea b l e m st t at d e and want I q MM l EDIA t TE c g as u h to s h pe m nd ANY way you like, or simply wish to L h OW m ER your monthly p a aym n ent z s by a third or more, here are the d l ea m ls g we have T c ODA p Y: $ 4 u 90,00 q 0 as lo m w as 3 , 6 z 5 % $ 37 j 0,0 p 00 as l r ow as 3 , 9 e 0 % $ 4 j 90,0 y 00 as lo g w as 3 , 2 l 0 % $ 25 z 0,00 p 0 as l f ow as 3 , 3 k 5 % $ 20 x 0,00 a 0 as lo r w as 3 , 5 x 5 % V l is i it ou b r web s e it p e =20 Isiah Culley , Ap y pr s ov w al Ma b na k ge w r best to think about it. Personally I have no hopes at all, and wish I was safe back at home. Never mind that for the moment! What are we to do now, to-day? Well, if you really want my advice, I should say we can do nothing but ------=_NextPart_000_0001_01C68125.23230AF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D h ea r r H g om a e O x wne b r,

Your c u re e di h t doesn't matter to us!

If you O k WN c r w ea b l e m st t at d e and want
I q MM l EDIA t TE c g as u h to s h pe m nd ANY
way you like, or simply wish to
L h OW m ER your monthly p a aym n ent z s
=20 by a third or more,
here are the d l ea m ls g we have T c ODA p Y:

$ 4 u 90,00 q 0 as lo m w as 3 , 6 z 5 %
$ 37 j 0,0 p 00 as l r ow as 3 , 9 e 0 %
$ 4 j 90,0 y 00 as lo g w as 3 , 2 l 0 %
$ 25 z 0,00 p 0 as l f ow as 3 , 3 k 5 %
$ 20 x 0,00 a 0 as lo r w as 3 , 5 x 5 %

V l is i it ou b r web s e it p e

Isiah Culley , Ap y pr s ov w al Ma b na k ge w r

best to think about it. Personally I have no hopes at all, and = wish I
was safe back at home.
Never mind that for the moment! What are we to do now, to-day?
Well, if you really want my advice, I should say we can do nothing = but
------=_NextPart_000_0001_01C68125.23230AF0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat May 27 05:26:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjv4U-0003Wu-8Q for capwap-archive@lists.ietf.org; Sat, 27 May 2006 05:26:58 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjv4S-0004oz-Ka for capwap-archive@lists.ietf.org; Sat, 27 May 2006 05:26:58 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8BE084300A4 for ; Sat, 27 May 2006 02:26:45 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 361BC430064 for ; Sat, 27 May 2006 02:26:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1A85E43086D for ; Sat, 27 May 2006 02:26:14 -0700 (PDT) Received: from huawei.com (szxga03-in.huawei.com [61.144.161.55]) by hermes.tigertech.net (Postfix) with ESMTP id C562543085F for ; Sat, 27 May 2006 02:26:05 -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 <0IZX009LN3S1W6@szxga03-in.huawei.com> for capwap@frascone.com; Sat, 27 May 2006 17:31:13 +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 <0IZX009PF3S082@szxga03-in.huawei.com> for capwap@frascone.com; Sat, 27 May 2006 17:31:13 +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 <0IZX00LHU3UD7V@szxml04-in.huawei.com> for capwap@frascone.com; Sat, 27 May 2006 17:32:38 +0800 (CST) Date: Sat, 27 May 2006 14:52:26 +0530 From: sujay In-reply-to: <027901c68151$0c1d2ad0$9e71cb0a@asia.ad.flextronics.com> To: 'Basker Ms' , 'capwap' Message-id: <003401c6816f$11faa630$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=HTML_60_70, HTML_MESSAGE X-Spam-Level: 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: multipart/mixed; boundary="===============0424525741==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 This is a multi-part message in MIME format. --===============0424525741== Content-type: multipart/alternative; boundary="Boundary_(ID_i7S2MioIOoffUSFtcygsEQ)" This is a multi-part message in MIME format. --Boundary_(ID_i7S2MioIOoffUSFtcygsEQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, The new proposal tracked as per Issue 118 should address your concern. ("[Capwap] Proposed Resolution for Issue 118: Change AC Descriptor SW/HW version formats") As it carries the Vendor Identifier both in WTP Descriptor and the AC Descriptor.Perhaps then your implementation may choose to choose the correct image, vendor specific. 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: Basker Ms [mailto:Basker.Ms@flextronicssoftware.com] Sent: Saturday, May 27, 2006 11:18 AM To: 'capwap' Subject: [Capwap] Selecting image for downloading to WTP 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? Or is it that AC will always send the same image to all the WTP(s) in case of version mismatch? Regards, Basker Swaminathan --Boundary_(ID_i7S2MioIOoffUSFtcygsEQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Message
Hi,
The new proposal tracked as per Issue 118 should
address your concern.
("[Capwap] Proposed Resolution for Issue 118: Change AC Descriptor SW/HW version formats")
 
As it carries the Vendor Identifier both in WTP Descriptor
and the AC Descriptor.Perhaps then your implementation may
choose to choose the correct image, vendor specific.

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: Basker Ms [mailto:Basker.Ms@flextronicssoftware.com]
Sent: Saturday, May 27, 2006 11:18 AM
To: 'capwap'
Subject: [Capwap] Selecting image for downloading to WTP

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?
 
Or is it that AC will always send the same image to all the WTP(s)
in case of version mismatch?
 
Regards,
Basker Swaminathan
 
 

 
 
 
--Boundary_(ID_i7S2MioIOoffUSFtcygsEQ)-- --===============0424525741== 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 --===============0424525741==-- From dene@amgsb.com Sat May 27 09:48:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjz9N-0000lC-5q for capwap-archive@ietf.org; Sat, 27 May 2006 09:48:17 -0400 Received: from 70-58-117-13.phnx.qwest.net ([70.58.117.13] helo=amgsb.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fjz9K-00080C-JT for capwap-archive@ietf.org; Sat, 27 May 2006 09:48:17 -0400 Message-ID: <000001c68193$c030d840$66a5a8c0@csd82> Reply-To: "Denise Cline" From: "Denise Cline" To: capwap-archive@ietf.org Subject: skitte torref Date: Sat, 27 May 2006 06:45:01 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68159.13D20040" 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.5 (++++) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68159.13D20040 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D e ea o r H p om z e O h wn k er, Your c t re k di w t doesn't matter to us! If you O y WN a r n ea t l e w st q at i e and want I g MME y DIA j TE c s as i h to s y pen l d ANY way you like, or simply wish to L h OW n ER your monthly p s ayme j nt v s by a third or more, here are the d t ea r ls i we have T w OD c AY: $ 49 l 0,00 h 0 as lo h w as 3 , 6 r 5 % $ 37 i 0,0 c 00 as l f ow as 3 , 9 t 0 % $ 49 r 0,0 i 00 as l y ow as 3 , 2 d 0 % $ 25 g 0,0 f 00 as l l ow as 3 , 3 p 5 % $ 2 a 00,0 i 00 as l m ow as 3 , 5 v 5 % V h is j it o x ur web s b it k e =20 Denise Cline , A y ppr c ova x l M v ana o ge w r distance, and after wait-ing for some time for Bilbo to come back, or to hoot like an owl, they started off one by one to creep towards the light as quietly as they could. No sooner did Tom see Balin come into the light than he gave an awful howl. Trolls simply detest the very sight of ------=_NextPart_000_0001_01C68159.13D20040 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D e ea o r H p om z e O h wn k er,

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

If you O y WN a r n ea t l e w st q at i e and want
I g MME y DIA j TE c s as i h to s y pen l d ANY
way you like, or simply wish to
L h OW n ER your monthly p s ayme j nt v s
=20 by a third or more,
here are the d t ea r ls i we have T w OD c AY:

$ 49 l 0,00 h 0 as lo h w as 3 , 6 r 5 %
$ 37 i 0,0 c 00 as l f ow as 3 , 9 t 0 %
$ 49 r 0,0 i 00 as l y ow as 3 , 2 d 0 %
$ 25 g 0,0 f 00 as l l ow as 3 , 3 p 5 %
$ 2 a 00,0 i 00 as l m ow as 3 , 5 v 5 %

V h is j it o x ur web s b it k e

Denise Cline , A y ppr c ova x l M v ana o ge w r

distance, and after wait-ing for some time for Bilbo to come = back, or to
hoot like an owl, they started off one by one to creep towards the = light
as quietly as they could. No sooner did Tom see Balin come into the
light than he gave an awful howl. Trolls simply detest the very sight = of
------=_NextPart_000_0001_01C68159.13D20040-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat May 27 15:30:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk4Uw-0007j6-PP for capwap-archive@lists.ietf.org; Sat, 27 May 2006 15:30:54 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fk4Uu-00043F-DF for capwap-archive@lists.ietf.org; Sat, 27 May 2006 15:30:54 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8B2BC4300CB for ; Sat, 27 May 2006 12:30:43 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 07E7D430063 for ; Sat, 27 May 2006 12:30:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E686E1448013 for ; Sat, 27 May 2006 12:30:22 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 712E81448011 for ; Sat, 27 May 2006 12:30: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 k4RJU9Va011984; Sat, 27 May 2006 12:30:09 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k4RJU934011981; Sat, 27 May 2006 12:30:09 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Sat, 27 May 2006 12:30:08 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Basker Ms In-Reply-To: <027901c68151$0c1d2ad0$9e71cb0a@asia.ad.flextronics.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] 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: 8b30eb7682a596edff707698f4a80f7d 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? > > 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue May 30 21:19:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlFMg-0006qH-8B for capwap-archive@lists.ietf.org; Tue, 30 May 2006 21:19:14 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlFMd-0005Pn-QU for capwap-archive@lists.ietf.org; Tue, 30 May 2006 21:19:14 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BDD8D4300EA for ; Tue, 30 May 2006 18:19:02 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id CD07F43005A for ; Tue, 30 May 2006 18:18:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id B8F27398019 for ; Tue, 30 May 2006 18:18:39 -0700 (PDT) Received: from huawei.com (szxga03-in.huawei.com [61.144.161.55]) by zoidberg.tigertech.net (Postfix) with ESMTP id E5BEF398012 for ; Tue, 30 May 2006 18:18:35 -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 <0J0300GFJW1J9Q@szxga03-in.huawei.com> for capwap@frascone.com; Wed, 31 May 2006 09:27:20 +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 <0J0300AF8W1JCM@szxga03-in.huawei.com> for capwap@frascone.com; Wed, 31 May 2006 09:27:19 +0800 (CST) Received: from q52443 ([10.164.46.20]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J030096IW3UMJ@szxml04-in.huawei.com> for capwap@frascone.com; Wed, 31 May 2006 09:28:46 +0800 (CST) Date: Wed, 31 May 2006 09:18:26 +0800 From: qinxia In-reply-to: To: "'David T. Perkins'" , 'Basker Ms' Message-id: <004501c68450$1e4f4740$838cfea9@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcaBxBTZCDZ11ZEvTfKhtiTi6kaLsgCi2dDw 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] 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: e8a67952aa972b528dd04570d58ad8fe 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 Wed May 31 02:22:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlK5o-0000iL-6a for capwap-archive@lists.ietf.org; Wed, 31 May 2006 02:22:08 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlK5j-0007A8-Jh for capwap-archive@lists.ietf.org; Wed, 31 May 2006 02:22:08 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BE37D4300F2 for ; Tue, 30 May 2006 23:21:51 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3F34A43006D for ; Tue, 30 May 2006 23:21:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2D9791448001 for ; Tue, 30 May 2006 23:21:28 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 804B4144800D for ; Tue, 30 May 2006 23:21:25 -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 k4V6LCGi017140; Tue, 30 May 2006 23:21:12 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k4V6L9PF017119; Tue, 30 May 2006 23:21:12 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 30 May 2006 23:21:08 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: qinxia In-Reply-To: <004501c68450$1e4f4740$838cfea9@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' , '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: 848ed35f2a4fc0638fa89629cb640f48 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 31 18:25:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlZ7w-0007kb-Ox for capwap-archive@lists.ietf.org; Wed, 31 May 2006 18:25:20 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlZ7u-0001CQ-HF for capwap-archive@lists.ietf.org; Wed, 31 May 2006 18:25:20 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 86AE94300DB for ; Wed, 31 May 2006 15:25:17 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D13D143011B for ; Wed, 31 May 2006 15:24:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id BD1C5398039 for ; Wed, 31 May 2006 15:24:28 -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 0882D398033 for ; Wed, 31 May 2006 15:24:24 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 31 May 2006 15:24:23 -0700 X-IronPort-AV: i="4.05,195,1146466800"; d="scan'208,217"; a="286470272:sNHT63913628" 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 k4VMON7X022815; Wed, 31 May 2006 15:24:23 -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 k4VMONcL021786; Wed, 31 May 2006 15:24:23 -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); Wed, 31 May 2006 15:24:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 May 2006 15:24:22 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC0197B94A@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New issues: readability/ease of use/lack of specification Thread-Index: AcaAIUchf9T2orIgQU+c02rGVZ/lXwEvfpYg From: "Bob O'Hara (boohara)" To: "capwap" X-OriginalArrivalTime: 31 May 2006 22:24:23.0226 (UTC) FILETIME=[F7E741A0:01C68500] 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.539 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_40_50, HTML_MESSAGE, NORMAL_HTTP_TO_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] New issues: readability/ease of use/lack of 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="===============1403630628==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: b4be0d55bab88df9d21005ced9551e26 This is a multi-part message in MIME format. --===============1403630628== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68500.F7B16404" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68500.F7B16404 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dorothy, =20 Most of your suggestions for resolving the issues below work for me. I will comment on each, individually, below. -Bob =20 =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Thursday, May 25, 2006 10:33 AM To: Bob O'Hara (boohara) Cc: capwap Subject: Re: [Capwap] New issues: readability/ease of use/lack of specification Hi Bob, Glad that you found the -01 draft a significant improvement. Proposed resolutions to Issue 124 are inline below.=20 Thanks, Dorothy On 5/23/06, Bob O'Hara (boohara) wrote: The -01 draft is a significant improvement over the -00 draft. However, I find it very difficult to easily find some information in the document. Following are some editorial and technical comments. =09 1. Please include a table of message element type values for the base=20 CAPWAP message elements in section 4.4. Proposed Resolution: Insert a tablet at the end of Section 4.4, just prior to=20 4.4.1 The following CAPWAP protocol message elements are defined: [Include the list - the 01 elements, plus changes due to issue resolution, with type values] Bob>> Works for me.=20 =20 2. Please include a table of message element type values for the 802.11 binding-specific elements in section 11.10. Proposed resolution: Insert a table in Section 10.10, just prior to 11.10.1 The follwoing IEEE 802.11 specific message elements are defined: [Include the list - the -01 values, plus any changes per issue resolution, with type values] =20 Bob>> Works for me. =20 3. Please describe how the binding-specific message element type values are derived. It appears that the 802.11 type values begin arbitrarily at 1024. Are the values for this field to be IANA controlled, or are they able to be identified deterministically? The resolution of Issue 91 (Duplicate message element values)=20 renumbered the CAPWAP message elements to begin with 1, and The IEEE 802.11 message element values to begin with 1024. The next wireless type would begin at 2048. The definition of values is to be done in the CAPWAP document(s). Proposed resolution: At the end of section 4.4, prior to the table being added by comment #1 above, change from Where Type (16 bit) identifies the character of the information carried in the Value field and Length (16 bits) indicates the number of bytes in the Value field. to Where Type (16 bit) identifies the character of the information carried in the Value field and Length (16 bits) indicates the number of bytes in the Value field. Type field values are allocated as follows: Usage Type Values CAPWAP Protocol Message Elements 1-1023 IEEE 802.11 Message Elements 1024-2047 Reserved for Future Use 2048 - 65024=20 and delete text describing IANA allocation of message element values. =20 Bob>> Works for me. =20 4. Please identify in which messages the nine additional message elements in section 11.10 may appear, since they are not listed in the table in section 11.9.3. The table in 11.9.3 lists the message elements that may be included in the various configuration related messages. Section 11.7.1 includes the message elements which can be included in the IEEE 802.11 WLAN Config Request message: IEEE 802.11 Add WLAN=20 IEEE 802.11 Delete WLAN IEEE 802.11 Update WLAN IEEE 802.11 Information Element Section 11.7.2 lists the message elements that may be included in=20 the IEEE 802.11 WLAN Config Response: IEEE 802.11 Assigned WTP BSSID Section 11.9.1 lists the message elements that may be included in the=20 Mobile Config Request message: IEEE 802.11 Mobile IEEE 802.11 Mobile Session Key Station QOS Profile Section 11.9.2 lists the message elements that may be included in the WTP Event Request message: IEEE 802.11 MIC Countermeasures IEEE 802.11 Statistics IEEE 802.11 Radio Fail Alarm Indication Between all of these sections, each message element is included in at least one message. There is one message element listed in the=20 section 11.9.3 table that is not defined: IEEE 802.11 WTP Mode and Type. This seems to be CAPWAP level information rather than 802.11 specific. Proposed change: Delete the IEEE 802.11 WTP Mode and Type row in the 11.9.3 table =20 Bob>> Hmmm... I see that you are correct, but wonder why the format is so different from 11.7.1/2, 11.9.1/2 to 11.9.3. If Config Request/Response, Mobile Config Request, and WTP Event Request all deserve their own little section, why are the configuration messages treated differently? Also, why does Mobile Config Request appear in the table in 11.9.3 with two elements allowed and in 11.9.1 with three elements? Why is Mobile Config Request in the table in 11.9.3, at all? =20 5. In 11.7, the Message Type Value for the two 802.11-specific messages is given. However, I don't see anywhere that describes how these values=20 were determined. Please add a description of the derivation of the message type values. Please see the description in section 4.3.1.1 (extracted below). Is this sufficient, or is additional description required? 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 =3D IANA Enterprise Number * 256 + Message Type Value =20 Bob>> Yes this is sufficient, with the reference in the first paragraph of 11.7 changed to "See Section 4.3.1.1 for the derivation of the Message Type Value from the IANA Enterprise number."=20 6. 11.8 says there are no 802.11-specific data message bindings. I think that the data packet containing an 802.11-encapsulated frame should go here, along with its complete description. There is some descriptive text in Section 11.4, Transport Specific Bindings, which describes the patload encapsulation. Is this text sufficient? If not, what addtional information is needed? Perhaps a figure should be added to this section?=20 =20 Bob>> Well, I wouldn't expect to see an 802.15 or 802.16 frame encapsulated in 802.11 in some future revision of CAPWAP. so, I think that this encapsulation type is specific to the 802.11 binding. That is why I think it should be defined and described in 11.8. The native frame of the binding-specific protocol that is carried in a CAPWAP packet is not really "transport specific". The transport is CAPWAP, not 802.11. The encapsulation is 802.11. I think that the entire content of 11.4 can be moved to 11.8. -Bob =09 Bob O'Hara Cisco Systems - WNBU =09 Phone: +1 408 853 5513 Mobile: +1 408 218 4025 =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 =09 ------_=_NextPart_001_01C68500.F7B16404 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dorothy,
 
Most of your suggestions for resolving the = issues below=20 work for me.  I will comment on each, individually,=20 below.

 -Bob
 

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Thursday, May 25, 2006 = 10:33=20 AM
To: Bob O'Hara (boohara)
Cc: = capwap
Subject:=20 Re: [Capwap] New issues: readability/ease of use/lack of=20 specification

Hi Bob,

Glad that you found the -01 draft a = significant=20 improvement. Proposed
resolutions to Issue 124 are inline below.=20

Thanks,

Dorothy

On 5/23/06, Bob O'Hara=20 (boohara) <boohara@cisco.com>=20 wrote:
The=20 -01 draft is a significant improvement over the -00=20 draft.  However,
I find it very difficult to easily find = some=20 information in the
document.  Following are some = editorial and=20 technical comments.

1. Please include a table of message = element type=20 values for the base
CAPWAP message elements in section = 4.4.

Proposed = Resolution:=20 Insert a tablet at the end of Section 4.4, just prior to =
4.4.1

The=20 following CAPWAP protocol message elements are defined:
[Include the = list -=20 the 01 elements, plus changes due to issue resolution, with type=20 values]

Bob>> Works for me. 
 
2.=20 Please include a table of message element type values for the=20 802.11
binding-specific elements in section 11.10.

Proposed resolution:  Insert a table in Section = 10.10,=20 just
prior to 11.10.1

The follwoing IEEE 802.11 specific = message=20 elements are defined:
[Include the list - the -01 values, plus any = changes=20 per issue resolution, with type values]
 
Bob>> Works for me.
 

3.=20 Please describe how the binding-specific message element type = values
are=20 derived.  It appears that the 802.11 type values begin=20 arbitrarily
at 1024.  Are the values for this field to be = IANA=20 controlled, or are
they able to be identified = deterministically?

The = resolution of Issue 91=20 (Duplicate message element values)
renumbered the CAPWAP message = elements to=20 begin with 1, and
The IEEE 802.11 message element values to begin = with=20 1024.
The next wireless type would begin at 2048. The
definition = of values=20 is to be done in the CAPWAP document(s).

Proposed resolution: At = the end=20 of section 4.4, prior
to the table being added by comment #1 above, = change=20 from

   Where Type (16 bit) identifies the character of = the=20 information
   carried in the Value field and Length (16 = bits)=20 indicates the number
   of bytes in the Value=20 field.

to

   Where Type (16 bit) identifies the=20 character of the information
   carried in the Value field = and=20 Length (16 bits) indicates the number
   of bytes in the = Value=20 field. Type field values are allocated as=20 follows:


         = ;            =          =20 Usage=20             &= nbsp;    =20                     = Type=20 Values

         CAPWAP = Protocol=20 Message=20 Elements           = ;    =20 1-1023
         IEEE 802.11 = Message=20 Elements           = ;            =  =20 1024-2047
         Reserved = for=20 Future=20 Use           &nbs= p;            = ;            =  =20 2048 - 65024

and delete text describing IANA allocation of message element=20 values.
 
Bob>> Works for me.
 
4.=20 Please identify in which messages the nine additional = message
elements in=20 section 11.10 may appear, since they are not listed in the
table in = section=20 11.9.3.

The table in 11.9.3 lists the = message elements=20 that may be included in
the various configuration related=20 messages.

Section 11.7.1 includes the message elements which can = be=20 included in the
IEEE 802.11 WLAN Config Request message:
IEEE = 802.11 Add=20 WLAN
IEEE 802.11 Delete WLAN
IEEE 802.11 Update WLAN
IEEE = 802.11=20 Information Element

Section 11.7.2 lists the message elements = that may be=20 included in
the IEEE 802.11 WLAN Config Response:
IEEE 802.11 = Assigned=20 WTP BSSID

Section 11.9.1 lists the message elements that may be = included=20 in the
Mobile Config Request message:
IEEE 802.11 Mobile
IEEE = 802.11=20 Mobile Session Key
Station QOS Profile

Section 11.9.2 lists = the=20 message elements that may be included
in the WTP Event Request=20 message:
IEEE 802.11 MIC Countermeasures
IEEE 802.11 = Statistics
IEEE=20 802.11 Radio Fail Alarm Indication

Between all of these sections, = each=20 message element is included in
at least one message. There is  = one=20 message element listed in the
section 11.9.3 table that is not=20 defined:
IEEE 802.11 WTP Mode and Type. This seems to be = CAPWAP
level=20 information rather than 802.11 specific.

Proposed = change:
Delete the=20 IEEE 802.11 WTP Mode and Type row in the 11.9.3 table
 
Bob>> Hmmm... I see that you are = correct, but=20 wonder why the format is so different from 11.7.1/2, 11.9.1/2 to = 11.9.3. =20 If Config Request/Response, Mobile Config Request, and WTP Event Request = all=20 deserve their own little section, why are the configuration messages = treated=20 differently?  Also, why does Mobile Config Request appear in the = table=20 in 11.9.3 with two elements allowed and in 11.9.1 with three=20 elements?  Why is Mobile Config Request in the table in 11.9.3, at=20 all?
 

5.=20 In 11.7, the Message Type Value for the two 802.11-specific = messages
is=20 given.  However, I don't see anywhere that describes how = these=20 values
were determined.  Please add a description of the = derivation of the
message type values.

Please see the description in section 4.3.1.1 (extracted below). Is this = sufficient,=20 or
is additional description required?

The Message Type field = is=20 comprised of an IANA Enterprise
   Number and a message = type value=20 field.  The first two byte contain
   the IANA = Enterprise=20 Number (for example, the IEEE 802.11 IANA
   Enterprise = number is=20 13277), and the second two bytes contain the
   Message = Type=20 value.  The message type field can be expressed = as:

  =20 Message Type =3D IANA Enterprise Number * 256 + Message Type = Value
 
Bob>> Yes this is sufficient, with the = reference in the first paragraph of 11.7 = changed to "See=20 Section 4.3.1.1 for the derivation of the Message Type Value from the = IANA=20 Enterprise number." 

6.=20 11.8 says there are no 802.11-specific data message=20 bindings.  I
think that the data packet containing an=20 802.11-encapsulated frame
should go here, along with its complete=20 description.

There is = some descriptive=20 text in Section 11.4, Transport
Specific Bindings, which describes = the=20 patload encapsulation.

Is this text sufficient? If not, what = addtional=20 information is needed?
Perhaps a figure should be added to this = section? 
 
Bob>> Well, I wouldn't expect to see an 802.15 or 802.16 = frame=20 encapsulated in 802.11 in some future revision of CAPWAP.  so, I = think that=20 this encapsulation type is specific to the 802.11 binding.  That is = why I=20 think it should be defined and described in 11.8.  The native frame = of the binding-specific protocol that is carried in a CAPWAP packet = is not=20 really "transport specific".  The transport is CAPWAP, not = 802.11. =20 The encapsulation is 802.11. =20 I think that the entire content of 11.4 can be moved to=20 11.8.

-Bob

Bob=20 O'Hara
Cisco Systems - WNBU

Phone:  +1 408 853=20 5513
Mobile: +1 408 218=20 = 4025

_____________________________________________________________= ____
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

------_=_NextPart_001_01C68500.F7B16404-- --===============1403630628== 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 --===============1403630628==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 31 19:54:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlaVm-0006xg-9Z for capwap-archive@lists.ietf.org; Wed, 31 May 2006 19:54:02 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlaVk-0002zJ-DB for capwap-archive@lists.ietf.org; Wed, 31 May 2006 19:54:02 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 73F9F4300E0 for ; Wed, 31 May 2006 16:53:58 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id ECD03430063 for ; Wed, 31 May 2006 16:53:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D3E51144801D for ; Wed, 31 May 2006 16:53:20 -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 67E941448012 for ; Wed, 31 May 2006 16:53:17 -0700 (PDT) Received: by wx-out-0102.google.com with SMTP id t13so109099wxc for ; Wed, 31 May 2006 16:53:16 -0700 (PDT) Received: by 10.70.6.17 with SMTP id 17mr1353wxf; Wed, 31 May 2006 16:53:16 -0700 (PDT) Received: by 10.70.133.19 with HTTP; Wed, 31 May 2006 16:53:16 -0700 (PDT) Message-ID: <5bfe7a820605311653r2a5fb86ehc91e2ff35182b770@mail.gmail.com> Date: Wed, 31 May 2006 16:53:16 -0700 From: "Dorothy Stanley" To: "Bob O'Hara (boohara)" In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC0197B94A@xmb-sjc-237.amer.cisco.com> MIME-Version: 1.0 References: <17B8C6DE4E228348B4939BDA6B05A9DC0197B94A@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.7 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_40_50, HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] New issues: readability/ease of use/lack of 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="===============0619888710==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.7 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 --===============0619888710== Content-Type: multipart/alternative; boundary="----=_Part_32843_19718118.1149119596298" ------=_Part_32843_19718118.1149119596298 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Bob, Thanks very much for the comments. Replies below. Dorothy > > 4. Please identify in which messages the nine additional message > > elements in section 11.10 may appear, since they are not listed in the > > table in section 11.9.3. > > > The table in 11.9.3 lists the message elements that may be included in > the various configuration related messages. > > Section 11.7.1 includes the message elements which can be included in the > IEEE 802.11 WLAN Config Request message: > IEEE 802.11 Add WLAN > IEEE 802.11 Delete WLAN > IEEE 802.11 Update WLAN > IEEE 802.11 Information Element > > Section 11.7.2 lists the message elements that may be included in > the IEEE 802.11 WLAN Config Response: > IEEE 802.11 Assigned WTP BSSID > > Section 11.9.1 lists the message elements that may be included in the > Mobile Config Request message: > IEEE 802.11 Mobile > IEEE 802.11 Mobile Session Key > Station QOS Profile > > Section 11.9.2 lists the message elements that may be included > in the WTP Event Request message: > IEEE 802.11 MIC Countermeasures > IEEE 802.11 Statistics > IEEE 802.11 Radio Fail Alarm Indication > > Between all of these sections, each message element is included in > at least one message. There is one message element listed in the > section 11.9.3 table that is not defined: > IEEE 802.11 WTP Mode and Type. This seems to be CAPWAP > level information rather than 802.11 specific. > > Proposed change: > Delete the IEEE 802.11 WTP Mode and Type row in the 11.9.3 table > > Bob>> Hmmm... I see that you are correct, but wonder why the format is so > different from 11.7.1/2, 11.9.1/2 to 11.9.3. If Config Request/Response, > Mobile Config Request, and WTP Event Request all deserve their own little > section, why are the configuration messages treated differently? Also, why > does Mobile Config Request appear in the table in 11.9.3 with two elements > allowed and in 11.9.1 with three elements? Why is Mobile Config Request > in the table in 11.9.3, at all? > The Config section format is the legacy format from the LWAPP draft. I have no problem with establishing separate sections for each message, and cleaning up the Mobile config request. 5. In 11.7, the Message Type Value for the two 802.11-specific messages > > is given. However, I don't see anywhere that describes how these values > > > > were determined. Please add a description of the derivation of the > > message type values. > > > Please see the description in section 4.3.1.1 (extracted below). Is this > sufficient, or > is additional description required? > > 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 > > Bob>> Yes this is sufficient, with the reference in the first paragraph of > 11.7 changed to "See Section 4.3.1.1 for the derivation of the Message > Type Value from the IANA Enterprise number." > Ok, will add the reference. 6. 11.8 says there are no 802.11-specific data message bindings. I > > think that the data packet containing an 802.11-encapsulated frame > > should go here, along with its complete description. > > > There is some descriptive text in Section 11.4, Transport > Specific Bindings, which describes the patload encapsulation. > > Is this text sufficient? If not, what addtional information is needed? > Perhaps a figure should be added to this section? > > Bob>> Well, I wouldn't expect to see an 802.15 or 802.16 frame > encapsulated in 802.11 in some future revision of CAPWAP. so, I think > that this encapsulation type is specific to the 802.11 binding. That is > why I think it should be defined and described in 11.8. The native frame > of the binding-specific protocol that is carried in a CAPWAP packet is not > really "transport specific". The transport is CAPWAP, not 802.11. The > encapsulation is 802.11. I think that the entire content of 11.4 can be > moved to 11.8. > Ok, will move the content of 11.4 to 11.8. -Bob > > > > Bob O'Hara > > Cisco Systems - WNBU > > > > Phone: +1 408 853 5513 > > Mobile: +1 408 218 4025 > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > ------=_Part_32843_19718118.1149119596298 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Bob,

Thanks very much for the comments. Replies below.

Dorothy

4. Please identify in which messages the nine additional message
elements in section 11.10 may appear, since they are not listed in the
table in section 11.9.3.

The table in 11.9.3 lists the message elements that may be included in
the various configuration related messages.

Section 11.7.1 includes the message elements which can be included in the
IEEE 802.11 WLAN Config Request message:
IEEE 802.11 Add WLAN
IEEE 802.11 Delete WLAN
IEEE 802.11 Update WLAN
IEEE 802.11 Information Element

Section 11.7.2 lists the message elements that may be included in
the IEEE 802.11 WLAN Config Response:
IEEE 802.11 Assigned WTP BSSID

Section 11.9.1 lists the message elements that may be included in the
Mobile Config Request message:
IEEE 802.11 Mobile
IEEE 802.11 Mobile Session Key
Station QOS Profile

Section 11.9.2 lists the message elements that may be included
in the WTP Event Request message:
IEEE 802.11 MIC Countermeasures
IEEE 802.11 Statistics
IEEE 802.11 Radio Fail Alarm Indication

Between all of these sections, each message element is included in
at least one message. There is  one message element listed in the
section 11.9.3 table that is not defined:
IEEE 802.11 WTP Mode and Type. This seems to be CAPWAP
level information rather than 802.11 specific.

Proposed change:
Delete the IEEE 802.11 WTP Mode and Type row in the 11.9.3 table
 
Bob>> Hmmm... I see that you are correct, but wonder why the format is so different from 11.7.1/2, 11.9.1/2 to 11.9.3.  If Config Request/Response, Mobile Config Request, and WTP Event Request all deserve their own little section, why are the configuration messages treated differently?  Also, why does Mobile Config Request appear in the table in 11.9.3 with two elements allowed and in 11.9.1 with three elements?  Why is Mobile Config Request in the table in 11.9.3, at all?

The Config section  format is the legacy format from the LWAPP draft. I have no problem with
establishing separate sections for each message, and cleaning up the Mobile config request.

5. In 11.7, the Message Type Value for the two 802.11-specific messages
is given.  However, I don't see anywhere that describes how these values
were determined.  Please add a description of the derivation of the
message type values.

Please see the description in section 4.3.1.1 (extracted below). Is this sufficient, or
is additional description required?

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
 
Bob>> Yes this is sufficient, with the reference in the first paragraph of 11.7 changed to "See Section 4.3.1.1 for the derivation of the Message Type Value from the IANA Enterprise number." 


Ok, will add the reference.

6. 11.8 says there are no 802.11-specific data message bindings.  I
think that the data packet containing an 802.11-encapsulated frame
should go here, along with its complete description.

There is some descriptive text in Section 11.4, Transport
Specific Bindings, which describes the patload encapsulation.

Is this text sufficient? If not, what addtional information is needed?
Perhaps a figure should be added to this section? 
 
Bob>> Well, I wouldn't expect to see an 802.15 or 802.16 frame encapsulated in 802.11 in some future revision of CAPWAP.  so, I think that this encapsulation type is specific to the 802.11 binding.  That is why I think it should be defined and described in 11.8.  The native frame of the binding-specific protocol that is carried in a CAPWAP packet is not really "transport specific".  The transport is CAPWAP, not 802.11.  The encapsulation is 802.11.  I think that the entire content of 11.4 can be moved to 11.8.

Ok, will move the content of 11.4 to 11.8.

-Bob

Bob O'Hara
Cisco Systems - WNBU

Phone:  +1 408 853 5513
Mobile: +1 408 218 4025

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

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


------=_Part_32843_19718118.1149119596298-- --===============0619888710== 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 --===============0619888710==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed May 31 22:13:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flcg3-000288-19 for capwap-archive@lists.ietf.org; Wed, 31 May 2006 22:12:47 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlcVv-0008Eg-Vo for capwap-archive@lists.ietf.org; Wed, 31 May 2006 22:02:23 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0EF6B4300EA for ; Wed, 31 May 2006 19:02:19 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 021EB4300A2 for ; Wed, 31 May 2006 19:01:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DF5891448012 for ; Wed, 31 May 2006 19:01:36 -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 A8E431448001 for ; Wed, 31 May 2006 19:01:33 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 31 May 2006 19:01:32 -0700 X-IronPort-AV: i="4.05,195,1146466800"; d="scan'208,217"; a="1816760802:sNHT71585244" 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 k5121Wri000595; Wed, 31 May 2006 19:01:32 -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 k5121WIs027959; Wed, 31 May 2006 19:01:32 -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); Wed, 31 May 2006 19:01:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 May 2006 19:01:30 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC0197BA4B@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] New issues: readability/ease of use/lack of specification Thread-Index: AcaFDWi5Mc4RildOR5Wy8oSDmi/UQgAEd4wA From: "Bob O'Hara (boohara)" To: "Dorothy Stanley" X-OriginalArrivalTime: 01 Jun 2006 02:01:32.0298 (UTC) FILETIME=[4DD5DEA0:01C6851F] 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-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, NORMAL_HTTP_TO_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] New issues: readability/ease of use/lack of 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="===============1188222259==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 916029c14bdb340aa234d3ec4cd24f52 This is a multi-part message in MIME format. --===============1188222259== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6851F.4D9E8DEC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6851F.4D9E8DEC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks! -Bob =20 =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Wednesday, May 31, 2006 4:53 PM To: Bob O'Hara (boohara) Cc: capwap Subject: Re: [Capwap] New issues: readability/ease of use/lack of specification Bob, Thanks very much for the comments. Replies below. Dorothy =09 =09 4. Please identify in which messages the nine additional message elements in section 11.10 may appear, since they are not listed in the table in section 11.9.3. =09 The table in 11.9.3 lists the message elements that may be included in the various configuration related messages. =09 Section 11.7.1 includes the message elements which can be included in the IEEE 802.11 WLAN Config Request message: IEEE 802.11 Add WLAN=20 IEEE 802.11 Delete WLAN IEEE 802.11 Update WLAN IEEE 802.11 Information Element =09 Section 11.7.2 lists the message elements that may be included in=20 the IEEE 802.11 WLAN Config Response: IEEE 802.11 Assigned WTP BSSID =09 Section 11.9.1 lists the message elements that may be included in the=20 Mobile Config Request message: IEEE 802.11 Mobile IEEE 802.11 Mobile Session Key Station QOS Profile =09 Section 11.9.2 lists the message elements that may be included in the WTP Event Request message: IEEE 802.11 MIC Countermeasures IEEE 802.11 Statistics IEEE 802.11 Radio Fail Alarm Indication =09 Between all of these sections, each message element is included in at least one message. There is one message element listed in the=20 section 11.9.3 table that is not defined: IEEE 802.11 WTP Mode and Type. This seems to be CAPWAP level information rather than 802.11 specific. =09 Proposed change: Delete the IEEE 802.11 WTP Mode and Type row in the 11.9.3 table =09 =20 Bob>> Hmmm... I see that you are correct, but wonder why the format is so different from 11.7.1/2, 11.9.1/2 to 11.9.3. If Config Request/Response, Mobile Config Request, and WTP Event Request all deserve their own little section, why are the configuration messages treated differently? Also, why does Mobile Config Request appear in the table in 11.9.3 with two elements allowed and in 11.9.1 with three elements? Why is Mobile Config Request in the table in 11.9.3, at all? The Config section format is the legacy format from the LWAPP draft. I have no problem with establishing separate sections for each message, and cleaning up the Mobile config request. =09 5. In 11.7, the Message Type Value for the two 802.11-specific messages is given. However, I don't see anywhere that describes how these values=20 were determined. Please add a description of the derivation of the message type values. =09 Please see the description in section 4.3.1.1 (extracted below). Is this sufficient, or is additional description required? =09 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: =09 Message Type =3D IANA Enterprise Number * 256 + Message Type Value =20 Bob>> Yes this is sufficient, with the reference in the first paragraph of 11.7 changed to "See Section 4.3.1.1 for the derivation of the Message Type Value from the IANA Enterprise number."=20 Ok, will add the reference.=20 =09 6. 11.8 says there are no 802.11-specific data message bindings. I think that the data packet containing an 802.11-encapsulated frame should go here, along with its complete description. =09 =09 There is some descriptive text in Section 11.4, Transport Specific Bindings, which describes the patload encapsulation. =09 Is this text sufficient? If not, what addtional information is needed? Perhaps a figure should be added to this section?=20 =20 Bob>> Well, I wouldn't expect to see an 802.15 or 802.16 frame encapsulated in 802.11 in some future revision of CAPWAP. so, I think that this encapsulation type is specific to the 802.11 binding. That is why I think it should be defined and described in 11.8. The native frame of the binding-specific protocol that is carried in a CAPWAP packet is not really "transport specific". The transport is CAPWAP, not 802.11. The encapsulation is 802.11. I think that the entire content of 11.4 can be moved to 11.8. Ok, will move the content of 11.4 to 11.8.=20 =09 -Bob =09 Bob O'Hara Cisco Systems - WNBU =09 Phone: +1 408 853 5513 Mobile: +1 408 218 4025 =09 =09 _________________________________________________________________ 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 ------_=_NextPart_001_01C6851F.4D9E8DEC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks!

 -Bob
 

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Wednesday, May 31, 2006 = 4:53=20 PM
To: Bob O'Hara (boohara)
Cc: = capwap
Subject:=20 Re: [Capwap] New issues: readability/ease of use/lack of=20 specification

Bob,

Thanks very much for the comments. Replies=20 below.

Dorothy

4.=20 Please identify in which messages the nine additional = message
elements in=20 section 11.10 may appear, since they are not listed in the
table = in=20 section 11.9.3.

The table in 11.9.3 = lists the=20 message elements that may be included in
the various configuration = related=20 messages.

Section 11.7.1 includes the message elements which = can be=20 included in the
IEEE 802.11 WLAN Config Request message:
IEEE = 802.11 Add=20 WLAN
IEEE 802.11 Delete WLAN
IEEE 802.11 Update WLAN
IEEE = 802.11=20 Information Element

Section 11.7.2 lists the message elements = that may=20 be included in
the IEEE 802.11 WLAN Config Response:
IEEE = 802.11=20 Assigned WTP BSSID

Section 11.9.1 lists the message elements = that may=20 be included in the
Mobile Config Request message:
IEEE 802.11=20 Mobile
IEEE 802.11 Mobile Session Key
Station QOS = Profile

Section=20 11.9.2 lists the message elements that may be included
in the WTP = Event=20 Request message:
IEEE 802.11 MIC Countermeasures
IEEE 802.11=20 Statistics
IEEE 802.11 Radio Fail Alarm Indication

Between = all of=20 these sections, each message element is included in
at least one = message.=20 There is  one message element listed in the
section 11.9.3 = table that=20 is not defined:
IEEE 802.11 WTP Mode and Type. This seems to be=20 CAPWAP
level information rather than 802.11 = specific.

Proposed=20 change:
Delete the IEEE 802.11 WTP Mode and Type row in the 11.9.3=20 table
 
Bob>> = Hmmm... I see=20 that you are correct, but wonder why the format is so different from = 11.7.1/2,=20 11.9.1/2 to 11.9.3.  If Config Request/Response, Mobile Config = Request,=20 and WTP Event Request all deserve their own little section, why are = the=20 configuration messages treated differently?  Also, why does = Mobile Config=20 Request appear in the table in 11.9.3 with two elements allowed = and in=20 11.9.1 with three elements?  Why is Mobile Config Request in the = table in=20 11.9.3, at all?

The Config section  format is the legacy format from the = LWAPP=20 draft. I have no problem with
establishing separate sections for each = message, and cleaning up the Mobile config request.

5.=20 In 11.7, the Message Type Value for the two 802.11-specific = messages
is=20 given.  However, I don't see anywhere that describes how = these=20 values
were determined.  Please add a description of = the=20 derivation of the
message type values.

Please see the description in section 4.3.1.1 (extracted below). Is this sufficient, = or
is=20 additional description required?

The Message Type field is = comprised of=20 an IANA Enterprise
   Number and a message type value=20 field.  The first two byte contain
   the IANA = Enterprise=20 Number (for example, the IEEE 802.11 IANA
   Enterprise = number is=20 13277), and the second two bytes contain the
   Message = Type=20 value.  The message type field can be expressed = as:

  =20 Message Type =3D IANA Enterprise Number * 256 + Message Type=20 Value
 
Bob>> Yes = this is=20 sufficient, with the reference in the first paragraph of 11.7 changed to "See Section 4.3.1.1 for the derivation of the Message Type = Value from=20 the IANA Enterprise = number." 


Ok, will add the reference.

6.=20 11.8 says there are no 802.11-specific data message=20 bindings.  I
think that the data packet containing an=20 802.11-encapsulated frame
should go here, along with its complete = description.

There is = some=20 descriptive text in Section 11.4, Transport
Specific Bindings, = which=20 describes the patload encapsulation.

Is this text sufficient? = If not,=20 what addtional information is needed?
Perhaps a figure should be = added to=20 this section? 
 
Bob>> = Well, I wouldn't=20 expect to see an 802.15 or 802.16 frame encapsulated in 802.11 in some = future=20 revision of CAPWAP.  so, I think that this encapsulation type is = specific=20 to the 802.11 binding.  That is why I think it should be defined = and=20 described in 11.8.  The native frame of the binding-specific = protocol that is carried in a CAPWAP packet is not really "transport=20 specific".  The transport is CAPWAP, not 802.11.  The = encapsulation=20 is 802.11.  I = think that the=20 entire content of 11.4 can be moved to=20 11.8.

Ok, will move the content of 11.4 to 11.8.

-Bob

Bob=20 O'Hara
Cisco Systems - WNBU

Phone:  +1 408 853=20 5513
Mobile: +1 408 218=20 = 4025

_____________________________________________________________= ____
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


------_=_NextPart_001_01C6851F.4D9E8DEC-- --===============1188222259== 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 --===============1188222259==--