From skitrip-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Apr 01 08:33:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPgEj-0000VC-8s for capwap-archive@lists.ietf.org; Sat, 01 Apr 2006 08:33:53 -0500 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPgEi-0000Ls-0U for capwap-archive@lists.ietf.org; Sat, 01 Apr 2006 08:33:53 -0500 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D376D4301DB for ; Sat, 1 Apr 2006 05:33:50 -0800 (PST) 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: Sat, 01 Apr 2006 05:31:20 -0800 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 Apr 03 15:31:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQUlR-0000UG-OZ for capwap-archive@lists.ietf.org; Mon, 03 Apr 2006 15:31:01 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQUlQ-0000sd-1b for capwap-archive@lists.ietf.org; Mon, 03 Apr 2006 15:31:01 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 203A0430077 for ; Mon, 3 Apr 2006 12:30:59 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 977AD430067 for ; Mon, 3 Apr 2006 12:30:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7C410144801B for ; Mon, 3 Apr 2006 12:30:22 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.196]) by hermes.tigertech.net (Postfix) with ESMTP id 35EC4144801C for ; Mon, 3 Apr 2006 12:30:18 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so839427wxd for ; Mon, 03 Apr 2006 12:30:18 -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=YopKvvI/6YrUso331dRUtzUpKtSehnRjacV1q/JTDYEOjRt9bp245fgUt1vb9QATZBaD1vDEO6fezCnBXTG7Sm2Bw1h4yEAuDJ6UpJTu63CDabnmY00LP490v+omX6rGO929Ykxqzgmn6gdAu53/GS6olt4Dzfb2k2j4dRwHkv4= Received: by 10.70.48.1 with SMTP id v1mr2425345wxv; Mon, 03 Apr 2006 12:30:16 -0700 (PDT) Received: by 10.70.133.1 with HTTP; Mon, 3 Apr 2006 12:30:15 -0700 (PDT) Message-ID: <5bfe7a820604031230j7d2d63f5jda26f3eba3d37c4e@mail.gmail.com> Date: Mon, 3 Apr 2006 12:30:15 -0700 From: "Dorothy Stanley" To: "Bob O'Hara (boohara)" Subject: Re: [Capwap] Editorial question - Location of Message elements In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC015249D0@xmb-sjc-237.amer.cisco.com> MIME-Version: 1.0 References: <17B8C6DE4E228348B4939BDA6B05A9DC015249D0@xmb-sjc-237.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.6 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_50_60, HTML_MESSAGE, RCVD_BY_IP 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="===============1789792641==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 4fc59e88b356924367ae169e6a06365d --===============1789792641== Content-Type: multipart/alternative; boundary="----=_Part_15006_2922184.1144092615720" ------=_Part_15006_2922184.1144092615720 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Bob, Here is a list of the message elements that would be in the new section, (tentatively 4.4) and their current location. These are all base protocol message elements. The 802.11 specific message elements would stay in section 11. Dorothy Vendor Specific 4.3.2.1.1 Discovery Type 5.1.1 WTP Descriptor 5.1.2 WTP Radio Information 5.1.3 WTP MAC Type 5.1.4 WTP Frame Type 5.1.5 AC Address 5.2.1 AC Descriptor 5.2.2 AC Name 5.2.3 WTP Manager Control IPv4 Address 5.2.4 WTP Manager Control IPv6 Address 5.2.5 Administrative State 7.2.1 - Suggest modifying the name to the Radio Administrative State, to provide a more specific name WTP Board Data 7.2.4 Statistics Timer 7.2.5 WTP Static IP Address Information 7.2.6 WTP Re-boot Statistics Decryption Error Report Period 7.3.1 Change State 7.3.2 CAPWAP Timers 7.3.3 AC IPv4 List 7.3.4 AC IPv6 List 7.3.5 WTP Fallback 7.3.6 Idle Timeout 7.3.7 WTP Name 7.4.1 Location Data 7.4.5 Add MAC ALC Entry 7.4.9 Delete MAC ACL Entry 7.4.10 Add Static MAC ACL Entry 7.4.11 Delete Static MAC ACL Entry 7.4.12 Timestamp 7.4.17 - Suggest modifying the name to AC Timestamp, to provide a more specific name Result Code 7.5.1 - Is this only the "Configuration Update Result Code" or used more generally? Image Download 8.1.1 Image Data 8.1.2 Decryption Error Report 8.5.1 Duplicate IPv4 Address 8.5.2 Duplicate IPv6 Address 8.5.3 Data Transfer Mode 8.71 Data Transfer Data 8.7.2 Add Mobile 9.1.1 - Suggest modifying the name to "Add Mobile Station", to align with the descriptive text Delete Mobile 9.1.2 - Suggest modifying the name to "Delete Mobile Station" to align with the descriptive text On 3/27/06, Bob O'Hara (boohara) wrote: > > Well, we shouldn't consolidate ALL the message elements in one section. > I think that the elements used in the base protocol should be consolidate= d > in one section and those for the 802.11 binding in another. > > -Bob > > > > ------------------------------ > *From:* Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > *Sent:* Monday, March 27, 2006 4:52 PM > *To:* Dorothy Stanley; capwap@frascone.com > *Subject:* RE: [Capwap] Editorial question - Location of Message elements > > Dorothy, > > > > I think structuring all the message elements in a single section is very > useful. It helps make reading easier. > > > > Saravanan > > > > > > > > > ------------------------------ > > *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] > *Sent:* Thursday, March 23, 2006 1:41 AM > *To:* capwap@frascone.com > *Subject:* [Capwap] Editorial question - Location of Message elements > > > > All, > > In the -00 draft, the CAPWAP message elements are defined in multiple > sections, specifically the section defining > the first message in which a particular message element appears. > > I propose to collect all of the message element definitions in a single > section, so that there is > one place where they are all defined, and can easily be found. > > Is there any objection to proceeding with this editorial change? > > At the CAPWAP meeting on Monday, there seemed to be support for this > approach, with > Pat noting that he LWAPP draft at one point was organized this way, but > was then changed, due to > comments received. So, comments please on this proposed editorial change > to the CAPWAP draft specification. > > Thanks, > > Dorothy > > ----------------- > Dorothy Stanley > Aruba Networks > 630-363-1389 (cell) 630-836-9734 (office) > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_15006_2922184.1144092615720 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Bob,

Here is a list of the message elements that would be in the new section, (t= entatively 4.4) and their current location.
These are all base protocol message elements.  The 802.11 specific mes= sage elements would stay in section 11.

Dorothy

Vendor Specific 4.3.2.1.1
Discovery Type 5.1.1
WTP Descriptor 5.1.2
WTP Radio Information 5.1.3
WTP MAC Type 5.1.4
WTP Frame Type 5.1.5
AC Address 5.2.1
AC Descriptor 5.2.2
AC Name 5.2.3
WTP Manager Control IPv4 Address 5.2.4
WTP Manager Control IPv6 Address 5.2.5
Administrative State 7.2.1 - Suggest modifying the name to the Radio Admini= strative State, to provide a more specific name
WTP Board Data 7.2.4
Statistics Timer 7.2.5
WTP Static IP Address Information 7.2.6
WTP Re-boot Statistics
Decryption Error Report Period 7.3.1
Change State 7.3.2
CAPWAP Timers 7.3.3
AC IPv4 List 7.3.4
AC IPv6 List 7.3.5
WTP Fallback 7.3.6
Idle Timeout 7.3.7
WTP Name 7.4.1
Location Data 7.4.5
Add MAC ALC Entry 7.4.9
Delete MAC ACL Entry 7.4.10
Add Static MAC ACL Entry 7.4.11
Delete Static MAC ACL Entry 7.4.12
Timestamp 7.4.17 - Suggest modifying the name to AC Timestamp, to provide a= more specific name
Result Code 7.5.1 - Is this only the "Configuration Update Result Code= " or used more generally?
Image Download 8.1.1
Image Data 8.1.2
Decryption Error Report 8.5.1
Duplicate IPv4 Address 8.5.2
Duplicate IPv6 Address 8.5.3
Data Transfer Mode 8.71
Data Transfer Data 8.7.2
Add Mobile 9.1.1 - Suggest modifying the name to "Add Mobile Station&q= uot;, to align with the descriptive text
Delete Mobile 9.1.2 - Suggest modifying the name to "Delete Mobile Sta= tion" to align with the descriptive text


On 3/27/06, Bob O'Hara (boohara) <b= oohara@cisco.com > wrote:
Well, we shouldn't consolidate ALL the message elements in=20 one section.  I think that the elements used in the base protocol shou= ld be=20 consolidated in one section and those for the 802.11 binding in=20 another.

 -Bob
 

 

From: Saravanan Govindan=20 [mailto:Saravanan.Go= vindan@sg.panasonic.com]
Sent: Monday, March 27,=20 2006 4:52 PM
To: Dorothy Stanley;=20 capwap@frascone.com
Subjec= t: RE: [Capwap] Editorial question -=20 Location of Message elements

Dorothy,

 

I think structuring all the message=20 elements in a single section is very useful. It helps make reading easier.= =20

 

Saravanan

 

 

 

 

From: Do= rothy=20 Stanley [mailto:dstanley1389@gmai= l.com]
Sent: Thurs= day, March 23, 2006 1:41=20 AM
To:=20 capwap@frascone.com
Subject:=20 [Capwap] Editorial question - Location of Message=20 elements

 

All,

In the=20 -00 draft, the CAPWAP message elements are defined in multiple sections,=20 specifically the section defining
the first message in which a particula= r=20 message element appears.

I propose to collect=20 all of the message element definitions in a single section, so that there= =20 is
one place where they are all defined, and can easily be=20 found.

Is there any=20 objection to proceeding with this editorial change?

At the CAPWAP=20 meeting on Monday, there seemed to be support for this approach, with
Pa= t=20 noting that he LWAPP draft at one point was organized this way, but was the= n=20 changed, due to
comments received. So, comments please on this proposed= =20 editorial change to the CAPWAP  draft=20 specification.

Thanks,

Dorothy

-----------------
Dorothy Stanley
Aruba Netwo= rks
630-363-1389 (cell) 630-836-9734=20 (office)


__________________________________________________________= _______
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_15006_2922184.1144092615720-- --===============1789792641== 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 --===============1789792641==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Apr 03 16:23:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQVa6-000053-34 for capwap-archive@lists.ietf.org; Mon, 03 Apr 2006 16:23:22 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQVa4-0003cZ-D3 for capwap-archive@lists.ietf.org; Mon, 03 Apr 2006 16:23:22 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C816E43010F for ; Mon, 3 Apr 2006 13:23:19 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1680A430077 for ; Mon, 3 Apr 2006 13:22:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0088A144800D for ; Mon, 3 Apr 2006 13:22:57 -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 633AB1448018 for ; Mon, 3 Apr 2006 13:22:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=ZelFtKqva9H2/+tv5XYdY8zzVTKZLXaEhuF8Uu0Hb3ci5p24Ovte8wZH7RZfgn1I; h=Received: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.38] (helo=elwamui-lapwing.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FQVZe-0004vd-Hk for capwap@frascone.com; Mon, 03 Apr 2006 16:22:54 -0400 Message-ID: <17204644.1144095774576.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> Date: Mon, 3 Apr 2006 13:22:54 -0700 (GMT-07:00) From: "Scott G. Kelly" To: capwap Subject: Re: [Capwap] PFS: requirement or not? 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: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710f053abc72142332e131a2050ee085f7c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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: 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: 31247fb3be228bb596db9127becad0bc Reply below.. > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Friday, March 31, 2006 2:24 PM > To: Pat Calhoun (pacalhou) > Cc: capwap > Subject: Re: [Capwap] PFS: requirement or not? > > In general, transient DTLS keys for past sessions would not be saved > on the WTP. Without PFS, if an attacker had saved the DTLS handshake > from the previous session, they could use the compromised long-term > key to derive past session keys, and therefore compromise past sessions. > Therefore, in general, PFS is a good thing. > > HOWEVER, what exactly are we trying to protect? The whole point of > DTLS is to prevent an attacker from compromising control traffic. My > question: What good is old control traffic to an attacker? The only > thing of value contained within is the PTK for 802.11i sessions that > are no longer active. Thus, my conclusion is that PFS is not a > requirement. > > I see no reason not to have PFS ciphersuites defined, but I don't > think they should be mandatory to implement. Let's go back to how this all started. This sentence appeared, offset from other text, in one of the later lwapp drafts: " It is important to note that Perfect Forward Secrecy is not a requirement for the LWAPP protocol." I've never agreed with this, and with it standing off by itself in the text, it's sort of like a "kick me" sign. Anyway, that got me to thinking, and here we are. This boils down to your point of view. At the risk of being trite, I might say it boils down to your "threat model". Unfortunately, that term has been so abused (these days it's little more than secu-babble) that it's hard to get people to take it seriously. Still, that's what we need to discuss. People who aren't security geeks might be more comfortable with "use cases and associated vulnerabilities/threats". In any event, let's talk about that. Implicit in the Charles' argument above is the assumption that the there is nothing of value to be had if old conversations can be decrypted, which sort of suggests the view that the 802.11i keys are little more than a wlan access control mechanism, sort of like a one-time-password . Also, it ignores the case where the credential may be compromised without detection (crack the AP open, get the key, close it back up and place it back into operation), which allows for real-time decryption, as well as injection and active MiM attacks over the wireless link. So, back to the threats: if you assume that there are only two deployment models, i.e. hotspot and closed enterprise networks with reasonably good physical security, then you might assume there is no real threat here. [Actually, there are many more than those two deployment models, and I'd love to chat about them, but I don't feel like emailing a book]. Still, even in the hotspot case, it turns out that this assumption would be incorrect. You have to remember: we are dividing the old 802.11 AP functionality in two, and then exposing the link in between - this opens up many new possibilities for the attacker, especially when this link runs over hostile territory. We discussed this in the capwap wg meeting and also in our saag presenation: capwap is being used to indirectly extend the trust bootstrapping process - it MUST NOT degrade the security of this arrangement. So, on to the beef: in the discussion below I'm going to be very concise, but I want the chairs, ADs, and working group to take note of the complexity involved in properly analyzing this stuff. This is why the security considerations of the capwap-00 draft was only a placeholder - we need a stand-alone document dedicated to this sort of analysis and elucidation of security requirements. I've been trying to make that point behind the scenes, but I'm not sure I've been very effective thus far. Hopefully this will drive the point home. Just for now, let's forget about all the various wlan deployment models, save just this one: the remote AP. In this model, APs are deployed in one place, and managed from somewhere else. I know of at least two vendors who are selling this model today. The management may be handled by some sort of MSP (with the AC in the cloud), or from a central headquarters AC. Typically, these will be local MAC configurations: security boundary ++========================++ || || || +---------------------++ || | local network || /^^^^^^^^^^^^^^\ || | | || ( ) +-----+ || | [user1]---| +----+ || ( [hostile hop] ) | | || | +-+ +--++----( )----+ | || | | | WTP| | AC | || | [srvr1]---+ | +--++----( )----+ | || | | +----+ || ( ) | | || | ^ || \vvvvvvvvvvvvvvvv/ +-----+ || +--------|------------++ || | || ++========================++ \ \ \--- soft and chewy I'm hoping webmail didn't mangle that too badly - if so, I'll post a follow up from a different email account. Pay special attention to the security boundary. For simplicity, let's talk about a branch office, with the WTPs being managed by headquarters, but note: the same sort of issues apply anytime capwap crosses a security boundary, and the user and WTP are together on one side of it. Can you see the issue here? Put simply, it is that confidential data is flowing over the 802.11 link, data which could have value to an attacker, and which should not be visible outside of the secuirty boundary. That data may be valuable long after it was transmitted, or it may have value only for seconds or moments after transmission. Still, the "old" 802.11i keys could very wll be worth a *lot* to an adversary. And in the case where the key is compromised without detection, the attacker may have access in real-time. Doh! Okay, now let's zoom out a bit, and come back in on a hotspot. I've heard lots of arguments around this scenario saying "if they can see the capwap, they can see the user's internet traffic and/or do a MiM from the other side of the AP, so why attack the credential?". Why, indeed. Note that being able to *see* the capwap (and Internet data) is not the same as being able to do a MiM - these are two very different capabilities. However, if you can see the capwap and you have the credential, an untraceable MiM attack over the WLAN is now possible. There certainly are more threats and vulnerabilities we could look at (actually, quite a few more), but in the interest of keeping this email manageable, I will stop here for now. Like I said, I think a document should be dedicated to this, and email is a difficult medium for such complexity. So, what's it take to defend against these particular threats? Turns out PFS goes a long way, and at very little cost to us. If we add PFS, an attacker can no longer simply sniff/record the capwap link to derive the session keys. Now, simply compromising the PSK is not enough. Instead, the attacker has to mount a successful MiM attack during the capwap key exchange, which is *significantly* more difficult And what does this added protection cost us? Very little - basically, a Diffie-Hellman exchange during session establishment. Assuming the gear is stable and we're using strong crypto for the capwap session, this should be relatively infrequent. We could say "use PFS in this scenario, and that scenario, ... oh yeah, and when this happens too", or we could just say "preshared key usage requires PFS". Operationally, the latter is much simpler, and much more likely to be correctly implemented. Those of you who watched the design and deployment of IPsec might agree that simpler is almost always better, and this is why I vote for PFS-only preshared keys. 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 Apr 03 17:44:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQWqt-0008Ok-FE for capwap-archive@lists.ietf.org; Mon, 03 Apr 2006 17:44:47 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQWqr-0006uE-Pm for capwap-archive@lists.ietf.org; Mon, 03 Apr 2006 17:44:47 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E6FCC4300ED for ; Mon, 3 Apr 2006 14:44:44 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 754F843006D for ; Mon, 3 Apr 2006 14:44:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 60460144800E for ; Mon, 3 Apr 2006 14:44:20 -0700 (PDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by hermes.tigertech.net (Postfix) with ESMTP id 2C68F1448017 for ; Mon, 3 Apr 2006 14:44:17 -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 k33Li32u017508; Mon, 3 Apr 2006 17:44:12 -0400 (EDT) Date: Mon, 3 Apr 2006 17:44:03 -0400 (EDT) From: "T. Charles Clancy" To: "Scott G. Kelly" Subject: Re: [Capwap] PFS: requirement or not? In-Reply-To: <17204644.1144095774576.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> Message-ID: References: <17204644.1144095774576.JavaMail.root@elwamui-lapwing.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: c83ccb5cc10e751496398f1233ca9c3a Some thoughts... I don't see how PFS will help us protect data. All data has to go through the AC (at least that's my understanding), so unless the CAPWAP data channel is protected, all data is vulnerable to compromise. Using a DTLS-protected data channel or terminating 802.11i at the AC will solve these problems, not PFS. Thus, IMHO, old CAPWAP traffic is not useful to an attacker, assuming the proper caveats. On the other hand, Scott does bring up a good point. PFS will force an attacker who has already compromised a CAPWAP credential to be active rather than passive when launching attacks against future sessions. Of course in order to have keys equivalently strong to AES-CCM-128, you'll need to use 3072-bit DH. The complexity of that is not something to sneeze at, especially for a super-cheap, light-weight AP. [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] On Mon, 3 Apr 2006, Scott G. Kelly wrote: > Reply below.. > >> -----Original Message----- >> From: Charles Clancy [mailto:clancy@cs.umd.edu] >> Sent: Friday, March 31, 2006 2:24 PM >> To: Pat Calhoun (pacalhou) >> Cc: capwap >> Subject: Re: [Capwap] PFS: requirement or not? >> >> In general, transient DTLS keys for past sessions would not be saved >> on the WTP. Without PFS, if an attacker had saved the DTLS handshake >> from the previous session, they could use the compromised long-term >> key to derive past session keys, and therefore compromise past sessions. >> Therefore, in general, PFS is a good thing. >> >> HOWEVER, what exactly are we trying to protect? The whole point of >> DTLS is to prevent an attacker from compromising control traffic. My >> question: What good is old control traffic to an attacker? The only >> thing of value contained within is the PTK for 802.11i sessions that >> are no longer active. Thus, my conclusion is that PFS is not a >> requirement. >> >> I see no reason not to have PFS ciphersuites defined, but I don't >> think they should be mandatory to implement. > > Let's go back to how this all started. This sentence appeared, offset from other text, in one of the later lwapp drafts: > > " It is important to note that Perfect Forward Secrecy is not a requirement for the LWAPP protocol." > > I've never agreed with this, and with it standing off by itself in the text, it's sort of like a "kick me" sign. Anyway, that got me to thinking, and here we are. > > This boils down to your point of view. At the risk of being trite, I might say it boils down to your "threat model". Unfortunately, that term has been so abused (these days it's little more than secu-babble) that it's hard to get people to take it seriously. Still, that's what we need to discuss. People who aren't security geeks might be more comfortable with "use cases and associated vulnerabilities/threats". In any event, let's talk about that. > > Implicit in the Charles' argument above is the assumption that the there is nothing of value to be had if old conversations can be decrypted, which sort of suggests the view that the 802.11i keys are little more than a wlan access control mechanism, sort of like a one-time-password . Also, it ignores the case where the credential may be compromised without detection (crack the AP open, get the key, close it back up and place it back into operation), which allows for real-time decryption, as well as injection and active MiM attacks over the wireless link. > > So, back to the threats: if you assume that there are only two deployment models, i.e. hotspot and closed enterprise networks with reasonably good physical security, then you might assume there is no real threat here. [Actually, there are many more than those two deployment models, and I'd love to chat about them, but I don't feel like emailing a book]. Still, even in the hotspot case, it turns out that this assumption would be incorrect. You have to remember: we are dividing the old 802.11 AP functionality in two, and then exposing the link in between - this opens up many new possibilities for the attacker, especially when this link runs over hostile territory. We discussed this in the capwap wg meeting and also in our saag presenation: capwap is being used to indirectly extend the trust bootstrapping process - it MUST NOT degrade the security of this arrangement. > > > So, on to the beef: in the discussion below I'm going to be very concise, but I want the chairs, ADs, and working group to take note of the complexity involved in properly analyzing this stuff. This is why the security considerations of the capwap-00 draft was only a placeholder - we need a stand-alone document dedicated to this sort of analysis and elucidation of security requirements. I've been trying to make that point behind the scenes, but I'm not sure I've been very effective thus far. Hopefully this will drive the point home. > > Just for now, let's forget about all the various wlan deployment models, save just this one: the remote AP. In this model, APs are deployed in one place, and managed from somewhere else. I know of at least two vendors who are selling this model today. The management may be handled by some sort of MSP (with the AC in the cloud), or from a central headquarters AC. Typically, these will be local MAC configurations: > > > security > boundary > ++========================++ > || || > || +---------------------++ > || | local network || /^^^^^^^^^^^^^^\ > || | | || ( ) +-----+ > || | [user1]---| +----+ || ( [hostile hop] ) | | > || | +-+ +--++----( )----+ | > || | | | WTP| | AC | > || | [srvr1]---+ | +--++----( )----+ | > || | | +----+ || ( ) | | > || | ^ || \vvvvvvvvvvvvvvvv/ +-----+ > || +--------|------------++ > || | || > ++========================++ > \ > \ > \--- soft and chewy > > > I'm hoping webmail didn't mangle that too badly - if so, I'll post a follow up from a different email account. Pay special attention to the security boundary. For simplicity, let's talk about a branch office, with the WTPs being managed by headquarters, but note: the same sort of issues apply anytime capwap crosses a security boundary, and the user and WTP are together on one side of it. > > Can you see the issue here? Put simply, it is that confidential data is flowing over the 802.11 link, data which could have value to an attacker, and which should not be visible outside of the secuirty boundary. That data may be valuable long after it was transmitted, or it may have value only for seconds or moments after transmission. Still, the "old" 802.11i keys could very wll be worth a *lot* to an adversary. And in the case where the key is compromised without detection, the attacker may have access in real-time. Doh! > > Okay, now let's zoom out a bit, and come back in on a hotspot. I've heard lots of arguments around this scenario saying "if they can see the capwap, they can see the user's internet traffic and/or do a MiM from the other side of the AP, so why attack the credential?". Why, indeed. Note that being able to *see* the capwap (and Internet data) is not the same as being able to do a MiM - these are two very different capabilities. However, if you can see the capwap and you have the credential, an untraceable MiM attack over the WLAN is now possible. > > There certainly are more threats and vulnerabilities we could look at (actually, quite a few more), but in the interest of keeping this email manageable, I will stop here for now. Like I said, I think a document should be dedicated to this, and email is a difficult medium for such complexity. > > So, what's it take to defend against these particular threats? Turns out PFS goes a long way, and at very little cost to us. If we add PFS, an attacker can no longer simply sniff/record the capwap link to derive the session keys. Now, simply compromising the PSK is not enough. Instead, the attacker has to mount a successful MiM attack during the capwap key exchange, which is *significantly* more difficult And what does this added protection cost us? Very little - basically, a Diffie-Hellman exchange during session establishment. Assuming the gear is stable and we're using strong crypto for the capwap session, this should be relatively infrequent. > > We could say "use PFS in this scenario, and that scenario, ... oh yeah, and when this happens too", or we could just say "preshared key usage requires PFS". Operationally, the latter is much simpler, and much more likely to be correctly implemented. Those of you who watched the design and deployment of IPsec might agree that simpler is almost always better, and this is why I vote for PFS-only preshared keys. > > 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 Apr 03 18:52:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQXuo-0007my-If for capwap-archive@lists.ietf.org; Mon, 03 Apr 2006 18:52:54 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQXun-000294-3F for capwap-archive@lists.ietf.org; Mon, 03 Apr 2006 18:52:54 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4DE3F4300D7 for ; Mon, 3 Apr 2006 15:52:52 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id ADA1B43006D for ; Mon, 3 Apr 2006 15:52:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8DEAD1448015 for ; Mon, 3 Apr 2006 15:52:30 -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 7E4AC1448019 for ; Mon, 3 Apr 2006 15:52:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=lD0Q8eeuB2w3fzK6VT1VcC6S5ff024vdYDaYXqN+wUVW6VcdwoTFpsaBbvv40DEt; h=Received: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.38] (helo=elwamui-lapwing.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FQXu8-0000a2-Qd; Mon, 03 Apr 2006 18:52:12 -0400 Message-ID: <9818156.1144104732825.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> Date: Mon, 3 Apr 2006 18:52:12 -0400 (EDT) From: "Scott G. Kelly" To: "T. Charles Clancy" Subject: Re: [Capwap] PFS: requirement or not? 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: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710028cc0cf22b64f8b9ba1e187554a4e7e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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 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: 50a516d93fd399dc60588708fd9a3002 Hi Charles, -----Original Message----- >From: "T. Charles Clancy" >Sent: Apr 3, 2006 2:44 PM >To: "Scott G. Kelly" >Cc: capwap >Subject: Re: [Capwap] PFS: requirement or not? > >Some thoughts... > >I don't see how PFS will help us protect data. All data has to go through >the AC (at least that's my understanding), so unless the CAPWAP data >channel is protected, all data is vulnerable to compromise. I wondered if you that's what you were thinking. This assumption is wrong - all data does *not* have to go through the AC, and especially not in many remote AP scenarios. What my diagram may not have illustrated so clearly is that in some local MAC scenarios, much of the wlan traffic may be destined for local (wired) servers/hosts. In general, this is described in the architecture taxonomy RFC as "Local MAC", and it's commonly deployed today. There are also hybrids possible. And the scenario I described is only one of many that we need to consider. There is far more to be concerned with than initially meets the eye. > Using a >DTLS-protected data channel or terminating 802.11i at the AC will solve >these problems, not PFS. Thus, IMHO, old CAPWAP traffic is not useful to >an attacker, assuming the proper caveats. Yes, as it turns out, data channel security will solve many problems. For example, terminating 802.11i at the AC largely overcomes the PFS, but it is simply not an option in many local MAC scenarios. In thinking about these problems over the weekend, I arrived at the conclusion that data channel security (of some sort) is a hard requirement for some scenarios - but that's another discussion, one I'm sure will be at least as much fun as this one :-) But again, let me emphasize this: since there may be confidential (read: high value) traffic on the local segment which is protected by 802.11i and does not traverse the link between WTP and AC (i.e. it is not supposed to be visible outside of the security boundary in my ascii drawing), we need to make sure someone can't record it and crack it later (unless they brute force the AES). PFS helps to mitigates this threat. >On the other hand, Scott does bring up a good point. PFS will force an >attacker who has already compromised a CAPWAP credential to be active >rather than passive when launching attacks against future sessions. > >Of course in order to have keys equivalently strong to AES-CCM-128, you'll >need to use 3072-bit DH. The complexity of that is not something to >sneeze at, especially for a super-cheap, light-weight AP. This is a very reasonable point, and we went through similar pain in IPsec when we added AES crypto suites. I think that in cases where you actually *need* 128 bits of security, you either won't be using preshared keys, or you'll have beefy-enough hardware to deal with this. A 200Mhz PPC (not a high end processor by today's measures, but very common in APs) can do the DH in a few hundred millisecs or less. If your hardware doesn't reboot every day, you won't have to do capwap session establishment very frequently, and one 128-bit key (assuming aes-ccm) should last you for 2^64 or so packets, (which should be a *very* long time if you're only encrypting control traffic). However, there are two other possibilities: first, use smaller moduli. If you only need, say, 80 bits of strength (suffiicient in many scenarios), you can use much smaller moduli/exponents. The second option is to use elliptic curves instead. There currently are no ECC PSK suites defined for (D)TLS, and I'm not sure what the IPR status is at this point, but I'll look into this a bit. Honestly, though, I don't think that people should be cheaping out on security-critical hardware. If 3072-bit DH is the price of admission, then it may be best just suck it up and deal with it... 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 Apr 03 20:04:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQZ1w-0000EH-5P for capwap-archive@lists.ietf.org; Mon, 03 Apr 2006 20:04:20 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQZ1u-0005Td-Nh for capwap-archive@lists.ietf.org; Mon, 03 Apr 2006 20:04:20 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1DC474300DA for ; Mon, 3 Apr 2006 17:04:18 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2AB3F4300C5 for ; Mon, 3 Apr 2006 17:03:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 182DF1448016 for ; Mon, 3 Apr 2006 17:03:57 -0700 (PDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by hermes.tigertech.net (Postfix) with ESMTP id 6B1251448015 for ; Mon, 3 Apr 2006 17:03:54 -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 k3403h2u018734; Mon, 3 Apr 2006 20:03:43 -0400 (EDT) Date: Mon, 3 Apr 2006 20:03:43 -0400 (EDT) From: "T. Charles Clancy" To: "Scott G. Kelly" Subject: Re: [Capwap] PFS: requirement or not? In-Reply-To: <9818156.1144104732825.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> Message-ID: References: <9818156.1144104732825.JavaMail.root@elwamui-lapwing.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: 52e1467c2184c31006318542db5614d5 > I wondered if you that's what you were thinking. This assumption is > wrong - all data does *not* have to go through the AC, and especially > not in many remote AP scenarios. Ah, I see. I guess I've been so focused on the security part, and how to multiplex DTLS and data channels, etc, I lost sight of the Local MAC model. > Yes, as it turns out, data channel security will solve many problems. > For example, terminating 802.11i at the AC largely overcomes the PFS, > but it is simply not an option in many local MAC scenarios. Implementing crypto on the data channels means you have something new in your security model that you need to protect, and may further substantiate the case for PFS. > Honestly, though, I don't think that people should be cheaping out on > security-critical hardware. If 3072-bit DH is the price of admission, > then it may be best just suck it up and deal with it... It might also be good to look at which DTLS ciphersuites would be NIST FIPS 140-2 certifiable. I agree that PFS is a good thing. I guess I'm just not entirely sold on the idea of it being mandatory. From a security perspective, we have bigger problems. For example, avoiding WEP and low-entropy RADIUS shared secrets is only RECOMMENDED. I guess CAPWAP has less control over those though, and we shouldn't let our protocol be the weak link. [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Apr 03 23:44:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQcSz-0003nt-S2 for capwap-archive@lists.ietf.org; Mon, 03 Apr 2006 23:44:29 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQcSy-0006Oh-D1 for capwap-archive@lists.ietf.org; Mon, 03 Apr 2006 23:44:29 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8CFD64300B6 for ; Mon, 3 Apr 2006 20:44:27 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id AB27443006D for ; Mon, 3 Apr 2006 20:44:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9EBE7398151 for ; Mon, 3 Apr 2006 20:44:06 -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 E6B7A3980E3 for ; Mon, 3 Apr 2006 20:44:04 -0700 (PDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 03 Apr 2006 20:44:05 -0700 X-IronPort-AV: i="4.03,160,1141632000"; d="scan'208"; a="1791399600:sNHT35946986" 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 k343i41j000916 for ; Mon, 3 Apr 2006 20:44:04 -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, 3 Apr 2006 20:44:03 -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, 3 Apr 2006 20:44:03 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201ABF44C@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Text for Issue 59 Thread-Index: AcZXmgQJTA+c2/5gSC+TGgfAJS3RZw== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 04 Apr 2006 03:44:03.0861 (UTC) FILETIME=[047E6450:01C6579A] 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] Proposed Text for Issue 59 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: 73734d43604d52d23b3eba644a169745 =20 All, The submitter of the issue was correct. as it turns out, the protocol was broken since there was no way to enable a mode after the discovery process had occurred. This change allows a WTP to be enable to use a specific mode of operation on a per WLAN basis. Comments welcomed. 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 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 Capability | WLAN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encryption Policy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Index | Shared Key | WPA Data Len |WPA IE Data ...| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSN Data Len |RSN IE Data ...| WME Data Len |WME IE Data ...| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 11e Data Len |11e IE Data ...| QoS | Auth Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Mode | Tunnel Mode | Suppress SSID | SSID ... <=3D=3D=3D NEW FIELDS +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [...] MAC Mode: This field specifies whether the WTP should support the WLAN in Local or Split MAC modes. Note that the AC MUST NOT request a mode of operation that was not advertised by the WTP during the discovery process (see section Section 5.1.4). The following values are supported: 0 - Local-MAC: Service for the WLAN is to be provided in Local MAC mode. 1 - Split-MAC: Service for the WLAN is to be provided in Split MAC mode. Tunnel Mode: This field specifies the tunneling type to be used for all stations associated with the WLAN. Note that the AC MUST NOT request a mode of operation that was not advertised by the WTP during the discovery process (see section Section 5.1.5). The following values are supported: 0 - Local Bridging: All user traffic is to be locally bridged. 1 - 802.3 Tunnel: All user traffic is to be tunneled to the AC in 802.3 format (see section Section 4.2). 2 - 802.11 Bridging: All user traffic is to be tunneled to the AC in 802.11 format. [...] 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 Apr 04 00:00:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQcih-0003WR-Hd for capwap-archive@lists.ietf.org; Tue, 04 Apr 2006 00:00:43 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQcTs-0006Q6-Jo for capwap-archive@lists.ietf.org; Mon, 03 Apr 2006 23:45:27 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 435E04300B6 for ; Mon, 3 Apr 2006 20:45:24 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 17A5F43007C for ; Mon, 3 Apr 2006 20:44:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0AE513980E3 for ; Mon, 3 Apr 2006 20:44:57 -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 427793981B0 for ; Mon, 3 Apr 2006 20:44:54 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-2.cisco.com with ESMTP; 03 Apr 2006 20:44:53 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k343irGv012558 for ; Mon, 3 Apr 2006 20:44:53 -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, 3 Apr 2006 20:44: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 Date: Mon, 3 Apr 2006 20:44:52 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201ABF44E@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Text for Issue 53 Thread-Index: AcZXmiGYKUrUeU/XT1OcZaCvsWKBVg== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 04 Apr 2006 03:44:53.0690 (UTC) FILETIME=[2231B1A0:01C6579A] 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] Proposed Text for Issue 53 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: 6e922792024732fb1bb6f346e63517e4 Here is my proposed text for Issue 53, which is the addition of a Data Rate In the CAPWAP header. Please let me know if you have any comments. =20 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | <=3D=3D=3D CHANGED!!! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ [...] 4.1.8. Reserved This 32 bit field is reserved and may be used by a binding specific extension. Refer to the transport portion of the binding for a specific wireless technology for the definition of this field. [...] 11.3.2. CAPWAP Header Reserved field 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 5.5Mbps would be set to 55, while 11Mbps would be set to 110. 11.3.2.2. Destination WLANs The Destination WLAN field is used to specify the target WLANs for a given frame, and is only used with broadcast and multicast frames. This field allows the AC to transmit a single broadcast or multicast frame to the WTP, and allows the WTP to perform the necessary frame replication services. The field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WLAN: This bit field indicates the WLAN ID (see section Section 11.8.1.1) which the WTP will transmit the associated frame on. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be enabled. Note this field is to be set to zero for unicast packets and is unused if the WTP is not providing encryption services. Reserved: This field MUST be set to zero. =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 Apr 04 14:54:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQqg2-0001v2-OX for capwap-archive@lists.ietf.org; Tue, 04 Apr 2006 14:54:54 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQqg0-0003op-OZ for capwap-archive@lists.ietf.org; Tue, 04 Apr 2006 14:54:54 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id F36504300BD for ; Tue, 4 Apr 2006 11:54:51 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id CF84743005F for ; Tue, 4 Apr 2006 11:54:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BB1321448014 for ; Tue, 4 Apr 2006 11:54:12 -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 CE8AB1448010 for ; Tue, 4 Apr 2006 11:54:10 -0700 (PDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 04 Apr 2006 11:54:11 -0700 X-IronPort-AV: i="4.03,164,1141632000"; d="scan'208,217"; a="266562732:sNHT127828640" 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 k34Is9Yg025288; Tue, 4 Apr 2006 11:54:09 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Apr 2006 11:54:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] Editorial question - Location of Message elements Date: Tue, 4 Apr 2006 11:54:08 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC015D5A1E@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Editorial question - Location of Message elements Thread-Index: AcZXVRvC7FE+klTCRnqfyr8G+WPjjAAsltYA From: "Bob O'Hara (boohara)" To: "Dorothy Stanley" X-OriginalArrivalTime: 04 Apr 2006 18:54:08.0858 (UTC) FILETIME=[279BB3A0:01C65819] X-Virus-Scanned: by amavisd-new-20030616-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: 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="===============1063758429==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: fbe0995f04cc21309ef8614a2838e306 This is a multi-part message in MIME format. --===============1063758429== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65819.2760CE6A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65819.2760CE6A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dorothy, =20 Thanks. this list of base message elements looks good to me. -Bob =20 =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Monday, April 03, 2006 12:30 PM To: Bob O'Hara (boohara) Cc: capwap@frascone.com Subject: Re: [Capwap] Editorial question - Location of Message elements Bob, Here is a list of the message elements that would be in the new section, (tentatively 4.4) and their current location. These are all base protocol message elements. The 802.11 specific message elements would stay in section 11. Dorothy Vendor Specific 4.3.2.1.1 Discovery Type 5.1.1 WTP Descriptor 5.1.2 WTP Radio Information 5.1.3 WTP MAC Type 5.1.4 WTP Frame Type 5.1.5 AC Address 5.2.1 AC Descriptor 5.2.2 AC Name 5.2.3 WTP Manager Control IPv4 Address 5.2.4 WTP Manager Control IPv6 Address 5.2.5 Administrative State 7.2.1 - Suggest modifying the name to the Radio Administrative State, to provide a more specific name WTP Board Data 7.2.4 Statistics Timer 7.2.5 WTP Static IP Address Information 7.2.6 WTP Re-boot Statistics Decryption Error Report Period 7.3.1 Change State 7.3.2 CAPWAP Timers 7.3.3 AC IPv4 List 7.3.4 AC IPv6 List 7.3.5 WTP Fallback 7.3.6 Idle Timeout 7.3.7 WTP Name 7.4.1 Location Data 7.4.5 Add MAC ALC Entry 7.4.9 Delete MAC ACL Entry 7.4.10 Add Static MAC ACL Entry 7.4.11 Delete Static MAC ACL Entry 7.4.12 Timestamp 7.4.17 - Suggest modifying the name to AC Timestamp, to provide a more specific name Result Code 7.5.1 - Is this only the "Configuration Update Result Code" or used more generally? Image Download 8.1.1 Image Data 8.1.2 Decryption Error Report 8.5.1 Duplicate IPv4 Address 8.5.2 Duplicate IPv6 Address 8.5.3 Data Transfer Mode 8.71 Data Transfer Data 8.7.2 Add Mobile 9.1.1 - Suggest modifying the name to "Add Mobile Station", to align with the descriptive text Delete Mobile 9.1.2 - Suggest modifying the name to "Delete Mobile Station" to align with the descriptive text On 3/27/06, Bob O'Hara (boohara) wrote:=20 =09 Well, we shouldn't consolidate ALL the message elements in one section. I think that the elements used in the base protocol should be consolidated in one section and those for the 802.11 binding in another. -Bob =20 =20 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Monday, March 27, 2006 4:52 PM To: Dorothy Stanley; capwap@frascone.com Subject: RE: [Capwap] Editorial question - Location of Message elements =09 =09 =09 Dorothy, =20 I think structuring all the message elements in a single section is very useful. It helps make reading easier.=20 =20 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Thursday, March 23, 2006 1:41 AM To: capwap@frascone.com Subject: [Capwap] Editorial question - Location of Message elements =20 All, =09 In the -00 draft, the CAPWAP message elements are defined in multiple sections, specifically the section defining the first message in which a particular message element appears. I propose to collect all of the message element definitions in a single section, so that there is one place where they are all defined, and can easily be found. Is there any objection to proceeding with this editorial change? At the CAPWAP meeting on Monday, there seemed to be support for this approach, with Pat noting that he LWAPP draft at one point was organized this way, but was then changed, due to=20 comments received. So, comments please on this proposed editorial change to the CAPWAP draft specification. Thanks, Dorothy ----------------- Dorothy Stanley Aruba Networks 630-363-1389 (cell) 630-836-9734 (office) =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 ------_=_NextPart_001_01C65819.2760CE6A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dorothy,
 
Thanks.  this list of base message = elements looks good=20 to me.

 -Bob
 

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Monday, April 03, 2006 = 12:30=20 PM
To: Bob O'Hara (boohara)
Cc:=20 capwap@frascone.com
Subject: Re: [Capwap] Editorial question - = Location of Message elements

Bob,

Here is a list of the message elements that would = be in=20 the new section, (tentatively 4.4) and their current location.
These = are all=20 base protocol message elements.  The 802.11 specific message = elements would=20 stay in section 11.

Dorothy

Vendor Specific = 4.3.2.1.1
Discovery=20 Type 5.1.1
WTP Descriptor 5.1.2
WTP Radio Information 5.1.3
WTP = MAC=20 Type 5.1.4
WTP Frame Type 5.1.5
AC Address 5.2.1
AC Descriptor=20 5.2.2
AC Name 5.2.3
WTP Manager Control IPv4 Address 5.2.4
WTP = Manager=20 Control IPv6 Address 5.2.5
Administrative State 7.2.1 - Suggest = modifying the=20 name to the Radio Administrative State, to provide a more specific = name
WTP=20 Board Data 7.2.4
Statistics Timer 7.2.5
WTP Static IP Address = Information=20 7.2.6
WTP Re-boot Statistics
Decryption Error Report Period=20 7.3.1
Change State 7.3.2
CAPWAP Timers 7.3.3
AC IPv4 List = 7.3.4
AC=20 IPv6 List 7.3.5
WTP Fallback 7.3.6
Idle Timeout 7.3.7
WTP Name=20 7.4.1
Location Data 7.4.5
Add MAC ALC Entry 7.4.9
Delete MAC = ACL Entry=20 7.4.10
Add Static MAC ACL Entry 7.4.11
Delete Static MAC ACL Entry = 7.4.12
Timestamp 7.4.17 - Suggest modifying the name to AC Timestamp, = to=20 provide a more specific name
Result Code 7.5.1 - Is this only the=20 "Configuration Update Result Code" or used more generally?
Image = Download=20 8.1.1
Image Data 8.1.2
Decryption Error Report 8.5.1
Duplicate = IPv4=20 Address 8.5.2
Duplicate IPv6 Address 8.5.3
Data Transfer Mode = 8.71
Data=20 Transfer Data 8.7.2
Add Mobile 9.1.1 - Suggest modifying the name to = "Add=20 Mobile Station", to align with the descriptive text
Delete Mobile = 9.1.2 -=20 Suggest modifying the name to "Delete Mobile Station" to align with the=20 descriptive text


On 3/27/06, Bob O'Hara=20 (boohara) <boohara@cisco.com = >=20 wrote:
Well, we=20 shouldn't consolidate ALL the message elements in one section.  I = think=20 that the elements used in the base protocol should be consolidated in = one=20 section and those for the 802.11 binding in=20 another.

 -Bob
 

 

From: Saravanan Govindan = [mailto:Saravanan.Govindan@sg.panasonic.com] =
Sent:=20 Monday, March 27, 2006 4:52 PM
To: Dorothy=20 Stanley; capwap@frascone.com
Subject: RE: = [Capwap]=20 Editorial question - Location of Message = elements

Dorothy,

 

I=20 think structuring all the message elements in a single section is very = useful.=20 It helps make reading easier.

 

Saravanan

 

 

 

 

From: Dorothy=20 Stanley [mailto:dstanley1389@gmail.com]=20
Sent: Thursday, = March 23,=20 2006 1:41 AM
To: capwap@frascone.com
Subject: [Capwap] Editorial = question -=20 Location of Message elements

 

All,

In the -00 draft, the CAPWAP = message=20 elements are defined in multiple sections, specifically the section=20 defining
the first message in which a particular message element = appears.=20

I propose=20 to collect all of the message element definitions in a single section, = so that=20 there is
one place where they are all defined, and can easily be=20 found.

Is there=20 any objection to proceeding with this editorial = change?

At the=20 CAPWAP meeting on Monday, there seemed to be support for this = approach,=20 with
Pat noting that he LWAPP draft at one point was organized this = way,=20 but was then changed, due to
comments received. So, comments = please on=20 this proposed editorial change to the CAPWAP  draft=20 specification.

Thanks,

Dorothy

-----------------
Dorothy Stanley
Aruba Networks
630-363-1389 (cell) = 630-836-9734=20 = (office)


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


------_=_NextPart_001_01C65819.2760CE6A-- --===============1063758429== 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 --===============1063758429==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Apr 04 14:55:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQqgy-0002mo-PD for capwap-archive@lists.ietf.org; Tue, 04 Apr 2006 14:55:52 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQqgx-0003po-7r for capwap-archive@lists.ietf.org; Tue, 04 Apr 2006 14:55:52 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DF3F1430123 for ; Tue, 4 Apr 2006 11:55:50 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 5019E4300AF for ; Tue, 4 Apr 2006 11:54:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3F316398017 for ; Tue, 4 Apr 2006 11:54:15 -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 9EC08398018 for ; Tue, 4 Apr 2006 11:54:10 -0700 (PDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 04 Apr 2006 11:54:10 -0700 X-IronPort-AV: i="4.03,164,1141632000"; d="scan'208"; a="1791675023:sNHT46499712" 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 k34Is9Yi025288 for ; Tue, 4 Apr 2006 11:54:09 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Apr 2006 11:54:09 -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 Text for Issue 53 Date: Tue, 4 Apr 2006 11:54:09 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC015D5A1F@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Text for Issue 53 Thread-Index: AcZXmiGYKUrUeU/XT1OcZaCvsWKBVgAbk1kA From: "Bob O'Hara (boohara)" To: "Pat Calhoun (pacalhou)" , "capwap" X-OriginalArrivalTime: 04 Apr 2006 18:54:09.0295 (UTC) FILETIME=[27DE61F0:01C65819] 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: 2086112c730e13d5955355df27e3074b Pat, A suggestion for better language defining the value of the Data Rate field: Replace only the second sentence with the following: "The content of the field is a value representing the data rate of the frame received by the WTP. The value is in units of 100kbps."=20 -Bob =20 -----Original Message----- From: Pat Calhoun (pacalhou)=20 Sent: Monday, April 03, 2006 8:45 PM To: capwap Subject: [Capwap] Proposed Text for Issue 53 Here is my proposed text for Issue 53, which is the addition of a Data Rate In the CAPWAP header. Please let me know if you have any comments. =20 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | <=3D=3D=3D CHANGED!!! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ [...] 4.1.8. Reserved This 32 bit field is reserved and may be used by a binding specific extension. Refer to the transport portion of the binding for a specific wireless technology for the definition of this field. [...] 11.3.2. CAPWAP Header Reserved field 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 5.5Mbps would be set to 55, while 11Mbps would be set to 110. 11.3.2.2. Destination WLANs The Destination WLAN field is used to specify the target WLANs for a given frame, and is only used with broadcast and multicast frames. This field allows the AC to transmit a single broadcast or multicast frame to the WTP, and allows the WTP to perform the necessary frame replication services. The field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WLAN: This bit field indicates the WLAN ID (see section Section 11.8.1.1) which the WTP will transmit the associated frame on. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be enabled. Note this field is to be set to zero for unicast packets and is unused if the WTP is not providing encryption services. Reserved: This field MUST be set to zero. =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 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Apr 04 18:52:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQuO7-0003Kj-JR for capwap-archive@lists.ietf.org; Tue, 04 Apr 2006 18:52:39 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQuO5-0005Qx-T8 for capwap-archive@lists.ietf.org; Tue, 04 Apr 2006 18:52:39 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id EBA234300E4 for ; Tue, 4 Apr 2006 15:52:36 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7FE0143005F for ; Tue, 4 Apr 2006 15:52:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6789C144801A for ; Tue, 4 Apr 2006 15:52:10 -0700 (PDT) X-Greylist-Status: Sender first seen 13 days 05:18:09 ago Received: from sinett.com (63-197-255-151.ded.pacbell.net [63.197.255.151]) by hermes.tigertech.net (Postfix) with ESMTP id B045B1448001 for ; Tue, 4 Apr 2006 15:52:08 -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] Proposed Text for Issue 53 Date: Tue, 4 Apr 2006 15:52:08 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Text for Issue 53 thread-index: AcZXmiGYKUrUeU/XT1OcZaCvsWKBVgAnw06w From: "Abhijit Choudhury" 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.1 tagged_above=-999.0 required=7.0 tests=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: 3971661e40967acfc35f708dd5f33760 Here's another approach... RSSI, SNR, and Data Rate are measurements/parameters of the radio channel that are being reported to the=20 AC for finer control. Carrying them in every data packet on the data channel means some logic or hardware in the AC will have to parse them out of every data packet and send them to the control path (CPU). Typically not every packet will go to the CPU and so this data will=20 have to be stored and periodically sent to or read=20 by the CPU. Note that the AC will be possibly dealing=20 with tens to hundreds of WTPs and hence a=20 potentially large number of STAs. This implies a=20 large amount of per-STA measurement data has to be stored and moved from the data path to the CPU. A more reasonable approach is to let the WTP=20 aggregate such data and periodically send it in the=20 control channel to the AC. Note the WTP has to deal with much much fewer clients - so the storage burden is less. All we'd need is a frame that carries this information to the AC at a specified=20 interval of time. This period could be configurable. Using this approach, we don't need to increase the CAPWAP header every time we need new measurement info. We can retain the current CAPWAP header and flexibly add any measurement information we need by adding it in the control channel. This is particularly important as we move forward to support 802.11n or other=20 non-802.11 technlogies. It decouples the CAPWAP header from the measurement data related information. Any thoughts on this ? Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Monday, April 03, 2006 8:45 PM To: capwap Subject: [Capwap] Proposed Text for Issue 53 Here is my proposed text for Issue 53, which is the addition of a Data Rate In the CAPWAP header. Please let me know if you have any comments. =20 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | <=3D=3D=3D CHANGED!!! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ [...] 4.1.8. Reserved This 32 bit field is reserved and may be used by a binding specific extension. Refer to the transport portion of the binding for a specific wireless technology for the definition of this field. [...] 11.3.2. CAPWAP Header Reserved field 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 5.5Mbps would be set to 55, while 11Mbps would be set to 110. 11.3.2.2. Destination WLANs The Destination WLAN field is used to specify the target WLANs for a given frame, and is only used with broadcast and multicast frames. This field allows the AC to transmit a single broadcast or multicast frame to the WTP, and allows the WTP to perform the necessary frame replication services. The field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WLAN: This bit field indicates the WLAN ID (see section Section 11.8.1.1) which the WTP will transmit the associated frame on. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be enabled. Note this field is to be set to zero for unicast packets and is unused if the WTP is not providing encryption services. Reserved: This field MUST be set to zero. =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 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Apr 04 19:51:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQvIo-0005Yt-V4 for capwap-archive@lists.ietf.org; Tue, 04 Apr 2006 19:51:14 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQvIn-00088x-B3 for capwap-archive@lists.ietf.org; Tue, 04 Apr 2006 19:51:14 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id AD2F543005F for ; Tue, 4 Apr 2006 16:51:12 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8D60243005F for ; Tue, 4 Apr 2006 16:50:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4B30E1448019 for ; Tue, 4 Apr 2006 16:50:46 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 23B8F1448010 for ; Tue, 4 Apr 2006 16:50:43 -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 k34Nof2O018774; Wed, 5 Apr 2006 08:50:41 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k34NofA04563; Wed, 5 Apr 2006 08:50:41 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with SMTP id k34NoeM12949; Wed, 5 Apr 2006 08:50:40 +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] Proposed Text for Issue 53 Date: Wed, 5 Apr 2006 07:48:57 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDC77696@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Text for Issue 53 Thread-Index: AcZXmiGYKUrUeU/XT1OcZaCvsWKBVgAnw06wAAH/5gA= From: "Saravanan Govindan" To: "Abhijit Choudhury" , "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: 963faf56c3a5b6715f0b71b66181e01a Hi Abhijit, I am in support of your suggestion. It is true that the AC does not process all data packets. Furthermore, I think for greater control, the AC will need information about the congestion level in the WLAN. This could be a derivative of interference and load factor.=20 As for your suggestion, I think measurement/parameter information from the WTP should be sent over the periodic Echo Request messages. The advantage is that header overhead is reduced.=20 I can prepare text for this approach. Cheers, Saravanan =20 -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com]=20 Sent: Wednesday, April 05, 2006 6:52 AM To: Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Here's another approach... RSSI, SNR, and Data Rate are measurements/parameters of the radio channel that are being reported to the=20 AC for finer control. Carrying them in every data packet on the data channel means some logic or hardware in the AC will have to parse them out of every data packet and send them to the control path (CPU). Typically not every packet will go to the CPU and so this data will=20 have to be stored and periodically sent to or read=20 by the CPU. Note that the AC will be possibly dealing=20 with tens to hundreds of WTPs and hence a=20 potentially large number of STAs. This implies a=20 large amount of per-STA measurement data has to be stored and moved from the data path to the CPU. A more reasonable approach is to let the WTP=20 aggregate such data and periodically send it in the=20 control channel to the AC. Note the WTP has to deal with much much fewer clients - so the storage burden is less. All we'd need is a frame that carries this information to the AC at a specified=20 interval of time. This period could be configurable. Using this approach, we don't need to increase the CAPWAP header every time we need new measurement info. We can retain the current CAPWAP header and flexibly add any measurement information we need by adding it in the control channel. This is particularly important as we move forward to support 802.11n or other=20 non-802.11 technlogies. It decouples the CAPWAP header from the measurement data related information. Any thoughts on this ? Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Monday, April 03, 2006 8:45 PM To: capwap Subject: [Capwap] Proposed Text for Issue 53 Here is my proposed text for Issue 53, which is the addition of a Data Rate In the CAPWAP header. Please let me know if you have any comments. =20 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | <=3D=3D=3D CHANGED!!! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ [...] 4.1.8. Reserved This 32 bit field is reserved and may be used by a binding specific extension. Refer to the transport portion of the binding for a specific wireless technology for the definition of this field. [...] 11.3.2. CAPWAP Header Reserved field 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 5.5Mbps would be set to 55, while 11Mbps would be set to 110. 11.3.2.2. Destination WLANs The Destination WLAN field is used to specify the target WLANs for a given frame, and is only used with broadcast and multicast frames. This field allows the AC to transmit a single broadcast or multicast frame to the WTP, and allows the WTP to perform the necessary frame replication services. The field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WLAN: This bit field indicates the WLAN ID (see section Section 11.8.1.1) which the WTP will transmit the associated frame on. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be enabled. Note this field is to be set to zero for unicast packets and is unused if the WTP is not providing encryption services. Reserved: This field MUST be set to zero. =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 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 Apr 05 10:19:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR8rV-0002wc-0c for capwap-archive@lists.ietf.org; Wed, 05 Apr 2006 10:19:57 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR8rS-00083E-BO for capwap-archive@lists.ietf.org; Wed, 05 Apr 2006 10:19:56 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3F851430136 for ; Wed, 5 Apr 2006 07:19:53 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id BBE16430094 for ; Wed, 5 Apr 2006 07:19:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A3B951448022 for ; Wed, 5 Apr 2006 07:19: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 8D351144801C for ; Wed, 5 Apr 2006 07:19:22 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 05 Apr 2006 07:15:13 -0700 X-IronPort-AV: i="4.04,89,1144047600"; d="scan'208"; a="266741444:sNHT1099774452" 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 k35EFDGv000336 for ; Wed, 5 Apr 2006 07:15:13 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Apr 2006 07:15:13 -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 Text for Issue 53 Date: Wed, 5 Apr 2006 07:15:03 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC015D5D54@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Text for Issue 53 Thread-Index: AcZXmiGYKUrUeU/XT1OcZaCvsWKBVgAnw06wAAH/5gAAHicW0A== From: "Bob O'Hara (boohara)" To: "capwap" X-OriginalArrivalTime: 05 Apr 2006 14:15:13.0802 (UTC) FILETIME=[5B268EA0:01C658BB] X-Virus-Scanned: by amavisd-new-20030616-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: a492040269d440726bfd84680622cee7 For those AC implementations that want to use per packet data for certain operations, aggregation of the data at the WTP as suggested by Abhijit will preclude this. The assertion by Saravanan that an AC does not process this information is incorrect. I can point to at least one existing implementation that already does process this information on a per packet basis. The current text, with the change I suggested, is the right way to handle this. If we want to ADD a capability that the WTP can provide aggregation, I have no objection to that. -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Tuesday, April 04, 2006 4:49 PM To: Abhijit Choudhury; Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Hi Abhijit, I am in support of your suggestion. It is true that the AC does not process all data packets. Furthermore, I think for greater control, the AC will need information about the congestion level in the WLAN. This could be a derivative of interference and load factor.=20 As for your suggestion, I think measurement/parameter information from the WTP should be sent over the periodic Echo Request messages. The advantage is that header overhead is reduced.=20 I can prepare text for this approach. Cheers, Saravanan =20 -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com]=20 Sent: Wednesday, April 05, 2006 6:52 AM To: Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Here's another approach... RSSI, SNR, and Data Rate are measurements/parameters of the radio channel that are being reported to the=20 AC for finer control. Carrying them in every data packet on the data channel means some logic or hardware in the AC will have to parse them out of every data packet and send them to the control path (CPU). Typically not every packet will go to the CPU and so this data will=20 have to be stored and periodically sent to or read=20 by the CPU. Note that the AC will be possibly dealing=20 with tens to hundreds of WTPs and hence a=20 potentially large number of STAs. This implies a=20 large amount of per-STA measurement data has to be stored and moved from the data path to the CPU. A more reasonable approach is to let the WTP=20 aggregate such data and periodically send it in the=20 control channel to the AC. Note the WTP has to deal with much much fewer clients - so the storage burden is less. All we'd need is a frame that carries this information to the AC at a specified=20 interval of time. This period could be configurable. Using this approach, we don't need to increase the CAPWAP header every time we need new measurement info. We can retain the current CAPWAP header and flexibly add any measurement information we need by adding it in the control channel. This is particularly important as we move forward to support 802.11n or other=20 non-802.11 technlogies. It decouples the CAPWAP header from the measurement data related information. Any thoughts on this ? Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Monday, April 03, 2006 8:45 PM To: capwap Subject: [Capwap] Proposed Text for Issue 53 Here is my proposed text for Issue 53, which is the addition of a Data Rate In the CAPWAP header. Please let me know if you have any comments. =20 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | <=3D=3D=3D CHANGED!!! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ [...] 4.1.8. Reserved This 32 bit field is reserved and may be used by a binding specific extension. Refer to the transport portion of the binding for a specific wireless technology for the definition of this field. [...] 11.3.2. CAPWAP Header Reserved field 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 5.5Mbps would be set to 55, while 11Mbps would be set to 110. 11.3.2.2. Destination WLANs The Destination WLAN field is used to specify the target WLANs for a given frame, and is only used with broadcast and multicast frames. This field allows the AC to transmit a single broadcast or multicast frame to the WTP, and allows the WTP to perform the necessary frame replication services. The field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WLAN: This bit field indicates the WLAN ID (see section Section 11.8.1.1) which the WTP will transmit the associated frame on. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be enabled. Note this field is to be set to zero for unicast packets and is unused if the WTP is not providing encryption services. Reserved: This field MUST be set to zero. =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 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 Apr 05 16:25:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREZF-0007mt-5F for capwap-archive@lists.ietf.org; Wed, 05 Apr 2006 16:25:29 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FREZD-00039U-Ki for capwap-archive@lists.ietf.org; Wed, 05 Apr 2006 16:25:29 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0AB7343011F for ; Wed, 5 Apr 2006 13:25:27 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 166D543005A for ; Wed, 5 Apr 2006 13:24:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id EDDC5398009 for ; Wed, 5 Apr 2006 13:24:57 -0700 (PDT) X-Greylist-Status: Sender first seen 2 mons 11 days 04:37:12 ago Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by zoidberg.tigertech.net (Postfix) with ESMTP id B64D8398030 for ; Wed, 5 Apr 2006 13:24:55 -0700 (PDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k35KMsQv005670 for ; Wed, 5 Apr 2006 16:22:54 -0400 Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tiere.net.avaya.com (Switch-3.1.8/Switch-3.1.0) with ESMTP id k35KLiKM015226 for ; Wed, 5 Apr 2006 16:21:44 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Apr 2006 14:24:53 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Security Advisors - CAPWAP Thread-Index: AcZY7wQqbDddUfHWTnazIsCXJ/Hlng== X-Priority: 1 Priority: Urgent Importance: high From: "Mani, Mahalingam (Mani)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.283 tagged_above=-999 required=7 tests=HTML_90_100, HTML_MESSAGE, X_PRIORITY_HIGH X-Spam-Level: Subject: [Capwap] Security Advisors - 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="===============0057009412==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.3 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 This is a multi-part message in MIME format. --===============0057009412== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C658EE.FF733980" This is a multi-part message in MIME format. ------_=_NextPart_001_01C658EE.FF733980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 Following the discussions in Dallas with the security area in SAAG on 3/24/06, Scott Kelly and Charles Clancy are nominated as Security Advisors for CAPWAP. =20 We just received confirmation from AD on this. =20 Welcome to both to continue to contribute, as in past, and provide security guidance in the new capacity. =20 Regards, -mani & Dorothy ------_=_NextPart_001_01C658EE.FF733980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

Following the discussions in Dallas with the security area in = SAAG on 3/24/06, Scott Kelly and Charles Clancy are nominated as Security = Advisors for CAPWAP.

 

We just received confirmation from AD on = this.

 

Welcome to both to continue to contribute, as in = past, and provide security guidance in the new capacity.

 

Regards,

-mani & Dorothy

------_=_NextPart_001_01C658EE.FF733980-- --===============0057009412== 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 --===============0057009412==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Apr 05 18:50:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGpI-0006QG-EK for capwap-archive@lists.ietf.org; Wed, 05 Apr 2006 18:50:12 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRGpG-0001h9-MY for capwap-archive@lists.ietf.org; Wed, 05 Apr 2006 18:50:12 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D3A7443012B for ; Wed, 5 Apr 2006 15:50:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2953A43005A for ; Wed, 5 Apr 2006 15:49:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 12A6E144801E for ; Wed, 5 Apr 2006 15:49:45 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by hermes.tigertech.net (Postfix) with ESMTP id 996B41448030 for ; Wed, 5 Apr 2006 15:49:43 -0700 (PDT) Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 05 Apr 2006 15:49:25 -0700 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id B1C482AF; Wed, 5 Apr 2006 15:49:25 -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 8D41F2AE; Wed, 5 Apr 2006 15:49:25 -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.3a-GA) with ESMTP id DFX14304; Wed, 5 Apr 2006 15:49:25 -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 1437820501; Wed, 5 Apr 2006 15:49:25 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] Proposed Text for Issue 53 Date: Wed, 5 Apr 2006 15:49:23 -0700 Message-ID: <8954613CA6BB3242A1531D916A527A41A743C4@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [Capwap] Proposed Text for Issue 53 Thread-Index: AcZXmiGYKUrUeU/XT1OcZaCvsWKBVgAnw06wAAH/5gAAHicW0AANpnXw From: "Puneet Agarwal" To: "Bob O'Hara (boohara)" , "capwap" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006040508; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230362E34343334343837392E303030442D412D; ENG=IBF; TS=20060405224930; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006040508_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 682A96FF1743329437-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: 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: 32029c790f79bd4a84a26bd2915c54b9 Hi Bob, It seems the real issue is what is the default mode of operation. Summary: --------- Pat/Bob: Carry the phy info in every CAPWAP data pkt as at least 1 implementation uses it Abhijit/Saravanan: Carry phy info in control msgs periodically and not in every CAPWAP data frame. My Proposal (Compromise): ------------------------- Sending the Phy info (RSSI/SNR/Speed) should be optional. By default this info should *NOT* be sent in every CAPWAP data packet. This capability should be negotiated at WTP<->AC handshake time. Comments? Thanks. -Puneet -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Wednesday, April 05, 2006 7:15 AM To: capwap Subject: RE: [Capwap] Proposed Text for Issue 53 For those AC implementations that want to use per packet data for certain operations, aggregation of the data at the WTP as suggested by Abhijit will preclude this. The assertion by Saravanan that an AC does not process this information is incorrect. I can point to at least one existing implementation that already does process this information on a per packet basis. The current text, with the change I suggested, is the right way to handle this. If we want to ADD a capability that the WTP can provide aggregation, I have no objection to that. -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Tuesday, April 04, 2006 4:49 PM To: Abhijit Choudhury; Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Hi Abhijit, I am in support of your suggestion. It is true that the AC does not process all data packets. Furthermore, I think for greater control, the AC will need information about the congestion level in the WLAN. This could be a derivative of interference and load factor.=20 As for your suggestion, I think measurement/parameter information from the WTP should be sent over the periodic Echo Request messages. The advantage is that header overhead is reduced.=20 I can prepare text for this approach. Cheers, Saravanan =20 -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com] Sent: Wednesday, April 05, 2006 6:52 AM To: Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Here's another approach... RSSI, SNR, and Data Rate are measurements/parameters of the radio channel that are being reported to the AC for finer control. Carrying them in every data packet on the data channel means some logic or hardware in the AC will have to parse them out of every data packet and send them to the control path (CPU). Typically not every packet will go to the CPU and so this data will have to be stored and periodically sent to or read by the CPU. Note that the AC will be possibly dealing with tens to hundreds of WTPs and hence a potentially large number of STAs. This implies a large amount of per-STA measurement data has to be stored and moved from the data path to the CPU. A more reasonable approach is to let the WTP aggregate such data and periodically send it in the control channel to the AC. Note the WTP has to deal with much much fewer clients - so the storage burden is less. All we'd need is a frame that carries this information to the AC at a specified interval of time. This period could be configurable. Using this approach, we don't need to increase the CAPWAP header every time we need new measurement info. We can retain the current CAPWAP header and flexibly add any measurement information we need by adding it in the control channel. This is particularly important as we move forward to support 802.11n or other non-802.11 technlogies. It decouples the CAPWAP header from the measurement data related information. Any thoughts on this ? Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Monday, April 03, 2006 8:45 PM To: capwap Subject: [Capwap] Proposed Text for Issue 53 Here is my proposed text for Issue 53, which is the addition of a Data Rate In the CAPWAP header. Please let me know if you have any comments. =20 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | <=3D=3D=3D CHANGED!!! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ [...] 4.1.8. Reserved This 32 bit field is reserved and may be used by a binding specific extension. Refer to the transport portion of the binding for a specific wireless technology for the definition of this field. [...] 11.3.2. CAPWAP Header Reserved field 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 5.5Mbps would be set to 55, while 11Mbps would be set to 110. 11.3.2.2. Destination WLANs The Destination WLAN field is used to specify the target WLANs for a given frame, and is only used with broadcast and multicast frames. This field allows the AC to transmit a single broadcast or multicast frame to the WTP, and allows the WTP to perform the necessary frame replication services. The field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WLAN: This bit field indicates the WLAN ID (see section Section 11.8.1.1) which the WTP will transmit the associated frame on. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be enabled. Note this field is to be set to zero for unicast packets and is unused if the WTP is not providing encryption services. Reserved: This field MUST be set to zero. =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 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 Apr 05 20:23:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRIHX-0003ik-0R for capwap-archive@lists.ietf.org; Wed, 05 Apr 2006 20:23:27 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRIHT-00051W-Ca for capwap-archive@lists.ietf.org; Wed, 05 Apr 2006 20:23:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 74CB44300DC for ; Wed, 5 Apr 2006 17:23:22 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4853543005A for ; Wed, 5 Apr 2006 17:22:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 31A451448017 for ; Wed, 5 Apr 2006 17:22:18 -0700 (PDT) X-Greylist-Status: Sender first seen 14 days 06:48:16 ago Received: from sinett.com (63-197-255-151.ded.pacbell.net [63.197.255.151]) by hermes.tigertech.net (Postfix) with ESMTP id 9FD13144800F for ; Wed, 5 Apr 2006 17:22:15 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] Proposed Text for Issue 53 Date: Wed, 5 Apr 2006 17:22:15 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Text for Issue 53 thread-index: AcZXmiGYKUrUeU/XT1OcZaCvsWKBVgAnw06wAAH/5gAAHicW0AANpnXwAAYZKxA= From: "Abhijit Choudhury" To: "Puneet Agarwal" , "Bob O'Hara (boohara)" , "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.1 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO, 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="===============0882361567==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: c892b762daa2dd1ca407c1f421df8b92 This is a multi-part message in MIME format. --===============0882361567== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65910.28028046" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65910.28028046 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The default mode is not the only issue. As Bob has pointed out some AC implementations may use per-packet receive info for value added functionalities. Some others=20 may use transmit info (like number of retries, transmit rate) to do similar services and prefer that instead or in addition. And some may be prefer the WTP to do the aggregation. So, now do we keep adding all this additional fields into the CAPWAP header ? Based on our current discussion, I would suggest having extension capabilities in the CAPWAP header. The current CAPWAP header can be the default header. (Note that we need=20 a 6 byte CAPWAP header for AC -> WTP direction as we need=20 the WLAN ID field. So, we can also carry RSSI/SNR for free). Below are some possibilities : 1. We can use the VER (version) field for this . For example, the current CAPWAP header can be VER 0. Now if someone needs data rate or other stats,=20 we can define different size fields (2bytes, 6 bytes etc) with the other encodings of VER. This gives us the flexbility to do carry additional information if the implementation needs it. 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| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSSI | SNR | Payload.... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSSI | SNR | Data Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ 2. Alternatively, we can use the current R bit as an option=20 flag (like L2TP). Data Rate (new D bit) could be a flag and if set, would indicate a 2 byte field at the end that carries data rate. D=3D0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|D| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSSI | SNR | Payload.... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D=3D1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|D| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSSI | SNR | Data Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ With this approach, we will have the flexibility to carry additional information if we need it on a per-packet basis, and only the default=20 header if we don't need it or are allowing the WTP to aggregate information. We will not need to make it mandatory for everyone to carry additional information. Comments ? Thanks, Abhijit -----Original Message----- From: Puneet Agarwal [mailto:pagarwal@broadcom.com ] Sent: Wednesday, April 05, 2006 3:49 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Hi Bob, It seems the real issue is what is the default mode of operation. Summary: --------- Pat/Bob: Carry the phy info in every CAPWAP data pkt as at least 1 implementation uses it Abhijit/Saravanan: Carry phy info in control msgs periodically and not in every CAPWAP data frame. My Proposal (Compromise): ------------------------- Sending the Phy info (RSSI/SNR/Speed) should be optional. By default this info should *NOT* be sent in every CAPWAP data packet. This capability should be negotiated at WTP<->AC handshake time. Comments? Thanks. -Puneet -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com ] Sent: Wednesday, April 05, 2006 7:15 AM To: capwap Subject: RE: [Capwap] Proposed Text for Issue 53 For those AC implementations that want to use per packet data for certain operations, aggregation of the data at the WTP as suggested by Abhijit will preclude this. The assertion by Saravanan that an AC does not process this information is incorrect. I can point to at least one existing implementation that already does process this information on a per packet basis. The current text, with the change I suggested, is the right way to handle this. If we want to ADD a capability that the WTP can provide aggregation, I have no objection to that. -Bob -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com ] Sent: Tuesday, April 04, 2006 4:49 PM To: Abhijit Choudhury; Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Hi Abhijit, I am in support of your suggestion. It is true that the AC does not process all data packets. Furthermore, I think for greater control, the AC will need information about the congestion level in the WLAN. This could be a derivative of interference and load factor. As for your suggestion, I think measurement/parameter information from the WTP should be sent over the periodic Echo Request messages. The advantage is that header overhead is reduced. I can prepare text for this approach. Cheers, Saravanan -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com ] Sent: Wednesday, April 05, 2006 6:52 AM To: Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Here's another approach... RSSI, SNR, and Data Rate are measurements/parameters of the radio channel that are being reported to the AC for finer control. Carrying them in every data packet on the data channel means some logic or hardware in the AC will have to parse them out of every data packet and send them to the control path (CPU). Typically not every packet will go to the CPU and so this data will have to be stored and periodically sent to or read by the CPU. Note that the AC will be possibly dealing with tens to hundreds of WTPs and hence a potentially large number of STAs. This implies a large amount of per-STA measurement data has to be stored and moved from the data path to the CPU. A more reasonable approach is to let the WTP aggregate such data and periodically send it in the control channel to the AC. Note the WTP has to deal with much much fewer clients - so the storage burden is less. All we'd need is a frame that carries this information to the AC at a specified interval of time. This period could be configurable. Using this approach, we don't need to increase the CAPWAP header every time we need new measurement info. We can retain the current CAPWAP header and flexibly add any measurement information we need by adding it in the control channel. This is particularly important as we move forward to support 802.11n or other non-802.11 technlogies. It decouples the CAPWAP header from the measurement data related information. Any thoughts on this ? Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com ] Sent: Monday, April 03, 2006 8:45 PM To: capwap Subject: [Capwap] Proposed Text for Issue 53 Here is my proposed text for Issue 53, which is the addition of a Data Rate In the CAPWAP header. Please let me know if you have any comments. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | <=3D=3D=3D CHANGED!!! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ [...] 4.1.8. Reserved This 32 bit field is reserved and may be used by a binding specific extension. Refer to the transport portion of the binding for a specific wireless technology for the definition of this field. [...] 11.3.2. CAPWAP Header Reserved field 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 5.5Mbps would be set to 55, while 11Mbps would be set to 110. 11.3.2.2. Destination WLANs The Destination WLAN field is used to specify the target WLANs for a given frame, and is only used with broadcast and multicast frames. This field allows the AC to transmit a single broadcast or multicast frame to the WTP, and allows the WTP to perform the necessary frame replication services. The field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WLAN: This bit field indicates the WLAN ID (see section Section 11.8.1.1) which the WTP will transmit the associated frame on. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be enabled. Note this field is to be set to zero for unicast packets and is unused if the WTP is not providing encryption services. Reserved: This field MUST be set to zero. 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: 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 =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 ------_=_NextPart_001_01C65910.28028046 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
The default mode is not = the only=20 issue. As Bob has
pointed out some AC implementations may use=20 per-packet
receive info for value = added=20 functionalities.  Some others
may use transmit info (like number of retries, = transmit
rate) to do=20 similar services and prefer that instead
or in addition.  And = some may=20 be prefer the WTP to do
the aggregation.  So, now = do we keep=20 adding all this
additional fields into the = CAPWAP header=20 ?

Based on our current discussion, I would suggest = having
extension=20 capabilities in the CAPWAP header. The current
CAPWAP header can be the = default header.=20 (Note that we need
a 6 byte CAPWAP header for AC = -> WTP=20 direction as we need
the WLAN ID field. So, we can = also carry=20 RSSI/SNR for free).

Below are some = possibilities=20 :

1. We can use the VER (version) field for this .
For = example, the=20 current CAPWAP header can be VER 0.
Now if someone needs data = rate or=20 other stats,
we can=20 define different size fields
(2bytes, 6 bytes etc) with the other = encodings=20 of VER.
This gives us the flexbility to do carry = additional
information if=20 the implementation needs it.
     =20 0            =       =20 1            =       =20 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=20 2 3 4 5 6 7 8 9 0 1
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |0 0| RID |F|L|R|    Frag ID   =20 |           =20 Length           &= nbsp;=20 |
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |     RSSI     =20 |     SNR      =20 |          =20 Payload....        =20 |
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    

     =20 0            =       =20 1            =       =20 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=20 2 3 4 5 6 7 8 9 0 1
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |0 1| RID |F|L|R|    Frag ID   =20 |           =20 Length           &= nbsp;=20 |
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |     RSSI     =20 |     SNR      =20 |           Data=20 Rate          =20 |
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |   Payload...  |
    =20 +-+-+-+-+-+-+-+-+

2. Alternatively, we can use the current R bit = as an=20 option
flag (like L2TP). Data Rate (new D bit) could be a = flag
and if=20 set, would indicate a 2 byte field at the end
that carries data=20 rate.

D=3D0     =20 0            =       =20 1            =       =20 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=20 2 3 4 5 6 7 8 9 0 1
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |VER| RID |F|L|D|    Frag ID   =20 |           =20 Length           &= nbsp;=20 |
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |     RSSI     =20 |     SNR      =20 |          =20 Payload....        =20 |
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

D=3D1
     =20 0            =       =20 1            =       =20 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=20 2 3 4 5 6 7 8 9 0 1
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |VER| RID |F|L|D|    Frag ID   =20 |           =20 Length           &= nbsp;=20 |
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |     RSSI     =20 |     SNR      =20 |           Data=20 Rate          =20 |
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |   Payload...  |
    =20 +-+-+-+-+-+-+-+-+

With this approach, we will = have the=20 flexibility to carry additional
information if we need it = on a=20 per-packet basis, and only the default
header if we don't need it or = are allowing=20 the WTP to aggregate information.
We will not need to make = it mandatory=20 for everyone to carry additional
information.

Comments=20 ?

Thanks,
   = Abhijit




-----Original=20 Message-----
From: Puneet Agarwal [mailto:pagarwal@broadcom.com]
Sent: Wednesday, April 05, 2006 3:49 = PM
To: Bob=20 O'Hara (boohara); capwap
Subject: RE: [Capwap] Proposed Text for = Issue=20 53


Hi Bob,

It seems the real issue is what is the = default mode=20 of operation.

Summary:
---------

Pat/Bob: Carry the phy = info in=20 every CAPWAP data pkt as at least 1 implementation uses = it
Abhijit/Saravanan:=20 Carry phy info in control msgs periodically and not in every CAPWAP data = frame.

My Proposal = (Compromise):
-------------------------
Sending=20 the Phy info (RSSI/SNR/Speed) should be optional. By default this info = should=20 *NOT* be sent in every CAPWAP data packet. This capability should be = negotiated=20 at WTP<->AC handshake=20 time.

Comments?

Thanks.

-Puneet


-----Orig= inal=20 Message-----
From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]
Sent: Wednesday, April 05, 2006 7:15 AM
To: = capwap
Subject:=20 RE: [Capwap] Proposed Text for Issue 53

For those AC = implementations that=20 want to use per packet data for certain operations, aggregation of the = data at=20 the WTP as suggested by Abhijit will preclude this.  The assertion = by=20 Saravanan that an AC does not process this information is = incorrect.  I can=20 point to at least one existing implementation that already does process = this=20 information on a per packet basis.

The current text, with the = change I=20 suggested, is the right way to handle this.  If we want to ADD a = capability=20 that the WTP can provide aggregation, I have no objection to=20 that.

 -Bob

-----Original Message-----
From: = Saravanan=20 Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: Tuesday, April = 04, 2006 4:49=20 PM
To: Abhijit Choudhury; Pat Calhoun (pacalhou); capwap
Subject: = RE:=20 [Capwap] Proposed Text for Issue 53

Hi Abhijit,

I am in = support of=20 your suggestion. It is true that the AC does not process all data = packets.=20 Furthermore, I think for greater control, the AC will need information = about the=20 congestion level in the WLAN. This could be a derivative of interference = and=20 load factor.

As for your suggestion, I think = measurement/parameter=20 information from the WTP should be sent over the periodic Echo Request = messages.=20 The advantage is that header overhead is reduced.

I can prepare = text for=20 this=20 approach.

Cheers,

Saravanan





-----Ori= ginal=20 Message-----
From: Abhijit Choudhury [mailto:Abhijit@sinett.com]
Sent: Wednesday, April 05, 2006 6:52 = AM
To: Pat=20 Calhoun (pacalhou); capwap
Subject: RE: [Capwap] Proposed Text for = Issue=20 53

Here's another approach...

RSSI, SNR, and Data Rate are = measurements/parameters of the radio channel that are being reported to = the AC=20 for finer control.  Carrying them in every data packet on the data = channel=20 means some logic or hardware in the AC will have to parse them out of = every data=20 packet and send them to the control path (CPU).  Typically not = every packet=20 will go to the CPU and so this data will have to be stored and = periodically sent=20 to or read by the CPU.  Note that the AC will be possibly dealing = with tens=20 to hundreds of WTPs and hence a potentially large number of STAs. This = implies a=20 large amount of per-STA measurement data has to be stored and moved from = the=20 data path to the CPU.

A more reasonable approach is to let the = WTP=20 aggregate such data and periodically send it in the control channel to = the=20 AC.  Note the WTP has to deal with much much fewer clients - so the = storage=20 burden is less. All we'd need is a frame that carries this information = to the AC=20 at a specified interval of time.  This period could be=20 configurable.

Using this approach, we don't need to increase the = CAPWAP=20 header every time we need new measurement info. We can retain the = current CAPWAP=20 header and flexibly add any measurement information we need by adding it = in the=20 control channel. This is particularly important as we move forward to = support=20 802.11n or other non-802.11 technlogies. It decouples the CAPWAP header = from the=20 measurement data related information.

Any thoughts on this=20 ?


Thanks,
   = Abhijit




-----Original=20 Message-----
From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Monday, April 03, 2006 8:45 = PM
To:=20 capwap
Subject: [Capwap] Proposed Text for Issue 53


Here = is my=20 proposed text for Issue 53, which is the addition of a Data Rate In the = CAPWAP=20 header.

Please let me know if you have any = comments.

4.1. =20 CAPWAP Transport Header

   All CAPWAP protocol messages = are=20 encapsulated using a common header
   format, regardless of = the=20 CAPWAP control or CAPWAP Data transport
   used to carry = the=20 messages.  However, certain flags are not
   = applicable for a=20 given transport.  Refer to the specific transport
   = section=20 in order to determine which flags are=20 valid.

     =20 0            =       =20 1            =       =20 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=20 2 3 4 5 6 7 8 9 0 1
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |VER| RID |F|L|R|    Frag ID   =20 |           =20 Length           &= nbsp;=20 |
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |            =             &= nbsp; =20 Reserved           = ;            =     =20 |
<=3D=3D=3D CHANGED!!!
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |   Payload...  |
    =20 +-+-+-+-+-+-+-+-+

[...]
4.1.8.  = Reserved

   This=20 32 bit field is reserved and may be used by a binding = specific
  =20 extension.  Refer to the transport portion of the binding for=20 a
   specific wireless technology for the definition of = this=20 field.

[...]

11.3.2.  CAPWAP Header Reserved=20 field

   The reserved CAPWAP header field (see figure = Section=20 4.1) is only
   used with CAPWAP data frames, and it serves = two=20 purposes, depending
   upon the direction of the = frame.  For=20 packets from the WTP to the AC,
   the field uses the = format=20 described in Section 11.3.2.1.  However,
   for frames = sent by=20 the AC to the WTP, the format used is described in
   = described in=20 Section 11.3.2.2.

11.3.2.1.  IEEE 802.11 Frame=20 Info

   When an CAPWAP data frame is received from a = station=20 over the air, it
   is encapsulated and this field is used = to=20 include radio and PHY
   specific information associated = with the=20 frame.

   When used with the IEEE 802.11 binding, the = field=20 follows the
   following=20 format:

     =20 0            =       =20 1            =       =20 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=20 2 3 4 5 6 7 8 9 0 1
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |     RSSI     =20 |     SNR      =20 |           Data=20 Rate          =20 |
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=   =20 RSSI:  RSSI is a signed, 8-bit value.  It is the received=20 signal
      strength indication, in=20 dBm.

   SNR:  SNR is a signed, 8-bit value.  = It is=20 the signal to noise ratio
      of the = received IEEE=20 802.11 frame, in dB.

   Data Rate:  The data rate = field is=20 a 16 bit unsigned value.  The
      = contents of=20 the field is set to 1/10th of the data rate of=20 the
      packet received by the WTP.  = For=20 instance, a packet received at
      5.5Mbps = would=20 be set to 55, while 11Mbps would be set to 110.

11.3.2.2. =20 Destination WLANs

   The Destination WLAN field is used = to=20 specify the target WLANs for a
   given frame, and is only = used=20 with broadcast and multicast frames.
   This field allows = the AC to=20 transmit a single broadcast or multicast
   frame to the = WTP, and=20 allows the WTP to perform the necessary frame
   = replication=20 services.  The field uses the following=20 format:

     =20 0            =       =20 1            =       =20 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=20 2 3 4 5 6 7 8 9 0 1
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |            =  =20 WLAN           &nb= sp;=20 |           =20 Reserved          =20 |
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=   =20 WLAN:  This bit field indicates the WLAN ID (see=20 section
      Section 11.8.1.1) which the = WTP will=20 transmit the associated frame
      = on.  For=20 instance, if a multicast packet is to be transmitted=20 on
      WLANs 1 and 3, bits 1 and 3 of this = field=20 would be enabled.  Note
      this = field is to=20 be set to zero for unicast packets and is=20 unused
      if the WTP is not providing = encryption=20 services.

   Reserved:  This field MUST be set to=20 zero.



Pat Calhoun
CTO, Wireless Networking Business=20 Unit
Cisco Systems=20 _________________________________________________________________
To=20 unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap
=
Archives: http://lists.frascone.com/pipermail/capwap
________________________________________________________________= _
To=20 unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap
=
Archives: http://lists.frascone.com/pipermail/capwap

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

________________________________________________________________= _
To=20 unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap
=
Archives: http://lists.frascone.com/pipermail/capwap
<= /BODY> ------_=_NextPart_001_01C65910.28028046-- --===============0882361567== 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 --===============0882361567==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Apr 05 20:34:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRISZ-0002mZ-J0 for capwap-archive@lists.ietf.org; Wed, 05 Apr 2006 20:34:51 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRISY-0005WU-UX for capwap-archive@lists.ietf.org; Wed, 05 Apr 2006 20:34:51 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8E43D430116 for ; Wed, 5 Apr 2006 17:34:50 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 862CB43005A for ; Wed, 5 Apr 2006 17:34:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6A54D144800F for ; Wed, 5 Apr 2006 17:34: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 5F75C144800B for ; Wed, 5 Apr 2006 17:34: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/bulls) with ESMTP id k360YKGC010825; Thu, 6 Apr 2006 09:34:20 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k360YKu19925; Thu, 6 Apr 2006 09:34:20 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with SMTP id k360YJV02806; Thu, 6 Apr 2006 09:34:19 +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] Proposed Text for Issue 53 Date: Thu, 6 Apr 2006 08:32:50 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDC77823@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Text for Issue 53 Thread-Index: AcZXmiGYKUrUeU/XT1OcZaCvsWKBVgAnw06wAAH/5gAAHicW0AAV2e5g From: "Saravanan Govindan" To: "Bob O'Hara (boohara)" , "capwap" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.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: 7698d1420ecbbce1995432e99bb6d1a1 Bob, I will accept that there is an AC implementation for per data packet processing.=20 I still prefer that the CAPWAP protocol aggregate measurement information for periodic exchange.=20 Saravanan =20 -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Wednesday, April 05, 2006 10:15 PM To: capwap Subject: RE: [Capwap] Proposed Text for Issue 53 For those AC implementations that want to use per packet data for certain operations, aggregation of the data at the WTP as suggested by Abhijit will preclude this. The assertion by Saravanan that an AC does not process this information is incorrect. I can point to at least one existing implementation that already does process this information on a per packet basis. The current text, with the change I suggested, is the right way to handle this. If we want to ADD a capability that the WTP can provide aggregation, I have no objection to that. -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Tuesday, April 04, 2006 4:49 PM To: Abhijit Choudhury; Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Hi Abhijit, I am in support of your suggestion. It is true that the AC does not process all data packets. Furthermore, I think for greater control, the AC will need information about the congestion level in the WLAN. This could be a derivative of interference and load factor.=20 As for your suggestion, I think measurement/parameter information from the WTP should be sent over the periodic Echo Request messages. The advantage is that header overhead is reduced.=20 I can prepare text for this approach. Cheers, Saravanan =20 -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com]=20 Sent: Wednesday, April 05, 2006 6:52 AM To: Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Here's another approach... RSSI, SNR, and Data Rate are measurements/parameters of the radio channel that are being reported to the=20 AC for finer control. Carrying them in every data packet on the data channel means some logic or hardware in the AC will have to parse them out of every data packet and send them to the control path (CPU). Typically not every packet will go to the CPU and so this data will=20 have to be stored and periodically sent to or read=20 by the CPU. Note that the AC will be possibly dealing=20 with tens to hundreds of WTPs and hence a=20 potentially large number of STAs. This implies a=20 large amount of per-STA measurement data has to be stored and moved from the data path to the CPU. A more reasonable approach is to let the WTP=20 aggregate such data and periodically send it in the=20 control channel to the AC. Note the WTP has to deal with much much fewer clients - so the storage burden is less. All we'd need is a frame that carries this information to the AC at a specified=20 interval of time. This period could be configurable. Using this approach, we don't need to increase the CAPWAP header every time we need new measurement info. We can retain the current CAPWAP header and flexibly add any measurement information we need by adding it in the control channel. This is particularly important as we move forward to support 802.11n or other=20 non-802.11 technlogies. It decouples the CAPWAP header from the measurement data related information. Any thoughts on this ? Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Monday, April 03, 2006 8:45 PM To: capwap Subject: [Capwap] Proposed Text for Issue 53 Here is my proposed text for Issue 53, which is the addition of a Data Rate In the CAPWAP header. Please let me know if you have any comments. =20 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | <=3D=3D=3D CHANGED!!! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ [...] 4.1.8. Reserved This 32 bit field is reserved and may be used by a binding specific extension. Refer to the transport portion of the binding for a specific wireless technology for the definition of this field. [...] 11.3.2. CAPWAP Header Reserved field 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 5.5Mbps would be set to 55, while 11Mbps would be set to 110. 11.3.2.2. Destination WLANs The Destination WLAN field is used to specify the target WLANs for a given frame, and is only used with broadcast and multicast frames. This field allows the AC to transmit a single broadcast or multicast frame to the WTP, and allows the WTP to perform the necessary frame replication services. The field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WLAN: This bit field indicates the WLAN ID (see section Section 11.8.1.1) which the WTP will transmit the associated frame on. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be enabled. Note this field is to be set to zero for unicast packets and is unused if the WTP is not providing encryption services. Reserved: This field MUST be set to zero. =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 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 Apr 05 21:18:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRJ8w-00007B-A8 for capwap-archive@lists.ietf.org; Wed, 05 Apr 2006 21:18:38 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRJ8t-0007am-Ms for capwap-archive@lists.ietf.org; Wed, 05 Apr 2006 21:18:38 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CE6564300AF for ; Wed, 5 Apr 2006 18:18:34 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7C1E943005A for ; Wed, 5 Apr 2006 18:17:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5D4081448025 for ; Wed, 5 Apr 2006 18:17:23 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 4FA00144800B for ; Wed, 5 Apr 2006 18:17: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/jazz) with ESMTP id k361HFmj011682; Thu, 6 Apr 2006 10:17:15 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k361HG118843; Thu, 6 Apr 2006 10:17:16 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with SMTP id k361HGV04721; Thu, 6 Apr 2006 10:17:16 +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 Text for Issue 53 Date: Thu, 6 Apr 2006 09:15:40 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDC77837@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Text for Issue 53 Thread-Index: AcZXmiGYKUrUeU/XT1OcZaCvsWKBVgAnw06wAAH/5gAAHicW0AANpnXwAAYZKxAAA3XZkA== From: "Saravanan Govindan" To: "Abhijit Choudhury" , "Puneet Agarwal" , "Bob O'Hara (boohara)" , "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.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: 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="===============1878180533==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 4e684258e4d4fb63d885728ac3390cd4 This is a multi-part message in MIME format. --===============1878180533== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65917.A246C40D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65917.A246C40D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Abhijit, =20 For clarification, your suggestion is to continue with having the WLAN ID field in CAPWAP packets for AC -> WTP. However, for CAPWAP packets for WTP -> AC, your suggestion is to replace WLAN ID field with the channel measurement information.=20 =20 Is this right?=20 Cheers, Saravanan =20 =20 =20 _____ =20 From: Abhijit Choudhury [mailto:Abhijit@sinett.com]=20 Sent: Thursday, April 06, 2006 8:22 AM To: Puneet Agarwal; Bob O'Hara (boohara); Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 =20 The default mode is not the only issue. As Bob has pointed out some AC implementations may use per-packet receive info for value added functionalities. Some others=20 may use transmit info (like number of retries, transmit rate) to do similar services and prefer that instead or in addition. And some may be prefer the WTP to do the aggregation. So, now do we keep adding all this additional fields into the CAPWAP header ? Based on our current discussion, I would suggest having extension capabilities in the CAPWAP header. The current CAPWAP header can be the default header. (Note that we need=20 a 6 byte CAPWAP header for AC -> WTP direction as we need=20 the WLAN ID field. So, we can also carry RSSI/SNR for free). Below are some possibilities : 1. We can use the VER (version) field for this . For example, the current CAPWAP header can be VER 0. Now if someone needs data rate or other stats,=20 we can define different size fields (2bytes, 6 bytes etc) with the other encodings of VER. This gives us the flexbility to do carry additional information if the implementation needs it. 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| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSSI | SNR | Payload.... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSSI | SNR | Data Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ 2. Alternatively, we can use the current R bit as an option=20 flag (like L2TP). Data Rate (new D bit) could be a flag and if set, would indicate a 2 byte field at the end that carries data rate. D=3D0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|D| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSSI | SNR | Payload.... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D=3D1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|D| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSSI | SNR | Data Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ With this approach, we will have the flexibility to carry additional information if we need it on a per-packet basis, and only the default=20 header if we don't need it or are allowing the WTP to aggregate information. We will not need to make it mandatory for everyone to carry additional information. Comments ? Thanks, Abhijit -----Original Message----- From: Puneet Agarwal [ mailto:pagarwal@broadcom.com] Sent: Wednesday, April 05, 2006 3:49 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Hi Bob, It seems the real issue is what is the default mode of operation. Summary: --------- Pat/Bob: Carry the phy info in every CAPWAP data pkt as at least 1 implementation uses it Abhijit/Saravanan: Carry phy info in control msgs periodically and not in every CAPWAP data frame. My Proposal (Compromise): ------------------------- Sending the Phy info (RSSI/SNR/Speed) should be optional. By default this info should *NOT* be sent in every CAPWAP data packet. This capability should be negotiated at WTP<->AC handshake time. Comments? Thanks. -Puneet -----Original Message----- From: Bob O'Hara (boohara) [ mailto:boohara@cisco.com] Sent: Wednesday, April 05, 2006 7:15 AM To: capwap Subject: RE: [Capwap] Proposed Text for Issue 53 For those AC implementations that want to use per packet data for certain operations, aggregation of the data at the WTP as suggested by Abhijit will preclude this. The assertion by Saravanan that an AC does not process this information is incorrect. I can point to at least one existing implementation that already does process this information on a per packet basis. The current text, with the change I suggested, is the right way to handle this. If we want to ADD a capability that the WTP can provide aggregation, I have no objection to that. -Bob -----Original Message----- From: Saravanan Govindan [ mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Tuesday, April 04, 2006 4:49 PM To: Abhijit Choudhury; Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Hi Abhijit, I am in support of your suggestion. It is true that the AC does not process all data packets. Furthermore, I think for greater control, the AC will need information about the congestion level in the WLAN. This could be a derivative of interference and load factor. As for your suggestion, I think measurement/parameter information from the WTP should be sent over the periodic Echo Request messages. The advantage is that header overhead is reduced. I can prepare text for this approach. Cheers, Saravanan -----Original Message----- From: Abhijit Choudhury [ mailto:Abhijit@sinett.com] Sent: Wednesday, April 05, 2006 6:52 AM To: Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Here's another approach... RSSI, SNR, and Data Rate are measurements/parameters of the radio channel that are being reported to the AC for finer control. Carrying them in every data packet on the data channel means some logic or hardware in the AC will have to parse them out of every data packet and send them to the control path (CPU). Typically not every packet will go to the CPU and so this data will have to be stored and periodically sent to or read by the CPU. Note that the AC will be possibly dealing with tens to hundreds of WTPs and hence a potentially large number of STAs. This implies a large amount of per-STA measurement data has to be stored and moved from the data path to the CPU. A more reasonable approach is to let the WTP aggregate such data and periodically send it in the control channel to the AC. Note the WTP has to deal with much much fewer clients - so the storage burden is less. All we'd need is a frame that carries this information to the AC at a specified interval of time. This period could be configurable. Using this approach, we don't need to increase the CAPWAP header every time we need new measurement info. We can retain the current CAPWAP header and flexibly add any measurement information we need by adding it in the control channel. This is particularly important as we move forward to support 802.11n or other non-802.11 technlogies. It decouples the CAPWAP header from the measurement data related information. Any thoughts on this ? Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) [ mailto:pcalhoun@cisco.com] Sent: Monday, April 03, 2006 8:45 PM To: capwap Subject: [Capwap] Proposed Text for Issue 53 Here is my proposed text for Issue 53, which is the addition of a Data Rate In the CAPWAP header. Please let me know if you have any comments. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | <=3D=3D=3D CHANGED!!! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ [...] 4.1.8. Reserved This 32 bit field is reserved and may be used by a binding specific extension. Refer to the transport portion of the binding for a specific wireless technology for the definition of this field. [...] 11.3.2. CAPWAP Header Reserved field 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 5.5Mbps would be set to 55, while 11Mbps would be set to 110. 11.3.2.2. Destination WLANs The Destination WLAN field is used to specify the target WLANs for a given frame, and is only used with broadcast and multicast frames. This field allows the AC to transmit a single broadcast or multicast frame to the WTP, and allows the WTP to perform the necessary frame replication services. The field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WLAN: This bit field indicates the WLAN ID (see section Section 11.8.1.1) which the WTP will transmit the associated frame on. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be enabled. Note this field is to be set to zero for unicast packets and is unused if the WTP is not providing encryption services. Reserved: This field MUST be set to zero. 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 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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_01C65917.A246C40D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Hi = Abhijit,

 

For clarification, your suggestion = is to continue with having the WLAN ID field in CAPWAP packets for AC -> = WTP. However, for CAPWAP packets for WTP -> AC, your suggestion is to replace WLAN = ID field with the channel measurement information.

 

Is this right?

Cheers,

Saravanan

 

 

 

From: = Abhijit Choudhury [mailto:Abhijit@sinett.com]
Sent: Thursday, April 06, = 2006 8:22 AM
To: Puneet Agarwal; Bob = O'Hara (boohara); Pat Calhoun (pacalhou); capwap
Subject: RE: [Capwap] = Proposed Text for Issue 53

 

The default mode is not the only issue. As = Bob has
pointed out some AC implementations may use = per-packet

receive info for value added = functionalities.  Some others
may use transmit info (like number of = retries, transmit
rate) to do similar services and prefer that instead
or in addition.  And some may be prefer the WTP to = do

the aggregation.  So, now do we keep = adding all this

additional fields into the CAPWAP header = ?

Based on our current discussion, I would suggest having
extension capabilities in the CAPWAP header. The = current

CAPWAP header can be the default header. = (Note that we need

a 6 byte CAPWAP header for AC -> WTP = direction as we need

the WLAN ID field. So, we can also carry = RSSI/SNR for free).


Below are some possibilities :

1. We can use the VER (version) field for this .
For example, the current CAPWAP header can be VER 0.
Now if someone needs data rate or other stats, =

we can = define different size fields
(2bytes, 6 bytes etc) with the other encodings of VER.
This gives us the flexbility to do carry additional
information if the implementation needs it.
      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| RID |F|L|R|    Frag ID    |            Length           &= nbsp; |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     RSSI      |     SNR       |           Payload....         |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     

      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 1| RID |F|L|R|    Frag ID    |            Length           &= nbsp; |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     RSSI      |     SNR       |           Data Rate           |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Payload...  |
     +-+-+-+-+-+-+-+-+

2. Alternatively, we can use the current R bit as an option
flag (like L2TP). Data Rate (new D bit) could be a flag
and if set, would indicate a 2 byte field at the end
that carries data rate.

D=3D0      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |VER| RID |F|L|D|    Frag ID    = |            Length           &= nbsp; |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     RSSI      |     SNR       |           Payload....         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

D=3D1
      = 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |VER| RID |F|L|D|    Frag ID    |            Length           &= nbsp; |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     RSSI      |     SNR       |           Data Rate           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Payload...  |
     +-+-+-+-+-+-+-+-+

With this approach, we will have the = flexibility to carry additional

information if we need it on a = per-packet basis, and only the default

header if we don't need it or are allowing = the WTP to aggregate information.

We will not need to make it mandatory for = everyone to carry additional

information.


Comments ?

Thanks,
   Abhijit




-----Original Message-----
From: Puneet Agarwal [mailto:pagarwal@broadcom.com]
Sent: Wednesday, April 05, 2006 3:49 PM
To: Bob O'Hara (boohara); capwap
Subject: RE: [Capwap] Proposed Text for Issue 53


Hi Bob,

It seems the real issue is what is the default mode of operation.

Summary:
---------

Pat/Bob: Carry the phy info in every CAPWAP data pkt as at least 1 = implementation uses it
Abhijit/Saravanan: Carry phy info in control msgs periodically and not = in every CAPWAP data frame.

My Proposal (Compromise):
-------------------------
Sending the Phy info (RSSI/SNR/Speed) should be optional. By default = this info should *NOT* be sent in every CAPWAP data packet. This capability should = be negotiated at WTP<->AC handshake time.

Comments?

Thanks.

-Puneet


-----Original Message-----
From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]
Sent: Wednesday, April 05, 2006 7:15 AM
To: capwap
Subject: RE: [Capwap] Proposed Text for Issue 53

For those AC implementations that want to use per packet data for = certain operations, aggregation of the data at the WTP as suggested by Abhijit = will preclude this.  The assertion by Saravanan that an AC does not = process this information is incorrect.  I can point to at least one = existing implementation that already does process this information on a per = packet basis.

The current text, with the change I suggested, is the right way to = handle this.  If we want to ADD a capability that the WTP can provide aggregation, I have no objection to that.

 -Bob

-----Original Message-----
From: Saravanan Govindan = [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: Tuesday, April 04, 2006 4:49 PM
To: Abhijit Choudhury; Pat Calhoun (pacalhou); capwap
Subject: RE: [Capwap] Proposed Text for Issue 53

Hi Abhijit,

I am in support of your suggestion. It is true that the AC does not = process all data packets. Furthermore, I think for greater control, the AC will need information about the congestion level in the WLAN. This could be a = derivative of interference and load factor.

As for your suggestion, I think measurement/parameter information from = the WTP should be sent over the periodic Echo Request messages. The advantage is = that header overhead is reduced.

I can prepare text for this approach.

Cheers,

Saravanan





-----Original Message-----
From: Abhijit Choudhury [mailto:Abhijit@sinett.com]
Sent: Wednesday, April 05, 2006 6:52 AM
To: Pat Calhoun (pacalhou); capwap
Subject: RE: [Capwap] Proposed Text for Issue 53

Here's another approach...

RSSI, SNR, and Data Rate are measurements/parameters of the radio = channel that are being reported to the AC for finer control.  Carrying them in = every data packet on the data channel means some logic or hardware in the AC = will have to parse them out of every data packet and send them to the control = path (CPU).  Typically not every packet will go to the CPU and so this = data will have to be stored and periodically sent to or read by the = CPU.  Note that the AC will be possibly dealing with tens to hundreds of WTPs and = hence a potentially large number of STAs. This implies a large amount of per-STA measurement data has to be stored and moved from the data path to the = CPU.

A more reasonable approach is to let the WTP aggregate such data and periodically send it in the control channel to the AC.  Note the = WTP has to deal with much much fewer clients - so the storage burden is less. = All we'd need is a frame that carries this information to the AC at a specified = interval of time.  This period could be configurable.

Using this approach, we don't need to increase the CAPWAP header every = time we need new measurement info. We can retain the current CAPWAP header and = flexibly add any measurement information we need by adding it in the control = channel. This is particularly important as we move forward to support 802.11n or = other non-802.11 technlogies. It decouples the CAPWAP header from the = measurement data related information.

Any thoughts on this ?


Thanks,
   Abhijit




-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Monday, April 03, 2006 8:45 PM
To: capwap
Subject: [Capwap] Proposed Text for Issue 53


Here is my proposed text for Issue 53, which is the addition of a Data = Rate In the CAPWAP header.

Please let me know if you have any comments.

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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |VER| RID |F|L|R|    Frag ID    |            Length           &= nbsp; |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            =             &= nbsp;  Reserved           = ;            =      |
<=3D=3D=3D CHANGED!!!
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Payload...  |
     +-+-+-+-+-+-+-+-+

[...]
4.1.8.  Reserved

   This 32 bit field is reserved and may be used by a binding specific
   extension.  Refer to the transport portion of the = binding for a
   specific wireless technology for the definition of this = field.

[...]

11.3.2.  CAPWAP Header Reserved field

   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
      5.5Mbps would be set to 55, while 11Mbps = would be set to 110.

11.3.2.2.  Destination WLANs

   The Destination WLAN field is used to specify the target = WLANs for a
   given frame, and is only used with broadcast and multicast = frames.
   This field allows the AC to transmit a single broadcast or multicast
   frame to the WTP, and allows the WTP to perform the = necessary frame
   replication services.  The field 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
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            =   WLAN           &nb= sp; |            = Reserved           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   WLAN:  This bit field indicates the WLAN ID (see = section
      Section 11.8.1.1) which the WTP will = transmit the associated frame
      on.  For instance, if a multicast = packet is to be transmitted on
      WLANs 1 and 3, bits 1 and 3 of this field = would be enabled.  Note
      this field is to be set to zero for = unicast packets and is unused
      if the WTP is not providing encryption = services.

   Reserved:  This field MUST be set to zero.



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

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

Archives: http://lists.frascone.com/pipermail/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_01C65917.A246C40D-- --===============1878180533== 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 --===============1878180533==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Apr 05 21:24:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRJEj-0005Xk-NN for capwap-archive@lists.ietf.org; Wed, 05 Apr 2006 21:24:37 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRJEi-00088h-2T for capwap-archive@lists.ietf.org; Wed, 05 Apr 2006 21:24:37 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 38A0D43011B for ; Wed, 5 Apr 2006 18:24:35 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 5C0F343005A for ; Wed, 5 Apr 2006 18:23:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 41FEF39801B for ; Wed, 5 Apr 2006 18:23:25 -0700 (PDT) X-Greylist-Status: Sender first seen 14 days 07:49:19 ago Received: from sinett.com (63-197-255-151.ded.pacbell.net [63.197.255.151]) by zoidberg.tigertech.net (Postfix) with ESMTP id 81EF4398013 for ; Wed, 5 Apr 2006 18:23:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] Proposed Text for Issue 53 Date: Wed, 5 Apr 2006 18:23:18 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Text for Issue 53 thread-index: AcZXmiGYKUrUeU/XT1OcZaCvsWKBVgAnw06wAAH/5gAAHicW0AANpnXwAAYZKxAAA3XZkAAAdQxA From: "Abhijit Choudhury" To: "Saravanan Govindan" , "Puneet Agarwal" , "Bob O'Hara (boohara)" , "Pat Calhoun (pacalhou)" , "capwap" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.078 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO, HTML_60_70, 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="===============0126488012==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: eb264a413118f6f3ac858421dc72f27b This is a multi-part message in MIME format. --===============0126488012== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65918.AF4EEC88" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65918.AF4EEC88 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Saravanan, =20 That's how it is now. I am just proposing that we retain the current format as the default. And have options to add information if desired. =20 Thanks, Abhijit -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, April 05, 2006 6:16 PM To: Abhijit Choudhury; Puneet Agarwal; Bob O'Hara (boohara); Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 =09 =09 Hi Abhijit, =20 For clarification, your suggestion is to continue with having the WLAN ID field in CAPWAP packets for AC -> WTP. However, for CAPWAP packets for WTP -> AC, your suggestion is to replace WLAN ID field with the channel measurement information.=20 =20 Is this right?=20 =09 Cheers, =09 Saravanan =20 =20 =20 =09 ________________________________ From: Abhijit Choudhury [mailto:Abhijit@sinett.com]=20 Sent: Thursday, April 06, 2006 8:22 AM To: Puneet Agarwal; Bob O'Hara (boohara); Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 =20 The default mode is not the only issue. As Bob has pointed out some AC implementations may use per-packet receive info for value added functionalities. Some others=20 may use transmit info (like number of retries, transmit rate) to do similar services and prefer that instead or in addition. And some may be prefer the WTP to do the aggregation. So, now do we keep adding all this additional fields into the CAPWAP header ? =09 Based on our current discussion, I would suggest having extension capabilities in the CAPWAP header. The current CAPWAP header can be the default header. (Note that we need=20 a 6 byte CAPWAP header for AC -> WTP direction as we need=20 the WLAN ID field. So, we can also carry RSSI/SNR for free). =09 Below are some possibilities : =09 1. We can use the VER (version) field for this . For example, the current CAPWAP header can be VER 0. Now if someone needs data rate or other stats,=20 we can define different size fields (2bytes, 6 bytes etc) with the other encodings of VER. This gives us the flexbility to do carry additional information if the implementation needs it. 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 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0| RID |F|L|R| Frag ID | Length | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSSI | SNR | Payload.... | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =09 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 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1| RID |F|L|R| Frag ID | Length | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSSI | SNR | Data Rate | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ =09 2. Alternatively, we can use the current R bit as an option=20 flag (like L2TP). Data Rate (new D bit) could be a flag and if set, would indicate a 2 byte field at the end that carries data rate. D=3D0 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 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|D| Frag ID | Length | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSSI | SNR | Payload.... | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D=3D1 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 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|D| Frag ID | Length | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSSI | SNR | Data Rate | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ With this approach, we will have the flexibility to carry additional information if we need it on a per-packet basis, and only the default=20 header if we don't need it or are allowing the WTP to aggregate information. We will not need to make it mandatory for everyone to carry additional information. =09 Comments ? =09 Thanks, Abhijit =09 =09 =09 =09 -----Original Message----- From: Puneet Agarwal [mailto:pagarwal@broadcom.com ] Sent: Wednesday, April 05, 2006 3:49 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 =09 =09 Hi Bob, =09 It seems the real issue is what is the default mode of operation. =09 Summary: --------- =09 Pat/Bob: Carry the phy info in every CAPWAP data pkt as at least 1 implementation uses it Abhijit/Saravanan: Carry phy info in control msgs periodically and not in every CAPWAP data frame. =09 My Proposal (Compromise): ------------------------- Sending the Phy info (RSSI/SNR/Speed) should be optional. By default this info should *NOT* be sent in every CAPWAP data packet. This capability should be negotiated at WTP<->AC handshake time. =09 Comments? =09 Thanks. =09 -Puneet =09 =09 -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com ] Sent: Wednesday, April 05, 2006 7:15 AM To: capwap Subject: RE: [Capwap] Proposed Text for Issue 53 =09 For those AC implementations that want to use per packet data for certain operations, aggregation of the data at the WTP as suggested by Abhijit will preclude this. The assertion by Saravanan that an AC does not process this information is incorrect. I can point to at least one existing implementation that already does process this information on a per packet basis. =09 The current text, with the change I suggested, is the right way to handle this. If we want to ADD a capability that the WTP can provide aggregation, I have no objection to that. =09 -Bob =09 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com ] Sent: Tuesday, April 04, 2006 4:49 PM To: Abhijit Choudhury; Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 =09 Hi Abhijit, =09 I am in support of your suggestion. It is true that the AC does not process all data packets. Furthermore, I think for greater control, the AC will need information about the congestion level in the WLAN. This could be a derivative of interference and load factor. =09 As for your suggestion, I think measurement/parameter information from the WTP should be sent over the periodic Echo Request messages. The advantage is that header overhead is reduced. =09 I can prepare text for this approach. =09 Cheers, =09 Saravanan =09 =09 =09 =09 =09 -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com ] Sent: Wednesday, April 05, 2006 6:52 AM To: Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 =09 Here's another approach... =09 RSSI, SNR, and Data Rate are measurements/parameters of the radio channel that are being reported to the AC for finer control. Carrying them in every data packet on the data channel means some logic or hardware in the AC will have to parse them out of every data packet and send them to the control path (CPU). Typically not every packet will go to the CPU and so this data will have to be stored and periodically sent to or read by the CPU. Note that the AC will be possibly dealing with tens to hundreds of WTPs and hence a potentially large number of STAs. This implies a large amount of per-STA measurement data has to be stored and moved from the data path to the CPU. =09 A more reasonable approach is to let the WTP aggregate such data and periodically send it in the control channel to the AC. Note the WTP has to deal with much much fewer clients - so the storage burden is less. All we'd need is a frame that carries this information to the AC at a specified interval of time. This period could be configurable. =09 Using this approach, we don't need to increase the CAPWAP header every time we need new measurement info. We can retain the current CAPWAP header and flexibly add any measurement information we need by adding it in the control channel. This is particularly important as we move forward to support 802.11n or other non-802.11 technlogies. It decouples the CAPWAP header from the measurement data related information. =09 Any thoughts on this ? =09 =09 Thanks, Abhijit =09 =09 =09 =09 -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com ] Sent: Monday, April 03, 2006 8:45 PM To: capwap Subject: [Capwap] Proposed Text for Issue 53 =09 =09 Here is my proposed text for Issue 53, which is the addition of a Data Rate In the CAPWAP header. =09 Please let me know if you have any comments. =09 4.1. CAPWAP Transport Header =09 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. =09 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 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|R| Frag ID | Length | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | <=3D=3D=3D CHANGED!!! =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ =09 [...] 4.1.8. Reserved =09 This 32 bit field is reserved and may be used by a binding specific extension. Refer to the transport portion of the binding for a specific wireless technology for the definition of this field. =09 [...] =09 11.3.2. CAPWAP Header Reserved field =09 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. =09 11.3.2.1. IEEE 802.11 Frame Info =09 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. =09 When used with the IEEE 802.11 binding, the field follows the following format: =09 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 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSSI | SNR | Data Rate | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 RSSI: RSSI is a signed, 8-bit value. It is the received signal strength indication, in dBm. =09 SNR: SNR is a signed, 8-bit value. It is the signal to noise ratio of the received IEEE 802.11 frame, in dB. =09 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 5.5Mbps would be set to 55, while 11Mbps would be set to 110. =09 11.3.2.2. Destination WLANs =09 The Destination WLAN field is used to specify the target WLANs for a given frame, and is only used with broadcast and multicast frames. This field allows the AC to transmit a single broadcast or multicast frame to the WTP, and allows the WTP to perform the necessary frame replication services. The field uses the following format: =09 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 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN | Reserved | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 WLAN: This bit field indicates the WLAN ID (see section Section 11.8.1.1) which the WTP will transmit the associated frame on. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be enabled. Note this field is to be set to zero for unicast packets and is unused if the WTP is not providing encryption services. =09 Reserved: This field MUST be set to zero. =09 =09 =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 =20 =09 Archives: http://lists.frascone.com/pipermail/capwap =20 =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 =20 =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 =20 =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 =20 =09 =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 =20 ------_=_NextPart_001_01C65918.AF4EEC88 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message=
Saravanan,
 
That's how it is now. I am just proposing = that
we retain the current format as the = default.
And have options to add information if = desired.
 
Thanks,
  =20 Abhijit

-----Original Message-----
From: = Saravanan=20 Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: = Wednesday, April 05, 2006 6:16 PM
To: Abhijit Choudhury; = Puneet=20 Agarwal; Bob O'Hara (boohara); Pat Calhoun (pacalhou);=20 capwap
Subject: RE: [Capwap] Proposed Text for Issue=20 53

Hi=20 Abhijit,

 

For = clarification,=20 your suggestion is to continue with having the WLAN ID field in CAPWAP = packets=20 for AC -> WTP. However, for CAPWAP packets for WTP -> AC, your=20 suggestion is to replace WLAN ID field with the channel measurement=20 information.

 

Is this = right?=20

Cheers,

Saravanan

 

 

 

From: Abhijit=20 Choudhury [mailto:Abhijit@sinett.com]
Sent: Thursday, April 06, 2006 = 8:22=20 AM
To: Puneet = Agarwal; Bob=20 O'Hara (boohara); Pat Calhoun (pacalhou); capwap
Subject: RE: [Capwap] Proposed = Text for=20 Issue 53

 

The default mode = is not=20 the only issue. As Bob has
pointed out some AC implementations may = use=20 per-packet

receive info for = value=20 added functionalities.  Some others
may use=20 transmit info (like number of retries, transmit
rate) to do similar = services and prefer that instead
or in addition.  And some may = be=20 prefer the WTP to do

the = aggregation.  So,=20 now do we keep adding all this

additional = fields into the=20 CAPWAP header ?

Based on our current discussion, I would = suggest=20 having
extension capabilities in the CAPWAP header. The=20 current

CAPWAP header = can be the=20 default header. (Note that we need

a 6 byte CAPWAP = header for=20 AC -> WTP direction as we need

the WLAN ID = field. So, we=20 can also carry RSSI/SNR for free).


Below are=20 some possibilities :

1. We can use the VER (version) field for = this=20 .
For example, the current CAPWAP header can be VER 0.
Now if=20 someone needs data rate or other stats,=20

we = can=20 define different size fields
(2bytes, 6 bytes etc) with the other = encodings=20 of VER.
This gives us the flexbility to do carry = additional
information=20 if the implementation needs it.
     =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0=20 1 2 3 4 5 6 7 8 9 0 1
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |0 0| RID |F|L|R|    Frag ID   =20 |           =20 = Length           &= nbsp;=20 |
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |     RSSI     =20 |     SNR      =20 |          =20 Payload....        =20 |
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    

     =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0=20 1 2 3 4 5 6 7 8 9 0 1
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |0 1| RID |F|L|R|    Frag ID   =20 |           =20 = Length           &= nbsp;=20 |
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |     RSSI     =20 |     SNR      =20 |           Data=20 Rate          =20 |
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |   Payload...  |
    =20 +-+-+-+-+-+-+-+-+

2. Alternatively, we can use the current R = bit as an=20 option
flag (like L2TP). Data Rate (new D bit) could be a = flag
and if=20 set, would indicate a 2 byte field at the end
that carries data=20 rate.

D=3D0     =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0=20 1 2 3 4 5 6 7 8 9 0 1
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |VER| RID |F|L|D|    Frag ID   =20 |           =20 = Length           &= nbsp;=20 |
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |     RSSI     =20 |     SNR      =20 |          =20 Payload....        =20 |
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

D=3D1
     =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0=20 1 2 3 4 5 6 7 8 9 0 1
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |VER| RID |F|L|D|    Frag ID   =20 |           =20 = Length           &= nbsp;=20 |
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |     RSSI     =20 |     SNR      =20 |           Data=20 Rate          =20 |
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |   Payload...  |
    =20 +-+-+-+-+-+-+-+-+

With this = approach, we=20 will have the flexibility to carry=20 additional

information if = we need it=20 on a per-packet basis, and only the default=20

header if we = don't need it=20 or are allowing the WTP to aggregate=20 information.

We will not need = to make=20 it mandatory for everyone to carry=20 additional

information.


Comments=20 ?

Thanks,
   Abhijit




-----Original=20 Message-----
From: Puneet Agarwal [mailto:pagarwal@broadcom.com]
Sent:=20 Wednesday, April 05, 2006 3:49 PM
To: Bob O'Hara (boohara);=20 capwap
Subject: RE: [Capwap] Proposed Text for Issue = 53


Hi=20 Bob,

It seems the real issue is what is the default mode of=20 operation.

Summary:
---------

Pat/Bob: Carry the phy = info in=20 every CAPWAP data pkt as at least 1 implementation uses=20 it
Abhijit/Saravanan: Carry phy info in control msgs periodically = and not=20 in every CAPWAP data frame.

My Proposal=20 (Compromise):
-------------------------
Sending the Phy info=20 (RSSI/SNR/Speed) should be optional. By default this info should *NOT* = be sent=20 in every CAPWAP data packet. This capability should be negotiated at=20 WTP<->AC handshake=20 = time.

Comments?

Thanks.

-Puneet


-----Orig= inal=20 Message-----
From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]
Sent:=20 Wednesday, April 05, 2006 7:15 AM
To: capwap
Subject: RE: = [Capwap]=20 Proposed Text for Issue 53

For those AC implementations that = want to=20 use per packet data for certain operations, aggregation of the data at = the WTP=20 as suggested by Abhijit will preclude this.  The assertion by = Saravanan=20 that an AC does not process this information is incorrect.  I can = point=20 to at least one existing implementation that already does process this = information on a per packet basis.

The current text, with the = change I=20 suggested, is the right way to handle this.  If we want to ADD a=20 capability that the WTP can provide aggregation, I have no objection = to=20 that.

 -Bob

-----Original Message-----
From:=20 Saravanan Govindan=20 [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent:=20 Tuesday, April 04, 2006 4:49 PM
To: Abhijit Choudhury; Pat Calhoun=20 (pacalhou); capwap
Subject: RE: [Capwap] Proposed Text for Issue=20 53

Hi Abhijit,

I am in support of your suggestion. It is = true=20 that the AC does not process all data packets. Furthermore, I think = for=20 greater control, the AC will need information about the congestion = level in=20 the WLAN. This could be a derivative of interference and load=20 factor.

As for your suggestion, I think measurement/parameter=20 information from the WTP should be sent over the periodic Echo Request = messages. The advantage is that header overhead is reduced.

I = can=20 prepare text for this=20 = approach.

Cheers,

Saravanan





-----Ori= ginal=20 Message-----
From: Abhijit Choudhury [mailto:Abhijit@sinett.com]
Sent:=20 Wednesday, April 05, 2006 6:52 AM
To: Pat Calhoun (pacalhou);=20 capwap
Subject: RE: [Capwap] Proposed Text for Issue = 53

Here's=20 another approach...

RSSI, SNR, and Data Rate are=20 measurements/parameters of the radio channel that are being reported = to the AC=20 for finer control.  Carrying them in every data packet on the = data=20 channel means some logic or hardware in the AC will have to parse them = out of=20 every data packet and send them to the control path (CPU).  = Typically not=20 every packet will go to the CPU and so this data will have to be = stored and=20 periodically sent to or read by the CPU.  Note that the AC will = be=20 possibly dealing with tens to hundreds of WTPs and hence a potentially = large=20 number of STAs. This implies a large amount of per-STA measurement = data has to=20 be stored and moved from the data path to the CPU.

A more = reasonable=20 approach is to let the WTP aggregate such data and periodically send = it in the=20 control channel to the AC.  Note the WTP has to deal with much = much fewer=20 clients - so the storage burden is less. All we'd need is a frame that = carries=20 this information to the AC at a specified interval of time.  This = period=20 could be configurable.

Using this approach, we don't need to = increase=20 the CAPWAP header every time we need new measurement info. We can = retain the=20 current CAPWAP header and flexibly add any measurement information we = need by=20 adding it in the control channel. This is particularly important as we = move=20 forward to support 802.11n or other non-802.11 technlogies. It = decouples the=20 CAPWAP header from the measurement data related = information.

Any=20 thoughts on this ?


Thanks,
  =20 Abhijit




-----Original Message-----
From: Pat = Calhoun=20 (pacalhou) [mailto:pcalhoun@cisco.com]
Sent:=20 Monday, April 03, 2006 8:45 PM
To: capwap
Subject: [Capwap] = Proposed=20 Text for Issue 53


Here is my proposed text for Issue 53, = which is=20 the addition of a Data Rate In the CAPWAP header.

Please let me = know if=20 you have any comments.

4.1.  CAPWAP Transport=20 Header

   All CAPWAP protocol messages are = encapsulated using=20 a common header
   format, regardless of the CAPWAP = control or=20 CAPWAP Data transport
   used to carry the = messages. =20 However, certain flags are not
   applicable for a given=20 transport.  Refer to the specific transport
   = section in=20 order to determine which flags are=20 valid.

     =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0=20 1 2 3 4 5 6 7 8 9 0 1
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |VER| RID |F|L|R|    Frag ID   =20 |           =20 = Length           &= nbsp;=20 |
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 = |            =             &= nbsp; =20 = Reserved           = ;            =     =20 |
<=3D=3D=3D CHANGED!!!
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |   Payload...  |
    =20 +-+-+-+-+-+-+-+-+

[...]
4.1.8.  = Reserved

  =20 This 32 bit field is reserved and may be used by a binding=20 specific
   extension.  Refer to the transport = portion of=20 the binding for a
   specific wireless technology for the = definition of this field.

[...]

11.3.2.  CAPWAP = Header=20 Reserved field

   The reserved CAPWAP header field = (see=20 figure Section 4.1) is only
   used with CAPWAP data = frames, and=20 it serves two purposes, depending
   upon the direction = of the=20 frame.  For packets from the WTP to the AC,
   the = field=20 uses the format described in Section 11.3.2.1.  = However,
  =20 for frames sent by the AC to the WTP, the format used is described=20 in
   described in Section = 11.3.2.2.

11.3.2.1.  IEEE=20 802.11 Frame Info

   When an CAPWAP data frame is = received=20 from a station over the air, it
   is encapsulated and = this field=20 is used to include radio and PHY
   specific information=20 associated with the frame.

   When used with the IEEE = 802.11=20 binding, the field follows the
   following=20 format:

     =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0=20 1 2 3 4 5 6 7 8 9 0 1
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |     RSSI     =20 |     SNR      =20 |           Data=20 Rate          =20 |
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=   =20 RSSI:  RSSI is a signed, 8-bit value.  It is the received=20 signal
      strength indication, in=20 dBm.

   SNR:  SNR is a signed, 8-bit = value.  It is=20 the signal to noise ratio
      of the = received=20 IEEE 802.11 frame, in dB.

   Data Rate:  The = data rate=20 field is a 16 bit unsigned value.  = The
     =20 contents of the field is set to 1/10th of the data rate of=20 the
      packet received by the = WTP.  For=20 instance, a packet received at
      = 5.5Mbps would=20 be set to 55, while 11Mbps would be set to 110.

11.3.2.2.  = Destination WLANs

   The Destination WLAN field is = used to=20 specify the target WLANs for a
   given frame, and is = only used=20 with broadcast and multicast frames.
   This field allows = the AC=20 to transmit a single broadcast or multicast
   frame to = the WTP,=20 and allows the WTP to perform the necessary frame
   = replication=20 services.  The field uses the following=20 format:

     =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0=20 1 2 3 4 5 6 7 8 9 0 1
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 = |            =  =20 = WLAN           &nb= sp;=20 |           =20 Reserved          =20 |
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=   =20 WLAN:  This bit field indicates the WLAN ID (see=20 section
      Section 11.8.1.1) which the = WTP will=20 transmit the associated frame
      = on.  For=20 instance, if a multicast packet is to be transmitted=20 on
      WLANs 1 and 3, bits 1 and 3 of = this field=20 would be enabled.  Note
      this = field is=20 to be set to zero for unicast packets and is=20 unused
      if the WTP is not providing=20 encryption services.

   Reserved:  This field = MUST be=20 set to zero.



Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems=20 = _________________________________________________________________
To=20 unsubscribe or modify your subscription options, please visit:=20 http://lists.frascone.com/mailman/listinfo/capwap=

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

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

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

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

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

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

------_=_NextPart_001_01C65918.AF4EEC88-- --===============0126488012== 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 --===============0126488012==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Apr 05 22:23:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRKA4-0003cB-L7 for capwap-archive@lists.ietf.org; Wed, 05 Apr 2006 22:23:52 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRKA2-0001VB-SL for capwap-archive@lists.ietf.org; Wed, 05 Apr 2006 22:23:52 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 474EC430116 for ; Wed, 5 Apr 2006 19:23:50 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E5C5F43005A for ; Wed, 5 Apr 2006 19:23:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id CBF4139800F for ; Wed, 5 Apr 2006 19:23:20 -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 D905E398013 for ; Wed, 5 Apr 2006 19:23:18 -0700 (PDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 05 Apr 2006 19:23:18 -0700 X-IronPort-AV: i="4.04,91,1144047600"; d="scan'208"; a="1792224990:sNHT96856046" 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 k362NH1j025145; Wed, 5 Apr 2006 19:23:17 -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, 5 Apr 2006 19:23: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] Proposed Text for Issue 53 Date: Wed, 5 Apr 2006 19:23:16 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC015D61C1@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Text for Issue 53 Thread-Index: AcZXmiGYKUrUeU/XT1OcZaCvsWKBVgAnw06wAAH/5gAAHicW0AANpnXwAAwoBZA= From: "Bob O'Hara (boohara)" To: "Puneet Agarwal" , "capwap" X-OriginalArrivalTime: 06 Apr 2006 02:23:17.0818 (UTC) FILETIME=[10DA69A0:01C65921] 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: 3f3e54d3c03ed638c06aa9fa6861237e Puneet, Optional fields in a packet are just plain evil.=20 -Bob =20 -----Original Message----- From: Puneet Agarwal [mailto:pagarwal@broadcom.com]=20 Sent: Wednesday, April 05, 2006 3:49 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Hi Bob, It seems the real issue is what is the default mode of operation. Summary: --------- Pat/Bob: Carry the phy info in every CAPWAP data pkt as at least 1 implementation uses it Abhijit/Saravanan: Carry phy info in control msgs periodically and not in every CAPWAP data frame. My Proposal (Compromise): ------------------------- Sending the Phy info (RSSI/SNR/Speed) should be optional. By default this info should *NOT* be sent in every CAPWAP data packet. This capability should be negotiated at WTP<->AC handshake time. Comments? Thanks. -Puneet -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Wednesday, April 05, 2006 7:15 AM To: capwap Subject: RE: [Capwap] Proposed Text for Issue 53 For those AC implementations that want to use per packet data for certain operations, aggregation of the data at the WTP as suggested by Abhijit will preclude this. The assertion by Saravanan that an AC does not process this information is incorrect. I can point to at least one existing implementation that already does process this information on a per packet basis. The current text, with the change I suggested, is the right way to handle this. If we want to ADD a capability that the WTP can provide aggregation, I have no objection to that. -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Tuesday, April 04, 2006 4:49 PM To: Abhijit Choudhury; Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Hi Abhijit, I am in support of your suggestion. It is true that the AC does not process all data packets. Furthermore, I think for greater control, the AC will need information about the congestion level in the WLAN. This could be a derivative of interference and load factor.=20 As for your suggestion, I think measurement/parameter information from the WTP should be sent over the periodic Echo Request messages. The advantage is that header overhead is reduced.=20 I can prepare text for this approach. Cheers, Saravanan =20 -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com] Sent: Wednesday, April 05, 2006 6:52 AM To: Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Here's another approach... RSSI, SNR, and Data Rate are measurements/parameters of the radio channel that are being reported to the AC for finer control. Carrying them in every data packet on the data channel means some logic or hardware in the AC will have to parse them out of every data packet and send them to the control path (CPU). Typically not every packet will go to the CPU and so this data will have to be stored and periodically sent to or read by the CPU. Note that the AC will be possibly dealing with tens to hundreds of WTPs and hence a potentially large number of STAs. This implies a large amount of per-STA measurement data has to be stored and moved from the data path to the CPU. A more reasonable approach is to let the WTP aggregate such data and periodically send it in the control channel to the AC. Note the WTP has to deal with much much fewer clients - so the storage burden is less. All we'd need is a frame that carries this information to the AC at a specified interval of time. This period could be configurable. Using this approach, we don't need to increase the CAPWAP header every time we need new measurement info. We can retain the current CAPWAP header and flexibly add any measurement information we need by adding it in the control channel. This is particularly important as we move forward to support 802.11n or other non-802.11 technlogies. It decouples the CAPWAP header from the measurement data related information. Any thoughts on this ? Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Monday, April 03, 2006 8:45 PM To: capwap Subject: [Capwap] Proposed Text for Issue 53 Here is my proposed text for Issue 53, which is the addition of a Data Rate In the CAPWAP header. Please let me know if you have any comments. =20 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | <=3D=3D=3D CHANGED!!! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ [...] 4.1.8. Reserved This 32 bit field is reserved and may be used by a binding specific extension. Refer to the transport portion of the binding for a specific wireless technology for the definition of this field. [...] 11.3.2. CAPWAP Header Reserved field 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 5.5Mbps would be set to 55, while 11Mbps would be set to 110. 11.3.2.2. Destination WLANs The Destination WLAN field is used to specify the target WLANs for a given frame, and is only used with broadcast and multicast frames. This field allows the AC to transmit a single broadcast or multicast frame to the WTP, and allows the WTP to perform the necessary frame replication services. The field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WLAN: This bit field indicates the WLAN ID (see section Section 11.8.1.1) which the WTP will transmit the associated frame on. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be enabled. Note this field is to be set to zero for unicast packets and is unused if the WTP is not providing encryption services. Reserved: This field MUST be set to zero. =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 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 Apr 05 22:26:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRKCO-0004Uy-Me for capwap-archive@lists.ietf.org; Wed, 05 Apr 2006 22:26:16 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRKCN-0001ch-Tz for capwap-archive@lists.ietf.org; Wed, 05 Apr 2006 22:26:16 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4188C430128 for ; Wed, 5 Apr 2006 19:26:15 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C002443005A for ; Wed, 5 Apr 2006 19:25:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8599B1448022 for ; Wed, 5 Apr 2006 19:25:42 -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 8F8BC144800F for ; Wed, 5 Apr 2006 19:25:40 -0700 (PDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 05 Apr 2006 19:25:40 -0700 X-IronPort-AV: i="4.04,91,1144047600"; d="scan'208"; a="1792225610:sNHT100474688" 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 k362Pc1l026089; Wed, 5 Apr 2006 19:25: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); Wed, 5 Apr 2006 19:25: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: [Capwap] Proposed Text for Issue 53 Date: Wed, 5 Apr 2006 19:25:36 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC015D61C3@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Text for Issue 53 Thread-Index: AcZXmiGYKUrUeU/XT1OcZaCvsWKBVgAnw06wAAH/5gAAHicW0AAV2e5gAAQCVeA= From: "Bob O'Hara (boohara)" To: "Saravanan Govindan" , "capwap" X-OriginalArrivalTime: 06 Apr 2006 02:25:39.0128 (UTC) FILETIME=[65149B80:01C65921] X-Virus-Scanned: by amavisd-new-20030616-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: 850245b51c39701e2700a112f3032caa So, your preference is to remove functionality that is already in a product available today, by eliminating this capability from the protocol. Given Moore's law advancement of processing capability, this seems a bit short sighted.=20 -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, April 05, 2006 5:33 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Bob, I will accept that there is an AC implementation for per data packet processing.=20 I still prefer that the CAPWAP protocol aggregate measurement information for periodic exchange.=20 Saravanan =20 -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Wednesday, April 05, 2006 10:15 PM To: capwap Subject: RE: [Capwap] Proposed Text for Issue 53 For those AC implementations that want to use per packet data for certain operations, aggregation of the data at the WTP as suggested by Abhijit will preclude this. The assertion by Saravanan that an AC does not process this information is incorrect. I can point to at least one existing implementation that already does process this information on a per packet basis. The current text, with the change I suggested, is the right way to handle this. If we want to ADD a capability that the WTP can provide aggregation, I have no objection to that. -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Tuesday, April 04, 2006 4:49 PM To: Abhijit Choudhury; Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Hi Abhijit, I am in support of your suggestion. It is true that the AC does not process all data packets. Furthermore, I think for greater control, the AC will need information about the congestion level in the WLAN. This could be a derivative of interference and load factor.=20 As for your suggestion, I think measurement/parameter information from the WTP should be sent over the periodic Echo Request messages. The advantage is that header overhead is reduced.=20 I can prepare text for this approach. Cheers, Saravanan =20 -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com]=20 Sent: Wednesday, April 05, 2006 6:52 AM To: Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Here's another approach... RSSI, SNR, and Data Rate are measurements/parameters of the radio channel that are being reported to the=20 AC for finer control. Carrying them in every data packet on the data channel means some logic or hardware in the AC will have to parse them out of every data packet and send them to the control path (CPU). Typically not every packet will go to the CPU and so this data will=20 have to be stored and periodically sent to or read=20 by the CPU. Note that the AC will be possibly dealing=20 with tens to hundreds of WTPs and hence a=20 potentially large number of STAs. This implies a=20 large amount of per-STA measurement data has to be stored and moved from the data path to the CPU. A more reasonable approach is to let the WTP=20 aggregate such data and periodically send it in the=20 control channel to the AC. Note the WTP has to deal with much much fewer clients - so the storage burden is less. All we'd need is a frame that carries this information to the AC at a specified=20 interval of time. This period could be configurable. Using this approach, we don't need to increase the CAPWAP header every time we need new measurement info. We can retain the current CAPWAP header and flexibly add any measurement information we need by adding it in the control channel. This is particularly important as we move forward to support 802.11n or other=20 non-802.11 technlogies. It decouples the CAPWAP header from the measurement data related information. Any thoughts on this ? Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Monday, April 03, 2006 8:45 PM To: capwap Subject: [Capwap] Proposed Text for Issue 53 Here is my proposed text for Issue 53, which is the addition of a Data Rate In the CAPWAP header. Please let me know if you have any comments. =20 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | <=3D=3D=3D CHANGED!!! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ [...] 4.1.8. Reserved This 32 bit field is reserved and may be used by a binding specific extension. Refer to the transport portion of the binding for a specific wireless technology for the definition of this field. [...] 11.3.2. CAPWAP Header Reserved field 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 5.5Mbps would be set to 55, while 11Mbps would be set to 110. 11.3.2.2. Destination WLANs The Destination WLAN field is used to specify the target WLANs for a given frame, and is only used with broadcast and multicast frames. This field allows the AC to transmit a single broadcast or multicast frame to the WTP, and allows the WTP to perform the necessary frame replication services. The field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WLAN: This bit field indicates the WLAN ID (see section Section 11.8.1.1) which the WTP will transmit the associated frame on. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be enabled. Note this field is to be set to zero for unicast packets and is unused if the WTP is not providing encryption services. Reserved: This field MUST be set to zero. =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 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 Apr 05 23:42:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRLOd-0001HX-0I for capwap-archive@lists.ietf.org; Wed, 05 Apr 2006 23:42:59 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRLOb-0004GS-7z for capwap-archive@lists.ietf.org; Wed, 05 Apr 2006 23:42:58 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4976343010B for ; Wed, 5 Apr 2006 20:42:56 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id CBB3443005A for ; Wed, 5 Apr 2006 20:42:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id BC17039801B for ; Wed, 5 Apr 2006 20:42:30 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 95E0A398020 for ; Wed, 5 Apr 2006 20:42:27 -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 k363gOle004382; Thu, 6 Apr 2006 12:42:24 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k363gQ127461; Thu, 6 Apr 2006 12:42:26 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with SMTP id k363gNS08546; Thu, 6 Apr 2006 12:42:23 +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] Proposed Text for Issue 53 Date: Thu, 6 Apr 2006 11:40:53 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDC778AF@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Text for Issue 53 Thread-Index: AcZXmiGYKUrUeU/XT1OcZaCvsWKBVgAnw06wAAH/5gAAHicW0AAV2e5gAAQCVeAAAewBIA== From: "Saravanan Govindan" To: "Bob O'Hara (boohara)" , "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: 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: fb93e867a11a29ac1dc5018706b412ac Bob, Without going in to pseudo-judicial rhetoric, I think we need to look at what is needed for the CAPWAP protocol.=20 >From the exchanges so far, we see that measurement information can be exchanged on a per data packet basis or on an aggregated basis. We have seen the advantages of exchanging then on aggregated basis. In the spirit of quick resolution, I suggest we select one as the default mode for CAPWAP and have the other as an additional feature. I believe this was suggested earlier also.=20 Saravanan -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Thursday, April 06, 2006 10:26 AM To: Saravanan Govindan; capwap Subject: RE: [Capwap] Proposed Text for Issue 53 So, your preference is to remove functionality that is already in a product available today, by eliminating this capability from the protocol. Given Moore's law advancement of processing capability, this seems a bit short sighted.=20 -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, April 05, 2006 5:33 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Bob, I will accept that there is an AC implementation for per data packet processing.=20 I still prefer that the CAPWAP protocol aggregate measurement information for periodic exchange.=20 Saravanan =20 -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Wednesday, April 05, 2006 10:15 PM To: capwap Subject: RE: [Capwap] Proposed Text for Issue 53 For those AC implementations that want to use per packet data for certain operations, aggregation of the data at the WTP as suggested by Abhijit will preclude this. The assertion by Saravanan that an AC does not process this information is incorrect. I can point to at least one existing implementation that already does process this information on a per packet basis. The current text, with the change I suggested, is the right way to handle this. If we want to ADD a capability that the WTP can provide aggregation, I have no objection to that. -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Tuesday, April 04, 2006 4:49 PM To: Abhijit Choudhury; Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Hi Abhijit, I am in support of your suggestion. It is true that the AC does not process all data packets. Furthermore, I think for greater control, the AC will need information about the congestion level in the WLAN. This could be a derivative of interference and load factor.=20 As for your suggestion, I think measurement/parameter information from the WTP should be sent over the periodic Echo Request messages. The advantage is that header overhead is reduced.=20 I can prepare text for this approach. Cheers, Saravanan =20 -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com]=20 Sent: Wednesday, April 05, 2006 6:52 AM To: Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Here's another approach... RSSI, SNR, and Data Rate are measurements/parameters of the radio channel that are being reported to the=20 AC for finer control. Carrying them in every data packet on the data channel means some logic or hardware in the AC will have to parse them out of every data packet and send them to the control path (CPU). Typically not every packet will go to the CPU and so this data will=20 have to be stored and periodically sent to or read=20 by the CPU. Note that the AC will be possibly dealing=20 with tens to hundreds of WTPs and hence a=20 potentially large number of STAs. This implies a=20 large amount of per-STA measurement data has to be stored and moved from the data path to the CPU. A more reasonable approach is to let the WTP=20 aggregate such data and periodically send it in the=20 control channel to the AC. Note the WTP has to deal with much much fewer clients - so the storage burden is less. All we'd need is a frame that carries this information to the AC at a specified=20 interval of time. This period could be configurable. Using this approach, we don't need to increase the CAPWAP header every time we need new measurement info. We can retain the current CAPWAP header and flexibly add any measurement information we need by adding it in the control channel. This is particularly important as we move forward to support 802.11n or other=20 non-802.11 technlogies. It decouples the CAPWAP header from the measurement data related information. Any thoughts on this ? Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Monday, April 03, 2006 8:45 PM To: capwap Subject: [Capwap] Proposed Text for Issue 53 Here is my proposed text for Issue 53, which is the addition of a Data Rate In the CAPWAP header. Please let me know if you have any comments. =20 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | <=3D=3D=3D CHANGED!!! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ [...] 4.1.8. Reserved This 32 bit field is reserved and may be used by a binding specific extension. Refer to the transport portion of the binding for a specific wireless technology for the definition of this field. [...] 11.3.2. CAPWAP Header Reserved field 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 5.5Mbps would be set to 55, while 11Mbps would be set to 110. 11.3.2.2. Destination WLANs The Destination WLAN field is used to specify the target WLANs for a given frame, and is only used with broadcast and multicast frames. This field allows the AC to transmit a single broadcast or multicast frame to the WTP, and allows the WTP to perform the necessary frame replication services. The field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WLAN: This bit field indicates the WLAN ID (see section Section 11.8.1.1) which the WTP will transmit the associated frame on. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be enabled. Note this field is to be set to zero for unicast packets and is unused if the WTP is not providing encryption services. Reserved: This field MUST be set to zero. =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 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 Apr 06 13:16:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRY5b-0006LS-Qf for capwap-archive@lists.ietf.org; Thu, 06 Apr 2006 13:16:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRY5a-0008K8-43 for capwap-archive@lists.ietf.org; Thu, 06 Apr 2006 13:16:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2C99443013D for ; Thu, 6 Apr 2006 10:16:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 49ACE43004F for ; Thu, 6 Apr 2006 10:15:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 70E391448035 for ; Thu, 6 Apr 2006 10:15:37 -0700 (PDT) X-Greylist-Status: Sender first seen 00:01:01 ago Received: from test-iport-1.cisco.com (test-iport-1.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id 1611E1448030 for ; Thu, 6 Apr 2006 10:15:33 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-1.cisco.com with ESMTP; 06 Apr 2006 10:14:32 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k36HEUw5024457; Thu, 6 Apr 2006 10:14:32 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Apr 2006 10:14: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] Proposed Text for Issue 53 Date: Thu, 6 Apr 2006 10:14:30 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC015D638B@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Text for Issue 53 Thread-Index: AcZXmiGYKUrUeU/XT1OcZaCvsWKBVgAnw06wAAH/5gAAHicW0AAV2e5gAAQCVeAAAewBIAAdCSWA From: "Bob O'Hara (boohara)" To: "Saravanan Govindan" , "capwap" X-OriginalArrivalTime: 06 Apr 2006 17:14:31.0718 (UTC) FILETIME=[91C80460:01C6599D] X-Virus-Scanned: by amavisd-new-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 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: 343d06d914165ffd9d590a64755216ca Saranavan, As I said in another email earlier in the thread than the one to which you responded, I do not have an objection to adding the reporting of aggregated information in a status report or other message. I do not want to lose the ability to deal with or have access to the real time information in the AC, on a packet by packet basis. Why do you object to enabling a function such as real time processing of the packet RSSI and SNR? -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, April 05, 2006 8:41 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Bob, Without going in to pseudo-judicial rhetoric, I think we need to look at what is needed for the CAPWAP protocol.=20 >From the exchanges so far, we see that measurement information can be exchanged on a per data packet basis or on an aggregated basis. We have seen the advantages of exchanging then on aggregated basis. In the spirit of quick resolution, I suggest we select one as the default mode for CAPWAP and have the other as an additional feature. I believe this was suggested earlier also.=20 Saravanan -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Thursday, April 06, 2006 10:26 AM To: Saravanan Govindan; capwap Subject: RE: [Capwap] Proposed Text for Issue 53 So, your preference is to remove functionality that is already in a product available today, by eliminating this capability from the protocol. Given Moore's law advancement of processing capability, this seems a bit short sighted.=20 -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, April 05, 2006 5:33 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Bob, I will accept that there is an AC implementation for per data packet processing.=20 I still prefer that the CAPWAP protocol aggregate measurement information for periodic exchange.=20 Saravanan =20 -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Wednesday, April 05, 2006 10:15 PM To: capwap Subject: RE: [Capwap] Proposed Text for Issue 53 For those AC implementations that want to use per packet data for certain operations, aggregation of the data at the WTP as suggested by Abhijit will preclude this. The assertion by Saravanan that an AC does not process this information is incorrect. I can point to at least one existing implementation that already does process this information on a per packet basis. The current text, with the change I suggested, is the right way to handle this. If we want to ADD a capability that the WTP can provide aggregation, I have no objection to that. -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Tuesday, April 04, 2006 4:49 PM To: Abhijit Choudhury; Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Hi Abhijit, I am in support of your suggestion. It is true that the AC does not process all data packets. Furthermore, I think for greater control, the AC will need information about the congestion level in the WLAN. This could be a derivative of interference and load factor.=20 As for your suggestion, I think measurement/parameter information from the WTP should be sent over the periodic Echo Request messages. The advantage is that header overhead is reduced.=20 I can prepare text for this approach. Cheers, Saravanan =20 -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com]=20 Sent: Wednesday, April 05, 2006 6:52 AM To: Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Here's another approach... RSSI, SNR, and Data Rate are measurements/parameters of the radio channel that are being reported to the=20 AC for finer control. Carrying them in every data packet on the data channel means some logic or hardware in the AC will have to parse them out of every data packet and send them to the control path (CPU). Typically not every packet will go to the CPU and so this data will=20 have to be stored and periodically sent to or read=20 by the CPU. Note that the AC will be possibly dealing=20 with tens to hundreds of WTPs and hence a=20 potentially large number of STAs. This implies a=20 large amount of per-STA measurement data has to be stored and moved from the data path to the CPU. A more reasonable approach is to let the WTP=20 aggregate such data and periodically send it in the=20 control channel to the AC. Note the WTP has to deal with much much fewer clients - so the storage burden is less. All we'd need is a frame that carries this information to the AC at a specified=20 interval of time. This period could be configurable. Using this approach, we don't need to increase the CAPWAP header every time we need new measurement info. We can retain the current CAPWAP header and flexibly add any measurement information we need by adding it in the control channel. This is particularly important as we move forward to support 802.11n or other=20 non-802.11 technlogies. It decouples the CAPWAP header from the measurement data related information. Any thoughts on this ? Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Monday, April 03, 2006 8:45 PM To: capwap Subject: [Capwap] Proposed Text for Issue 53 Here is my proposed text for Issue 53, which is the addition of a Data Rate In the CAPWAP header. Please let me know if you have any comments. =20 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | <=3D=3D=3D CHANGED!!! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ [...] 4.1.8. Reserved This 32 bit field is reserved and may be used by a binding specific extension. Refer to the transport portion of the binding for a specific wireless technology for the definition of this field. [...] 11.3.2. CAPWAP Header Reserved field 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 5.5Mbps would be set to 55, while 11Mbps would be set to 110. 11.3.2.2. Destination WLANs The Destination WLAN field is used to specify the target WLANs for a given frame, and is only used with broadcast and multicast frames. This field allows the AC to transmit a single broadcast or multicast frame to the WTP, and allows the WTP to perform the necessary frame replication services. The field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WLAN: This bit field indicates the WLAN ID (see section Section 11.8.1.1) which the WTP will transmit the associated frame on. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be enabled. Note this field is to be set to zero for unicast packets and is unused if the WTP is not providing encryption services. Reserved: This field MUST be set to zero. =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 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 Apr 06 19:45:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FReAL-0004bf-9Z for capwap-archive@lists.ietf.org; Thu, 06 Apr 2006 19:45:29 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FReAJ-00041K-S9 for capwap-archive@lists.ietf.org; Thu, 06 Apr 2006 19:45:29 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0576943005A for ; Thu, 6 Apr 2006 16:45:27 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2FC8943005A for ; Thu, 6 Apr 2006 16:44:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 158B4144801D for ; Thu, 6 Apr 2006 16:44:41 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.201]) by hermes.tigertech.net (Postfix) with ESMTP id 2E1AD1448015 for ; Thu, 6 Apr 2006 16:44:40 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so193827wxd for ; Thu, 06 Apr 2006 16:44:39 -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=tWCdnh4XpnzXkrlhjfCmuvDDEqqt/ncBVWaHFhlP9iuB0AObYwybtBRI7BOHhAc1u/OOY4hxa69DYz02W0HXgfgx+AtPSSO4+dOfhsLV3zLD7kJBX+5UfnQELTaniJVYph+/bbxDE+KNjX1IhiWl4w4QW0NYaKIpM/AvqSzaW7w= Received: by 10.70.30.19 with SMTP id d19mr855700wxd; Thu, 06 Apr 2006 16:44:39 -0700 (PDT) Received: by 10.70.133.14 with HTTP; Thu, 6 Apr 2006 16:44:39 -0700 (PDT) Message-ID: <5bfe7a820604061644h43105e01h9fd46fa43f17e9f8@mail.gmail.com> Date: Thu, 6 Apr 2006 16:44:39 -0700 From: "Dorothy Stanley" To: "Saravanan Govindan" , pagarwal@broadcom.com Subject: Re: [Capwap] Proposed Text for Issue 53 In-Reply-To: <5F09D220B62F79418461A978CA0921BDC77837@pslexc01.psl.local> MIME-Version: 1.0 References: <5F09D220B62F79418461A978CA0921BDC77837@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_40_50, HTML_MESSAGE, 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: , Content-Type: multipart/mixed; boundary="===============0082202857==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 --===============0082202857== Content-Type: multipart/alternative; boundary="----=_Part_4349_23769896.1144367079197" ------=_Part_4349_23769896.1144367079197 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Puneet, Would WTP support of the "sending the phy info in every packet" capability be (a) mandatory to implement and optional to configure? or (b) optional to implement? Sending the Phy info (RSSI/SNR/Speed) should be optional. By default this info should *NOT* be sent in every CAPWAP data packet. This capability should be negotiated at WTP<->AC handshake time. Thanks, Dorothy > > Hi Bob, > > It seems the real issue is what is the default mode of operation. > > Summary: > --------- > > Pat/Bob: Carry the phy info in every CAPWAP data pkt as at least 1 > implementation uses it > Abhijit/Saravanan: Carry phy info in control msgs periodically and not in > every CAPWAP data frame. > > My Proposal (Compromise): > ------------------------- > Sending the Phy info (RSSI/SNR/Speed) should be optional. By default this > info should *NOT* be sent in every CAPWAP data packet. This capability > should be negotiated at WTP<->AC handshake time. > > Comments? > > Thanks. > > -Puneet > > > > > ------=_Part_4349_23769896.1144367079197 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Puneet,

Would WTP support of the "sending the phy info in every packet" c= apability
be

(a) mandatory to implement and optional to configure?  or
(b) optional to implement?

Sending the Phy info (RSSI/SNR/Speed) should be optional. By default this i= nfo should *NOT* be sent in every CAPWAP data packet. This capability should be negotiated at WTP<->AC handshake time.

Thanks,

Dorothy

Hi Bob,

It seems the real issue is what is the default mode of operation.

Summary:
---------

Pat/Bob: Carry the phy info in every CAPWAP data pkt as at least 1 implemen= tation uses it
Abhijit/Saravanan: Carry phy info in control msgs periodically and not in e= very CAPWAP data frame.

My Proposal (Compromise):
-------------------------
Sending the Phy info (RSSI/SNR/Speed) should be optional. By default this i= nfo should *NOT* be sent in every CAPWAP data packet. This capability should be negotiated at WTP<->AC handshake time.

Comments?

Thanks.

-Puneet





------=_Part_4349_23769896.1144367079197-- --===============0082202857== 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 --===============0082202857==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Apr 06 21:15:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRfZe-00047L-N8 for capwap-archive@lists.ietf.org; Thu, 06 Apr 2006 21:15:42 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRfZc-0007JF-TQ for capwap-archive@lists.ietf.org; Thu, 06 Apr 2006 21:15:42 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C6AD4430138 for ; Thu, 6 Apr 2006 18:15:39 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 307CE4300B3 for ; Thu, 6 Apr 2006 18:15:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 20400398023 for ; Thu, 6 Apr 2006 18:15:13 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 091B2398015 for ; Thu, 6 Apr 2006 18:15:10 -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 k371F7DA007576; Fri, 7 Apr 2006 10:15:07 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k371F9619661; Fri, 7 Apr 2006 10:15:09 +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 k371F8s06205; Fri, 7 Apr 2006 10:15:08 +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] Proposed Text for Issue 53 Date: Fri, 7 Apr 2006 09:13:39 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDC77A17@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Text for Issue 53 Thread-Index: AcZXmiGYKUrUeU/XT1OcZaCvsWKBVgAnw06wAAH/5gAAHicW0AAV2e5gAAQCVeAAAewBIAAdCSWAABDYbCA= From: "Saravanan Govindan" To: "Bob O'Hara (boohara)" , "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: 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: 9e5c23589e6cce06555030c0194c9e2b Bob, I understand from your note that per data packet measurement is the basis for real time AC processing. My support for aggregated measurement exchange is based on efficiency considerations. Having said this, I do not want to exclude one or the other - the exchanges so far show both make for valuable additions to CAPWAP. I think we can move forward now maintaining / incorporating both types of exchanges in to the CAPWAP specs. Saravanan -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Friday, April 07, 2006 1:15 AM To: Saravanan Govindan; capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Saranavan, As I said in another email earlier in the thread than the one to which you responded, I do not have an objection to adding the reporting of aggregated information in a status report or other message. I do not want to lose the ability to deal with or have access to the real time information in the AC, on a packet by packet basis. Why do you object to enabling a function such as real time processing of the packet RSSI and SNR? -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, April 05, 2006 8:41 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Bob, Without going in to pseudo-judicial rhetoric, I think we need to look at what is needed for the CAPWAP protocol.=20 >From the exchanges so far, we see that measurement information can be exchanged on a per data packet basis or on an aggregated basis. We have seen the advantages of exchanging then on aggregated basis. In the spirit of quick resolution, I suggest we select one as the default mode for CAPWAP and have the other as an additional feature. I believe this was suggested earlier also.=20 Saravanan -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Thursday, April 06, 2006 10:26 AM To: Saravanan Govindan; capwap Subject: RE: [Capwap] Proposed Text for Issue 53 So, your preference is to remove functionality that is already in a product available today, by eliminating this capability from the protocol. Given Moore's law advancement of processing capability, this seems a bit short sighted.=20 -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, April 05, 2006 5:33 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Bob, I will accept that there is an AC implementation for per data packet processing.=20 I still prefer that the CAPWAP protocol aggregate measurement information for periodic exchange.=20 Saravanan =20 -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Wednesday, April 05, 2006 10:15 PM To: capwap Subject: RE: [Capwap] Proposed Text for Issue 53 For those AC implementations that want to use per packet data for certain operations, aggregation of the data at the WTP as suggested by Abhijit will preclude this. The assertion by Saravanan that an AC does not process this information is incorrect. I can point to at least one existing implementation that already does process this information on a per packet basis. The current text, with the change I suggested, is the right way to handle this. If we want to ADD a capability that the WTP can provide aggregation, I have no objection to that. -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Tuesday, April 04, 2006 4:49 PM To: Abhijit Choudhury; Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Hi Abhijit, I am in support of your suggestion. It is true that the AC does not process all data packets. Furthermore, I think for greater control, the AC will need information about the congestion level in the WLAN. This could be a derivative of interference and load factor.=20 As for your suggestion, I think measurement/parameter information from the WTP should be sent over the periodic Echo Request messages. The advantage is that header overhead is reduced.=20 I can prepare text for this approach. Cheers, Saravanan =20 -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com]=20 Sent: Wednesday, April 05, 2006 6:52 AM To: Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Here's another approach... RSSI, SNR, and Data Rate are measurements/parameters of the radio channel that are being reported to the=20 AC for finer control. Carrying them in every data packet on the data channel means some logic or hardware in the AC will have to parse them out of every data packet and send them to the control path (CPU). Typically not every packet will go to the CPU and so this data will=20 have to be stored and periodically sent to or read=20 by the CPU. Note that the AC will be possibly dealing=20 with tens to hundreds of WTPs and hence a=20 potentially large number of STAs. This implies a=20 large amount of per-STA measurement data has to be stored and moved from the data path to the CPU. A more reasonable approach is to let the WTP=20 aggregate such data and periodically send it in the=20 control channel to the AC. Note the WTP has to deal with much much fewer clients - so the storage burden is less. All we'd need is a frame that carries this information to the AC at a specified=20 interval of time. This period could be configurable. Using this approach, we don't need to increase the CAPWAP header every time we need new measurement info. We can retain the current CAPWAP header and flexibly add any measurement information we need by adding it in the control channel. This is particularly important as we move forward to support 802.11n or other=20 non-802.11 technlogies. It decouples the CAPWAP header from the measurement data related information. Any thoughts on this ? Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Monday, April 03, 2006 8:45 PM To: capwap Subject: [Capwap] Proposed Text for Issue 53 Here is my proposed text for Issue 53, which is the addition of a Data Rate In the CAPWAP header. Please let me know if you have any comments. =20 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | <=3D=3D=3D CHANGED!!! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ [...] 4.1.8. Reserved This 32 bit field is reserved and may be used by a binding specific extension. Refer to the transport portion of the binding for a specific wireless technology for the definition of this field. [...] 11.3.2. CAPWAP Header Reserved field 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 5.5Mbps would be set to 55, while 11Mbps would be set to 110. 11.3.2.2. Destination WLANs The Destination WLAN field is used to specify the target WLANs for a given frame, and is only used with broadcast and multicast frames. This field allows the AC to transmit a single broadcast or multicast frame to the WTP, and allows the WTP to perform the necessary frame replication services. The field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WLAN: This bit field indicates the WLAN ID (see section Section 11.8.1.1) which the WTP will transmit the associated frame on. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be enabled. Note this field is to be set to zero for unicast packets and is unused if the WTP is not providing encryption services. Reserved: This field MUST be set to zero. =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 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 Apr 07 00:39:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRilL-0007HY-Od for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 00:39:59 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRilK-0004Cb-A6 for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 00:39:59 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id F37144300E4 for ; Thu, 6 Apr 2006 21:39:57 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 34E0E4300B4 for ; Thu, 6 Apr 2006 21:39:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2320A144802B for ; Thu, 6 Apr 2006 21:39:40 -0700 (PDT) Received: from trpz.com (mail1.trpz.com [66.7.225.38]) by hermes.tigertech.net (Postfix) with ESMTP id 732411448026 for ; Thu, 6 Apr 2006 21:39: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 k374aNl0016591; Thu, 6 Apr 2006 21:36:26 -0700 Message-ID: <4435ED05.7090903@trapezenetworks.com> Date: Thu, 06 Apr 2006 21:39:33 -0700 From: Jim Murphy User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Dorothy Stanley Subject: Re: [Capwap] Proposed Text for Issue 53 References: <5F09D220B62F79418461A978CA0921BDC77837@pslexc01.psl.local> <5bfe7a820604061644h43105e01h9fd46fa43f17e9f8@mail.gmail.com> In-Reply-To: <5bfe7a820604061644h43105e01h9fd46fa43f17e9f8@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.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: Saravanan Govindan , 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: 14582b0692e7f70ce7111d04db3781c8 I suggest "optional to implement" for the following reasons. 1. This information is either only a partial view of what the WTP sees on the air or its transmission is a waste or bandwidth. I say either, because it depends on the implementation. It is a partial view if it includes only traffic from stations that are associated with the WTP. There are many other packets that the WTP receives that are not sent to the AC because the stations (including other WTPs) are not associated with the WTP. These other packets are very interesting to the AC because they allow the AC to make decisions based on non-associated station activity. There is a large set of decisions that can only be made with this additional information. If, however, the AC receives all the packets that the WTP receives, then perhaps the AC has all the information the WTP has, but the cost to the network between the WTP and AC is considerable. In fact, it may dominate the traffic between WTP and AC. 2. This information is not available to the AC in the local MAC case. Since data packets are not transmitted to the AC with local MAC, CAPWAP must support an alternative mechanism. Therefore, to answer the interesting questions that today's ACs answer, to use bandwidth efficiently, and to support all the forwarding models being addressed by CAPWAP, CAPWAP must support the reporting of aggregated information in the control path as described by Saravanan. Furthermore, this bandwidth inefficient, superfluous information in the data path should be optional. Thanks, Jim Dorothy Stanley wrote: > Puneet, > > Would WTP support of the "sending the phy info in every packet" capability > be > > (a) mandatory to implement and optional to configure? or > (b) optional to implement? > > Sending the Phy info (RSSI/SNR/Speed) should be optional. By default > this info should *NOT* be sent in every CAPWAP data packet. This > capability should be negotiated at WTP<->AC handshake time. > > Thanks, > > Dorothy > > > Hi Bob, > > It seems the real issue is what is the default mode of operation. > > Summary: > --------- > > Pat/Bob: Carry the phy info in every CAPWAP data pkt as at least 1 > implementation uses it > Abhijit/Saravanan: Carry phy info in control msgs periodically and > not in every CAPWAP data frame. > > My Proposal (Compromise): > ------------------------- > Sending the Phy info (RSSI/SNR/Speed) should be optional. By default > this info should *NOT* be sent in every CAPWAP data packet. This > capability should be negotiated at WTP<->AC handshake time. > > Comments? > > 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 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Apr 07 01:18:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRjMa-0000Me-72 for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 01:18:28 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRjMY-0005Xx-Ds for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 01:18:28 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BCC5C430108 for ; Thu, 6 Apr 2006 22:18:25 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4E7F1430077 for ; Thu, 6 Apr 2006 22:17:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0943B1448035 for ; Thu, 6 Apr 2006 22:17:55 -0700 (PDT) X-Greylist-Status: Sender first seen 15 days 11:43:54 ago Received: from sinett.com (63-197-255-151.ded.pacbell.net [63.197.255.151]) by hermes.tigertech.net (Postfix) with ESMTP id 8DD8B1448034 for ; Thu, 6 Apr 2006 22:17:53 -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] Proposed Text for Issue 53 Date: Thu, 6 Apr 2006 22:17:37 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Text for Issue 53 thread-index: AcZXmiGYKUrUeU/XT1OcZaCvsWKBVgAnw06wAAH/5gAAHicW0AAV2e5gAAQCVeAAAewBIAAdCSWAABDYbCAACDF+oA== From: "Abhijit Choudhury" To: "Saravanan Govindan" , "Bob O'Hara (boohara)" , "capwap" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=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: 96e0f8497f38c15fbfc8f6f315bcdecb Bob, Saravanan: Here's what I'd suggest. Since the current CAPWAP spec already supports carrying RSSI/SNR in the base CAPWAP header (in the 6 bytes), we can make=20 transmission of per-packet measurement the default mode,=20 and the exchange of aggregated information from the WTP=20 an "optional to implement" mode. =20 However, we will use an extension of the=20 base CAPWAP header, say with the D bit as explained=20 in my earlier email, to extend the CAPWAP header by=20 2 more bytes to carry additional per-packet=20 info like the data rate. This way vendors who want to use per-packet information can do so, without burdening others who decide to implement the option of the WTP sending aggregated=20 information. I think this is a reasonable compromise that satisfactorily resolves Issue 53, while allowing for flexibility. Comments ? Thanks, Abhijit -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Thursday, April 06, 2006 6:14 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Bob, I understand from your note that per data packet measurement is the basis for real time AC processing. My support for aggregated measurement exchange is based on efficiency considerations. Having said this, I do not want to exclude one or the other - the exchanges so far show both make for valuable additions to CAPWAP. I think we can move forward now maintaining / incorporating both types of exchanges in to the CAPWAP specs. Saravanan -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Friday, April 07, 2006 1:15 AM To: Saravanan Govindan; capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Saranavan, As I said in another email earlier in the thread than the one to which you responded, I do not have an objection to adding the reporting of aggregated information in a status report or other message. I do not want to lose the ability to deal with or have access to the real time information in the AC, on a packet by packet basis. Why do you object to enabling a function such as real time processing of the packet RSSI and SNR? -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, April 05, 2006 8:41 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Bob, Without going in to pseudo-judicial rhetoric, I think we need to look at what is needed for the CAPWAP protocol.=20 >From the exchanges so far, we see that measurement information can be exchanged on a per data packet basis or on an aggregated basis. We have seen the advantages of exchanging then on aggregated basis. In the spirit of quick resolution, I suggest we select one as the default mode for CAPWAP and have the other as an additional feature. I believe this was suggested earlier also.=20 Saravanan -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Thursday, April 06, 2006 10:26 AM To: Saravanan Govindan; capwap Subject: RE: [Capwap] Proposed Text for Issue 53 So, your preference is to remove functionality that is already in a product available today, by eliminating this capability from the protocol. Given Moore's law advancement of processing capability, this seems a bit short sighted.=20 -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, April 05, 2006 5:33 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Bob, I will accept that there is an AC implementation for per data packet processing.=20 I still prefer that the CAPWAP protocol aggregate measurement information for periodic exchange.=20 Saravanan =20 -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Wednesday, April 05, 2006 10:15 PM To: capwap Subject: RE: [Capwap] Proposed Text for Issue 53 For those AC implementations that want to use per packet data for certain operations, aggregation of the data at the WTP as suggested by Abhijit will preclude this. The assertion by Saravanan that an AC does not process this information is incorrect. I can point to at least one existing implementation that already does process this information on a per packet basis. The current text, with the change I suggested, is the right way to handle this. If we want to ADD a capability that the WTP can provide aggregation, I have no objection to that. -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Tuesday, April 04, 2006 4:49 PM To: Abhijit Choudhury; Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Hi Abhijit, I am in support of your suggestion. It is true that the AC does not process all data packets. Furthermore, I think for greater control, the AC will need information about the congestion level in the WLAN. This could be a derivative of interference and load factor.=20 As for your suggestion, I think measurement/parameter information from the WTP should be sent over the periodic Echo Request messages. The advantage is that header overhead is reduced.=20 I can prepare text for this approach. Cheers, Saravanan =20 -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com]=20 Sent: Wednesday, April 05, 2006 6:52 AM To: Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Here's another approach... RSSI, SNR, and Data Rate are measurements/parameters of the radio channel that are being reported to the=20 AC for finer control. Carrying them in every data packet on the data channel means some logic or hardware in the AC will have to parse them out of every data packet and send them to the control path (CPU). Typically not every packet will go to the CPU and so this data will=20 have to be stored and periodically sent to or read=20 by the CPU. Note that the AC will be possibly dealing=20 with tens to hundreds of WTPs and hence a=20 potentially large number of STAs. This implies a=20 large amount of per-STA measurement data has to be stored and moved from the data path to the CPU. A more reasonable approach is to let the WTP=20 aggregate such data and periodically send it in the=20 control channel to the AC. Note the WTP has to deal with much much fewer clients - so the storage burden is less. All we'd need is a frame that carries this information to the AC at a specified=20 interval of time. This period could be configurable. Using this approach, we don't need to increase the CAPWAP header every time we need new measurement info. We can retain the current CAPWAP header and flexibly add any measurement information we need by adding it in the control channel. This is particularly important as we move forward to support 802.11n or other=20 non-802.11 technlogies. It decouples the CAPWAP header from the measurement data related information. Any thoughts on this ? Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Monday, April 03, 2006 8:45 PM To: capwap Subject: [Capwap] Proposed Text for Issue 53 Here is my proposed text for Issue 53, which is the addition of a Data Rate In the CAPWAP header. Please let me know if you have any comments. =20 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | <=3D=3D=3D CHANGED!!! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ [...] 4.1.8. Reserved This 32 bit field is reserved and may be used by a binding specific extension. Refer to the transport portion of the binding for a specific wireless technology for the definition of this field. [...] 11.3.2. CAPWAP Header Reserved field 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 5.5Mbps would be set to 55, while 11Mbps would be set to 110. 11.3.2.2. Destination WLANs The Destination WLAN field is used to specify the target WLANs for a given frame, and is only used with broadcast and multicast frames. This field allows the AC to transmit a single broadcast or multicast frame to the WTP, and allows the WTP to perform the necessary frame replication services. The field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WLAN: This bit field indicates the WLAN ID (see section Section 11.8.1.1) which the WTP will transmit the associated frame on. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be enabled. Note this field is to be set to zero for unicast packets and is unused if the WTP is not providing encryption services. Reserved: This field MUST be set to zero. =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 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 dawnueleni@mail.primorye.ru Fri Apr 07 01:19:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRjN8-0000cP-0B for capwap-archive@ietf.org; Fri, 07 Apr 2006 01:19:02 -0400 Received: from [218.159.88.18] (helo=mail.primorye.ru) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRjN6-0005YF-Bg for capwap-archive@ietf.org; Fri, 07 Apr 2006 01:19:01 -0400 Message-ID: <000001c65a02$c0633780$c652a8c0@fkd51> Reply-To: "Eleni Dawn" From: "Eleni Dawn" To: capwap-archive@ietf.org Subject: Re: your home Date: Fri, 7 Apr 2006 01:18:49 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C659E1.39519780" 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: 25620135586de10c627e3628c432b04a This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C659E1.39519780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Home O w n e r ,=20 =20 Your credit doesn't matter to us ! =20 If you O W N real e s t a t e=20 and want l M M E D l A T E c a s h to s p e n d ANY way you like, or simply wish=20 to L O W E R your monthly p a y m e n t s by a third or more, here are the deals=20 we have T O D A Y :=20 =20 $ 488 , 000 at a 3 , 67 % F i x e d - r a t e=20 $ 372 , 000 at a 3 , 90 % V a r i a b I e - r a t e=20 $ 492 , 000 at a 3 , 21 % l n t e r e s t - o n l y=20 $ 248 , 000 at a 3 , 36 % F i x e d - r a t e=20 $ 198 , 000 at a 3 , 55 % V a r i a b I e - r a t e=20 =20 Hurry, when these deals are gone, they are gone! =20 Don't worry about a p p r o v a l , your credit will not d i s q u a I i f y you ! =20 web site =20 =20 Sincerely, Eleni Dawn =20 A p p r o v a l Manager ------=_NextPart_000_0001_01C659E1.39519780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Home   O w n e r ,
=  
Your credit doesn't matter to us !
 
If you O W N real   e s t a t e
and want   l M M E D l A = T E   c a s h   to   s p e n d   ANY way you=20 like, or simply wish
to   L O W E R   your monthly   = p a y m e n t s   by a third or more,=20 here are the deals
we have   T O D A Y   :
  =
=20 $ 488 , 000 at a 3 , 67 %   F i x e d - r a t e
=20 $ 372 , 000 at a 3 , 90 %   V a r i a b I e - r a t e
=20 $ 492 , 000 at a 3 , 21 %   l n t e r e s t - o n l y
=20 $ 248 , 000 at a 3 , 36 %   F i x e d - r a t e
=20 $ 198 , 000 at a 3 , 55 %   V a r i a b I e - r a t e
  =
=20 Hurry, when these deals are gone, they are gone!
 
Don't worry about   a p p r o v a l   , your credit will not =   d i s q u a I i f y   you !
 =20
web site
 
Sincerely, Eleni Dawn
 
A p p r o v a l =   Manager
------=_NextPart_000_0001_01C659E1.39519780-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 07 06:52:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRoZy-0003KF-08 for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 06:52:38 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRoZw-0007rg-5m for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 06:52:37 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 23D9A4300E4 for ; Fri, 7 Apr 2006 03:52:35 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E2938430071 for ; Fri, 7 Apr 2006 03:52:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CBD6F430E42 for ; Fri, 7 Apr 2006 03:52:04 -0700 (PDT) Received: from huawei.com (szxga01-in.huawei.com [61.144.161.53]) by hermes.tigertech.net (Postfix) with ESMTP id 7FCF7430E41 for ; Fri, 7 Apr 2006 03:52:03 -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 <0IXC00EPMLSH72@szxga01-in.huawei.com> for capwap@frascone.com; Fri, 07 Apr 2006 18:43:29 +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 <0IXC000S2LS9Z1@szxga01-in.huawei.com> for capwap@frascone.com; Fri, 07 Apr 2006 18:43:29 +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 <0IXC00FJVMF5W8@szxml02-in.huawei.com>; Fri, 07 Apr 2006 18:57:06 +0800 (CST) Date: Fri, 07 Apr 2006 16:13:25 +0530 From: sujay Subject: RE: [Capwap] Proposed Text for Issue 53 In-reply-to: To: 'Abhijit Choudhury' , 'Saravanan Govindan' , "'Bob O'Hara (boohara)'" , 'capwap' Message-id: <000001c65a30$1a2f8610$7107120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 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: 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: 715d0e6950aaebd45af78ef9318d0186 Abhijit, This looks like a good idea, it can carry packet by packet information as well as aggregated information as per the R bit usage. Considering that the single available 'R' bit will be exhausted by this approach. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Is it advisable to have an option field of more than 1-bit , say 2 or 3 bits to accommodate future changes?? 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L| R(opt) | Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The current header is too tight. Regds, sujay -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com] Sent: Friday, April 07, 2006 10:48 AM To: Saravanan Govindan; Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Bob, Saravanan: Here's what I'd suggest. Since the current CAPWAP spec already supports carrying RSSI/SNR in the base CAPWAP header (in the 6 bytes), we can make transmission of per-packet measurement the default mode, and the exchange of aggregated information from the WTP an "optional to implement" mode. However, we will use an extension of the base CAPWAP header, say with the D bit as explained in my earlier email, to extend the CAPWAP header by 2 more bytes to carry additional per-packet info like the data rate. This way vendors who want to use per-packet information can do so, without burdening others who decide to implement the option of the WTP sending aggregated information. I think this is a reasonable compromise that satisfactorily resolves Issue 53, while allowing for flexibility. Comments ? Thanks, Abhijit -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Thursday, April 06, 2006 6:14 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Bob, I understand from your note that per data packet measurement is the basis for real time AC processing. My support for aggregated measurement exchange is based on efficiency considerations. Having said this, I do not want to exclude one or the other - the exchanges so far show both make for valuable additions to CAPWAP. I think we can move forward now maintaining / incorporating both types of exchanges in to the CAPWAP specs. Saravanan -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] Sent: Friday, April 07, 2006 1:15 AM To: Saravanan Govindan; capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Saranavan, As I said in another email earlier in the thread than the one to which you responded, I do not have an objection to adding the reporting of aggregated information in a status report or other message. I do not want to lose the ability to deal with or have access to the real time information in the AC, on a packet by packet basis. Why do you object to enabling a function such as real time processing of the packet RSSI and SNR? -Bob -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Wednesday, April 05, 2006 8:41 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Bob, Without going in to pseudo-judicial rhetoric, I think we need to look at what is needed for the CAPWAP protocol. >From the exchanges so far, we see that measurement information can be exchanged on a per data packet basis or on an aggregated basis. We have seen the advantages of exchanging then on aggregated basis. In the spirit of quick resolution, I suggest we select one as the default mode for CAPWAP and have the other as an additional feature. I believe this was suggested earlier also. Saravanan -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] Sent: Thursday, April 06, 2006 10:26 AM To: Saravanan Govindan; capwap Subject: RE: [Capwap] Proposed Text for Issue 53 So, your preference is to remove functionality that is already in a product available today, by eliminating this capability from the protocol. Given Moore's law advancement of processing capability, this seems a bit short sighted. -Bob -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Wednesday, April 05, 2006 5:33 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Bob, I will accept that there is an AC implementation for per data packet processing. I still prefer that the CAPWAP protocol aggregate measurement information for periodic exchange. Saravanan -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] Sent: Wednesday, April 05, 2006 10:15 PM To: capwap Subject: RE: [Capwap] Proposed Text for Issue 53 For those AC implementations that want to use per packet data for certain operations, aggregation of the data at the WTP as suggested by Abhijit will preclude this. The assertion by Saravanan that an AC does not process this information is incorrect. I can point to at least one existing implementation that already does process this information on a per packet basis. The current text, with the change I suggested, is the right way to handle this. If we want to ADD a capability that the WTP can provide aggregation, I have no objection to that. -Bob -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Tuesday, April 04, 2006 4:49 PM To: Abhijit Choudhury; Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Hi Abhijit, I am in support of your suggestion. It is true that the AC does not process all data packets. Furthermore, I think for greater control, the AC will need information about the congestion level in the WLAN. This could be a derivative of interference and load factor. As for your suggestion, I think measurement/parameter information from the WTP should be sent over the periodic Echo Request messages. The advantage is that header overhead is reduced. I can prepare text for this approach. Cheers, Saravanan -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com] Sent: Wednesday, April 05, 2006 6:52 AM To: Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Here's another approach... RSSI, SNR, and Data Rate are measurements/parameters of the radio channel that are being reported to the AC for finer control. Carrying them in every data packet on the data channel means some logic or hardware in the AC will have to parse them out of every data packet and send them to the control path (CPU). Typically not every packet will go to the CPU and so this data will have to be stored and periodically sent to or read by the CPU. Note that the AC will be possibly dealing with tens to hundreds of WTPs and hence a potentially large number of STAs. This implies a large amount of per-STA measurement data has to be stored and moved from the data path to the CPU. A more reasonable approach is to let the WTP aggregate such data and periodically send it in the control channel to the AC. Note the WTP has to deal with much much fewer clients - so the storage burden is less. All we'd need is a frame that carries this information to the AC at a specified interval of time. This period could be configurable. Using this approach, we don't need to increase the CAPWAP header every time we need new measurement info. We can retain the current CAPWAP header and flexibly add any measurement information we need by adding it in the control channel. This is particularly important as we move forward to support 802.11n or other non-802.11 technlogies. It decouples the CAPWAP header from the measurement data related information. Any thoughts on this ? Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Monday, April 03, 2006 8:45 PM To: capwap Subject: [Capwap] Proposed Text for Issue 53 Here is my proposed text for Issue 53, which is the addition of a Data Rate In the CAPWAP header. Please let me know if you have any comments. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | <=== CHANGED!!! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ [...] 4.1.8. Reserved This 32 bit field is reserved and may be used by a binding specific extension. Refer to the transport portion of the binding for a specific wireless technology for the definition of this field. [...] 11.3.2. CAPWAP Header Reserved field 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 5.5Mbps would be set to 55, while 11Mbps would be set to 110. 11.3.2.2. Destination WLANs The Destination WLAN field is used to specify the target WLANs for a given frame, and is only used with broadcast and multicast frames. This field allows the AC to transmit a single broadcast or multicast frame to the WTP, and allows the WTP to perform the necessary frame replication services. The field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WLAN: This bit field indicates the WLAN ID (see section Section 11.8.1.1) which the WTP will transmit the associated frame on. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be enabled. Note this field is to be set to zero for unicast packets and is unused if the WTP is not providing encryption services. Reserved: This field MUST be set to zero. 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 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 07 10:42:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRsAd-0003nF-Lk for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 10:42:43 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRsAc-0007RY-3u for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 10:42:43 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4513B430140 for ; Fri, 7 Apr 2006 07:42:41 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 2A33C43009A for ; Fri, 7 Apr 2006 07:42:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 18DA939801F for ; Fri, 7 Apr 2006 07:42:19 -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 E461039802B for ; Fri, 7 Apr 2006 07:42:14 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-3.cisco.com with ESMTP; 07 Apr 2006 07:42:14 -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 k37EgEw1009387; Fri, 7 Apr 2006 07:42:14 -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, 7 Apr 2006 07:42:14 -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] PFS: requirement or not? Date: Fri, 7 Apr 2006 07:42:12 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201B20FE5@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] PFS: requirement or not? Thread-Index: AcZXcVt3m8xxCv//Tq2OKSU0vuEC8AC3/vig From: "Pat Calhoun (pacalhou)" To: "Scott G. Kelly" , "T. Charles Clancy" X-OriginalArrivalTime: 07 Apr 2006 14:42:14.0196 (UTC) FILETIME=[75CE8F40:01C65A51] 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: 5d7a7e767f20255fce80fa0b77fb2433 > I wondered if you that's what you were thinking. This=20 > assumption is wrong - all data does *not* have to go through=20 > the AC, and especially not in many remote AP scenarios. What=20 > my diagram may not have illustrated so clearly is that in=20 > some local MAC scenarios, much of the wlan traffic may be=20 > destined for local (wired) servers/hosts. In general, this is=20 > described in the architecture taxonomy RFC as "Local MAC",=20 > and it's commonly deployed today. There are also hybrids=20 > possible. And the scenario I described is only one of many=20 > that we need to consider. There is far more to be concerned=20 > with than initially meets the eye. Just to make sure we are on the same wavelength, all traffic for a given WLAN is either terminated locally, or not. There is no such thing in the protocol as half going one way, and half going the other way. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com]=20 > Sent: Monday, April 03, 2006 3:52 PM > To: T. Charles Clancy > Cc: capwap > Subject: Re: [Capwap] PFS: requirement or not? >=20 > Hi Charles, >=20 > -----Original Message----- > >From: "T. Charles Clancy" > >Sent: Apr 3, 2006 2:44 PM > >To: "Scott G. Kelly" > >Cc: capwap > >Subject: Re: [Capwap] PFS: requirement or not? > > > >Some thoughts... > > > >I don't see how PFS will help us protect data. All data has to go=20 > >through the AC (at least that's my understanding), so unless=20 > the CAPWAP=20 > >data channel is protected, all data is vulnerable to compromise. >=20 >=20 > > Using a > >DTLS-protected data channel or terminating 802.11i at the AC=20 > will solve=20 > >these problems, not PFS. Thus, IMHO, old CAPWAP traffic is=20 > not useful=20 > >to an attacker, assuming the proper caveats. >=20 > Yes, as it turns out, data channel security will solve many=20 > problems. For example, terminating 802.11i at the AC largely=20 > overcomes the PFS, but it is simply not an option in many=20 > local MAC scenarios. In thinking about these problems over=20 > the weekend, I arrived at the conclusion that data channel=20 > security (of some sort) is a hard requirement for some=20 > scenarios - but that's another discussion, one I'm sure will=20 > be at least as much fun as this one :-) >=20 > But again, let me emphasize this: since there may be=20 > confidential (read: high value) traffic on the local segment=20 > which is protected by 802.11i and does not traverse the link=20 > between WTP and AC (i.e. it is not supposed to be visible=20 > outside of the security boundary in my ascii drawing), we=20 > need to make sure someone can't record it and crack it later=20 > (unless they brute force the AES). PFS helps to mitigates this threat. >=20 > >On the other hand, Scott does bring up a good point. PFS=20 > will force an=20 > >attacker who has already compromised a CAPWAP credential to=20 > be active=20 > >rather than passive when launching attacks against future sessions. > > > >Of course in order to have keys equivalently strong to AES-CCM-128,=20 > >you'll need to use 3072-bit DH. The complexity of that is not=20 > >something to sneeze at, especially for a super-cheap,=20 > light-weight AP. >=20 > This is a very reasonable point, and we went through similar=20 > pain in IPsec when we added AES crypto suites. I think that=20 > in cases where you actually *need* 128 bits of security, you=20 > either won't be using preshared keys, or you'll have=20 > beefy-enough hardware to deal with this.=20 >=20 > A 200Mhz PPC (not a high end processor by today's measures,=20 > but very common in APs) can do the DH in a few hundred=20 > millisecs or less. If your hardware doesn't reboot every day,=20 > you won't have to do capwap session establishment very=20 > frequently, and one 128-bit key (assuming aes-ccm) should=20 > last you for 2^64 or so packets, (which should be a *very*=20 > long time if you're only encrypting control traffic). >=20 > However, there are two other possibilities: first, use=20 > smaller moduli. If you only need, say, 80 bits of strength=20 > (suffiicient in many scenarios), you can use much smaller=20 > moduli/exponents. The second option is to use elliptic=20 > curves instead. There currently are no ECC PSK suites defined=20 > for (D)TLS, and I'm not sure what the IPR status is at this=20 > point, but I'll look into this a bit.=20 >=20 > Honestly, though, I don't think that people should be=20 > cheaping out on security-critical hardware. If 3072-bit DH is=20 > the price of admission, then it may be best just suck it up=20 > and deal with it... >=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 Fri Apr 07 10:52:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRsK2-00070F-B6 for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 10:52:26 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRsK0-0007fG-OU for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 10:52:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 65F664300FF for ; Fri, 7 Apr 2006 07:52:24 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id C725B43009A for ; Fri, 7 Apr 2006 07:51:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id B5DF4398039 for ; Fri, 7 Apr 2006 07:51:54 -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 E92A639801F for ; Fri, 7 Apr 2006 07:51:52 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2006 07:51:52 -0700 X-IronPort-AV: i="4.04,98,1144047600"; d="scan'208"; a="422810536:sNHT37943220" 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 k37Epq7T016023; Fri, 7 Apr 2006 07:51:52 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Apr 2006 07:51: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] Proposed Text for Issue 53 Date: Fri, 7 Apr 2006 07:51:52 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC016207B7@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Text for Issue 53 Thread-Index: AcZZ/VQTAfdG8nyoSNajCia+nLAHrgAVUoqQ From: "Bob O'Hara (boohara)" To: "Dorothy Stanley" X-OriginalArrivalTime: 07 Apr 2006 14:51:52.0454 (UTC) FILETIME=[CE79BA60:01C65A52] 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: 37af5f8fbf6f013c5b771388e24b09e7 The fields in the data packet must be present, filling them with information may be optional. -Bob =20 -----Original Message----- From: Jim Murphy [mailto:jmurphy@trapezenetworks.com]=20 Sent: Thursday, April 06, 2006 9:40 PM To: Dorothy Stanley Cc: Saravanan Govindan; capwap; Abhijit Choudhury Subject: Re: [Capwap] Proposed Text for Issue 53 I suggest "optional to implement" for the following reasons. 1. This information is either only a partial view of what the WTP sees on the air or its transmission is a waste or bandwidth. I say either, because it depends on the implementation. It is a partial view if it includes only traffic from stations that are associated with the WTP. There are many other packets that the WTP receives that are not sent to the AC because the stations (including other WTPs) are not associated with the WTP. These other packets are very interesting to the AC because they allow the AC to make decisions based on non-associated station activity. There is a large set of decisions that can only be made with this additional information. If, however, the AC receives all the packets that the WTP receives, then perhaps the AC has all the information the WTP has, but the cost to the network between the WTP and AC is considerable. In fact, it may dominate the traffic between WTP and AC. 2. This information is not available to the AC in the local MAC case. Since data packets are not transmitted to the AC with local MAC, CAPWAP must support an alternative mechanism. Therefore, to answer the interesting questions that today's ACs answer, to use bandwidth efficiently, and to support all the forwarding models being addressed by CAPWAP, CAPWAP must support the reporting of aggregated information in the control path as described by Saravanan. Furthermore, this bandwidth inefficient, superfluous information in the data path should be optional. Thanks, Jim Dorothy Stanley wrote: > Puneet, >=20 > Would WTP support of the "sending the phy info in every packet" capability > be >=20 > (a) mandatory to implement and optional to configure? or > (b) optional to implement? >=20 > Sending the Phy info (RSSI/SNR/Speed) should be optional. By default=20 > this info should *NOT* be sent in every CAPWAP data packet. This=20 > capability should be negotiated at WTP<->AC handshake time. >=20 > Thanks, >=20 > Dorothy >=20 >=20 > Hi Bob, >=20 > It seems the real issue is what is the default mode of operation. >=20 > Summary: > --------- >=20 > Pat/Bob: Carry the phy info in every CAPWAP data pkt as at least 1 > implementation uses it > Abhijit/Saravanan: Carry phy info in control msgs periodically and > not in every CAPWAP data frame. >=20 > My Proposal (Compromise): > ------------------------- > Sending the Phy info (RSSI/SNR/Speed) should be optional. By default > this info should *NOT* be sent in every CAPWAP data packet. This > capability should be negotiated at WTP<->AC handshake time. >=20 > Comments? >=20 > Thanks. >=20 > -Puneet >=20 >=20 >=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 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Apr 07 10:54:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRsLy-00073R-CJ for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 10:54:26 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRsLx-0007ge-Hh for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 10:54:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2FE1A4300FF for ; Fri, 7 Apr 2006 07:54:25 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id EAA384300A4 for ; Fri, 7 Apr 2006 07:53:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id DD4C6398046 for ; Fri, 7 Apr 2006 07:53:55 -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 BA44039803B for ; Fri, 7 Apr 2006 07:53:53 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 07 Apr 2006 07:53:53 -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 k37Err7X017747 for ; Fri, 7 Apr 2006 07:53:53 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Apr 2006 07:53: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] Proposed Text for Issue 53 Date: Fri, 7 Apr 2006 07:53:52 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC016207BA@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Text for Issue 53 Thread-Index: AcZXmiGYKUrUeU/XT1OcZaCvsWKBVgAnw06wAAH/5gAAHicW0AAV2e5gAAQCVeAAAewBIAAdCSWAABDYbCAACDF+oAAUbVAQ From: "Bob O'Hara (boohara)" To: "capwap" X-OriginalArrivalTime: 07 Apr 2006 14:53:53.0078 (UTC) FILETIME=[165F7D60:01C65A53] 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: 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: f0ea5880a0890be2408609376fa519aa =20 If this is all that we can agree to, then this would be acceptable. I still think that fields appearing or disappearing from a packet header is a bad path to follow. -Bob =20 -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com]=20 Sent: Thursday, April 06, 2006 10:18 PM To: Saravanan Govindan; Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Bob, Saravanan: Here's what I'd suggest. Since the current CAPWAP spec already supports carrying RSSI/SNR in the base CAPWAP header (in the 6 bytes), we can make=20 transmission of per-packet measurement the default mode,=20 and the exchange of aggregated information from the WTP=20 an "optional to implement" mode. =20 However, we will use an extension of the=20 base CAPWAP header, say with the D bit as explained=20 in my earlier email, to extend the CAPWAP header by=20 2 more bytes to carry additional per-packet=20 info like the data rate. This way vendors who want to use per-packet information can do so, without burdening others who decide to implement the option of the WTP sending aggregated=20 information. I think this is a reasonable compromise that satisfactorily resolves Issue 53, while allowing for flexibility. Comments ? Thanks, Abhijit -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Thursday, April 06, 2006 6:14 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Bob, I understand from your note that per data packet measurement is the basis for real time AC processing. My support for aggregated measurement exchange is based on efficiency considerations. Having said this, I do not want to exclude one or the other - the exchanges so far show both make for valuable additions to CAPWAP. I think we can move forward now maintaining / incorporating both types of exchanges in to the CAPWAP specs. Saravanan -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Friday, April 07, 2006 1:15 AM To: Saravanan Govindan; capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Saranavan, As I said in another email earlier in the thread than the one to which you responded, I do not have an objection to adding the reporting of aggregated information in a status report or other message. I do not want to lose the ability to deal with or have access to the real time information in the AC, on a packet by packet basis. Why do you object to enabling a function such as real time processing of the packet RSSI and SNR? -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, April 05, 2006 8:41 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Bob, Without going in to pseudo-judicial rhetoric, I think we need to look at what is needed for the CAPWAP protocol.=20 >From the exchanges so far, we see that measurement information can be exchanged on a per data packet basis or on an aggregated basis. We have seen the advantages of exchanging then on aggregated basis. In the spirit of quick resolution, I suggest we select one as the default mode for CAPWAP and have the other as an additional feature. I believe this was suggested earlier also.=20 Saravanan -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Thursday, April 06, 2006 10:26 AM To: Saravanan Govindan; capwap Subject: RE: [Capwap] Proposed Text for Issue 53 So, your preference is to remove functionality that is already in a product available today, by eliminating this capability from the protocol. Given Moore's law advancement of processing capability, this seems a bit short sighted.=20 -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, April 05, 2006 5:33 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Bob, I will accept that there is an AC implementation for per data packet processing.=20 I still prefer that the CAPWAP protocol aggregate measurement information for periodic exchange.=20 Saravanan =20 -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Wednesday, April 05, 2006 10:15 PM To: capwap Subject: RE: [Capwap] Proposed Text for Issue 53 For those AC implementations that want to use per packet data for certain operations, aggregation of the data at the WTP as suggested by Abhijit will preclude this. The assertion by Saravanan that an AC does not process this information is incorrect. I can point to at least one existing implementation that already does process this information on a per packet basis. The current text, with the change I suggested, is the right way to handle this. If we want to ADD a capability that the WTP can provide aggregation, I have no objection to that. -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Tuesday, April 04, 2006 4:49 PM To: Abhijit Choudhury; Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Hi Abhijit, I am in support of your suggestion. It is true that the AC does not process all data packets. Furthermore, I think for greater control, the AC will need information about the congestion level in the WLAN. This could be a derivative of interference and load factor.=20 As for your suggestion, I think measurement/parameter information from the WTP should be sent over the periodic Echo Request messages. The advantage is that header overhead is reduced.=20 I can prepare text for this approach. Cheers, Saravanan =20 -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com]=20 Sent: Wednesday, April 05, 2006 6:52 AM To: Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Here's another approach... RSSI, SNR, and Data Rate are measurements/parameters of the radio channel that are being reported to the=20 AC for finer control. Carrying them in every data packet on the data channel means some logic or hardware in the AC will have to parse them out of every data packet and send them to the control path (CPU). Typically not every packet will go to the CPU and so this data will=20 have to be stored and periodically sent to or read=20 by the CPU. Note that the AC will be possibly dealing=20 with tens to hundreds of WTPs and hence a=20 potentially large number of STAs. This implies a=20 large amount of per-STA measurement data has to be stored and moved from the data path to the CPU. A more reasonable approach is to let the WTP=20 aggregate such data and periodically send it in the=20 control channel to the AC. Note the WTP has to deal with much much fewer clients - so the storage burden is less. All we'd need is a frame that carries this information to the AC at a specified=20 interval of time. This period could be configurable. Using this approach, we don't need to increase the CAPWAP header every time we need new measurement info. We can retain the current CAPWAP header and flexibly add any measurement information we need by adding it in the control channel. This is particularly important as we move forward to support 802.11n or other=20 non-802.11 technlogies. It decouples the CAPWAP header from the measurement data related information. Any thoughts on this ? Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Monday, April 03, 2006 8:45 PM To: capwap Subject: [Capwap] Proposed Text for Issue 53 Here is my proposed text for Issue 53, which is the addition of a Data Rate In the CAPWAP header. Please let me know if you have any comments. =20 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | <=3D=3D=3D CHANGED!!! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ [...] 4.1.8. Reserved This 32 bit field is reserved and may be used by a binding specific extension. Refer to the transport portion of the binding for a specific wireless technology for the definition of this field. [...] 11.3.2. CAPWAP Header Reserved field 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 5.5Mbps would be set to 55, while 11Mbps would be set to 110. 11.3.2.2. Destination WLANs The Destination WLAN field is used to specify the target WLANs for a given frame, and is only used with broadcast and multicast frames. This field allows the AC to transmit a single broadcast or multicast frame to the WTP, and allows the WTP to perform the necessary frame replication services. The field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WLAN: This bit field indicates the WLAN ID (see section Section 11.8.1.1) which the WTP will transmit the associated frame on. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be enabled. Note this field is to be set to zero for unicast packets and is unused if the WTP is not providing encryption services. Reserved: This field MUST be set to zero. =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 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 07 11:34:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRsyI-00055g-D0 for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 11:34:02 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRsyG-0000TM-EH for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 11:34:02 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 25B1F4300E4 for ; Fri, 7 Apr 2006 08:33:59 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2ACED4300A4 for ; Fri, 7 Apr 2006 08:33:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 17C8243122A for ; Fri, 7 Apr 2006 08:33:31 -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 0C1EA431223 for ; Fri, 7 Apr 2006 08:33:28 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 07 Apr 2006 08:33:28 -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 k37FXS7T010964; Fri, 7 Apr 2006 08:33:28 -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, 7 Apr 2006 08:33: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] Proposed Text for Issue 53 Date: Fri, 7 Apr 2006 08:33:27 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201B21022@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Text for Issue 53 Thread-Index: AcZXmiGYKUrUeU/XT1OcZaCvsWKBVgAnw06wAAH/5gAAHicW0AAV2e5gAFHUOsA= From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , "Bob O'Hara (boohara)" , "capwap" X-OriginalArrivalTime: 07 Apr 2006 15:33:28.0089 (UTC) FILETIME=[9DFD6890:01C65A58] X-Virus-Scanned: by amavisd-new-20030616-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: 27ec2ff0f5c3b18b49c722f4f1748838 This can be provided through the existing statistics interface in the protocol. If implementations rather use this, they can. I believe per packet is required for finer control. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 > Sent: Wednesday, April 05, 2006 5:33 PM > To: Bob O'Hara (boohara); capwap > Subject: RE: [Capwap] Proposed Text for Issue 53 >=20 > Bob, >=20 > I will accept that there is an AC implementation for per data=20 > packet processing.=20 >=20 > I still prefer that the CAPWAP protocol aggregate measurement=20 > information for periodic exchange.=20 >=20 > Saravanan >=20 >=20 > =20 >=20 > -----Original Message----- > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > Sent: Wednesday, April 05, 2006 10:15 PM > To: capwap > Subject: RE: [Capwap] Proposed Text for Issue 53 >=20 > For those AC implementations that want to use per packet data=20 > for certain operations, aggregation of the data at the WTP as=20 > suggested by Abhijit will preclude this. The assertion by=20 > Saravanan that an AC does not process this information is=20 > incorrect. I can point to at least one existing=20 > implementation that already does process this information on=20 > a per packet basis. >=20 > The current text, with the change I suggested, is the right=20 > way to handle this. If we want to ADD a capability that the=20 > WTP can provide aggregation, I have no objection to that. >=20 > -Bob > =20 > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Tuesday, April 04, 2006 4:49 PM > To: Abhijit Choudhury; Pat Calhoun (pacalhou); capwap > Subject: RE: [Capwap] Proposed Text for Issue 53 >=20 > Hi Abhijit, >=20 > I am in support of your suggestion. It is true that the AC=20 > does not process all data packets. Furthermore, I think for=20 > greater control, the AC will need information about the=20 > congestion level in the WLAN. This could be a derivative of=20 > interference and load factor.=20 >=20 > As for your suggestion, I think measurement/parameter=20 > information from the WTP should be sent over the periodic=20 > Echo Request messages. The advantage is that header overhead=20 > is reduced.=20 >=20 > I can prepare text for this approach. >=20 > Cheers, >=20 > Saravanan >=20 >=20 >=20 > =20 >=20 > -----Original Message----- > From: Abhijit Choudhury [mailto:Abhijit@sinett.com] > Sent: Wednesday, April 05, 2006 6:52 AM > To: Pat Calhoun (pacalhou); capwap > Subject: RE: [Capwap] Proposed Text for Issue 53 >=20 > Here's another approach... >=20 > RSSI, SNR, and Data Rate are measurements/parameters of the=20 > radio channel that are being reported to the AC for finer=20 > control. Carrying them in every data packet on the data=20 > channel means some logic or hardware in the AC will have to=20 > parse them out of every data packet and send them to the=20 > control path (CPU). Typically not every packet will go to=20 > the CPU and so this data will have to be stored and=20 > periodically sent to or read by the CPU. Note that the AC=20 > will be possibly dealing with tens to hundreds of WTPs and=20 > hence a potentially large number of STAs. This implies a=20 > large amount of per-STA measurement data has to be stored and=20 > moved from the data path to the CPU. >=20 > A more reasonable approach is to let the WTP aggregate such=20 > data and periodically send it in the control channel to the=20 > AC. Note the WTP has to deal with much much fewer clients -=20 > so the storage burden is less. All we'd need is a frame that=20 > carries this information to the AC at a specified interval of=20 > time. This period could be configurable. >=20 > Using this approach, we don't need to increase the CAPWAP=20 > header every time we need new measurement info. We can retain=20 > the current CAPWAP header and flexibly add any measurement=20 > information we need by adding it in the control channel. This=20 > is particularly important as we move forward to support=20 > 802.11n or other > non-802.11 technlogies. It decouples the CAPWAP header from=20 > the measurement data related information. >=20 > Any thoughts on this ? >=20 >=20 > Thanks, > Abhijit >=20 >=20 >=20 >=20 > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Monday, April 03, 2006 8:45 PM > To: capwap > Subject: [Capwap] Proposed Text for Issue 53 >=20 >=20 > Here is my proposed text for Issue 53, which is the addition of a Data > Rate In the CAPWAP header. >=20 > Please let me know if you have any comments. > =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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |VER| RID |F|L|R| Frag ID | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | > <=3D=3D=3D CHANGED!!! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload... | > +-+-+-+-+-+-+-+-+ >=20 > [...] > 4.1.8. Reserved >=20 > This 32 bit field is reserved and may be used by a binding specific > extension. Refer to the transport portion of the binding for a > specific wireless technology for the definition of this field. >=20 > [...] >=20 > 11.3.2. CAPWAP Header Reserved field >=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=20 > 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=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 over=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RSSI | SNR | Data Rate | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=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 received at > 5.5Mbps would be set to 55, while 11Mbps would be set to 110. >=20 > 11.3.2.2. Destination WLANs >=20 > The Destination WLAN field is used to specify the target=20 > WLANs for a > given frame, and is only used with broadcast and multicast frames. > This field allows the AC to transmit a single broadcast or=20 > multicast > frame to the WTP, and allows the WTP to perform the necessary frame > replication services. The field uses 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | WLAN | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > WLAN: This bit field indicates the WLAN ID (see section > Section 11.8.1.1) which the WTP will transmit the=20 > associated frame > on. For instance, if a multicast packet is to be transmitted on > WLANs 1 and 3, bits 1 and 3 of this field would be=20 > enabled. Note > this field is to be set to zero for unicast packets and=20 > is unused > if the WTP is not providing encryption services. >=20 > Reserved: This field MUST be set to zero. > =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 >=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 > _________________________________________________________________ > 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 > _________________________________________________________________ > 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 Apr 07 11:37:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRt1T-0007da-2w for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 11:37:19 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRt1R-0000Vy-GC for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 11:37:19 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B5E7743019B for ; Fri, 7 Apr 2006 08:37:16 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 988094300A4 for ; Fri, 7 Apr 2006 08:36:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8806639801F for ; Fri, 7 Apr 2006 08:36:44 -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 D4C9E398007 for ; Fri, 7 Apr 2006 08:36:42 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-2.cisco.com with ESMTP; 07 Apr 2006 08:36:42 -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 k37FagGv018842; Fri, 7 Apr 2006 08:36:42 -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, 7 Apr 2006 08:36: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] Proposed Text for Issue 53 Date: Fri, 7 Apr 2006 08:36:40 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201B21023@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Text for Issue 53 Thread-Index: AcZZ/VXYtULXXNY2TxeAiDtKMcNQhAAW577A From: "Pat Calhoun (pacalhou)" To: "Jim Murphy" , "Dorothy Stanley" X-OriginalArrivalTime: 07 Apr 2006 15:36:41.0868 (UTC) FILETIME=[117DBCC0:01C65A59] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=3.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, RCVD_IN_BL_SPAMCOP_NET X-Spam-Level: *** Cc: Saravanan Govindan , 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: 1.8 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Jim Murphy says: > Furthermore, this bandwidth inefficient, superfluous=20 > information in the data path should be optional. I think 2 bytes in the header can hardly be called bandwidth innefficient. 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 Apr 07 11:38:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRt34-0000Nl-6s for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 11:38:58 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRt32-0000X5-UP for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 11:38:58 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 259C54301AB for ; Fri, 7 Apr 2006 08:38:56 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 578C14300A4 for ; Fri, 7 Apr 2006 08:38:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 466BC4311EE for ; Fri, 7 Apr 2006 08:38:21 -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 18CF84311E9 for ; Fri, 7 Apr 2006 08:38:18 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 07 Apr 2006 08:38:18 -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 k37FcI7T014092; Fri, 7 Apr 2006 08:38:18 -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, 7 Apr 2006 08:38:18 -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 Text for Issue 53 Date: Fri, 7 Apr 2006 08:38:17 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201B21026@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Text for Issue 53 Thread-Index: AcZXmiGYKUrUeU/XT1OcZaCvsWKBVgAnw06wAAH/5gAAHicW0AAV2e5gAAQCVeAAAewBIAAdCSWAABDYbCAACDF+oAAV+VaA From: "Pat Calhoun (pacalhou)" To: "Abhijit Choudhury" , "Saravanan Govindan" , "Bob O'Hara (boohara)" , "capwap" X-OriginalArrivalTime: 07 Apr 2006 15:38:18.0554 (UTC) FILETIME=[4B1ED9A0:01C65A59] X-Virus-Scanned: by amavisd-new-20030616-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: 031b5f42d6d2cd097710e6b68613cb36 My preference is to not start including optional fields in The header. I agree with Bob that those are evil. Implementations oOf Acs are free to ignore the data included in this header, and=20 requiring that the WTP include this data at all times is really not much of a burden. For ACs that do wish to ignore this data, the statistics mechanism is used instead. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Abhijit Choudhury [mailto:Abhijit@sinett.com]=20 > Sent: Thursday, April 06, 2006 10:18 PM > To: Saravanan Govindan; Bob O'Hara (boohara); capwap > Subject: RE: [Capwap] Proposed Text for Issue 53 >=20 > Bob, Saravanan: >=20 > Here's what I'd suggest. Since the current CAPWAP spec=20 > already supports carrying RSSI/SNR in the base CAPWAP header=20 > (in the 6 bytes), we can make transmission of per-packet=20 > measurement the default mode, and the exchange of aggregated=20 > information from the WTP an "optional to implement" mode. =20 > However, we will use an extension of the base CAPWAP header,=20 > say with the D bit as explained in my earlier email, to=20 > extend the CAPWAP header by > 2 more bytes to carry additional per-packet info like the data rate. >=20 > This way vendors who want to use per-packet information can=20 > do so, without burdening others who decide to implement the=20 > option of the WTP sending aggregated information. I think=20 > this is a reasonable compromise that satisfactorily resolves=20 > Issue 53, while allowing for flexibility. >=20 > Comments ? >=20 > Thanks, > Abhijit >=20 >=20 >=20 >=20 > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Thursday, April 06, 2006 6:14 PM > To: Bob O'Hara (boohara); capwap > Subject: RE: [Capwap] Proposed Text for Issue 53 >=20 >=20 > Bob, >=20 > I understand from your note that per data packet measurement is the > basis for real time AC processing. My support for aggregated=20 > measurement > exchange is based on efficiency considerations. Having said this, I do > not want to exclude one or the other - the exchanges so far show both > make for valuable additions to CAPWAP. >=20 > I think we can move forward now maintaining / incorporating both types > of exchanges in to the CAPWAP specs. >=20 > Saravanan >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 > Sent: Friday, April 07, 2006 1:15 AM > To: Saravanan Govindan; capwap > Subject: RE: [Capwap] Proposed Text for Issue 53 >=20 > Saranavan, >=20 > As I said in another email earlier in the thread than the one to which > you responded, I do not have an objection to adding the reporting of > aggregated information in a status report or other message. I do not > want to lose the ability to deal with or have access to the real time > information in the AC, on a packet by packet basis. >=20 > Why do you object to enabling a function such as real time=20 > processing of > the packet RSSI and SNR? >=20 > -Bob > =20 > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 > Sent: Wednesday, April 05, 2006 8:41 PM > To: Bob O'Hara (boohara); capwap > Subject: RE: [Capwap] Proposed Text for Issue 53 >=20 > Bob, >=20 > Without going in to pseudo-judicial rhetoric, I think we need=20 > to look at > what is needed for the CAPWAP protocol.=20 >=20 > >From the exchanges so far, we see that measurement information can be > exchanged on a per data packet basis or on an aggregated=20 > basis. We have > seen the advantages of exchanging then on aggregated basis. In the > spirit of quick resolution, I suggest we select one as the=20 > default mode > for CAPWAP and have the other as an additional feature. I believe this > was suggested earlier also.=20 >=20 > Saravanan >=20 >=20 >=20 >=20 > -----Original Message----- > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 > Sent: Thursday, April 06, 2006 10:26 AM > To: Saravanan Govindan; capwap > Subject: RE: [Capwap] Proposed Text for Issue 53 >=20 > So, your preference is to remove functionality that is already in a > product available today, by eliminating this capability from the > protocol. Given Moore's law advancement of processing=20 > capability, this > seems a bit short sighted.=20 >=20 >=20 > -Bob > =20 > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 > Sent: Wednesday, April 05, 2006 5:33 PM > To: Bob O'Hara (boohara); capwap > Subject: RE: [Capwap] Proposed Text for Issue 53 >=20 > Bob, >=20 > I will accept that there is an AC implementation for per data packet > processing.=20 >=20 > I still prefer that the CAPWAP protocol aggregate measurement > information for periodic exchange.=20 >=20 > Saravanan >=20 >=20 > =20 >=20 > -----Original Message----- > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 > Sent: Wednesday, April 05, 2006 10:15 PM > To: capwap > Subject: RE: [Capwap] Proposed Text for Issue 53 >=20 > For those AC implementations that want to use per packet data for > certain operations, aggregation of the data at the WTP as suggested by > Abhijit will preclude this. The assertion by Saravanan that=20 > an AC does > not process this information is incorrect. I can point to at=20 > least one > existing implementation that already does process this=20 > information on a > per packet basis. >=20 > The current text, with the change I suggested, is the right way to > handle this. If we want to ADD a capability that the WTP can provide > aggregation, I have no objection to that. >=20 > -Bob > =20 > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 > Sent: Tuesday, April 04, 2006 4:49 PM > To: Abhijit Choudhury; Pat Calhoun (pacalhou); capwap > Subject: RE: [Capwap] Proposed Text for Issue 53 >=20 > Hi Abhijit, >=20 > I am in support of your suggestion. It is true that the AC does not > process all data packets. Furthermore, I think for greater=20 > control, the > AC will need information about the congestion level in the WLAN. This > could be a derivative of interference and load factor.=20 >=20 > As for your suggestion, I think measurement/parameter information from > the WTP should be sent over the periodic Echo Request messages. The > advantage is that header overhead is reduced.=20 >=20 > I can prepare text for this approach. >=20 > Cheers, >=20 > Saravanan >=20 >=20 >=20 > =20 >=20 > -----Original Message----- > From: Abhijit Choudhury [mailto:Abhijit@sinett.com]=20 > Sent: Wednesday, April 05, 2006 6:52 AM > To: Pat Calhoun (pacalhou); capwap > Subject: RE: [Capwap] Proposed Text for Issue 53 >=20 > Here's another approach... >=20 > RSSI, SNR, and Data Rate are measurements/parameters > of the radio channel that are being reported to the=20 > AC for finer control. Carrying them in every data packet > on the data channel means some logic or hardware in the > AC will have to parse them out of every data packet > and send them to the control path (CPU). Typically not > every packet will go to the CPU and so this data will=20 > have to be stored and periodically sent to or read=20 > by the CPU. Note that the AC will be possibly dealing=20 > with tens to hundreds of WTPs and hence a=20 > potentially large number of STAs. This implies a=20 > large amount of per-STA measurement data has to be stored > and moved from the data path to the CPU. >=20 > A more reasonable approach is to let the WTP=20 > aggregate such data and periodically send it in the=20 > control channel to the AC. Note the WTP > has to deal with much much fewer clients - so the > storage burden is less. All we'd need is a frame that > carries this information to the AC at a specified=20 > interval of time. This period could be configurable. >=20 > Using this approach, we don't need to increase the CAPWAP header every > time we need new measurement info. We can retain the current CAPWAP > header and flexibly add any measurement information we need=20 > by adding it > in the control channel. This is particularly important as we move > forward to support 802.11n or other=20 > non-802.11 technlogies. It decouples the CAPWAP header from > the measurement data related information. >=20 > Any thoughts on this ? >=20 >=20 > Thanks, > Abhijit >=20 >=20 >=20 >=20 > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 > Sent: Monday, April 03, 2006 8:45 PM > To: capwap > Subject: [Capwap] Proposed Text for Issue 53 >=20 >=20 > Here is my proposed text for Issue 53, which is the addition of a Data > Rate In the CAPWAP header. >=20 > Please let me know if you have any comments. > =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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |VER| RID |F|L|R| Frag ID | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | > <=3D=3D=3D CHANGED!!! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload... | > +-+-+-+-+-+-+-+-+ >=20 > [...] > 4.1.8. Reserved >=20 > This 32 bit field is reserved and may be used by a binding specific > extension. Refer to the transport portion of the binding for a > specific wireless technology for the definition of this field. >=20 > [...] >=20 > 11.3.2. CAPWAP Header Reserved field >=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=20 > 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=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 over=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RSSI | SNR | Data Rate | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=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 received at > 5.5Mbps would be set to 55, while 11Mbps would be set to 110. >=20 > 11.3.2.2. Destination WLANs >=20 > The Destination WLAN field is used to specify the target=20 > WLANs for a > given frame, and is only used with broadcast and multicast frames. > This field allows the AC to transmit a single broadcast or=20 > multicast > frame to the WTP, and allows the WTP to perform the necessary frame > replication services. The field uses 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | WLAN | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > WLAN: This bit field indicates the WLAN ID (see section > Section 11.8.1.1) which the WTP will transmit the=20 > associated frame > on. For instance, if a multicast packet is to be transmitted on > WLANs 1 and 3, bits 1 and 3 of this field would be=20 > enabled. Note > this field is to be set to zero for unicast packets and=20 > is unused > if the WTP is not providing encryption services. >=20 > Reserved: This field MUST be set to zero. > =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 >=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 > _________________________________________________________________ > 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 > _________________________________________________________________ > 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 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Apr 07 11:43:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRt71-0002gf-Ux for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 11:43:03 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRt6y-0000eh-1e for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 11:43:03 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 14CF1430193 for ; Fri, 7 Apr 2006 08:42:59 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id CC37843009A for ; Fri, 7 Apr 2006 08:42:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 325B643124A for ; Fri, 7 Apr 2006 08:42:35 -0700 (PDT) Received: from test-iport-1.cisco.com (test-iport-1.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id 42153431251 for ; Fri, 7 Apr 2006 08:42:32 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 07 Apr 2006 08:42:32 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k37FgWGv023282; Fri, 7 Apr 2006 08:42: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); Fri, 7 Apr 2006 08:42:32 -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] Issue 61: Justification Required Date: Fri, 7 Apr 2006 08:42:31 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201B2102E@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Capwap] Issue 61: Justification Required Thread-Index: AcZT+tc7bxXpib7AQGu4BTcfwaIHrgA2Zq1AAWFAfKA= From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , "zhaoyujin 31390" , "Saravanan Govindan" X-OriginalArrivalTime: 07 Apr 2006 15:42:32.0691 (UTC) FILETIME=[E2991430:01C65A59] X-Virus-Scanned: by amavisd-new-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 X-Spam-Level: *** Cc: Saravanan.Govindan@sg.panasonic.com, 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.8 (+) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 To get closure on this issue, the general sentiment that I've=20 seen is that it would be a "nice to have" to allow the WTP to manage its own MAC Addresses. I heard about "possible implementations" Bbut no one that said this would be a problem for them. One example that was provided in the thread where it could be required is the one where an existing WTP is enabled to support multiple BSSIDs by loading MAC addresses after it has been=20 deployed. In this scenario, we can simply require that a contiguous range of n MAC addresses be loaded on the WTP (where 'n' is the number of BSSIDs desired), as opposed to n-1 (in order to keep the original MAC address). Thoughts? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Pat Calhoun (pacalhou)=20 > Sent: Friday, March 31, 2006 7:05 AM > To: zhaoyujin 31390; Saravanan Govindan > Cc: Saravanan.Govindan@sg.panasonic.com; capwap@frascone.com > Subject: RE: RE: [Capwap] Issue 61: Justification Required >=20 > Unfortunately, radios have BSSIDs, not the ACs. >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 > =20 >=20 > > -----Original Message----- > > From: zhaoyujin 31390 [mailto:zhaoyujin@huawei.com] > > Sent: Thursday, March 30, 2006 5:07 AM > > To: Saravanan Govindan > > Cc: Pat Calhoun (pacalhou); > > Saravanan.Govindan@sg.panasonic.com; capwap@frascone.com > > Subject: RE:RE: [Capwap] Issue 61: Justification Required > >=20 > > Hi all: > >=20 > > I think current protocol mechanism is ok.=20 > >=20 > > The map of WLAN ID and BSSID is very simple, and it is only an=20 > > offset from based BSSID. > >=20 > > The WLAN ID length is shorter than BSSID, and easy to used than=20 > > BSSID (It is a MAC address). > >=20 > > Another if keep BSSID on AC is based on vendor, and it is out of=20 > > protocol scope. > >=20 > > Best regard > > Michael > >=20 > >=20 > >=20 > > > Yes, Pat. > > >=20 > > >=20 > > >=20 > > > ----Original Message Follows---- > > > From: "Pat Calhoun (pacalhou)" > > > To: "Saravanan Govindan"=20 > > > ,"capwap"=20 > > > > > > Subject: RE: [Capwap] Issue 61: Justification Required > > > Date: Wed, 29 Mar 2006 10:36:22 -0800 > > >=20 > > > So if I understand properly, you'd like the AC to also=20 > include the=20 > > > BSSID the WTP should use, in addition to the WLAN ID? > > >=20 > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Saravanan Govindan [Saravanan.Govindan@sg.panasonic.com] > > > > Sent: Tuesday, March 28, 2006 5:21 PM > > > > To: Pat Calhoun (pacalhou); capwap > > > > Subject: RE: [Capwap] Issue 61: Justification Required > > > > > > > > Pat, > > > > > > > > I like the idea of specifying a default mode for WLAN > > configuration > > > > because it helps implementers with an exact spec. In a > > slight change > > > > from the request below, I would like to see the AC decide > > the WLAN > > > > ID and its corresponding BSSID (for the WTP) and notify > > this mapping > > > > within the Configuration Response. > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Pat Calhoun (pacalhou) [pcalhoun@cisco.com] > > > > Sent: Wednesday, March 29, 2006 2:06 AM > > > > To: capwap > > > > Subject: [Capwap] Issue 61: Justification Required > > > > > > > > The original request stated: > > > > > Page 108, Section 11.8.1.1. I would like to suggest a=20 > slightly=20 > > > > > different behavior for configuring a WLAN on a WTP. > > > > > The AC would send a WLAN ID as part of the Configuration > > > > Request and > > > > > the WTP would respond with the BSSID that would be used for > > > > the WLAN > > > > > as part of the Configuration Response. > > > > > In that way, the WTP is responsible for maintaining BSSID > > > > to WLAN ID > > > > > mappings. > > > > > > > > I'd like to better understand the justification for=20 > making such a=20 > > > > change. Anyone have strong feelings, and reasons, for > > this feature? > > > > > > > > > > > > Pat Calhoun > > > > CTO, Wireless Networking Business Unit Cisco Systems=20 > > > >=20 > _________________________________________________________________ > > > > To unsubscribe or modify your subscription options,=20 > please visit: > > > > http://lists.frascone.com/mailman/listinfo/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 > > > _________________________________________________________________ > > > Get an advanced look at the new version of MSN Messenger.=20 > > > http://messenger.msn.com.sg/Beta/Default.aspx > > >=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 > _________________________________________________________________ > 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 Apr 07 11:43:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRt7j-0002nq-NZ for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 11:43:47 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRt7j-0000fm-4h for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 11:43:47 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 775784301C9 for ; Fri, 7 Apr 2006 08:43:46 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 0A1CF4300B7 for ; Fri, 7 Apr 2006 08:43:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E436C431252 for ; Fri, 7 Apr 2006 08:43:25 -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 0C5EB43124F for ; Fri, 7 Apr 2006 08:43:23 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 07 Apr 2006 08:43:23 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k37FhM7V016431 for ; Fri, 7 Apr 2006 08:43:23 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Apr 2006 08:43: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] Issue 69: Clarify the contents of the key field inadd/update WLAN Date: Fri, 7 Apr 2006 08:43:21 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201B2102F@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 69: Clarify the contents of the key field inadd/update WLAN Thread-Index: AcZSkxT+6e4I9zTlSpOHuNm/3jGPnwHxuGHQ From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , "capwap" X-OriginalArrivalTime: 07 Apr 2006 15:43:22.0488 (UTC) FILETIME=[00477F80:01C65A5A] X-Virus-Scanned: by amavisd-new-20030616-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: 3e15cc4fdc61d7bce84032741d11c8e5 Seeing no further activity on this issue, I will consider it closed. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Pat Calhoun (pacalhou)=20 > Sent: Tuesday, March 28, 2006 10:12 AM > To: capwap > Subject: [Capwap] Issue 69: Clarify the contents of the key=20 > field inadd/update WLAN >=20 > The original comment was: > > 2. Isn't it likely for the WTP and AC to support more than one=20 > > encryption algorithm for the data from the mobile stations=20 > ? And the=20 > > mobile stations can make a choice of the encr algo that=20 > they can use. > >=20 > > In that case, the Encryption policy defined as part of=20 > Update WLAN=20 > > ( Section 11.8.1.3) and Secn 11.8.1.1 (Add WLAN) should be=20 > a bit-map. >=20 > The quick answer is no, only a single encryption mechanism=20 > can be used. > Recall that this key indication is for either shared WEP, or dynamic > (802.11i) encryption keys. Using the former, only a single=20 > method is supported. As far as 802.11i, the standard states=20 > that the lower encryption method advertised is used in=20 > broadcast messages. For instance, if a BSSID advertises=20 > support for WEP, TKIP and AES, all broadcast messages would=20 > use WEP. So there is no such concept as having different=20 > encryption group encryption algorithms per BSSID. >=20 > So I'd like to close this issue, unless folks disagree.=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 >=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 Apr 07 14:22:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRvbj-0001ia-QJ for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 14:22:55 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRvbi-0000IF-E2 for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 14:22:55 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A67D143016F for ; Fri, 7 Apr 2006 11:22:53 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C4F2643009A for ; Fri, 7 Apr 2006 11:22:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 53E724313D8 for ; Fri, 7 Apr 2006 11:22:31 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id C9469431372 for ; Fri, 7 Apr 2006 11:22:28 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k37IMSMC003115 for ; Fri, 7 Apr 2006 11:22:28 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k37IMRSf003111 for ; Fri, 7 Apr 2006 11:22:28 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 7 Apr 2006 11:22:27 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [Capwap] Use of "Status/WLANs" field in ctrl msgs 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: 79899194edc4f33a41f49410777972f8 HI, Presently, the "Status/WLANs" field in the CAPWAP header is not used (always has a value of zero) in CAPWAP control messages. I suggest that this contain a timestamp sent in a request and echoed back in a response to help determine retransmission timeout (RTO). The details for how to use this and the motivations are described in "UNIX Network Programming, vol 1, 3rd Ed" by Stevens, section 22.5 (starts on page 597). Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 07 14:35:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRvnu-0001S2-QI for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 14:35:30 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRvnt-0000eG-EU for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 14:35:30 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DCC9143015C for ; Fri, 7 Apr 2006 11:35:28 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D91084300A4 for ; Fri, 7 Apr 2006 11:35:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C3F6D39801A for ; Fri, 7 Apr 2006 11:35:10 -0700 (PDT) Received: from trpz.com (mail1.trpz.com [66.7.225.38]) by zoidberg.tigertech.net (Postfix) with ESMTP id 28D78398007 for ; Fri, 7 Apr 2006 11:35:08 -0700 (PDT) Received: from [127.0.0.1] ([192.168.12.194]) by trpz.com (8.13.5/8.11.6) with ESMTP id k37IVtYO020530; Fri, 7 Apr 2006 11:31:55 -0700 Message-ID: <4436B0D7.1040808@trapezenetworks.com> Date: Fri, 07 Apr 2006 11:35:03 -0700 From: Jim Murphy User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: capwap Subject: Re: [Capwap] Proposed Text for Issue 53 References: <4FF84B0BC277FF45AA27FE969DD956A201B21023@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201B21023@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: 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: 0bc60ec82efc80c84b8d02f4b0e4de22 Pat Calhoun (pacalhou) wrote: > Jim Murphy says: >> Furthermore, this bandwidth inefficient, superfluous >> information in the data path should be optional. > > I think 2 bytes in the header can hardly be called > bandwidth innefficient. Do you prefer wasteful? The current proposal is 4 bytes. Why burden everyone with 4 bytes per packet just to support this sub-optimal, LWAPP backward compatibility requirement? Thanks, Jim > > 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 Apr 07 20:39:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS1To-00009I-5O for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 20:39:08 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS1Tm-00047N-Oa for capwap-archive@lists.ietf.org; Fri, 07 Apr 2006 20:39:08 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D79504300BF for ; Fri, 7 Apr 2006 17:39:05 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 61CE043006C for ; Fri, 7 Apr 2006 17:38:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3ADAB144801A for ; Fri, 7 Apr 2006 17:38:47 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id AC4C51448010 for ; Fri, 7 Apr 2006 17:38:45 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k380cf93001310 for ; Fri, 7 Apr 2006 17:38:41 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k380ceT6001304 for ; Fri, 7 Apr 2006 17:38:40 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 7 Apr 2006 17:38:39 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [Capwap] Please describe flow for image transfer to WTP 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 HI, I'm having a little trouble understanding the image download operation in the CAPWAP-00 spec. Pat (or anyone else that understands) would you please provide an example. In particular, it appears that either an AC and WTP can initiate an image transfer. Is this correct, or can only the AC push an image to a WTP, or can a WTP also pull an image? There are two message types - Image Data Request(14), and Image Data Response(15), which are defined in sections 8.1 and 8.2 respectively. The message elements for a request are: 1) a filename (section 8.1.1) and 2) image data (section 8.1.2) A response has no message elements. Consider an image file named xyz-wtp-foo-ver1.1.9.img on the AC that is 48000 octets long. 1) what are the operations (and the values of the message elements) to transfer this file to the WTP? 2) where does the WTP store the image? (Is it to "memory", or can it also be to persistent store, such as flash? If there are more than one place to store the image (such as 2 banks of flash), how is this indicated?) 3) what happens if the WTP can not store the image due to say, not enough memory space, not enough of some other system resource, a hardware failure in storage subsystem. 4) can two image transfers occur at the same time? If so, how are blocks of data from one image distingushed from the other image? 5) The control messages are running on DTLS, so it seems like the checksum is not needed. Would it's use be explained? 6) Is it assumed that the complete image is to be transfer before it is to be stored in persistent storage (flash)? 7) When an how would an WTP initiate an image transfer from the AC to the WTP? 8) Can an image be transfered from the WTP to an AC? If so, please describe. Thanks, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Apr 10 10:24:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxJB-00007H-5v for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 10:24:01 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSxJ7-0003PR-I9 for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 10:24:01 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9C9494300D6 for ; Mon, 10 Apr 2006 07:23:56 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2CB25430073 for ; Mon, 10 Apr 2006 07:23:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0C3C2144800D for ; Mon, 10 Apr 2006 07:23:27 -0700 (PDT) Received: from aruba-mx.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by hermes.tigertech.net (Postfix) with SMTP id 27C5F1448008 for ; Mon, 10 Apr 2006 07:23:23 -0700 (PDT) Received: from aruba-mx1.arubanetworks.com ([10.1.1.17]) by aruba-mx.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 07:23:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: [Capwap] Issue 61: Justification Required Date: Mon, 10 Apr 2006 07:23:23 -0700 Message-ID: <99C8B9B2AD99664A87E12C839A2E9093023744CE@aruba-mx1.arubanetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Capwap] Issue 61: Justification Required Thread-Index: AcZT+tc7bxXpib7AQGu4BTcfwaIHrgA2Zq1AAWFAfKAAAq1ucA== From: "Partha Narasimhan" To: "Pat Calhoun (pacalhou)" , "zhaoyujin 31390" , "Saravanan Govindan" X-OriginalArrivalTime: 10 Apr 2006 14:23:23.0232 (UTC) FILETIME=[52F06600:01C65CAA] X-Virus-Scanned: by amavisd-new-20030616-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@sg.panasonic.com, 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: 8b6657e60309a1317174c9db2ae5f227 While many existing implementations are probably not affected as it stands today, I do sense ugliness in the current mechanism that can be easily addressed with a few lines of text. I have no trouble with using a shorter WLAN-ID, but would prefer to have the WTP choose the BSSID to WLAN-ID mapping. This way we do not have to make assumptions on how WTPs manage their MAC addresses. I plan to submit text to address this the cleaner way, unless there are serious objections to my doing so. Thanks partha > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Friday, April 07, 2006 8:43 AM > To: Pat Calhoun (pacalhou); zhaoyujin 31390; Saravanan Govindan > Cc: Saravanan.Govindan@sg.panasonic.com; capwap@frascone.com > Subject: RE: RE: [Capwap] Issue 61: Justification Required >=20 > To get closure on this issue, the general sentiment that I've > seen is that it would be a "nice to have" to allow the WTP to > manage its own MAC Addresses. I heard about "possible implementations" > Bbut no one that said this would be a problem for them. >=20 > One example that was provided in the thread where it could be > required is the one where an existing WTP is enabled to support > multiple BSSIDs by loading MAC addresses after it has been > deployed. In this scenario, we can simply require that a contiguous > range of n MAC addresses be loaded on the WTP (where 'n' is the > number of BSSIDs desired), as opposed to n-1 (in order to keep the > original MAC address). >=20 > Thoughts? >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 >=20 >=20 > > -----Original Message----- > > From: Pat Calhoun (pacalhou) > > Sent: Friday, March 31, 2006 7:05 AM > > To: zhaoyujin 31390; Saravanan Govindan > > Cc: Saravanan.Govindan@sg.panasonic.com; capwap@frascone.com > > Subject: RE: RE: [Capwap] Issue 61: Justification Required > > > > Unfortunately, radios have BSSIDs, not the ACs. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > -----Original Message----- > > > From: zhaoyujin 31390 [mailto:zhaoyujin@huawei.com] > > > Sent: Thursday, March 30, 2006 5:07 AM > > > To: Saravanan Govindan > > > Cc: Pat Calhoun (pacalhou); > > > Saravanan.Govindan@sg.panasonic.com; capwap@frascone.com > > > Subject: RE:RE: [Capwap] Issue 61: Justification Required > > > > > > Hi all: > > > > > > I think current protocol mechanism is ok. > > > > > > The map of WLAN ID and BSSID is very simple, and it is only an > > > offset from based BSSID. > > > > > > The WLAN ID length is shorter than BSSID, and easy to used than > > > BSSID (It is a MAC address). > > > > > > Another if keep BSSID on AC is based on vendor, and it is out of > > > protocol scope. > > > > > > Best regard > > > Michael > > > > > > > > > > > > > Yes, Pat. > > > > > > > > > > > > > > > > ----Original Message Follows---- > > > > From: "Pat Calhoun (pacalhou)" > > > > To: "Saravanan Govindan" > > > > ,"capwap" > > > > > > > > Subject: RE: [Capwap] Issue 61: Justification Required > > > > Date: Wed, 29 Mar 2006 10:36:22 -0800 > > > > > > > > So if I understand properly, you'd like the AC to also > > include the > > > > BSSID the WTP should use, in addition to the WLAN ID? > > > > > > > > Pat Calhoun > > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Saravanan Govindan [Saravanan.Govindan@sg.panasonic.com] > > > > > Sent: Tuesday, March 28, 2006 5:21 PM > > > > > To: Pat Calhoun (pacalhou); capwap > > > > > Subject: RE: [Capwap] Issue 61: Justification Required > > > > > > > > > > Pat, > > > > > > > > > > I like the idea of specifying a default mode for WLAN > > > configuration > > > > > because it helps implementers with an exact spec. In a > > > slight change > > > > > from the request below, I would like to see the AC decide > > > the WLAN > > > > > ID and its corresponding BSSID (for the WTP) and notify > > > this mapping > > > > > within the Configuration Response. > > > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Pat Calhoun (pacalhou) [pcalhoun@cisco.com] > > > > > Sent: Wednesday, March 29, 2006 2:06 AM > > > > > To: capwap > > > > > Subject: [Capwap] Issue 61: Justification Required > > > > > > > > > > The original request stated: > > > > > > Page 108, Section 11.8.1.1. I would like to suggest a > > slightly > > > > > > different behavior for configuring a WLAN on a WTP. > > > > > > The AC would send a WLAN ID as part of the Configuration > > > > > Request and > > > > > > the WTP would respond with the BSSID that would be used for > > > > > the WLAN > > > > > > as part of the Configuration Response. > > > > > > In that way, the WTP is responsible for maintaining BSSID > > > > > to WLAN ID > > > > > > mappings. > > > > > > > > > > I'd like to better understand the justification for > > making such a > > > > > change. Anyone have strong feelings, and reasons, for > > > this feature? > > > > > > > > > > > > > > > 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 > > > > > > > > _________________________________________________________________ > > > > 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 >=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 Apr 10 12:11:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSyzH-0001jn-Rm for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 12:11:35 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSyzG-00087Y-Ej for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 12:11:35 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9536E4300BD for ; Mon, 10 Apr 2006 09:11:33 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D8C2443005F for ; Mon, 10 Apr 2006 09:11:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C07A1144800C for ; Mon, 10 Apr 2006 09:11:10 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.201]) by hermes.tigertech.net (Postfix) with ESMTP id 07A9B1448014 for ; Mon, 10 Apr 2006 09:11:08 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so636384wxd for ; Mon, 10 Apr 2006 09:11:07 -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=IqaedrJ8lCYEeiVMBjp5m+U1AEX/b2ZmVlDx/Dpcm/BQ8hnp5VCJd3kDptNvtjwvzkbIXhZLjwJ6CuVKVl6xD9oTJc/ZufWti3fVH2tnSjs/InvCzRlQLKT16rM92zFVfyheoAnLlbtX5I3i2Bpsby0TTD4E0cebjb462vOrAa4= Received: by 10.70.24.8 with SMTP id 8mr3136723wxx; Mon, 10 Apr 2006 09:11:07 -0700 (PDT) Received: by 10.70.133.14 with HTTP; Mon, 10 Apr 2006 09:11:07 -0700 (PDT) Message-ID: <5bfe7a820604100911q617c1965vcb6b244a5e8974da@mail.gmail.com> Date: Mon, 10 Apr 2006 09:11:07 -0700 From: "Dorothy Stanley" To: capwap MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.8 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_10_20, HTML_MESSAGE, RCVD_BY_IP X-Spam-Level: Subject: [Capwap] Proposed resolution for Issue 39 - Remove AC Address 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="===============0814984907==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.8 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 --===============0814984907== Content-Type: multipart/alternative; boundary="----=_Part_5135_15763495.1144685467268" ------=_Part_5135_15763495.1144685467268 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, Comments in the issue data base indicate that the proposed resolution for issue #39 has been generally agreed to - to remove the AC address message element. >Page 35 -- 5.2.1 AC address > I do not understand this. It is not useful with a layer 3 > transport. If using a layer 2 transport then I would assume > the broadcast or multicast from the Discovery Message would > have been heard by any other AC's -- so rather than respond > -- would it not be best to stay silent? Agree to remove this information element Proposed resolution: delete 5.2.1 "AC address", and references to it Let me know if there are any objections to this proposed resolution. Thanks, Dorothy ------=_Part_5135_15763495.1144685467268 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All,

Comments in the issue data base indicate that  the proposed resolution= for issue #39
has been generally agreed to - to remove the AC address message element. 
>Page 35 -- 5.2.1 AC address
> I do not understand this.  It =
is not useful with a layer 3 
> transport.  If using a layer 2 transp=
ort then I would assume 
> the broadcast or multicast from the Discov=
ery Message would=20

> have been heard by any other AC's -- so rather than respond 
&g=
t; -- would it not be best to stay silent?

Agree to remove this info=
rmation element

Proposed resolution: delete 5.2.1 "AC address", and references to= it

Let me know if there are any objections to this proposed resolution.

Thanks,

Dorothy
------=_Part_5135_15763495.1144685467268-- --===============0814984907== 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 --===============0814984907==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Apr 10 12:55:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSzfZ-00084u-0Z for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 12:55:17 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSzfX-00010J-FV for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 12:55:16 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id ABD224300DD for ; Mon, 10 Apr 2006 09:55:14 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E735A43005F for ; Mon, 10 Apr 2006 09:54:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CB06D1448007 for ; Mon, 10 Apr 2006 09:54:45 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.194]) by hermes.tigertech.net (Postfix) with ESMTP id D62281448012 for ; Mon, 10 Apr 2006 09:54:42 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h30so960870wxd for ; Mon, 10 Apr 2006 09:54:42 -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=hY9ulQ/sn3mYeHrn7t7peGYJcAmBkIDs0WUXL9PBeCCZj4izisHtnG99sdaDuKUGhDSxa3cwbXrjd7z4XJmRYiRRjFzPmXI06cFsDaSiwK49LCWTJEbVCiWP9ZwIsPU58+ePgYGOgO34hD888wfz+AqWFZAVuR/j+penusDgX98= Received: by 10.70.68.10 with SMTP id q10mr5232869wxa; Mon, 10 Apr 2006 09:54:42 -0700 (PDT) Received: by 10.70.133.14 with HTTP; Mon, 10 Apr 2006 09:54:42 -0700 (PDT) Message-ID: <5bfe7a820604100954x2756a278gdb8e1928f79948f5@mail.gmail.com> Date: Mon, 10 Apr 2006 09:54:42 -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.9 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_10_20, HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP X-Spam-Level: Subject: [Capwap] Proposed Resolution to Issue 42 - PMK Sharing 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="===============0506783021==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.9 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f --===============0506783021== Content-Type: multipart/alternative; boundary="----=_Part_6043_12842278.1144688082127" ------=_Part_6043_12842278.1144688082127 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, Issue 42 - PMK Sharing has the following discussion in the issues data base= : Issue: In the case of an AC managing a same PMK across many WTPs, IEEE 802.11 stations cannot distinguish between PMKs that are validly shared and those that have been compromised (I0 of Issues/Recommendations). My recommendation: Include text in the Security Considerations (draft-ohara-capwap-lwapp-03.tx= t) Section 15 along the lines; "The CAPWAP protocol may be used in scenarios in which an AC manages a PMK across many WTPs. In such scenarios, IEEE 802.11 stations moving across WTP= s cannot distinguish between PMKs that are legitimately shared and PMKs that have been compromised. The CAPWAP WG recognizes this ambiguity and recommends implementers of the protocol to review the outcome of IEEE 802.11r efforts for resolution." No agreement on this request Perhaps we need further clarification on what "manages a PMK across many WTPs" means. If "manages a PMK across many WTPs" means that it delivers the PMK to more than one WTP, then: It is not clear that the CAPWAP specification, current draft does indeed provide a mechanism to deliver the PMK to the WTPs, to share the PMK across WTPs. Below are the message elements that deliver keys: - The IEEE 802.11 Add WLAN message element (11.8.1.1) - typically delivers the GTK - The IEEE 802.11 Mobile Session Key message element (11.7.1.2) delivers a session key, the PTK - The IEEE 802.11 Update WLAN message element (11.8.1.3) - typically delivers the GTK CAPWAP does support the ability to securely deliver the GTK and PTK from th= e AC to a WTP. CAPWAP supports a secure control interface, requiring mutual authentication between the AC and WTPs that are connected to it. Recommended resolution: Reject the comment, with the reason that "An implementation which delivers PMKs to WTPs is not in compliance with th= e CAPWAP protocol" and change the text in 11.8.1.1 and 11.8.1.3 describing the key that is delivered from: "Key: A 32 byte Session Key to use with the encryption policy" to "Key: A 32 byte key to use with the encryption key, typically the GTK" Comments, discussion please. Thanks, Dorothy ------=_Part_6043_12842278.1144688082127 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All,

Issue 42 - PMK Sharing has the following discussion in the issues data base= :

Issue:

In the case of an AC managing a same PMK across many WTP=
s, IEEE 802.11 
stations cannot distinguish between PMKs that are validl=
y shared and those 
that have been compromised (I0 of Issues/Recommendat=
ions).


My recommendation:

Include text in the Security Consideratio=
ns (draft-ohara-capwap-lwapp-03.txt) 
Section 15 along the lines;
"The CAPWAP protocol may be used in scenarios in which an AC manages a PMK=
=20

across many WTPs. In such scenarios, IEEE 802.11 stations moving across=
 WTPs 
cannot distinguish between PMKs that are legitimately shared and =
PMKs that 
have been compromised. 
The CAPWAP WG recognizes this ambi=
guity and recommends implementers of the=20

protocol to review the outcome of IEEE 802.11r efforts for resolution."=


No agreement on this request

Perhaps we need further clarification on what "manages a PMK across ma= ny WTPs" means.
If "manages a PMK across many WTPs" means that it delivers the PM= K to more than one WTP, then:

It is not clear that the CAPWAP specification, current draft  does ind= eed provide a mechanism to deliver
the PMK to the WTPs, to share the PMK across WTPs.  Below are the mess= age elements that deliver keys:
- The IEEE 802.11 Add WLAN message element (11.= 8.1.1) - typically delivers the GTK
- The IEEE 802.11 Mobile Session Key message element (11.7.1.2) delivers a session key, the PTK
- The IEEE 802.11 Update WLAN message element (= 11.8.1.3)  - typically delivers the GTK

CAPWAP does support the ability to securely deliver the GTK and PTK from th= e AC to a WTP.
CAPWAP supports a secure control interface, requiring mutual authentication between the AC and  WTPs that are connected to it.

Recommended resolution:
Reject the comment, with the reason that
"An implementation which delivers PMKs to WTPs is not in compliance wi= th the CAPWAP protocol"

and change the text in 11.8.1.1 and 11.8.1.3 describing the key that is delivered from= :
"Key: A 32 byte Session Key to use with the encryption policy" to=
"Key: A 32 byte key to use with the encryption key, typically the GTK&= quot;

Comments, discussion please.

Thanks,

Dorothy
------=_Part_6043_12842278.1144688082127-- --===============0506783021== 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 --===============0506783021==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Apr 10 12:56:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSzgf-0008Nw-DC for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 12:56:25 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSzgd-00011J-Vp for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 12:56:25 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A40A54300E2 for ; Mon, 10 Apr 2006 09:56:23 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 844DE43005F for ; Mon, 10 Apr 2006 09:55:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 799FE398043 for ; Mon, 10 Apr 2006 09:55:54 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id 99CF2398024 for ; Mon, 10 Apr 2006 09:55:52 -0700 (PDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 10 Apr 2006 09:55:51 -0700 X-IronPort-AV: i="4.04,108,1144047600"; d="scan'208"; a="1793456398:sNHT50801958" 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 k3AGtlYu006653; Mon, 10 Apr 2006 09:55:50 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Apr 2006 09:55:49 -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 Text for Issue 53 Date: Mon, 10 Apr 2006 09:55:48 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201B2164D@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Text for Issue 53 Thread-Index: AcZachNVNCHcZDioSY6CcG/awj40IgCTSkCw From: "Pat Calhoun (pacalhou)" To: "Jim Murphy" , "capwap" X-OriginalArrivalTime: 10 Apr 2006 16:55:49.0742 (UTC) FILETIME=[9EAF10E0:01C65CBF] 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: 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: 7d33c50f3756db14428398e2bdedd581 > Do you prefer wasteful? The current proposal is 4 bytes. > Why burden everyone with 4 bytes per packet just to support=20 > this sub-optimal, LWAPP backward compatibility requirement? This has nothing to do with LWAPP backward compatibility, in fact you will note that this is actually changing the format of the header. So clearly one cannot exactly claim that backward compability is main Motivation here. That said, perhaps it would be useful if you were to=20 provide ideas on how you plan to provide real-time monitoring of signal strength, etc? Or are you claiming that this is not required and wireless technologies really don't need any different treatment=20 over a normal wired connection? 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 Apr 10 12:58:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSzil-0000dJ-1e for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 12:58:35 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSzij-0001CL-Ch for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 12:58:35 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id F27034300DB for ; Mon, 10 Apr 2006 09:58:32 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7E5364300C5 for ; Mon, 10 Apr 2006 09:57:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 72C0B398024 for ; Mon, 10 Apr 2006 09:57:46 -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 6D517398044 for ; Mon, 10 Apr 2006 09:57:42 -0700 (PDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 10 Apr 2006 09:57:42 -0700 X-IronPort-AV: i="4.04,108,1144047600"; d="scan'208"; a="267691816:sNHT35434790" 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 k3AGvd1j019608; Mon, 10 Apr 2006 09:57:39 -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, 10 Apr 2006 09:57: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] Issue 61: Justification Required Date: Mon, 10 Apr 2006 09:57:35 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201B21652@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Capwap] Issue 61: Justification Required Thread-Index: AcZT+tc7bxXpib7AQGu4BTcfwaIHrgA2Zq1AAWFAfKAAAq1ucACW4deA From: "Pat Calhoun (pacalhou)" To: "Partha Narasimhan" , "zhaoyujin 31390" , "Saravanan Govindan" X-OriginalArrivalTime: 10 Apr 2006 16:57:39.0732 (UTC) FILETIME=[E03E3540:01C65CBF] 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: Saravanan.Govindan@sg.panasonic.com, 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: e1924de3f9fb68e58c31920136007eb1 No objections on my end, but I'd like a sense for the group on whether they feel this is needed. My current feeling is that this level of complexity is not required as the alternative is clearly=20 there, and works fine with most manufacturing environments that I=20 am aware of. I guess I'm still looking for the driving application that makes this necessary... Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Partha Narasimhan [mailto:partha@arubanetworks.com]=20 > Sent: Monday, April 10, 2006 7:23 AM > To: Pat Calhoun (pacalhou); zhaoyujin 31390; Saravanan Govindan > Cc: Saravanan.Govindan@sg.panasonic.com; capwap@frascone.com > Subject: RE: RE: [Capwap] Issue 61: Justification Required >=20 > While many existing implementations are probably not affected=20 > as it stands today, I do sense ugliness in the current=20 > mechanism that can be easily addressed with a few lines of=20 > text. I have no trouble with using a shorter WLAN-ID, but=20 > would prefer to have the WTP choose the BSSID to WLAN-ID=20 > mapping. This way we do not have to make assumptions on how=20 > WTPs manage their MAC addresses. >=20 > I plan to submit text to address this the cleaner way, unless=20 > there are serious objections to my doing so. >=20 > Thanks > partha >=20 > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Friday, April 07, 2006 8:43 AM > > To: Pat Calhoun (pacalhou); zhaoyujin 31390; Saravanan Govindan > > Cc: Saravanan.Govindan@sg.panasonic.com; capwap@frascone.com > > Subject: RE: RE: [Capwap] Issue 61: Justification Required > >=20 > > To get closure on this issue, the general sentiment that=20 > I've seen is=20 > > that it would be a "nice to have" to allow the WTP to=20 > manage its own=20 > > MAC Addresses. I heard about "possible implementations" > > Bbut no one that said this would be a problem for them. > >=20 > > One example that was provided in the thread where it could=20 > be required=20 > > is the one where an existing WTP is enabled to support=20 > multiple BSSIDs=20 > > by loading MAC addresses after it has been deployed. In=20 > this scenario,=20 > > we can simply require that a contiguous range of n MAC addresses be=20 > > loaded on the WTP (where 'n' is the number of BSSIDs desired), as=20 > > opposed to n-1 (in order to keep the original MAC address). > >=20 > > Thoughts? > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Pat Calhoun (pacalhou) > > > Sent: Friday, March 31, 2006 7:05 AM > > > To: zhaoyujin 31390; Saravanan Govindan > > > Cc: Saravanan.Govindan@sg.panasonic.com; capwap@frascone.com > > > Subject: RE: RE: [Capwap] Issue 61: Justification Required > > > > > > Unfortunately, radios have BSSIDs, not the ACs. > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > -----Original Message----- > > > > From: zhaoyujin 31390 [mailto:zhaoyujin@huawei.com] > > > > Sent: Thursday, March 30, 2006 5:07 AM > > > > To: Saravanan Govindan > > > > Cc: Pat Calhoun (pacalhou); > > > > Saravanan.Govindan@sg.panasonic.com; capwap@frascone.com > > > > Subject: RE:RE: [Capwap] Issue 61: Justification Required > > > > > > > > Hi all: > > > > > > > > I think current protocol mechanism is ok. > > > > > > > > The map of WLAN ID and BSSID is very simple, and it is only an > > > > offset from based BSSID. > > > > > > > > The WLAN ID length is shorter than BSSID, and easy to=20 > used than > > > > BSSID (It is a MAC address). > > > > > > > > Another if keep BSSID on AC is based on vendor, and=20 > it is out of > > > > protocol scope. > > > > > > > > Best regard > > > > Michael > > > > > > > > > > > > > > > > > Yes, Pat. > > > > > > > > > > > > > > > > > > > > ----Original Message Follows---- > > > > > From: "Pat Calhoun (pacalhou)" > > > > > To: "Saravanan Govindan" > > > > > ,"capwap" > > > > > > > > > > Subject: RE: [Capwap] Issue 61: Justification Required > > > > > Date: Wed, 29 Mar 2006 10:36:22 -0800 > > > > > > > > > > So if I understand properly, you'd like the AC to also > > > include the > > > > > BSSID the WTP should use, in addition to the WLAN ID? > > > > > > > > > > Pat Calhoun > > > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Saravanan Govindan=20 > [Saravanan.Govindan@sg.panasonic.com] > > > > > > Sent: Tuesday, March 28, 2006 5:21 PM > > > > > > To: Pat Calhoun (pacalhou); capwap > > > > > > Subject: RE: [Capwap] Issue 61: Justification Required > > > > > > > > > > > > Pat, > > > > > > > > > > > > I like the idea of specifying a default mode for WLAN > > > > configuration > > > > > > because it helps implementers with an exact spec. In a > > > > slight change > > > > > > from the request below, I would like to see the AC decide > > > > the WLAN > > > > > > ID and its corresponding BSSID (for the WTP) and notify > > > > this mapping > > > > > > within the Configuration Response. > > > > > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Pat Calhoun (pacalhou) [pcalhoun@cisco.com] > > > > > > Sent: Wednesday, March 29, 2006 2:06 AM > > > > > > To: capwap > > > > > > Subject: [Capwap] Issue 61: Justification Required > > > > > > > > > > > > The original request stated: > > > > > > > Page 108, Section 11.8.1.1. I would like to suggest a > > > slightly > > > > > > > different behavior for configuring a WLAN on a WTP. > > > > > > > The AC would send a WLAN ID as part of the Configuration > > > > > > Request and > > > > > > > the WTP would respond with the BSSID that would=20 > be used for > > > > > > the WLAN > > > > > > > as part of the Configuration Response. > > > > > > > In that way, the WTP is responsible for maintaining BSSID > > > > > > to WLAN ID > > > > > > > mappings. > > > > > > > > > > > > I'd like to better understand the justification for > > > making such a > > > > > > change. Anyone have strong feelings, and reasons, for > > > > this feature? > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > _________________________________________________________________ > > > > > 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 > >=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 Mon Apr 10 13:20:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT044-0006rh-MJ for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 13:20:36 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT043-0002go-6a for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 13:20:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 995784300E2 for ; Mon, 10 Apr 2006 10:20:34 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 776A743005F for ; Mon, 10 Apr 2006 10:20:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5FEBD398023 for ; Mon, 10 Apr 2006 10:20:07 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.205]) by zoidberg.tigertech.net (Postfix) with ESMTP id D3C65398046 for ; Mon, 10 Apr 2006 10:19:58 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id i28so684231wxd for ; Mon, 10 Apr 2006 10:19:58 -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=R5diCUfWEm3QtjPhcndycUUMrf+8DDe+B4zd7h6rwIerg0vfCnAwgh9NY2mu0EKKywTuTiT/8znRXMvBMy//Q++2AnhDjrRvCAqVbtHR5VT9agnf0O0MI3lGaIsraYi57sdDBVql4BBImfU8Qs4aWXMbNHIoc+jwT5nA5ukipjU= Received: by 10.70.43.2 with SMTP id q2mr5305885wxq; Mon, 10 Apr 2006 10:19:58 -0700 (PDT) Received: by 10.70.133.14 with HTTP; Mon, 10 Apr 2006 10:19:58 -0700 (PDT) Message-ID: <5bfe7a820604101019n71e902cfsfe29dcf2d8ae8c20@mail.gmail.com> Date: Mon, 10 Apr 2006 10:19:58 -0700 From: "Dorothy Stanley" To: capwap MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.759 tagged_above=-999 required=7 tests=FROM_ENDS_IN_NUMS, HTML_00_10, HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP X-Spam-Level: Subject: [Capwap] Proposed Resolution to Issue 45 - Issue on combining messages 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="===============1108435097==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.8 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 --===============1108435097== Content-Type: multipart/alternative; boundary="----=_Part_6539_17873397.1144689598165" ------=_Part_6539_17873397.1144689598165 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, 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 Comments please. Thanks, Dorothy ------=_Part_6539_17873397.1144689598165 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All,

Issue 45, Issue on Combining messages currently has the following discussio= n 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 combi=
ne 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

Comments please.

Thanks,

Dorothy
------=_Part_6539_17873397.1144689598165-- --===============1108435097== 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 --===============1108435097==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Apr 10 14:04:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT0jj-0004wr-2D for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 14:03:39 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT0Yr-0003UL-1F for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 13:52:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 572534300D8 for ; Mon, 10 Apr 2006 10:52:24 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 0993D430077 for ; Mon, 10 Apr 2006 10:51:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E8A051448019 for ; Mon, 10 Apr 2006 10:51:57 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.196]) by hermes.tigertech.net (Postfix) with ESMTP id 1C3621448013 for ; Mon, 10 Apr 2006 10:51:56 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so652413wxd for ; Mon, 10 Apr 2006 10:51: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:mime-version:content-type; b=ZBDQ61ZiPM7xemNqn8PWlmVykoYq1+VAc+2ee5b6bmONfDr5FwG1KoxOdbuZXrl9yIRi+TjW8hW7grKhmIvRYoGgLO7O9D/WZRugek8RiOYkMAtW1NH0chqhD5o/7E4ViCHX2tkTCsrutq4tK44oo3E9KStpTcMk1VAdcLAz0Ik= Received: by 10.70.14.2 with SMTP id 2mr391258wxn; Mon, 10 Apr 2006 10:51:56 -0700 (PDT) Received: by 10.70.133.14 with HTTP; Mon, 10 Apr 2006 10:51:56 -0700 (PDT) Message-ID: <5bfe7a820604101051s3c1b3060rd7761b985044f93f@mail.gmail.com> Date: Mon, 10 Apr 2006 10:51:56 -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 X-Spam-Level: Subject: [Capwap] Proposed Resolution for Issue 58 - Need to rename Config Request and Config Update Request 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="===============0856727523==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.8 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 --===============0856727523== Content-Type: multipart/alternative; boundary="----=_Part_7167_20788581.1144691516335" ------=_Part_7167_20788581.1144691516335 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, Issue 58 currently has the following discussion in the issues list: > > Page 104, Section 11.8.1. The description for Config-Request > describes a message sent from the AC to the WTP. In Section > 7.2, the config request is sent from the AP to the WTP. I > would prefer the mechanism described in 11.8.1. > 40.=09 There are two types of configuration messages, one that comes from the WTP to the AC, and is used for the WTP to update the AC with its config at boot time. The second allows the AC to push down a new config to the WTP, and this can occur at run time. The former is called the Configure Request, while the latter is called the Configuration update Request. That said, I think we should come up with a different set of names to differentiate them better. In the Configure State, we currently have: Configure Request - WTP sends AC its boot-time config Configure Response - AC overrides the current WTP boot-time config In the Run state, we currently have Configure Update Request - AC sends WTP new config parameters Configure Update Response - WTP acknowledges the Configure Update Request, includes result code IEEE 802.11 WLAN Config Request Recommended resolution: Accept, make the following changes: In the Configure State, rename to Configuration Status - WTP sends AC its boot-time config Configuration Status Response - AC overrides the current WTP boot-time config In the Run state, - keep Configure Update Request - AC sends WTP new config parameters Configure Update Response - WTP acknowledges the Configure Update Request, includes result code, and in IEEE 802.11 WLAN Config Request, update the text in 11.8.1 to reference usage after Configure Update Request Comments please. Thanks, Dorothy ------=_Part_7167_20788581.1144691516335 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All,

Issue 58 currently has the following discussion in the issues list:

> 
> Page 104, Section 11.8.1. The description for Config-Req=
uest 
> describes a message sent from the AC to the WTP. In Section <=
br>> 7.2, the config request is sent from the AP to the WTP. I 

> would prefer the mechanism described in 11.8.1.
> 40.=09

=
There are two types of configuration messages, one that comes from
the W=
TP to the AC, and is used for the WTP to update the AC with its
config a=
t boot time. The second allows the AC to push down a new

config to the WTP, and this can occur at run time. The former is
cal=
led the Configure Request, while the latter is called the Configuration
=
update Request. That said, I think we should come up with a different

set of names to differentiate them better.

In the Configure State, we currently have:
Configure Request - WTP sends AC its boot-time config
Configure Response - AC overrides the current WTP boot-time config

In the Run state, we currently have
Configure Update Request - AC sends WTP new config parameters
Configure Update Response - WTP acknowledges the Configure Update Request, = includes result code
IEEE 802.11 WLAN Config Request

Recommended resolution: Accept, make the following changes:

In the Configure State, rename to
Configuration Status - WTP sends AC its boot-time config
Configuration Status Response - AC overrides the current WTP boot-time conf= ig

In the Run state,  - keep
Configure Update Request - AC sends WTP new config parameters
Configure Update Response - WTP acknowledges the Configure Update Request, = includes result code, and in
IEEE 802.11 WLAN Config Request, update the text in 11.8.1  to referen= ce usage after Configure Update Request

Comments please.

Thanks,

Dorothy
------=_Part_7167_20788581.1144691516335-- --===============0856727523== 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 --===============0856727523==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Apr 10 14:48:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT1RU-0003sR-S1 for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 14:48:52 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT1RT-00066K-Fd for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 14:48:52 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A7CCA4300F0 for ; Mon, 10 Apr 2006 11:48:50 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B79E543007C for ; Mon, 10 Apr 2006 11:48:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A576C39801D for ; Mon, 10 Apr 2006 11:48:32 -0700 (PDT) Received: from trpz.com (mail1.trpz.com [66.7.225.38]) by zoidberg.tigertech.net (Postfix) with ESMTP id A965D398024 for ; Mon, 10 Apr 2006 11:48:30 -0700 (PDT) Received: from [127.0.0.1] ([192.168.12.194]) by trpz.com (8.13.5/8.11.6) with ESMTP id k3AImLou031710; Mon, 10 Apr 2006 11:48:22 -0700 Message-ID: <443AA87B.8000000@trapezenetworks.com> Date: Mon, 10 Apr 2006 11:48:27 -0700 From: Jim Murphy User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" Subject: Re: [Capwap] Proposed Text for Issue 53 References: <4FF84B0BC277FF45AA27FE969DD956A201B2164D@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201B2164D@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: a7d6aff76b15f3f56fcb94490e1052e4 Pat, Pat Calhoun (pacalhou) wrote: >> Do you prefer wasteful? The current proposal is 4 bytes. >> Why burden everyone with 4 bytes per packet just to support >> this sub-optimal, LWAPP backward compatibility requirement? > > This has nothing to do with LWAPP backward compatibility, in fact you > will note that this is actually changing the format of the header. So > clearly one cannot exactly claim that backward compability is main > Motivation here. That said, perhaps it would be useful if you were to > provide ideas on how you plan to provide real-time monitoring of > signal strength, etc? Or are you claiming that this is not required > and wireless technologies really don't need any different treatment > over a normal wired connection? > I am not saying that this feature should be removed, it should just be optional to implement. Please see my original email on this thread for an explanation of why this phy information is incomplete. Real time monitoring can occur on the WTP with a trigger sent to the AC when some condition is met. This is probably very similar to what is going on in the forward path on your device. An event must be generated to the control processor when something interesting happens. There is no reason that this event can't come from the WTP. The set of triggers can be much richer when run from the WTP since the WTP has much more information available. Thanks, Jim > 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 Apr 10 15:09:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT1kz-0008Ez-4H for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 15:09:01 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT1kx-0007E2-OT for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 15:09:01 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6B62F4300E0 for ; Mon, 10 Apr 2006 12:08:59 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1BFF4430077 for ; Mon, 10 Apr 2006 12:08:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 04C391448012 for ; Mon, 10 Apr 2006 12:08:42 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7CCFD1448018 for ; Mon, 10 Apr 2006 12:08:40 -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 k3AJ8eq5018088 for ; Mon, 10 Apr 2006 12:08:40 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k3AJ8dlO018082 for ; Mon, 10 Apr 2006 12:08:39 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Mon, 10 Apr 2006 12:08:38 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: [Capwap] Reliable transport 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 HI, In the CAPWAP-00 spec, the term "reliable" transport is used in several places. Also, there are timeout intervals and counters that seem to be somewhat confusing to me. I'd appreciate some clarification of these terms and some examples showing a timing diagram using the following: 12.3. NeighborDeadInterval 12.5. EchoInterval 12.7. RetransmitInterval 12.8. ResponseTimeout 13.3. RetransmitCount 13.4. MaxRetransmit Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Apr 10 15:17:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT1tL-0004Ds-Fl for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 15:17:39 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT1tK-0007hY-6e for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 15:17:39 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D4E184300BD for ; Mon, 10 Apr 2006 12:17:37 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 71B7D43009A for ; Mon, 10 Apr 2006 12:17:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5A7C5398028 for ; Mon, 10 Apr 2006 12:17:21 -0700 (PDT) Received: from trpz.com (mail1.trpz.com [66.7.225.38]) by zoidberg.tigertech.net (Postfix) with ESMTP id EC692398023 for ; Mon, 10 Apr 2006 12:17:12 -0700 (PDT) Received: from [127.0.0.1] ([192.168.12.194]) by trpz.com (8.13.5/8.11.6) with ESMTP id k3AJH6bD000677 for ; Mon, 10 Apr 2006 12:17:07 -0700 Message-ID: <443AAF35.7020507@trapezenetworks.com> Date: Mon, 10 Apr 2006 12:17:09 -0700 From: Jim Murphy User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: capwap 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: Subject: [Capwap] RID field in the CAPWAP Transport 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: d6b246023072368de71562c0ab503126 Hi, The RID field in the CAPWAP transport header is only 3 bits but elsewhere in the document the field is 8 bits, for example, section 5.1.3. Does this make any sense? The RID field should be moved to some (to be designed) optional, wireless protocol specific portion of the header. It doesn't make any sense if the data payload is 802.3 frames, for example. 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 capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Apr 10 15:23:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT1yk-0005pf-NF for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 15:23:15 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT1yj-0007vT-Dz for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 15:23:14 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C1BDB4300BD for ; Mon, 10 Apr 2006 12:23:12 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C84B943009A for ; Mon, 10 Apr 2006 12:22:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id ADF831448018 for ; Mon, 10 Apr 2006 12:22:55 -0700 (PDT) Received: from trpz.com (mail1.trpz.com [66.7.225.38]) by hermes.tigertech.net (Postfix) with ESMTP id 2ADEF1448019 for ; Mon, 10 Apr 2006 12:22:53 -0700 (PDT) Received: from [127.0.0.1] ([192.168.12.194]) by trpz.com (8.13.5/8.11.6) with ESMTP id k3AJMlcO000956 for ; Mon, 10 Apr 2006 12:22:48 -0700 Message-ID: <443AB088.70403@trapezenetworks.com> Date: Mon, 10 Apr 2006 12:22:48 -0700 From: Jim Murphy User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: capwap 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: Subject: [Capwap] Length field in CAPWAP Transport 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: 1ac7cc0a4cd376402b85bc1961a86ac2 The length field in the CAPWAP Transport header seems to be redundant with the Length field in the encapsulating UDP header. Am I missing something? If not, I propose that the Length field is removed. 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 capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Apr 10 15:27:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT23E-00070z-Hr for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 15:27:52 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT23D-00085U-3j for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 15:27:52 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BEA614300AA for ; Mon, 10 Apr 2006 12:27:50 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B908043009A for ; Mon, 10 Apr 2006 12:27:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id AE68239802A for ; Mon, 10 Apr 2006 12:27:30 -0700 (PDT) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by zoidberg.tigertech.net (Postfix) with ESMTP id A705E398029 for ; Mon, 10 Apr 2006 12:27:27 -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 k3AJRLlt000642; Mon, 10 Apr 2006 15:27:21 -0400 (EDT) Date: Mon, 10 Apr 2006 15:27:20 -0400 (EDT) From: "T. Charles Clancy" To: Dorothy Stanley Subject: Re: [Capwap] Proposed Resolution to Issue 42 - PMK Sharing In-Reply-To: <5bfe7a820604100954x2756a278gdb8e1928f79948f5@mail.gmail.com> Message-ID: References: <5bfe7a820604100954x2756a278gdb8e1928f79948f5@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: 00e94c813bef7832af255170dca19e36 This was my original point -- CAPWAP doesn't let you share the PMK, so I never understood why this was an issue. [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] On Mon, 10 Apr 2006, Dorothy Stanley wrote: > All, > > Issue 42 - PMK Sharing has the following discussion in the issues data base: > > Issue: > > In the case of an AC managing a same PMK across many WTPs, IEEE 802.11 > stations cannot distinguish between PMKs that are validly shared and those > that have been compromised (I0 of Issues/Recommendations). > > My recommendation: > > Include text in the Security Considerations (draft-ohara-capwap-lwapp-03.txt) > Section 15 along the lines; > > "The CAPWAP protocol may be used in scenarios in which an AC manages a PMK > across many WTPs. In such scenarios, IEEE 802.11 stations moving across WTPs > cannot distinguish between PMKs that are legitimately shared and PMKs that > have been compromised. > The CAPWAP WG recognizes this ambiguity and recommends implementers of the > protocol to review the outcome of IEEE 802.11r efforts for resolution." > > No agreement on this request > > > Perhaps we need further clarification on what "manages a PMK across many > WTPs" means. > If "manages a PMK across many WTPs" means that it delivers the PMK to more > than one WTP, then: > > It is not clear that the CAPWAP specification, current draft does indeed > provide a mechanism to deliver > the PMK to the WTPs, to share the PMK across WTPs. Below are the message > elements that deliver keys: > - The IEEE 802.11 Add WLAN message element (11.8.1.1) - typically delivers > the GTK > - The IEEE 802.11 Mobile Session Key message element (11.7.1.2) delivers a > session key, the PTK > - The IEEE 802.11 Update WLAN message element (11.8.1.3) - typically > delivers the GTK > > CAPWAP does support the ability to securely deliver the GTK and PTK from the > AC to a WTP. > CAPWAP supports a secure control interface, requiring mutual authentication > between the AC and WTPs that are connected to it. > > Recommended resolution: > Reject the comment, with the reason that > "An implementation which delivers PMKs to WTPs is not in compliance with the > CAPWAP protocol" > > and change the text in 11.8.1.1 and 11.8.1.3 describing the key that is > delivered from: > "Key: A 32 byte Session Key to use with the encryption policy" to > "Key: A 32 byte key to use with the encryption key, typically the GTK" > > Comments, discussion please. > > Thanks, > > Dorothy > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Apr 10 16:21:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT2tG-000618-6B for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 16:21:38 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT2tE-0002ig-Cb for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 16:21:38 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 644B54300BD for ; Mon, 10 Apr 2006 13:21:35 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3944D43007C for ; Mon, 10 Apr 2006 13:20:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 23913144800C for ; Mon, 10 Apr 2006 13:20:56 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.192]) by hermes.tigertech.net (Postfix) with ESMTP id 25BD41448002 for ; Mon, 10 Apr 2006 13:20:54 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so673225wxd for ; Mon, 10 Apr 2006 13:20: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:mime-version:content-type; b=hUgTqARLfUgIzMgg6eltBZR3m1Lr/iTf2FtVTNhiapar7hsfHdtdcjDBv/7AaWTvqHmNakrSsnP7I7RWIN+eWhaDX6vuU0b4NzjRpJXBXdykpUVkFxZRaEEI3+Lt+CDn75YO62uqDuiS97mqt75ZUNmLObX70vyDQhn03uk1+LE= Received: by 10.70.42.13 with SMTP id p13mr2315306wxp; Mon, 10 Apr 2006 13:20:53 -0700 (PDT) Received: by 10.70.133.14 with HTTP; Mon, 10 Apr 2006 13:20:53 -0700 (PDT) Message-ID: <5bfe7a820604101320i7df4e81cyf56b518ba3a95d19@mail.gmail.com> Date: Mon, 10 Apr 2006 13:20: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.6 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_60_70, HTML_MESSAGE, RCVD_BY_IP X-Spam-Level: Subject: [Capwap] Proposed Resolution for Issue 46 - WTP Model and Serial number 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="===============0510186178==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 94902b99ee6852833c9a2b680a1de4d3 --===============0510186178== Content-Type: multipart/alternative; boundary="----=_Part_9701_7137833.1144700453440" ------=_Part_9701_7137833.1144700453440 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, Issue 46 - WTP Model and Serial number currently has the following discussion in the issues list: The length of wtpModel in Section 7.2.4 is specified as 8 bytes. I think th= is space could be small for some model types. Same way, 24 bytes WTP Serial Number could be small depending upon how seri= al number is assigned. Section 7.2.4, WTP Board Data The WTP model and serial number value lengths will vary with product and vendor, and are likely to have a wide range of lengths. The current spec fixes the lengths at model number - 8 bytes, and the serial number at 24 bytes. The comment is that these fixed lengths are likely to be too small for some vendors. We could increase the fixed values, with the risk that the values we select will not serve some vendor, or make them excessively long to meet all needs. Another approach is to give the model and serial number a type/length value structure, including a vendor identifier, and allow a variety of lengths. Additional comments on other WTP Board data fields: Need more explicit definition for Card ID and Card Revision values. For some vendors, these are not applicable. If not generally applicable, leave as vendor specific. Indicated these as optional to include, renaming to "board" from "card" to be consistent with the message element name. Can open a new issue for this if needed. . WTP Board Data also includes the Ethernet MAC address. Why is the layer 2 MAC address needed? Recommend removing the Ethernet MAC address field from the WTP Board Data message element (similar to AC MAC address in Issue 39) Recommendation: Change WTP Board Data definition from: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Card ID | Card Revision | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WTP Model | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WTP Model | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WTP Serial Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WTP Serial Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | WTP Serial Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WTP Serial Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WTP Serial Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WTP Serial Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Ethernet MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet MAC Address| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++++ Type: 50 for WTP Board Data Length: 26 Card ID: A 2 byte hardware identifier. Card Revision: A 2 byte Revision of the card. WTP Model: 8 byte WTP Model Number. WTP Serial Number: 24 byte WTP Serial Number. Ethernet MAC Address: MAC Address of the WTP's Ethernet interface. to 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Vendor Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=3D0 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Value..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type=3D1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value.... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ | Optional additional vendor specific WTP board data TLVs Type: 50 for WTP Board Data Length: >=3D 3 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI Network Management Private Enterprise Codes" Type: The following values are supported 0 - WTP Model Number; The WTP Model Number MUST be included in the WTP Boar= d 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 Boar= d Data message element. 3 - Board Revision, A revision number of the board, which MAY be included i= n the WTP Board Data message element. Length: The length of the value field Value: The value of the indicated field. The Vendor Identifier, WTP Model Number and WTP Serial Number are optionall= y followed by additional vendor specific values. Comments please. Thanks, Dorothy ------=_Part_9701_7137833.1144700453440 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All,

Issue 46 - WTP Model and Serial number currently has the following discussi= on in the issues list:

The length of wtpModel in Section 7.2.4 is specified as 8 bytes. I thi=
nk this 
space could be small for some model types. 

Same way, 24=
 bytes WTP Serial Number could be small depending upon how serial 


number is assigned.

Section 7.2.4, WTP Board Data

The WTP model and serial number value lengths will vary with product and ve= ndor, and are likely
to have a wide range of lengths. The current spec fixes the lengths at
model number - 8 bytes, and the serial number at 24 bytes. The comment is t= hat these fixed lengths
are likely to be too small for some vendors.

We could increase the fixed values, with the risk that the values we select= will not serve some vendor, or make
them excessively long to meet all needs.
Another approach is to give the model and serial number a type/length value= structure, including a vendor identifier, and
allow a variety of lengths.

Additional comments on other WTP Board data fields:
Need more explicit definition for  Card ID and Card Revision values. For some vendors, these are not applicable. If not generally applicable, leave as vendor specific. Indicated these as o= ptional to include, renaming to "board" from "card"
to be consistent with the message element name. Can open a new issue for th= is if needed.
.
WTP Board Data also includes the Ethernet MAC address. Why is the layer 2 M= AC address needed? Recommend
removing the Ethernet MAC address field from the WTP Board Data message ele= ment (similar to AC MAC address
in Issue 39)

Recommendation: Change WTP Board Data definition from:

0            &n= bsp;            = ;  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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|       &= nbsp;           &nbs= p;   Card ID         |           Card Revision           &= nbsp;          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |            &n= bsp;            = ;            WTP Model                                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |            &n= bsp;            = ;            WTP Model                                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            &n= bsp;            = ;    WTP Serial Number           &nb= sp;            =             &nb= sp;  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |            &n= bsp;            = ;    WTP Serial Number           &nb= sp;            =             &nb= sp;  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| =
|            &n= bsp;            = ;    WTP Serial Number           &nb= sp;            =             &nb= sp;  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            &n= bsp;            = ;    WTP Serial Number           &nb= sp;            =             &nb= sp;  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |            &n= bsp;            = ;    WTP Serial Number           &nb= sp;            =             &nb= sp;  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            &n= bsp;            = ;    WTP Serial Number           &nb= sp;            =             &nb= sp;  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|            &n= bsp;          Ethernet MAC Address              &nb= sp;            =             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |            &n= bsp;           Ethernet MAC Address|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++++

Type: 50 for WTP Board Data
 Length: 26
Card ID: A 2 byte hardware identifier.
Card Revision: A 2 byte Revision of the card.
WTP Model: 8 byte WTP Model Number.
WTP Serial Number: 24 byte WTP Serial Number.
Ethernet MAC Address: MAC Address of the WTP's Ethernet interface.

to

0            &n= bsp;            = ;  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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|            &n= bsp;            = ;       Vendor Identifier                                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            &n= bsp;     Type=3D0              |            Length           &nb= sp;            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|            &n= bsp;            = ;         Value.....                                                         
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|            &n= bsp;     Type=3D1              |            Length           &nb= sp;             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       &= nbsp;           &nbs= p;            &= nbsp; Value....                                                     
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Optional additional vendor specific WTP board data TLVs


Type: 50 for WTP Board Data
Length: >=3D 3
Vendor Identifier: A 32-bit value containing the IANA assigned "SMI Ne= twork Management Private Enterprise Codes"
Type: The following values are supported
0 - WTP Model Number; The WTP Model Number MUST be included in the WTP Boar= d Data message element.
1 - WTP Serial Number; The WTP Serial Number MUST be included in the WTP Bo= ard Data message element.
2 - Board ID; A  hardware identifier, which MAY be included in the WTP= Board Data message element.
3 - Board Revision, A revision number of the board, which MAY be included= in the WTP Board Data message element.

Length: The length of the value field

Value: The value of the indicated field.

The Vendor Identifier, WTP Model Number and WTP Serial Number are optionall= y followed by additional
vendor specific values.

Comments please.

Thanks,

Dorothy
------=_Part_9701_7137833.1144700453440-- --===============0510186178== 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 --===============0510186178==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Apr 10 17:04:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT3YR-0006fK-VK for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 17:04:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT3YQ-0004A2-B5 for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 17:04:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B654E4300CC for ; Mon, 10 Apr 2006 14:04:09 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B024643007C for ; Mon, 10 Apr 2006 14:03:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7C68F1448013 for ; Mon, 10 Apr 2006 14:03:44 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.196]) by hermes.tigertech.net (Postfix) with ESMTP id 9572A1448011 for ; Mon, 10 Apr 2006 14:03:41 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so679095wxd for ; Mon, 10 Apr 2006 14:03:41 -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=jxTJKlP4oVsAbzg9fevzZdFIJMcCOITwSETV+XR5FyOxJS14pWhtXEk6OoFyyjvalghBLj6QkZN0BgVWdrO4uDLxIguHIpfdxkxbg6k9ZXj3JUoM3zkJLooYSAzkxcAxJDc+1/dHlyzcJm4D6V1h8X1TlxBclkGqoSgTbKAPPnE= Received: by 10.70.22.15 with SMTP id 15mr1511914wxv; Mon, 10 Apr 2006 14:03:40 -0700 (PDT) Received: by 10.70.133.14 with HTTP; Mon, 10 Apr 2006 14:03:40 -0700 (PDT) Message-ID: <5bfe7a820604101403r64e6a10dyef8036987d88a81a@mail.gmail.com> Date: Mon, 10 Apr 2006 14:03:40 -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 X-Spam-Level: Subject: [Capwap] Proposed resolution of 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: , Content-Type: multipart/mixed; boundary="===============0967731193==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.7 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d --===============0967731193== Content-Type: multipart/alternative; boundary="----=_Part_10407_26244308.1144703020971" ------=_Part_10407_26244308.1144703020971 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, Issue 50 - Increase maximum number of BSSs currently has the following discussion in the issues list: > 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? Section 5.1.3 is the WTP Radio Information message element. WTP Radio Information is included in the discovery request message. The message element currently includes a - Radio ID, indicating an interface index - Radio type - a bitfield indicating the type of radio present. 5 values, out of 16 are currently used, and indicate the general radio type and then subtype together in one field - 802.11 a,b,g,n, all of previous values. In the future say if 802.16comes along, will have more radio types. Looks like the current length is extensible to only one more "type" of radio. Suggest increasing the length of this field, or go to a type ( 802.11, 802.16, etc), and subtype (a/b/g/etc) structure. The comment asks for the number of BSSIDs supported at the WTP to be added to information provided by the WTP to the AC. The comment also asks the question of a maximum. Currently the max is 16. Changing this maximum is a separate question from having the WTP indicate the value. - Could add the Number of BSSIDs to the WTP radio information element. The radio information element is a CAPWAP level message element though. Are BSSIDs likely to apply to multiple radio types - .11/.16 etc? The Num of BSSIDs is included in the IEEE 802..11 WTP WLAN Radio Configuration message element, see 11.9.1. While the text in 11.9.1 refers only to the message element being used by the AC to configure a radio on the WTP, the list in 11.9 shows this message element being included in the Configuration Request message, indicating that it can be sent from the WTP to the AC, presumably for the WTP to report its current capabilities. Proposed Resolution: Modify the text in 11.9.1 to indicate that the WTP Radio Configuration element is also used by the WTP to report its capabilities to the AC in the Configuration Request (proposed to be renamed to Configuration Status message - issue 58) Also, propose to increase the length of the radio type field in 5.1.3 from = 2 to 4 bytes, and change value of "all" from "0cFFFF" to "ox0F" - since "all" means the previous ones indicated, not all potential future values. Will add this in a new issue. Comments? Thanks, Dorothy ------=_Part_10407_26244308.1144703020971 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All,

Issue 50 - Increase maximum number of BSSs currently has the following disc= ussion in the issues list:

> 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 assu=
me that every 
> WTP supports 16 radios and add a field to indicate t=
he 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?

Section 5.1.3 is the WTP Radio Information message element. WTP Radio Infor= mation
is included in the discovery request message.

The message element currently includes a
- Radio ID, indicating an interface index
- Radio type - a bitfield indicating the type of radio present. 5 values, o= ut of 16 are
currently used, and indicate the general radio type and then subtype togeth= er in one
field - 802.11 a,b,g,n, all of previous values. In the future say if 802.16= comes along, will
have more radio types. Looks like the current length is extensible to only = one more "type"
of radio. Suggest increasing the length of this field, or go to a type (802= .11, 802.16, etc), and
subtype (a/b/g/etc) structure.

The comment asks for the number of BSSIDs supported at the WTP to be added = to information provided
by the WTP to the AC. The comment also asks the question of a maximum. Curr= ently the max is 16. Changing
this maximum is a separate question from having the WTP indicate the value.=

- Could add the Number of BSSIDs to the WTP radio information element. The = radio information element is
a CAPWAP level message element though. Are BSSIDs likely to apply to multip= le radio types - .11/.16 etc?
The Num of BSSIDs is included in the IEEE 802..11 WTP WLAN Radio Configurat= ion message element, see 11.9.1.

While the text in 11.9.1 refers only to the message element being used by t= he AC to configure a radio on the WTP, the
list in 11.9 shows this message element being included in the Configuration= Request message, indicating that it can be
sent from the WTP to the AC, presumably for the WTP to report its current c= apabilities.

Proposed Resolution:

Modify the text in 11.9.1 to indicate that the WTP Radio Configuration elem= ent is also used by the WTP to
report its capabilities to the AC in the Configuration Request (proposed to be renamed to Configuration Status message - issue 58)

Also, propose to increase the length of the radio type field in 5.1.3 from = 2 to 4 bytes, and change value of
"all" from "0cFFFF" to "ox0F" - since "a= ll" means the previous ones indicated, not all potential future values= .
Will add this in a new issue.

Comments?

Thanks,

Dorothy
------=_Part_10407_26244308.1144703020971-- --===============0967731193== 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 --===============0967731193==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Apr 10 22:28:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT8cK-00030G-91 for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 22:28:32 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT8cI-00022J-01 for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 22:28:32 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id EA9EB4300CF for ; Mon, 10 Apr 2006 19:28:28 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 5F877430067 for ; Mon, 10 Apr 2006 19:27:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 456921448011 for ; Mon, 10 Apr 2006 19:27:50 -0700 (PDT) Received: from webmail.rp.edu.sg (webmail.rp.sg [202.21.158.83]) by hermes.tigertech.net (Postfix) with ESMTP id 51CE51448002 for ; Mon, 10 Apr 2006 19:27:46 -0700 (PDT) Received: from staff-mail.rp.edu.sg ([202.21.158.80]) by webmail.rp.edu.sg with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 10:27:44 +0800 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Importance: normal Priority: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages Date: Tue, 11 Apr 2006 10:27:41 +0800 Message-ID: <9C374CF75527504394E573E1937136C402C450A1@staff-mail.rp.edu.sg> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages thread-index: AcZcwxCxoB87V8dGR/mneAVUhr7KsAASpG1Q From: "Richard Gwee" To: "Dorothy Stanley" , "capwap" X-OriginalArrivalTime: 11 Apr 2006 02:27:44.0456 (UTC) FILETIME=[83D8E480:01C65D0F] X-Virus-Scanned: by amavisd-new-20030616-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=FORGED_RCVD_HELO, HTML_50_60, HTML_MESSAGE, HTML_TAG_EXIST_TBODY, HTML_TEXT_AFTER_BODY, NORMAL_HTTP_TO_IP 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="===============1355495195==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 17589c7043b24a47064a4b7516f59671 This is a multi-part message in MIME format. --===============1355495195== Content-Transfer-Encoding: 7bit Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65D0F.82C559AE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65D0F.82C559AE X-EC0D2A8E-5CB7-4969-9C36-46D859D137BE-PartID: 969AB787-A5C2-480F-A954-FD57AC4DCA39 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Dorothy, =20 I believe that I have mentioned this point during my presentation in the last IETF meeting. While combining messages does reduce overhead significantly (as shown in my powerpoint presentation slides), we should also look at another benefit of combining the keepalive and statistics messages. As I have highlighted before, there is no statistics for the whole WLAN in the CAPWAP protocol. We need to include this in and I feel that putting this statistics element in the Echo Request message is the best bet. While I understand your concern for keeping the echo messages simple, I cannot visualize how much more complicated it can be if we just combine statistics for our keepalive mechanism. =20 Appreciate any comments. =20 Thanks & Regards Richard Gwee =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Tuesday, April 11, 2006 1:20 AM To: capwap Subject: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages =20 All, 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.=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. Recommended resolution: reject the comment, with the explanation in the above paragraph Comments please. Thanks, Dorothy Republic Polytechnic, 9 Woodlands Avenue 9, Singapore 738964 (Near = Woodlands MRT/Interchange) . www.rp.sg . Fax: +65 6415-1310 .=20 Republic Polytechnic, the first Institute of Higher Learning to fully = adopt the Problem-Based Learning approach in Singapore, continues to = strive towards best practices and maintain excellence in service = standards with the following certifications: Singapore Innovation Class = (SIC), Singapore Quality Class (SQC), People Developer Standards and = QEHS (ISO 9001, 14001 and OHSAS 18001) -------------------------------------------------------------------------= ------- CONFIDENTIALITY CAUTION: This message is intended only for the use of = the individual or entity to whom it is addressed and contains = information that is privileged and confidential. If you, the reader of = this message, are not the intended recipient, you should not = disseminate, distribute or copy this communication. If you have received = this communication in error, please notify us immediately by return = email and delete the original message. Thank you. =20 ------_=_NextPart_001_01C65D0F.82C559AE X-EC0D2A8E-5CB7-4969-9C36-46D859D137BE-PartID: CB297565-532A-433A-8FA3-3D52B658C779 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Dorothy,

 

I believe that I have mentioned = this point during my presentation in the last IETF meeting. While combining = messages does reduce overhead significantly (as shown in my powerpoint presentation = slides), we should also look at another benefit of combining the keepalive and = statistics messages. As I have highlighted before, there is no statistics for the = whole WLAN in the CAPWAP protocol. We need to include this in and I feel that = putting this statistics element in the Echo Request message is the best bet. = While I understand your concern for keeping the echo messages simple, I cannot visualize = how much more complicated it can be if we just combine statistics for our = keepalive mechanism.

 

Appreciate any = comments.

 

Thanks & = Regards

Richard Gwee

 

From: Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Tuesday, April 11, = 2006 1:20 AM
To: capwap
Subject: [Capwap] = Proposed Resolution to Issue 45 - Issue on combiningmessages

 

All,

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

Comments please.

Thanks,

Dorothy

Republic Polytechnic, 9 Woodlands = Avenue 9, Singapore 738964 (Near = Woodlands MRT/Interchange)
. www.rp.sg . Fax: +65 6415-1310 .

Republic Polytechnic, = the first Institute of Higher Learning to fully adopt the Problem-Based = Learning approach in Singapore, continues to strive towards best = practices and maintain excellence in service standards with the = following certifications: Singapore Innovation Class (SIC), Singapore = Quality Class (SQC), People Developer Standards and QEHS (ISO 9001, = 14001 and OHSAS 18001)

CONFIDENTIALITY CAUTION: = This message is intended only for the use of the individual or entity to = whom it is addressed and contains information that is privileged and = confidential. If you, the reader of this message, are not the intended = recipient, you should not disseminate, distribute or copy this = communication. If you have received this communication in error, please = notify us immediately by return email and delete the original message. = Thank you.
------_=_NextPart_001_01C65D0F.82C559AE-- --===============1355495195== 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 --===============1355495195==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Apr 10 23:25:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT9VI-0005uP-7K for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 23:25:20 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT9VF-0004K1-C9 for capwap-archive@lists.ietf.org; Mon, 10 Apr 2006 23:25:20 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BD3B44300B7 for ; Mon, 10 Apr 2006 20:25:16 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3B816430067 for ; Mon, 10 Apr 2006 20:24:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1F859398026 for ; Mon, 10 Apr 2006 20:24:46 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id C61CE398028 for ; Mon, 10 Apr 2006 20:24:44 -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 k3B3OfBU017536; Tue, 11 Apr 2006 12:24:41 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k3B3Oh506330; Tue, 11 Apr 2006 12:24:43 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with SMTP id k3B3Ohc07400; Tue, 11 Apr 2006 12:24:43 +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] Proposed Text for Issue 53 Date: Tue, 11 Apr 2006 11:23:01 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDCDBC63@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Text for Issue 53 Thread-Index: AcZXmiGYKUrUeU/XT1OcZaCvsWKBVgAnw06wAAH/5gAAHicW0AAV2e5gAAQCVeAAAewBIAAdCSWAABDYbCAACDF+oADE7Pig From: "Saravanan Govindan" To: "Abhijit Choudhury" , "Bob O'Hara (boohara)" , "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: 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: a5d64674af3d12893846a18a44c07b83 Hi Abhijit, I understand your suggestion below.=20 However, following from the point Jim made earlier, per-data-packet statistics only applies to split-MAC WTP. It does not apply to local-MAC WTPs where not all data packets reach the AC.=20 Aggregated statistics, on the other hand, can be used for both split-MAC and local-MAC WTPs. Since this covers both types of WTPs that CAPWAP will be used for, I think we should use this as the default.=20 My suggestion is to have the Echo Request carry aggregated statistics as default and have the RSSI/SNR header fields as optional.=20 Cheers, Saravanan -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com]=20 Sent: Friday, April 07, 2006 1:18 PM To: Saravanan Govindan; Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Bob, Saravanan: Here's what I'd suggest. Since the current CAPWAP spec already supports carrying RSSI/SNR in the base CAPWAP header (in the 6 bytes), we can make=20 transmission of per-packet measurement the default mode,=20 and the exchange of aggregated information from the WTP=20 an "optional to implement" mode. =20 However, we will use an extension of the=20 base CAPWAP header, say with the D bit as explained=20 in my earlier email, to extend the CAPWAP header by=20 2 more bytes to carry additional per-packet=20 info like the data rate. This way vendors who want to use per-packet information can do so, without burdening others who decide to implement the option of the WTP sending aggregated=20 information. I think this is a reasonable compromise that satisfactorily resolves Issue 53, while allowing for flexibility. Comments ? Thanks, Abhijit -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Thursday, April 06, 2006 6:14 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Bob, I understand from your note that per data packet measurement is the basis for real time AC processing. My support for aggregated measurement exchange is based on efficiency considerations. Having said this, I do not want to exclude one or the other - the exchanges so far show both make for valuable additions to CAPWAP. I think we can move forward now maintaining / incorporating both types of exchanges in to the CAPWAP specs. Saravanan -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Friday, April 07, 2006 1:15 AM To: Saravanan Govindan; capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Saranavan, As I said in another email earlier in the thread than the one to which you responded, I do not have an objection to adding the reporting of aggregated information in a status report or other message. I do not want to lose the ability to deal with or have access to the real time information in the AC, on a packet by packet basis. Why do you object to enabling a function such as real time processing of the packet RSSI and SNR? -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, April 05, 2006 8:41 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Bob, Without going in to pseudo-judicial rhetoric, I think we need to look at what is needed for the CAPWAP protocol.=20 >From the exchanges so far, we see that measurement information can be exchanged on a per data packet basis or on an aggregated basis. We have seen the advantages of exchanging then on aggregated basis. In the spirit of quick resolution, I suggest we select one as the default mode for CAPWAP and have the other as an additional feature. I believe this was suggested earlier also.=20 Saravanan -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Thursday, April 06, 2006 10:26 AM To: Saravanan Govindan; capwap Subject: RE: [Capwap] Proposed Text for Issue 53 So, your preference is to remove functionality that is already in a product available today, by eliminating this capability from the protocol. Given Moore's law advancement of processing capability, this seems a bit short sighted.=20 -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, April 05, 2006 5:33 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Bob, I will accept that there is an AC implementation for per data packet processing.=20 I still prefer that the CAPWAP protocol aggregate measurement information for periodic exchange.=20 Saravanan =20 -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Wednesday, April 05, 2006 10:15 PM To: capwap Subject: RE: [Capwap] Proposed Text for Issue 53 For those AC implementations that want to use per packet data for certain operations, aggregation of the data at the WTP as suggested by Abhijit will preclude this. The assertion by Saravanan that an AC does not process this information is incorrect. I can point to at least one existing implementation that already does process this information on a per packet basis. The current text, with the change I suggested, is the right way to handle this. If we want to ADD a capability that the WTP can provide aggregation, I have no objection to that. -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Tuesday, April 04, 2006 4:49 PM To: Abhijit Choudhury; Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Hi Abhijit, I am in support of your suggestion. It is true that the AC does not process all data packets. Furthermore, I think for greater control, the AC will need information about the congestion level in the WLAN. This could be a derivative of interference and load factor.=20 As for your suggestion, I think measurement/parameter information from the WTP should be sent over the periodic Echo Request messages. The advantage is that header overhead is reduced.=20 I can prepare text for this approach. Cheers, Saravanan =20 -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com]=20 Sent: Wednesday, April 05, 2006 6:52 AM To: Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Here's another approach... RSSI, SNR, and Data Rate are measurements/parameters of the radio channel that are being reported to the=20 AC for finer control. Carrying them in every data packet on the data channel means some logic or hardware in the AC will have to parse them out of every data packet and send them to the control path (CPU). Typically not every packet will go to the CPU and so this data will=20 have to be stored and periodically sent to or read=20 by the CPU. Note that the AC will be possibly dealing=20 with tens to hundreds of WTPs and hence a=20 potentially large number of STAs. This implies a=20 large amount of per-STA measurement data has to be stored and moved from the data path to the CPU. A more reasonable approach is to let the WTP=20 aggregate such data and periodically send it in the=20 control channel to the AC. Note the WTP has to deal with much much fewer clients - so the storage burden is less. All we'd need is a frame that carries this information to the AC at a specified=20 interval of time. This period could be configurable. Using this approach, we don't need to increase the CAPWAP header every time we need new measurement info. We can retain the current CAPWAP header and flexibly add any measurement information we need by adding it in the control channel. This is particularly important as we move forward to support 802.11n or other=20 non-802.11 technlogies. It decouples the CAPWAP header from the measurement data related information. Any thoughts on this ? Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Monday, April 03, 2006 8:45 PM To: capwap Subject: [Capwap] Proposed Text for Issue 53 Here is my proposed text for Issue 53, which is the addition of a Data Rate In the CAPWAP header. Please let me know if you have any comments. =20 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | <=3D=3D=3D CHANGED!!! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ [...] 4.1.8. Reserved This 32 bit field is reserved and may be used by a binding specific extension. Refer to the transport portion of the binding for a specific wireless technology for the definition of this field. [...] 11.3.2. CAPWAP Header Reserved field 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 5.5Mbps would be set to 55, while 11Mbps would be set to 110. 11.3.2.2. Destination WLANs The Destination WLAN field is used to specify the target WLANs for a given frame, and is only used with broadcast and multicast frames. This field allows the AC to transmit a single broadcast or multicast frame to the WTP, and allows the WTP to perform the necessary frame replication services. The field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WLAN: This bit field indicates the WLAN ID (see section Section 11.8.1.1) which the WTP will transmit the associated frame on. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be enabled. Note this field is to be set to zero for unicast packets and is unused if the WTP is not providing encryption services. Reserved: This field MUST be set to zero. =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 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 Tue Apr 11 01:25:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTBNc-0002Zf-2Q for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 01:25:32 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTBNY-0008B0-9h for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 01:25:32 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 60EB64300CB for ; Mon, 10 Apr 2006 22:25:27 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 853BA430067 for ; Mon, 10 Apr 2006 22:24:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 63007398028 for ; Mon, 10 Apr 2006 22:24:53 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id CF08039800C for ; Mon, 10 Apr 2006 22:24:50 -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 k3B5Omxx022530; Tue, 11 Apr 2006 14:24:48 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k3B5Omk08837; Tue, 11 Apr 2006 14:24:48 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with SMTP id k3B5OlL27394; Tue, 11 Apr 2006 14:24:47 +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 - Issue on combiningmessages Date: Tue, 11 Apr 2006 13:23:12 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDCDBCB0@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages Thread-Index: AcZcwt7IXq4uGplPQPe6kjVV4ScCXwAZFAZQ From: "Saravanan Govindan" To: "Dorothy Stanley" , "capwap" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.532 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_60_70, HTML_MESSAGE, NORMAL_HTTP_TO_IP 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="===============0796777892==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 58b614506802734014829a093beb6879 This is a multi-part message in MIME format. --===============0796777892== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65D28.08DAEABE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65D28.08DAEABE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dorothy, =20 I think this recommendation add substantial value to the CAPWAP protocol. There have been discussions on the need for aggregating statistics information from the WTP to AC. The Echo Request offers a way for achieving this. The mechanisms for statistics exchanges - timer, periodic exchange - are available with Echo Request. So I think it is of value to keep Echo Request and add statistics information fields to it.=20 =20 Cheers, =20 Saravanan =20 =20 =20 _____ =20 From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Tuesday, April 11, 2006 1:20 AM To: capwap Subject: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages =20 All, 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.=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. Recommended resolution: reject the comment, with the explanation in the above paragraph Comments please. Thanks, Dorothy ------_=_NextPart_001_01C65D28.08DAEABE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dorothy,

 

I think this recommendation add substantial value to = the CAPWAP protocol. There have been discussions on the need for aggregating statistics information from the WTP to AC. The Echo Request offers a way = for achieving this. The mechanisms for statistics exchanges – timer, = periodic exchange – are available with Echo Request. So I think it is of = value to keep Echo Request and add statistics information fields to it. =

 

Cheers,

 

Saravanan

 

 

 

From: = Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Tuesday, April 11, = 2006 1:20 AM
To: capwap
Subject: [Capwap] = Proposed Resolution to Issue 45 - Issue on = combiningmessages

 

All,

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

Comments please.

Thanks,

Dorothy

------_=_NextPart_001_01C65D28.08DAEABE-- --===============0796777892== 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 --===============0796777892==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Apr 11 07:32:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTH6u-0005TZ-Vs for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 07:32:40 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTH6s-0005ak-TQ for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 07:32:40 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C885843008C for ; Tue, 11 Apr 2006 04:32:37 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 95F4D430073 for ; Tue, 11 Apr 2006 04:31:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 84D23398026 for ; Tue, 11 Apr 2006 04:31:48 -0700 (PDT) Received: from huawei.com (szxga01-in.huawei.com [61.144.161.53]) by zoidberg.tigertech.net (Postfix) with ESMTP id 163F939801D for ; Tue, 11 Apr 2006 04:31:45 -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 <0IXK00KAM2OWV4@szxga01-in.huawei.com> for capwap@frascone.com; Tue, 11 Apr 2006 19:31:45 +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 <0IXK005VF2OVEX@szxga01-in.huawei.com> for capwap@frascone.com; Tue, 11 Apr 2006 19:31:44 +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 <0IXK003ON3HYHJ@szxml01-in.huawei.com>; Tue, 11 Apr 2006 19:49:11 +0800 (CST) Date: Tue, 11 Apr 2006 17:01:41 +0530 From: sujay In-reply-to: <5F09D220B62F79418461A978CA0921BDC7714A@pslexc01.psl.local> To: 'Saravanan Govindan' , capwap@frascone.com, "'Pat Calhoun (pacalhou)'" Message-id: <004801c65d5b$81960ee0$7107120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.001 tagged_above=-999 required=7 tests=HTML_MESSAGE X-Spam-Level: Cc: Subject: [Capwap] RE: WTP Mac Type negotiation. 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="===============1333713188==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7466aa14f8cee8a5830833f08db79654 This is a multi-part message in MIME format. --===============1333713188== Content-type: multipart/alternative; boundary="Boundary_(ID_oujacSFHz6ndKIwkJd0L2A)" This is a multi-part message in MIME format. --Boundary_(ID_oujacSFHz6ndKIwkJd0L2A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Saravanan, I suggest not to limit the AC's mode of operation, by classifying modes of operation viz Control - bias and Load-bias mode. Keeping it simple; 5.2.6. Operating Mode The Operating Mode message element specifies the mode of operation for a WTP capable of operating in both Local-MAC and Split-MAC modes. 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Operating Mode | +-+-+-+-+-+-+-+-+ Type: TBD Length: 1 Operating Mode: The selected mode for WTP operation < 0: Control-bias mode, WTP operates in Split-MAC mode 1: Load-bias mode, WTP operates in Local-MAC mode /> change to; < 0: Split-MAC mode, WTP operates in Split-MAC mode 1: Local-MAC mode, WTP operates in Local-MAC mode /> Any suggestions? Sujay -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Friday, March 31, 2006 8:14 AM To: sujay; capwap@frascone.com Subject: RE: WTP Mac Type negotiation. Dear All, Following from Sujay G's suggestion, this is text for mode selection in the case where a WTP supports both split-MAC and local-MAC modes and can also support the different tunnel options. Cheers, Saravanan ----oooo---- Introduce how operational mode is selected in Section 2 (Protocol Overview) [Paragraph 3, after 2nd sentence] "The WTPs specify their operational modes in their Discovery Request message, to which the responding AC selects particular operational modes and specifies them in the Discovery Response message." Then in Section 5.2 (Discovery Response) [After Paragraph 2, include following paragraph] " In the case where a requesting WTP is capable of both Local-MAC and Split-MAC operations (MAC Type [Section 5.1.4] value "2") or where a WTP is capable of all types of bridging (Frame Type [Section 5.1.5] value "7"), AC determines the particular operating mode based on the following; i. Control-bias Mode In this mode, the AC has greater control of WTP operations. So the AC instructs the requesting WTP to operate in Split-MAC mode. ii. Load-bias Mode In this mode, the AC reduces processing load of WTP operations. So the AC instructs the requesting WTP to operate in Local-MAC mode. " Introduce Operation Mode message element as Section 5.2.6 (Operating Mode). 5.2.6. Operating Mode The Operating Mode message element specifies the mode of operation for a WTP capable of operating in both Local-MAC and Split-MAC modes. 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Operating Mode | +-+-+-+-+-+-+-+-+ Type: TBD Length: 1 Operating Mode: The selected mode for WTP operation 0: Control-bias mode, WTP operates in Split-MAC mode 1: Load-bias mode, WTP operates in Local-MAC mode ----XXXX---- -----Original Message----- From: sujay [mailto:sujayg@huawei.com] Sent: Friday, March 17, 2006 2:32 PM To: capwap@frascone.com Cc: Saravanan Govindan Subject: WTP Mac Type negotiation. Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal The CAPWAP does not specify as to how the selection is made if the WTP Can support both Modes Split and Local and Frame (Tunnel ) type. The WTP specifies MAC Type and Frame Type in Discovery Request message, but if it supports both modes , there is no provision for the AC to select the working mode. Recommendation : 1. Add the WTP mode and WTP tunnel type messages in the configure response ? Which makes it binding agnostic. 2. The logic for choosing WTP mode type on the AC could depend on the load, and user policy. Solicit comments. Regds, Sujay --Boundary_(ID_oujacSFHz6ndKIwkJd0L2A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable Message
Saravanan,
I suggest not to = limit the AC's=20 mode of operation,
by classifying = modes of=20 operation viz Control - bias
and Load-bias=20 mode.
 
Keeping it=20 simple;
 

5.2.6.  =20 Operating Mode

 

   = The=20 Operating Mode message element specifies the mode of operation for a WTP = capable=20 of  

   = operating in=20 both Local-MAC and Split-MAC modes.

 

      =
0
      0 1 2 3 4 5 6 =
7
     =
+-+-+-+-+-+-+-+-+
     |Operating Mode =
|
     =
+-+-+-+-+-+-+-+-+
 
   Type:  =
TBD
 
   Length:  =
1
 
   Operating Mode:  The selected mode for WTP =
operation
 
<
        0: Control-bias =
mode, WTP operates in Split-MAC mode
 =

        1: Load-bias =
mode, WTP operates in Local-MAC mode 
/>
change to;
<
        0: Split-MAC mode, =
WTP operates in Split-MAC mode
 =

        1: Local-MAC =
mode, WTP operates in Local-MAC mode 
/>
 
Any =
suggestions?
Sujay
 
 
-----Original Message-----
From: = Saravanan=20 Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: = Friday,=20 March 31, 2006 8:14 AM
To: sujay;=20 capwap@frascone.com
Subject: RE: WTP Mac Type=20 negotiation.

Dear=20 All,

 

Following = from Sujay=20 G's suggestion, this is text for mode selection in the case where a = WTP=20 supports both split-MAC and local-MAC modes and can also support the = different=20 tunnel options.

 

Cheers,

Saravanan

 

 

 

 

----oooo----

<NOTE>=20

Introduce how = operational mode is selected in Section 2 (Protocol Overview) = [Paragraph 3,=20 after 2nd sentence]

<END=20 NOTE>

 

"The WTPs = specify their=20 operational modes in their Discovery Request message, to which the = responding=20 AC selects particular operational modes and specifies them in the = Discovery=20 Response message."

 

 

<NOTE>=20

Then in = Section 5.2=20 (Discovery Response) [After Paragraph 2, include following=20 paragraph]

<END=20 NOTE>

 

 

" In the case = where a=20 requesting WTP is capable of both Local-MAC and Split-MAC operations = (MAC Type=20 [Section 5.1.4] value "2") or where a WTP is capable of all types of = bridging=20 (Frame Type [Section 5.1.5] value "7"), AC determines the particular = operating=20 mode based on the following;

 

i. = Control-bias=20 Mode

 

In this mode, = the AC=20 has greater control of WTP operations. So the AC instructs the = requesting WTP=20 to operate in Split-MAC mode.

 

ii. Load-bias = Mode

 

In this mode, = the AC=20 reduces processing load of WTP operations. So the AC instructs the = requesting=20 WTP to operate in Local-MAC mode. "

 

 

<NOTE>

Introduce = Operation=20 Mode message element as Section 5.2.6 (Operating=20 Mode).

<END=20 NOTE>

 

 

5.2.6.  =20 Operating Mode

 

   = The=20 Operating Mode message element specifies the mode of operation for a = WTP=20 capable of  

   = operating=20 in both Local-MAC and Split-MAC modes.

 

      =
0
      0 1 2 3 4 5 6 =
7
     =
+-+-+-+-+-+-+-+-+
     |Operating Mode =
|
     =
+-+-+-+-+-+-+-+-+
 
   Type:  =
TBD
 
   Length:  =
1
 
   Operating Mode:  The selected mode for WTP =
operation
 
        0: Control-bias =
mode, WTP operates in Split-MAC =
mode
 =

        1: Load-bias =
mode, WTP operates in Local-MAC mode

 

----XXXX----

 

 

 

 

 

 

 

 

 

-----Original Message-----
From: sujay=20 [mailto:sujayg@huawei.com]
Sent: Friday, March 17, 2006 2:32 = PM
To:=20 capwap@frascone.com
Cc: Saravanan Govindan
Subject: WTP Mac Type = negotiation.

 

Importance: Normal

X-Priority: 3 (Normal)

X-MSMail-priority: Normal

 

 

The CAPWAP does not specify as to how the = selection is=20 made if the WTP

Can support both Modes Split and Local and = Frame=20 (Tunnel ) type.

 

The WTP specifies MAC Type and Frame = Type  in=20 Discovery Request message,

but if it supports =

both modes , there is no provision for the = AC to=20 select the working

mode.

 

 

Recommendation = :

1. Add the WTP mode and WTP tunnel type = messages =20 in the

configure response ? Which  makes it = binding=20

agnostic.

 

2. The logic for choosing WTP mode type on = the AC=20 could depend on the

load, and user = policy.

 

Solicit = comments.

 

Regds,

Sujay

 

 

--Boundary_(ID_oujacSFHz6ndKIwkJd0L2A)-- --===============1333713188== 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 --===============1333713188==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Apr 11 10:51:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKCt-0005Qx-Aa for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 10:51:03 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTKCq-0004UE-Hb for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 10:51:03 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7554A4300C9 for ; Tue, 11 Apr 2006 07:50:59 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2DAFF430073 for ; Tue, 11 Apr 2006 07:50:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0E800430D61 for ; Tue, 11 Apr 2006 07:50:25 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.200]) by hermes.tigertech.net (Postfix) with ESMTP id AA52C1448002 for ; Tue, 11 Apr 2006 07:50:23 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so806268wxd for ; Tue, 11 Apr 2006 07:50: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=pDLKDW/oOcq1paPGgb4Mbsr4SOX2Fx/aImU/i7WFPuhmxczJAPxlIdGr4EAn9B9xwlGDAetjWfuGrJnzpxxEX/SwUJTjFmo/QdEOP2E3nV773l4FhQ+fEoqagr0lkBhn2I/5HDermSTCm51xdKYdNzxNaklEeilBRNBk51ZZh4c= Received: by 10.70.52.6 with SMTP id z6mr2474932wxz; Tue, 11 Apr 2006 07:50:22 -0700 (PDT) Received: by 10.70.133.14 with HTTP; Tue, 11 Apr 2006 07:50:22 -0700 (PDT) Message-ID: <5bfe7a820604110750t27e0b254w3329c3523b4409f6@mail.gmail.com> Date: Tue, 11 Apr 2006 07:50:22 -0700 From: "Dorothy Stanley" To: "Saravanan Govindan" Subject: Re: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages In-Reply-To: <5F09D220B62F79418461A978CA0921BDCDBCB0@pslexc01.psl.local> MIME-Version: 1.0 References: <5F09D220B62F79418461A978CA0921BDCDBCB0@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="===============1520091762==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.7 (/) X-Scan-Signature: 4fc59e88b356924367ae169e6a06365d --===============1520091762== Content-Type: multipart/alternative; boundary="----=_Part_6765_24075520.1144767022792" ------=_Part_6765_24075520.1144767022792 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Saravanan, Richard, First of all, thank you for your comments. Clearly, the WTP must have a means to provide statistics and other relevant data to the AC.. The question becomes, what specific mechanism should be used? Overloading the echo request message is one way. CAPWAP has the WTP event request message, section 8.5, and already includes the decryption error report, and can include the .11 specific statistics report. Why is using the WTP event report to report statistics not sufficient? We should add other applicable CAPWAP message elements to be included in it. Thanks, Dorothy On 4/10/06, Saravanan Govindan wrote: > > Hi Dorothy, > > > > I think this recommendation add substantial value to the CAPWAP protocol. > There have been discussions on the need for aggregating statistics > information from the WTP to AC. The Echo Request offers a way for achievi= ng > this. The mechanisms for statistics exchanges =96 timer, periodic exchang= e =96 > are available with Echo Request. So I think it is of value to keep Echo > Request and add statistics information fields to it. > > > > Cheers, > > > > Saravanan > > > > > > > ------------------------------ > > *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] > *Sent:* Tuesday, April 11, 2006 1:20 AM > *To:* capwap > *Subject:* [Capwap] Proposed Resolution to Issue 45 - Issue on > combiningmessages > > > > All, > > 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 > > Comments please. > > Thanks, > > Dorothy > ------=_Part_6765_24075520.1144767022792 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Saravanan, Richard,

First of all, thank you for your comments.

Clearly, the WTP must have a means to provide statistics and other relevant= data to the AC..

The question becomes, what specific mechanism should be used?
Overloading the echo request message is one way. CAPWAP  has the WTP e= vent request message,
section 8.5, and already includes the decryption error report, and can incl= ude the .11 specific
statistics report.

Why is using the WTP event report to report statistics not sufficient? We s= hould add other applicable CAPWAP message elements
to be included in it.

Thanks,

Dorothy

On 4/10/06, Saravanan Govindan <Saravanan.Govindan@sg.panasonic.com> wrote:

Hi Dorothy,

 

I think this recommendation add substantial value to the CAPWAP protocol. There have been discussions on the need for aggregating statistics information from the WTP to AC. The Echo Request offers a way fo= r achieving this. The mechanisms for statistics exchanges =96 timer, periodic exchange =96 are available with Echo Request. So I think it is of value to = keep Echo Request and add statistics information fields to it.

 

Cheers,

=

 

Saravanan

 

 

 

 

All,

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 <=
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 combined.
=




Recommendation:



To combine the keepalive and statist=
ics message into one combined message, 

thus reducing overhead signi=
ficantly.


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

Comments please.

Thanks,

Dorothy


------=_Part_6765_24075520.1144767022792-- --===============1520091762== 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 --===============1520091762==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Apr 11 11:22:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKh5-0000yN-Et for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 11:22:15 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTKh1-00060q-JX for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 11:22:15 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id EF06B4300E1 for ; Tue, 11 Apr 2006 08:22:10 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id EBD72430073 for ; Tue, 11 Apr 2006 08:21:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DAAFF1448004 for ; Tue, 11 Apr 2006 08:21:37 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.193]) by hermes.tigertech.net (Postfix) with ESMTP id C337C1448001 for ; Tue, 11 Apr 2006 08:21:34 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so811756wxd for ; Tue, 11 Apr 2006 08:21:33 -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=Q4p+4hypiSFeM33gPyYiVVl+6+Kx6xsUM9xEXoq5vg0MErvdiHY4J9m/XQA48TWfBl1Ha27iaUjSDnaeM+lvdNFTJu9JiQjYIbNRq/cu2QFMKQ1jEuO8p1n8+k1zX1aLeMlJwR/gBQ1Mx40Z3sY30xgLHhJxpq3p/ZAEy10it/E= Received: by 10.70.36.16 with SMTP id j16mr884526wxj; Tue, 11 Apr 2006 08:21:33 -0700 (PDT) Received: by 10.70.133.14 with HTTP; Tue, 11 Apr 2006 08:21:33 -0700 (PDT) Message-ID: <5bfe7a820604110821i43c1cb88r245d54fb9ce972b4@mail.gmail.com> Date: Tue, 11 Apr 2006 08:21:33 -0700 From: "Dorothy Stanley" To: "Richard Gwee" Subject: Re: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages In-Reply-To: <9C374CF75527504394E573E1937136C402C450A1@staff-mail.rp.edu.sg> MIME-Version: 1.0 References: <9C374CF75527504394E573E1937136C402C450A1@staff-mail.rp.edu.sg> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.9 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_40_50, HTML_MESSAGE, HTML_TAG_EXIST_TBODY, 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="===============2132034747==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.9 (/) X-Scan-Signature: 9e1884bf469cda400682762c3e8d96c9 --===============2132034747== Content-Type: multipart/alternative; boundary="----=_Part_7637_4459113.1144768893391" ------=_Part_7637_4459113.1144768893391 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello Richard, Is the statistics message element that the presentation refers to a new message element, or one/part of one that is already defined? - The CAPWAP Protocol needs regular Statistics exchange - Statistics should be applicable to the overall network, e.g. congestion, traffic loading,channel interferences -Size of statistics element 4-8 bytes If it is a new message element, then we need to agree on the contents of that element, and then the means of its transport. Thanks, Dorothy On 4/10/06, Richard Gwee wrote: > > Hi Dorothy, > > > > I believe that I have mentioned this point during my presentation in the > last IETF meeting. While combining messages does reduce overhead > significantly (as shown in my powerpoint presentation slides), we should > also look at another benefit of combining the keepalive and statistics > messages. As I have highlighted before, there is no statistics for the wh= ole > WLAN in the CAPWAP protocol. We need to include this in and I feel that > putting this statistics element in the Echo Request message is the best b= et. > While I understand your concern for keeping the echo messages simple, I > cannot visualize how much more complicated it can be if we just combine > statistics for our keepalive mechanism. > > > > Appreciate any comments. > > > > Thanks & Regards > > Richard Gwee > > > ------------------------------ > > *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] > *Sent:* Tuesday, April 11, 2006 1:20 AM > *To:* capwap > *Subject:* [Capwap] Proposed Resolution to Issue 45 - Issue on > combiningmessages > > > > All, > > 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 > > Comments please. > > Thanks, > > Dorothy > > ------------------------------ > > Republic Polytechnic, 9 Woodlands Avenue 9, Singapore 738964 (Near > Woodlands MRT/Interchange) > . *www.rp.sg* . Fax: +65 6415-1310 . > > *Republic Polytechnic, the first Institute of Higher Learning to fully > adopt the Problem-Based Learning approach in Singapore, continues to stri= ve > towards best practices and maintain excellence in service standards with = the > following certifications: Singapore Innovation Class (SIC), Singapore > Quality Class (SQC), People Developer Standards and QEHS (ISO 9001, 14001 > and OHSAS 18001)* > ------------------------------ > > CONFIDENTIALITY CAUTION: This message is intended only for the use of > the individual or entity to whom it is addressed and contains information > that is privileged and confidential. If you, the reader of this message, = are > not the intended recipient, you should not disseminate, distribute or cop= y > this communication. If you have received this communication in error, ple= ase > notify us immediately by return email and delete the original message. Th= ank > you. > > ------=_Part_7637_4459113.1144768893391 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello Richard,

Is the statistics message element that the
presentation refers to a new message element, or one/part of one that is al= ready defined?

- The CAPWAP Protocol needs regular Statistics exchange
- Statistics should be applicable to the overall network, e.g. congestion, = traffic loading,channel interferences
-Size of statistics element  4-8 bytes

If it is a new message element, then we need to agree on the
contents of that element, and then the means of its transport.

Thanks,

Dorothy

On 4/10/06, Richard Gwee <richard_gwee= @rp.sg> wrote:

Hi Dorothy,

 

I believe that I have mentioned th= is point during my presentation in the last IETF meeting. While combining messages d= oes reduce overhead significantly (as shown in my powerpoint presentation slide= s), we should also look at another benefit of combining the keepalive and statisti= cs messages. As I have highlighted before, there is no statistics for the whol= e WLAN in the CAPWAP protocol. We need to include this in and I feel that put= ting this statistics element in the Echo Request message is the best bet. While = I understand your concern for keeping the echo messages simple, I cannot visualize how m= uch more complicated it can be if we just combine statistics for our keepalive mechanism.

 

Appreciate any comments.

 

Thanks & Regards=

Richard Gwee

 

 

All,

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 <=
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 combined.
=




Recommendation:



To combine the keepalive and statist=
ics message into one combined message, 

thus reducing overhead signi=
ficantly.


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

Comments please.

Thanks,

Dorothy

Republic Polytechnic, 9 Woodlands Avenue 9,= Singapore 738964 (Near Woodlands MRT/Interchange)
. www.rp.sg . Fax: +65 6415-1310 .

Republic Polytechni= c, the first Institute of Higher Learning to fully adopt the Problem-Based Learning approach in Singapore, continues to strive towards best practices and maintain excellence in service standards with the following certifications: Singapore Innovation Class (SIC), Singapore Quality Class (SQC), People Developer Standards and QEHS (ISO 9001, 14001 and OHSAS 18001)

CONFIDENTIALITY CAUTION= : This message is intended only for the use of the individual or entity to whom it is addressed and contains information that is privileged and confidential. If you, the reader of this message, are not the intended recipient, you should not disseminate, distribute or copy this communication. If you have received this communication in error, please notify us immediately by return email and delete the original message. Thank you.


------=_Part_7637_4459113.1144768893391-- --===============2132034747== 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 --===============2132034747==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Apr 11 11:53:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLBd-0006M9-CE for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 11:53:49 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTLBb-0007DR-TT for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 11:53:49 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 156544300FF for ; Tue, 11 Apr 2006 08:53:47 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 5A103430073 for ; Tue, 11 Apr 2006 08:53:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4163D1448001 for ; Tue, 11 Apr 2006 08:53:20 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.196]) by hermes.tigertech.net (Postfix) with ESMTP id BD26F1448006 for ; Tue, 11 Apr 2006 08:53:16 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so817101wxd for ; Tue, 11 Apr 2006 08:53:15 -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=WpXlNb+QEiEyTSBUGdmC9AFaM03zhaLK+rluFF19GEW4VUKnlsAkkKDEgNYK+AiLCYatSuHRnIBVWzl6aIWphDe9KyvyYeXTqZNs7prb/0Ci1YR32AlWVLZL/R3zRehREkxla0bOeK6nmq5oyNz10Y3O4/9FMCZwcvT7SBRM3ao= Received: by 10.70.130.7 with SMTP id c7mr1948302wxd; Tue, 11 Apr 2006 08:53:14 -0700 (PDT) Received: by 10.70.133.14 with HTTP; Tue, 11 Apr 2006 08:53:14 -0700 (PDT) Message-ID: <5bfe7a820604110853k4427a872t974733a98d1f45db@mail.gmail.com> Date: Tue, 11 Apr 2006 08:53:14 -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 X-Spam-Level: Subject: [Capwap] New Question/Issue - 5.1.1 Discovery type definition inconsistencies 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="===============1485856045==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.8 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 --===============1485856045== Content-Type: multipart/alternative; boundary="----=_Part_8229_7453841.1144770794934" ------=_Part_8229_7453841.1144770794934 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, 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 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 Comments please. Thanks, Dorothy ------=_Part_8229_7453841.1144770794934 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All,

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 confi= gure 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 disco= very request message.
3. What is the purpose/value of including "Discovery Type"? Eithe= r define consistently, or delete it

Do we mean the following?


The Discovery Type message element is used to indicate that the WTP has be= en 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

Comments please.

Thanks,

Dorothy

------=_Part_8229_7453841.1144770794934-- --===============1485856045== 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 --===============1485856045==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Apr 11 12:31:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLm3-00064n-Ck for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 12:31:27 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTLm1-0000MS-TC for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 12:31:27 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3F6A3430104 for ; Tue, 11 Apr 2006 09:31:25 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C7C6C43008F for ; Tue, 11 Apr 2006 09:31:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B25381448004 for ; Tue, 11 Apr 2006 09:31:03 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0BF3F1448002 for ; Tue, 11 Apr 2006 09:30: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 k3BGUvtB001929; Tue, 11 Apr 2006 09:30:57 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k3BGUveg001906; Tue, 11 Apr 2006 09:30:57 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 11 Apr 2006 09:30:57 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Dorothy Stanley Subject: Re: [Capwap] New Question/Issue - 5.1.1 Discovery type definition inconsistencies In-Reply-To: <5bfe7a820604110853k4427a872t974733a98d1f45db@mail.gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new-20030616-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: b22590c27682ace61775ee7b453b40d3 HI, I started work on a document that described the CAPWAP boot model. I sent Scott and Charles a copy, but didn't send one to you or the WG mailing list, since it is not yet done. I'll try to get it wrapped up, but realy need some clarification on the previous question (on image transfer) plus the state diagram update. In general, the boot model as described in the LWAPP-03 and CAPWAP-00 leaves out a lot of details. In trying to address one part, with the question below, I believe you are possibly making detailed choices that may not fit with the overall "boot model". The "boot model" is the process that is used to get a WTP to the run state. Even though it is not well described (and the text may be inconsistent in places), the current CAPWAP-00 document describes the following: A WTP can be configured to be managed by an ordered list of ACs (which is stored in persistent storage). The first is the "primary". A WTP may also get AC addresses via DHCP option 43 or a "well known" DNS name. And finally, a WTP may broadcast or multicast when an IP address is unknown. The details of how the list is used is not specified in the CAPWAP-00 document. For example, does the WTP send Discovery messages to all ACs in the list, or just the first? And only send mcast/bcast if the list is empty or no response is received from any AC on the list? I believe that the boot model should be worked out before the details of messages used in the boot process are worked out. However, for the below, I suggest that the values for "Discovery type" be modified to be an enum that has values: 0 - bcast/mcast 1 - last AC (the AC used last time the WTP booted) 2 - AC address from DHCP 3 - AC address from DNS 4-127 reserved 128 - first configured AC 129 - second configured AC 130 - third configured AC 131-255 reserved On Tue, 11 Apr 2006, Dorothy Stanley wrote: > All, > > 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 > > Comments please. > > Thanks, > > Dorothy > Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Apr 11 12:41:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLvv-0003mx-B2 for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 12:41:39 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTLvu-0000eJ-EM for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 12:41:39 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0CCB143011D for ; Tue, 11 Apr 2006 09:41:38 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 62018430073 for ; Tue, 11 Apr 2006 09:41:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 50933398042 for ; Tue, 11 Apr 2006 09:41:07 -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 1A526398029 for ; Tue, 11 Apr 2006 09:41:04 -0700 (PDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 11 Apr 2006 09:41:05 -0700 X-IronPort-AV: i="4.04,112,1144047600"; d="scan'208"; a="268019685:sNHT45460284" 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 k3BGewZ2011009 for ; Tue, 11 Apr 2006 09:41: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); Tue, 11 Apr 2006 09:40: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 Date: Tue, 11 Apr 2006 09:40:57 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201B21B69@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Variable Length headers Thread-Index: AcZXmiGYKUrUeU/XT1OcZaCvsWKBVgAnw06wAAH/5gAAHicW0AAV2e5gAAQCVeAAAewBIAAdCSWAABDYbCAACDF+oADE7PigABxmTnA= From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 11 Apr 2006 16:40:58.0179 (UTC) FILETIME=[B5AF1930:01C65D86] 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] Variable Length headers 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: 916029c14bdb340aa234d3ec4cd24f52 All, As a result of issue 53, two requests have come in to make the CAPWAP headers variable in length, using a bit in the header to indicate additional data. I'd like to get a sense from the group on whether there are objections to=20 changing the text for issue 53 to change the CAPWAP header to make all of the RF related info optional. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 > Sent: Monday, April 10, 2006 8:23 PM > To: Abhijit Choudhury; Bob O'Hara (boohara); capwap > Subject: RE: [Capwap] Proposed Text for Issue 53 >=20 > Hi Abhijit, >=20 > I understand your suggestion below.=20 >=20 > However, following from the point Jim made earlier,=20 > per-data-packet statistics only applies to split-MAC WTP. It=20 > does not apply to local-MAC WTPs where not all data packets=20 > reach the AC.=20 >=20 > Aggregated statistics, on the other hand, can be used for=20 > both split-MAC and local-MAC WTPs. Since this covers both=20 > types of WTPs that CAPWAP will be used for, I think we should=20 > use this as the default.=20 >=20 > My suggestion is to have the Echo Request carry aggregated=20 > statistics as default and have the RSSI/SNR header fields as=20 > optional.=20 >=20 > Cheers, >=20 > Saravanan >=20 >=20 >=20 >=20 > -----Original Message----- > From: Abhijit Choudhury [mailto:Abhijit@sinett.com] > Sent: Friday, April 07, 2006 1:18 PM > To: Saravanan Govindan; Bob O'Hara (boohara); capwap > Subject: RE: [Capwap] Proposed Text for Issue 53 >=20 > Bob, Saravanan: >=20 > Here's what I'd suggest. Since the current CAPWAP spec=20 > already supports carrying RSSI/SNR in the base CAPWAP header=20 > (in the 6 bytes), we can make transmission of per-packet=20 > measurement the default mode, and the exchange of aggregated=20 > information from the WTP an "optional to implement" mode. =20 > However, we will use an extension of the base CAPWAP header,=20 > say with the D bit as explained in my earlier email, to=20 > extend the CAPWAP header by > 2 more bytes to carry additional per-packet info like the data rate. >=20 > This way vendors who want to use per-packet information can=20 > do so, without burdening others who decide to implement the=20 > option of the WTP sending aggregated information. I think=20 > this is a reasonable compromise that satisfactorily resolves=20 > Issue 53, while allowing for flexibility. >=20 > Comments ? >=20 > Thanks, > Abhijit >=20 >=20 >=20 >=20 > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Thursday, April 06, 2006 6:14 PM > To: Bob O'Hara (boohara); capwap > Subject: RE: [Capwap] Proposed Text for Issue 53 >=20 >=20 > Bob, >=20 > I understand from your note that per data packet measurement is the > basis for real time AC processing. My support for aggregated=20 > measurement > exchange is based on efficiency considerations. Having said this, I do > not want to exclude one or the other - the exchanges so far show both > make for valuable additions to CAPWAP. >=20 > I think we can move forward now maintaining / incorporating both types > of exchanges in to the CAPWAP specs. >=20 > Saravanan >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 > Sent: Friday, April 07, 2006 1:15 AM > To: Saravanan Govindan; capwap > Subject: RE: [Capwap] Proposed Text for Issue 53 >=20 > Saranavan, >=20 > As I said in another email earlier in the thread than the one to which > you responded, I do not have an objection to adding the reporting of > aggregated information in a status report or other message. I do not > want to lose the ability to deal with or have access to the real time > information in the AC, on a packet by packet basis. >=20 > Why do you object to enabling a function such as real time=20 > processing of > the packet RSSI and SNR? >=20 > -Bob > =20 > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 > Sent: Wednesday, April 05, 2006 8:41 PM > To: Bob O'Hara (boohara); capwap > Subject: RE: [Capwap] Proposed Text for Issue 53 >=20 > Bob, >=20 > Without going in to pseudo-judicial rhetoric, I think we need=20 > to look at > what is needed for the CAPWAP protocol.=20 >=20 > >From the exchanges so far, we see that measurement information can be > exchanged on a per data packet basis or on an aggregated=20 > basis. We have > seen the advantages of exchanging then on aggregated basis. In the > spirit of quick resolution, I suggest we select one as the=20 > default mode > for CAPWAP and have the other as an additional feature. I believe this > was suggested earlier also.=20 >=20 > Saravanan >=20 >=20 >=20 >=20 > -----Original Message----- > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 > Sent: Thursday, April 06, 2006 10:26 AM > To: Saravanan Govindan; capwap > Subject: RE: [Capwap] Proposed Text for Issue 53 >=20 > So, your preference is to remove functionality that is already in a > product available today, by eliminating this capability from the > protocol. Given Moore's law advancement of processing=20 > capability, this > seems a bit short sighted.=20 >=20 >=20 > -Bob > =20 > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 > Sent: Wednesday, April 05, 2006 5:33 PM > To: Bob O'Hara (boohara); capwap > Subject: RE: [Capwap] Proposed Text for Issue 53 >=20 > Bob, >=20 > I will accept that there is an AC implementation for per data packet > processing.=20 >=20 > I still prefer that the CAPWAP protocol aggregate measurement > information for periodic exchange.=20 >=20 > Saravanan >=20 >=20 > =20 >=20 > -----Original Message----- > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 > Sent: Wednesday, April 05, 2006 10:15 PM > To: capwap > Subject: RE: [Capwap] Proposed Text for Issue 53 >=20 > For those AC implementations that want to use per packet data for > certain operations, aggregation of the data at the WTP as suggested by > Abhijit will preclude this. The assertion by Saravanan that=20 > an AC does > not process this information is incorrect. I can point to at=20 > least one > existing implementation that already does process this=20 > information on a > per packet basis. >=20 > The current text, with the change I suggested, is the right way to > handle this. If we want to ADD a capability that the WTP can provide > aggregation, I have no objection to that. >=20 > -Bob > =20 > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 > Sent: Tuesday, April 04, 2006 4:49 PM > To: Abhijit Choudhury; Pat Calhoun (pacalhou); capwap > Subject: RE: [Capwap] Proposed Text for Issue 53 >=20 > Hi Abhijit, >=20 > I am in support of your suggestion. It is true that the AC does not > process all data packets. Furthermore, I think for greater=20 > control, the > AC will need information about the congestion level in the WLAN. This > could be a derivative of interference and load factor.=20 >=20 > As for your suggestion, I think measurement/parameter information from > the WTP should be sent over the periodic Echo Request messages. The > advantage is that header overhead is reduced.=20 >=20 > I can prepare text for this approach. >=20 > Cheers, >=20 > Saravanan >=20 >=20 >=20 > =20 >=20 > -----Original Message----- > From: Abhijit Choudhury [mailto:Abhijit@sinett.com]=20 > Sent: Wednesday, April 05, 2006 6:52 AM > To: Pat Calhoun (pacalhou); capwap > Subject: RE: [Capwap] Proposed Text for Issue 53 >=20 > Here's another approach... >=20 > RSSI, SNR, and Data Rate are measurements/parameters > of the radio channel that are being reported to the=20 > AC for finer control. Carrying them in every data packet > on the data channel means some logic or hardware in the > AC will have to parse them out of every data packet > and send them to the control path (CPU). Typically not > every packet will go to the CPU and so this data will=20 > have to be stored and periodically sent to or read=20 > by the CPU. Note that the AC will be possibly dealing=20 > with tens to hundreds of WTPs and hence a=20 > potentially large number of STAs. This implies a=20 > large amount of per-STA measurement data has to be stored > and moved from the data path to the CPU. >=20 > A more reasonable approach is to let the WTP=20 > aggregate such data and periodically send it in the=20 > control channel to the AC. Note the WTP > has to deal with much much fewer clients - so the > storage burden is less. All we'd need is a frame that > carries this information to the AC at a specified=20 > interval of time. This period could be configurable. >=20 > Using this approach, we don't need to increase the CAPWAP header every > time we need new measurement info. We can retain the current CAPWAP > header and flexibly add any measurement information we need=20 > by adding it > in the control channel. This is particularly important as we move > forward to support 802.11n or other=20 > non-802.11 technlogies. It decouples the CAPWAP header from > the measurement data related information. >=20 > Any thoughts on this ? >=20 >=20 > Thanks, > Abhijit >=20 >=20 >=20 >=20 > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 > Sent: Monday, April 03, 2006 8:45 PM > To: capwap > Subject: [Capwap] Proposed Text for Issue 53 >=20 >=20 > Here is my proposed text for Issue 53, which is the addition of a Data > Rate In the CAPWAP header. >=20 > Please let me know if you have any comments. > =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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |VER| RID |F|L|R| Frag ID | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | > <=3D=3D=3D CHANGED!!! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload... | > +-+-+-+-+-+-+-+-+ >=20 > [...] > 4.1.8. Reserved >=20 > This 32 bit field is reserved and may be used by a binding specific > extension. Refer to the transport portion of the binding for a > specific wireless technology for the definition of this field. >=20 > [...] >=20 > 11.3.2. CAPWAP Header Reserved field >=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=20 > 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=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 over=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RSSI | SNR | Data Rate | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=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 received at > 5.5Mbps would be set to 55, while 11Mbps would be set to 110. >=20 > 11.3.2.2. Destination WLANs >=20 > The Destination WLAN field is used to specify the target=20 > WLANs for a > given frame, and is only used with broadcast and multicast frames. > This field allows the AC to transmit a single broadcast or=20 > multicast > frame to the WTP, and allows the WTP to perform the necessary frame > replication services. The field uses 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | WLAN | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > WLAN: This bit field indicates the WLAN ID (see section > Section 11.8.1.1) which the WTP will transmit the=20 > associated frame > on. For instance, if a multicast packet is to be transmitted on > WLANs 1 and 3, bits 1 and 3 of this field would be=20 > enabled. Note > this field is to be set to zero for unicast packets and=20 > is unused > if the WTP is not providing encryption services. >=20 > Reserved: This field MUST be set to zero. > =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 >=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 > _________________________________________________________________ > 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 > _________________________________________________________________ > 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 Tue Apr 11 12:48:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTM2w-0006Hb-4f for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 12:48:54 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTM2u-0000tE-JE for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 12:48:54 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3C014430161 for ; Tue, 11 Apr 2006 09:48:52 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id BAFFD43008C for ; Tue, 11 Apr 2006 09:48:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A53D71448002 for ; Tue, 11 Apr 2006 09:48:23 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.205]) by hermes.tigertech.net (Postfix) with ESMTP id B7F031448004 for ; Tue, 11 Apr 2006 09:47:56 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so826258wxd for ; Tue, 11 Apr 2006 09:47: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:mime-version:content-type; b=AAuBlxIO9B+vxEW/Nc23w8qU2Xf+Kkd2koQwt2mD2V9Jn+vndTNHrhYHC+nQv+g9h/gLSjtvCFv4iwjgbxd4OmR19y44AS/szN9f3A3gR6DsPEkUAqWJSChfEMfFW+IjDJegPwY42KAy7jQmkbUCHKJ7IV7hP07lo/RKoQSPLr8= Received: by 10.70.80.13 with SMTP id d13mr65328wxb; Tue, 11 Apr 2006 09:47:56 -0700 (PDT) Received: by 10.70.133.14 with HTTP; Tue, 11 Apr 2006 09:47:56 -0700 (PDT) Message-ID: <5bfe7a820604110947tba07daeq57158b195d4c4cef@mail.gmail.com> Date: Tue, 11 Apr 2006 09:47:56 -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 X-Spam-Level: Subject: [Capwap] New issue - Correct Clause 11 Message Naming, Clean-up terminology 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="===============0655325751==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.8 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 --===============0655325751== Content-Type: multipart/alternative; boundary="----=_Part_9209_16305477.1144774076007" ------=_Part_9209_16305477.1144774076007 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, Some suggested, largely editorial changes, throughout Clause 11: 1. Figures 5,7,8 show examples of message Flow and Roaming, and show "Add Mobile" as the message exchanged between the AC and WTP. But "Add Mobile" is the message element, not the message - the Mobile Config Request, changing to "Mobile Station Config Request" is the message name. Recommended change: Change "Add Mobile" to "Mobile Station Config Request[Add Mobile...]" 2. 11.1.2 Local MAC - Last paragraph describes optionally tunnelling data frames to the AC, which is not consistent with Local MAC. Recommended change: Delete the last paragraph 3. 11.3.1 Wording change: From: The CAPWAP protocol defines the data frame, which allows a wireless payload to be encapsulated. to: The CAPWAP protocol defines CAPWAP data packets, which are used to encapsulate an IEEE 802.11 payload. 4. 11.1.1 and 11.1.2 - Clarity In the function lists, change from Probe Response to Generate Probe Response 5. 11.1.1 Split MAC, first paragraph below the figure The Distribution and Integration services reside on the AC, and therefore all user data is tunneled between the WTP and the AC. As noted above, all real-time 802.11 services, including the control protocol and the beacon and probe response frames, are handled on the WTP. "control protocol" usually refers to the CAPWAP control protocol. Change to The Distribution and Integration services reside on the AC, and all user data is tunneled between the WTP and the AC. All real-time IEEE 802.11servi= ces, including the IEEE 802.11 control frames, such as the Beacon and Probe Response frames, are handled on the WTP. 6. 11.3 - Correct use of terms 11.3 Transport specific bindings "All CAPWAP transports have the following IEEE 802.11 specific bindings:" Section 3, "CAPWAP Transport" talks about UDP with IPv4 or IPv6, rather tha= n the payload encapsulation and status and WLANs field Suggest 11.3 IEEE 802.11 bindings for the CAPWAP Protocol This section defines the IEEE 802.11 specific bindings used with the CAPWAP protocol. 7. I1.2, First sentence in the second paragraph, change "access point" to "WTP". Comments please. Thanks, Dorothy ------=_Part_9209_16305477.1144774076007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All,

Some suggested, largely editorial changes, throughout Clause 11:

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

Recommended change: Change  "Add Mobile" to "Mobile Sta= tion Config Request[Add Mobile...]"

2. 11.1.2 Local MAC - Last paragraph describes optionally tunnelling data f= rames to the AC, which
is not consistent with Local MAC.

Recommended change: Delete the last paragraph

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

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

5. 11.1.1 Split MAC, first paragraph below the figure

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

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

Change to

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

6. 11.3 - Correct use of terms

11.3 Transport specific bindings

"All CAPWAP transports have the following IEEE 802.11 specific binding= s:"

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

Suggest

11.3 IEEE 802.11 bindings for the CAPWAP Protocol

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

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

Comments please.

Thanks,

Dorothy

------=_Part_9209_16305477.1144774076007-- --===============0655325751== 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 --===============0655325751==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Apr 11 15:09:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOF9-0004rU-6H for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 15:09:39 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTOF7-00063O-Pd for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 15:09:39 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4F242430094 for ; Tue, 11 Apr 2006 12:09:37 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1D4C2430073 for ; Tue, 11 Apr 2006 12:09:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 09B9D1448001 for ; Tue, 11 Apr 2006 12:09:09 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.201]) by hermes.tigertech.net (Postfix) with ESMTP id 49A5B1448013 for ; Tue, 11 Apr 2006 12:09:08 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so847371wxd for ; Tue, 11 Apr 2006 12:09:07 -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=ITj+bAx+TPirf3Dq5anU/I098uRINvcVGPmX0Lhya7IRbjnR4j/IQt08YfIQVtrWhIBcDC6/Ium7Si31cnb8slpe0eoBMYga5De169YZ5Li4uetMiwVkNL4L4AT+DsvsJtsN/5jhKCnkp0lyceXyGMqUNVOt7mPfJ1PUJZqQGrE= Received: by 10.70.80.13 with SMTP id d13mr247287wxb; Tue, 11 Apr 2006 12:09:07 -0700 (PDT) Received: by 10.70.133.14 with HTTP; Tue, 11 Apr 2006 12:09:07 -0700 (PDT) Message-ID: <5bfe7a820604111209x18daba48sb62b9ac4e95b86e@mail.gmail.com> Date: Tue, 11 Apr 2006 12:09:07 -0700 From: "Dorothy Stanley" To: capwap MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.8 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_10_20, HTML_MESSAGE, RCVD_BY_IP X-Spam-Level: Subject: [Capwap] New Issue - Section 11.5 overlap with Section 4.3.3 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="===============2093761274==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.8 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a --===============2093761274== Content-Type: multipart/alternative; boundary="----=_Part_11085_5457254.1144782547173" ------=_Part_11085_5457254.1144782547173 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, Section 4.3.3 defines the Quality of Service to be used with CAPWAP control messages. values of 7/46 Section 11.5 is titled "Quality of Service for Control Messages" and specifies values of 6&4/46&34. 1. Does the draft specify that IEEE 802.11 MAC management frames are sent as CAPWAP control messages? If not, we should say this, if it is intended, as implied by the title of the section, or chanage the section title. 2. Any reason not to use 7/46 in both cases, with Probe Request Frames treated differently? Since 46 is used for both, why not use 7 for both? Comments welcome. Thanks, Dorothy ------=_Part_11085_5457254.1144782547173 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All,

Section 4.3.3 defines the Quality of Service to be used with CAPWAP control= messages. values of 7/46
Section 11.5 is titled "Quality of Service for  Control Messages&= quot;  and specifies values of 6&4/46&34.

1. Does the draft specify that IEEE 802.11 MAC management frames are sent as CAPWAP control messages? If not, we should say this, if it is intended, = as implied by the title of the section,
or chanage the section title.

2. Any reason not to use 7/46 in both cases, with Probe Request Frames trea= ted differently?
Since 46 is used for both, why not use 7 for both?

Comments welcome.

Thanks,

Dorothy

------=_Part_11085_5457254.1144782547173-- --===============2093761274== 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 --===============2093761274==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Apr 11 15:30:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOZR-0005JK-VW for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 15:30: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 1FTO1C-0005Oi-P9 for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 14:55:14 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FTNnc-0000zi-IL for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 14:41:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 46360430063 for ; Tue, 11 Apr 2006 11:41:11 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3C6D343004F for ; Tue, 11 Apr 2006 11:40:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id ED5AE1448006 for ; Tue, 11 Apr 2006 11:40:44 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.194]) by hermes.tigertech.net (Postfix) with ESMTP id 46A711448001 for ; Tue, 11 Apr 2006 11:40:42 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so843331wxd for ; Tue, 11 Apr 2006 11:40:41 -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=dPvQ3rt/0LRImDmtInmzLnRAFfhEZy10u4YMPAB+vTo0LkOXaiclR1bb2DHro0534bSr3OLX0GH87RerfysQM3ZpqEEIdCQJ5gzqcXaFLnmiExJUzgH62Evv+ifACeFYS9XBulmenuGhUbl6TN0eR2G8xYEJfEHeO4T7wAvyRfo= Received: by 10.70.84.17 with SMTP id h17mr1668170wxb; Tue, 11 Apr 2006 11:40:41 -0700 (PDT) Received: by 10.70.133.14 with HTTP; Tue, 11 Apr 2006 11:40:41 -0700 (PDT) Message-ID: <5bfe7a820604111140m201774cep4474fc4f374b29a7@mail.gmail.com> Date: Tue, 11 Apr 2006 11:40:41 -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 X-Spam-Level: Subject: [Capwap] New Issue - Local MAC MUST vs MAY forward association request messages 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="===============1048390415==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.3 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --===============1048390415== Content-Type: multipart/alternative; boundary="----=_Part_10817_8991029.1144780841487" ------=_Part_10817_8991029.1144780841487 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, Section 11.1.2 Local MAC describes the Local MAC operation. It currently states (second paragraph below Figure 6): While the MAC is terminated on the WTP, it is necessary for the AC to be aware of mobility events within the WTPs. As a consequence, the WTP MUST forward the IEEE 802.11 Association Requests to the AC, and the AC MAY reply with a failed Association Response if it deems it necessary. Since this is the Local MAC case, it seems that a MAY should be sufficient. Recommended change: The MAC is terminated on the WTP, but the AC may need to be aware of mobility events within the WTPs. As a consequence, the WTP MAY forward the IEEE 802.11 Association Requests to the AC, and the AC MAY reply with a failed Association Response. Comments? Thanks, Dorothy ------=_Part_10817_8991029.1144780841487 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All,

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

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


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

Recommended change:

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

Comments?

Thanks,

Dorothy
------=_Part_10817_8991029.1144780841487-- --===============1048390415== 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 --===============1048390415==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Apr 11 15:51:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOu0-00075N-H8 for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 15:51:52 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTOtx-0007Td-Vv for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 15:51:52 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 35BA94300E7 for ; Tue, 11 Apr 2006 12:51:49 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C6F0F43004F for ; Tue, 11 Apr 2006 12:51:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AEED11448011 for ; Tue, 11 Apr 2006 12:51:23 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.194]) by hermes.tigertech.net (Postfix) with ESMTP id 022311448007 for ; Tue, 11 Apr 2006 12:51:20 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so853379wxd for ; Tue, 11 Apr 2006 12:51:20 -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=blXjRNBjGigj2tUhCWO1aqvf+wZLO7HJyrZ+Czs1E+zPlHsv7Zgr8qLweaUk0irJTp5c95HY0kkigsSdh6RcrV4hzmbo6XFPgXu1chg/9MlmYa5765SAYkVv2ckXw95m0ApcNkfvkCT0CwElBwTj3DO4U/bQMwaTTogzA0h4nqY= Received: by 10.70.45.3 with SMTP id s3mr1089784wxs; Tue, 11 Apr 2006 12:51:20 -0700 (PDT) Received: by 10.70.133.14 with HTTP; Tue, 11 Apr 2006 12:51:18 -0700 (PDT) Message-ID: <5bfe7a820604111251x342243c8t9e5c338709336beb@mail.gmail.com> Date: Tue, 11 Apr 2006 12:51:19 -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.9 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_10_20, HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP X-Spam-Level: Subject: [Capwap] New Issue - 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: , Content-Type: multipart/mixed; boundary="===============1862797652==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.9 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 --===============1862797652== Content-Type: multipart/alternative; boundary="----=_Part_11793_30695320.1144785079998" ------=_Part_11793_30695320.1144785079998 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, Section 11.8.1.1 defines the IEEE 802.11 Add WLAN message element, and includes the encryption policy, key, WPAIE and RSNIE. Rather than defining new values, we should re-use the existing IEEE 802.11 definitions, making the message element more easily extensible. Recommended change: Change the message element to include a list of IEEE 802.11 information elements, using the element ID, Length and values as defined in section 7.3.2 of the IEEE 802.11 spec, 802.11ma-REV. This should eliminate new definitions for WLAN capability, encryption policy, WPA data length, WPA IE, RSN Data Length, RSN IE, WME (now re-named WMM) data length, WME IE, dot11E Data Length, Dot11E IE, QOS, Auth type. Include the Key Data Field from IEEE 802.11 Clause 8.5.2 to transport the key. Comments please. Thanks, Dorothy ------=_Part_11793_30695320.1144785079998 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All,

Section 11.8.1.1 defines the IEEE 802.11 Ad= d WLAN message element, and includes
the encryption policy, key, WPAIE and RSNIE. Rather than defining new value= s, we
should re-use the existing IEEE 802.11 definitions, making the message elem= ent more easily
extensible.

Recommended change:

Change the message element to include a list of IEEE 802.11 information elements, using the element ID, Length and values as defined
in section 7.3.2 of the IEEE 802.11 spec, 802.11ma-REV.

This should eliminate new definitions for WLAN capability, encryption polic= y, WPA data length, WPA IE, RSN Data Length,
RSN IE, WME (now re-named WMM) data length, WME IE, dot11E Data Length, Dot= 11E IE, QOS, Auth type.

Include the Key Data Field from IEEE 802.11 Clause 8.5.2 to transport the k= ey.

Comments please.

Thanks,

Dorothy




------=_Part_11793_30695320.1144785079998-- --===============1862797652== 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 --===============1862797652==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Apr 11 16:27:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTPSU-0006Jd-D8 for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 16:27:30 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTPSS-0001bx-W2 for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 16:27:30 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1FB554300AF for ; Tue, 11 Apr 2006 13:27:28 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C7F1A43004F for ; Tue, 11 Apr 2006 13:27:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AAAF7144801B for ; Tue, 11 Apr 2006 13:27:01 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.207]) by hermes.tigertech.net (Postfix) with ESMTP id 8A2901448016 for ; Tue, 11 Apr 2006 13:26:59 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so858365wxd for ; Tue, 11 Apr 2006 13:26:58 -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=Q8Y/bZtzl1XNU5evo/LpgzTYQyaktHhaUS4LbEycoyA0U3WKC0McJj+L1sVSU32yyanGvnkY+C3E2GQ23zCDSncnCXwL0AV54r2aEOvy4dPesL4mRSVWD1OLnLv8rsNkWwOSypxANiZlrcz5vbXiEC+PYgCOksqvRoAyUlCxCno= Received: by 10.70.22.15 with SMTP id 15mr2998293wxv; Tue, 11 Apr 2006 13:26:58 -0700 (PDT) Received: by 10.70.133.14 with HTTP; Tue, 11 Apr 2006 13:26:58 -0700 (PDT) Message-ID: <5bfe7a820604111326w589a36a5ua844aaa1b64b85a4@mail.gmail.com> Date: Tue, 11 Apr 2006 13:26:58 -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 X-Spam-Level: Subject: [Capwap] New Issue - 11.9.1 WTP WLAN Radio Configuration Changes 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="===============0443606384==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.8 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 --===============0443606384== Content-Type: multipart/alternative; boundary="----=_Part_12357_30355579.1144787218785" ------=_Part_12357_30355579.1144787218785 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, Section 11.9.1 describes a WTP WLAN Radio configuration message element, used by the AC to configure a radio on the WTP. Suggested changes: 1. Change the name of the message element to "WTP WLAN Configuration" message element, since it is the WLAN on the radio that is being configured. 2. Delete country code. The FCC does not allow the country code to be changed from a controller. 3. PCF is often not supported, and is not used widely - used in the downlin= k more than in the uplink, not reliably supported on clients. Delete CFP Maximum duration, CFP Period and Occupancy Limit. Comments? Thanks, Dorothy ------=_Part_12357_30355579.1144787218785 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All,

Section 11.9.1 describes a WTP WLAN Radio configuration message element, us= ed by the AC to configure a
radio on the WTP.

Suggested changes:

1. Change the name of the message element to "WTP WLAN Configuration&q= uot; message element, since it is the
WLAN on the radio that is being configured.

2. Delete country code. The FCC does not allow the country code to be chang= ed from a controller.

3. PCF is often not supported, and is not used widely - used in the downlin= k more than in the uplink, not
reliably supported on clients.  Delete CFP Maximum duration, CFP Perio= d and Occupancy Limit.

Comments?

Thanks,

Dorothy
------=_Part_12357_30355579.1144787218785-- --===============0443606384== 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 --===============0443606384==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Apr 11 16:40:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTPfA-0001tA-C3 for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 16:40:36 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTPf9-00022T-HW for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 16:40:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2B01A43008F for ; Tue, 11 Apr 2006 13:40:35 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id A726F43004F for ; Tue, 11 Apr 2006 13:39:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8F3651448013 for ; Tue, 11 Apr 2006 13:39:56 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.192]) by hermes.tigertech.net (Postfix) with ESMTP id 1D31D1448002 for ; Tue, 11 Apr 2006 13:39:54 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so860190wxd for ; Tue, 11 Apr 2006 13:39: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=XHMzpCssXXuWzFjzIpeBuFSF+tJC89TpPR0VVpn8ubawO89P9v1HGtzt7fjvqvZ1fuFPtYEqMmBn3XhVLxhcSlIURCA6As2KjFtNioXaMAHkcOpnFReghEl573v+GgDAjCxdo37ZH0MS9w+TMh24s46mA+7TfxvMQCYlPr8cKl8= Received: by 10.70.36.16 with SMTP id j16mr1306754wxj; Tue, 11 Apr 2006 13:39:54 -0700 (PDT) Received: by 10.70.133.14 with HTTP; Tue, 11 Apr 2006 13:39:54 -0700 (PDT) Message-ID: <5bfe7a820604111339p5ce8d2b4l55ae4f8221f80e6a@mail.gmail.com> Date: Tue, 11 Apr 2006 13:39:54 -0700 From: "Dorothy Stanley" To: "David T. Perkins" Subject: Re: [Capwap] New Question/Issue - 5.1.1 Discovery type definition inconsistencies In-Reply-To: MIME-Version: 1.0 References: <5bfe7a820604110853k4427a872t974733a98d1f45db@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 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="===============1230297918==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.0 (+) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 --===============1230297918== Content-Type: multipart/alternative; boundary="----=_Part_12581_22089746.1144787994403" ------=_Part_12581_22089746.1144787994403 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline David, Clarifying the boot model is helpful. Note that there are also two in-run-state discovery messages that are also currently defined, the Primary Discovery Request and Primary Discovery Response. So you might need to look at what happens in th= e run state, in addtion to getting there. The contents of these messages are identical to the Discovery Request and Response. In this extended Discovery Type list, ther= e may be a way to indicate "primary discovery" and eliminate two messages. However, for the below, I suggest that the values for "Discovery type" be modified to be an enum that has values: 0 - bcast/mcast 1 - last AC (the AC used last time the WTP booted) 2 - AC address from DHCP 3 - AC address from DNS 4-127 reserved 128 - first configured AC 129 - second configured AC 130 - third configured AC 131-255 reserved Thanks, Dorothy On 4/11/06, David T. Perkins wrote: > > HI, > > I started work on a document that described the CAPWAP boot model. > I sent Scott and Charles a copy, but didn't send one to you > or the WG mailing list, since it is not yet done. I'll try > to get it wrapped up, but realy need some clarification on > the previous question (on image transfer) plus the state > diagram update. > > In general, the boot model as described in the LWAPP-03 and > CAPWAP-00 leaves out a lot of details. > > In trying to address one part, with the question below, > I believe you are possibly making detailed choices > that may not fit with the overall "boot model". > The "boot model" is the process that is used to > get a WTP to the run state. > > Even though it is not well described (and the text may be > inconsistent in places), the current CAPWAP-00 document > describes the following: > > A WTP can be configured to be managed by an ordered list > of ACs (which is stored in persistent storage). The first > is the "primary". A WTP may also get AC addresses via > DHCP option 43 or a "well known" DNS name. And finally, > a WTP may broadcast or multicast when an IP address is > unknown. > The details of how the list is used is not specified > in the CAPWAP-00 document. For example, does the WTP > send Discovery messages to all ACs in the list, or > just the first? And only send mcast/bcast if the > list is empty or no response is received from any > AC on the list? > > I believe that the boot model should be worked out > before the details of messages used in the boot process > are worked out. > > However, for the below, I suggest that the values > for "Discovery type" be modified to be an enum > that has values: > 0 - bcast/mcast > 1 - last AC (the AC used last time the WTP booted) > 2 - AC address from DHCP > 3 - AC address from DNS > 4-127 reserved > 128 - first configured AC > 129 - second configured AC > 130 - third configured AC > 131-255 reserved > > On Tue, 11 Apr 2006, Dorothy Stanley wrote: > > All, > > > > 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 > > > > Comments please. > > > > Thanks, > > > > Dorothy > > > Regards, > /david t. perkins > > > ------=_Part_12581_22089746.1144787994403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline David,

Clarifying the boot model is helpful. Note that there are also two in-run-s= tate discovery
messages that are also currently defined, the Primary Discovery Request and=
Primary Discovery Response. So you might need to look at what happens in th= e
run state, in addtion to getting there. The contents of these messages are = identical to the
Discovery Request and Response.  In this extended Discovery Type list,= there may be a way to
indicate "primary discovery" and eliminate two messages.


However, for the below, I suggest that the values
for "Discovery type" be modified to be an enum
that has values:
 0 - bcast/mcast
 1 - last AC (the AC used last time the WTP booted)
 2 - AC address from DHCP
 3 - AC address from DNS
 4-127 reserved
 128 - first configured AC
 129 - second configured AC
 130 - third configured AC
 131-255 reserved

Thanks,

Dorothy

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

I started work on a document that described the CAPWAP boot mode= l.
I sent Scott and Charles a copy, but didn't send one to you
or the= WG mailing list, since it is not yet done. I'll try
to get it wrapped u= p, but realy need some clarification on
the previous question (on image transfer) plus the state
diagram upd= ate.

In general, the boot model as described in the LWAPP-03 and
= CAPWAP-00 leaves out a lot of details.

In trying to address one part= , with the question below,
I believe you are possibly making detailed choices
that may not fit = with the overall "boot model".
The "boot model" is t= he process that is used to
get a WTP to the run state.

Even thoug= h it is not well described (and the text may be
inconsistent in places), the current CAPWAP-00 document
describes th= e following:

A WTP can be configured to be managed by an ordered lis= t
of ACs (which is stored in persistent storage). The first
is the &q= uot;primary". A WTP may also get AC addresses via
DHCP option 43 or a "well known" DNS name. And finally,
a = WTP may broadcast or multicast when an IP address is
unknown.
The det= ails of how the list is used is not specified
in the CAPWAP-00 document.= For example, does the WTP
send Discovery messages to all ACs in the list, or
just the first? A= nd only send mcast/bcast if the
list is empty or no response is received= from any
AC on the list?

I believe that the boot model should be= worked out
before the details of messages used in the boot process
are worked o= ut.

However, for the below, I suggest that the values
for "D= iscovery type" be modified to be an enum
that has values:
 =  0 - bcast/mcast
  1 - last AC (the AC used last time the WTP booted)
 = ; 2 - AC address from DHCP
  3 - AC address from DNS
&= nbsp; 4-127 reserved
  128 - first configured AC
 = ; 129 - second configured AC
  130 - third configured AC
  131-255 reserved

On Tue, 11 Apr 2006, Dorothy Stanle= y wrote:
> All,
>
> Section 5.1.1 Defines the Discovery T= ype 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 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 pa= rt 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 ha= s been
> configured with the AC address
> to which the correspo= nding Discovery Request message is sent.
>  0
> =  0 1 2 3 4 5 6 7
> +-+-+-+-+-+-+-+-+
>  | Discovery Type|
>&nbs= p; +-+-+-+-+-+-+-+-+
>
> Type: 58 for Discovery Type
&g= t;
>  Length: 1
> Discovery Type: An 8-bit value indi= cating WTP knowledge of the AC
> The following values are supported:
>  0 - Unknown=
> 1 -  Configured
>
> Comments please.
>=
> Thanks,
>
> Dorothy
>
Regards,
/david t. p= erkins



------=_Part_12581_22089746.1144787994403-- --===============1230297918== 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 --===============1230297918==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Apr 11 21:32:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTUE1-0007D5-K5 for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 21:32:53 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTUDz-00070S-Nu for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 21:32:53 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DCDE64300AE for ; Tue, 11 Apr 2006 18:32:50 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id DEAB4430063 for ; Tue, 11 Apr 2006 18:32:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C4A181448007 for ; Tue, 11 Apr 2006 18:32:12 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 52D881448012 for ; Tue, 11 Apr 2006 18:32:08 -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 k3C1W7DV029333; Wed, 12 Apr 2006 10:32:07 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k3C1W7i12618; Wed, 12 Apr 2006 10:32:07 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with SMTP id k3C1W7C00897; Wed, 12 Apr 2006 10:32:07 +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 - Issue on combiningmessages Date: Wed, 12 Apr 2006 09:30:27 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDCDBE1A@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages Thread-Index: AcZddxC5F6UCY5hyS5SboAy+j9CZEQAVmhdw From: "Saravanan Govindan" To: "Dorothy Stanley" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_60_70, HTML_MESSAGE, 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="===============0471288192==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: c25c25eef92c03b403abac6c7c688517 This is a multi-part message in MIME format. --===============0471288192== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65DD0.B172C685" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65DD0.B172C685 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dorothy, =20 WTP Event Request is being positioned for technology-specific statistics exchange (Section 2.1). So my understanding is that WTP Event Request would be used for information such as transmission attempts, beacon and probe counts, decryption errors etc.=20 =20 In addition to technology-specific information, the AC also needs big-picture information on factors affecting the WLAN as a whole. This would include WTP buffer levels, congestion conditions, etc. This information is not specific to a technology but does affect the WLAN. It is this type of statistics that I suggest the Echo Request exchange. =20 Cheers, Saravanan =20 =20 =20 =20 _____ =20 From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Tuesday, April 11, 2006 10:50 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages =20 Saravanan, Richard, First of all, thank you for your comments. Clearly, the WTP must have a means to provide statistics and other relevant data to the AC.. The question becomes, what specific mechanism should be used?=20 Overloading the echo request message is one way. CAPWAP has the WTP event request message, section 8.5, and already includes the decryption error report, and can include the .11 specific statistics report. Why is using the WTP event report to report statistics not sufficient? We should add other applicable CAPWAP message elements to be included in it. Thanks, Dorothy On 4/10/06, Saravanan Govindan wrote:=20 Hi Dorothy, =20 I think this recommendation add substantial value to the CAPWAP protocol. There have been discussions on the need for aggregating statistics information from the WTP to AC. The Echo Request offers a way for achieving this. The mechanisms for statistics exchanges - timer, periodic exchange - are available with Echo Request. So I think it is of value to keep Echo Request and add statistics information fields to it.=20 =20 Cheers, =20 Saravanan =20 =20 =20 _____ =20 From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Tuesday, April 11, 2006 1:20 AM To: capwap Subject: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages =20 All, 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.=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. Recommended resolution: reject the comment, with the explanation in the above paragraph Comments please. Thanks, Dorothy =20 ------_=_NextPart_001_01C65DD0.B172C685 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dorothy,

 

WTP Event Request is being positioned for technology-specific statistics exchange (Section 2.1). So my = understanding is that WTP Event Request would be used for information such as = transmission attempts, beacon and probe counts, decryption errors etc. =

 

In addition to technology-specific information, the = AC also needs big-picture information on factors affecting the WLAN as a whole. = This would include WTP buffer levels, congestion conditions, etc. This = information is not specific to a technology but does affect the WLAN. It is this = type of statistics that I suggest the Echo Request = exchange.

 

Cheers,


Saravanan

 

 

 

 

From: = Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Tuesday, April 11, = 2006 10:50 PM
To: Saravanan = Govindan
Cc: capwap
Subject: Re: [Capwap] = Proposed Resolution to Issue 45 - Issue on = combiningmessages

 

Saravanan, = Richard,

First of all, thank you for your comments.

Clearly, the WTP must have a means to provide statistics and other = relevant data to the AC..

The question becomes, what specific mechanism should be used?
Overloading the echo request message is one way. CAPWAP  has the = WTP event request message,
section 8.5, and already includes the decryption error report, and can = include the .11 specific
statistics report.

Why is using the WTP event report to report statistics not sufficient? = We should add other applicable CAPWAP message elements
to be included in it.

Thanks,

Dorothy

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

Hi Dorothy,

 

I think this recommendation add substantial value to the CAPWAP protocol. = There have been discussions on the need for aggregating statistics information = from the WTP to AC. The Echo Request offers a way for achieving this. The = mechanisms for statistics exchanges – timer, periodic exchange – are = available with Echo Request. So I think it is of value to keep Echo Request and = add statistics information fields to it.

 

Cheers,

 

Saravanan=

 

 

 

From: Dorothy Stanley = [mailto:dstanley1389@gmail.com]
Sent: Tuesday, April 11, = 2006 1:20 AM
To: capwap
Subject: [Capwap] = Proposed Resolution to Issue 45 - Issue on = combiningmessages

 

All,

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

Comments please.

Thanks,

Dorothy

 

------_=_NextPart_001_01C65DD0.B172C685-- --===============0471288192== 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 --===============0471288192==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Apr 11 22:11:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTUp8-0008W6-AY for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 22:11:14 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTUp5-00081b-RN for capwap-archive@lists.ietf.org; Tue, 11 Apr 2006 22:11:14 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D1B3143008C for ; Tue, 11 Apr 2006 19:11:10 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A1F2C430063 for ; Tue, 11 Apr 2006 19:10:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 95123398028 for ; Tue, 11 Apr 2006 19:10:24 -0700 (PDT) Received: from webmail.rp.edu.sg (webmail.rp.sg [202.21.158.83]) by zoidberg.tigertech.net (Postfix) with ESMTP id 58167398018 for ; Tue, 11 Apr 2006 19:10:17 -0700 (PDT) Received: from staff-mail.rp.edu.sg ([202.21.158.80]) by webmail.rp.edu.sg with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Apr 2006 10:10:16 +0800 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Importance: normal Priority: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages Date: Wed, 12 Apr 2006 10:10:12 +0800 Message-ID: <9C374CF75527504394E573E1937136C402C7A277@staff-mail.rp.edu.sg> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages thread-index: AcZde6HKvz3JofLRSQanAwqFa+vglgAWYSIg From: "Richard Gwee" To: "Dorothy Stanley" X-OriginalArrivalTime: 12 Apr 2006 02:10:16.0060 (UTC) FILETIME=[3D5E1BC0:01C65DD6] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.542 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO, HTML_60_70, HTML_MESSAGE, HTML_TAG_EXIST_TBODY, HTML_TEXT_AFTER_BODY, 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="===============0081318662==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: efecd979fb9d15792ac142aa0178058d This is a multi-part message in MIME format. --===============0081318662== Content-Transfer-Encoding: 7bit Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65DD6.3C16DB8D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65DD6.3C16DB8D X-EC0D2A8E-5CB7-4969-9C36-46D859D137BE-PartID: 5ACCAB9E-62EF-4793-8973-83F47119BDA2 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Dorothy, =20 Thanks for the email. I will like to propose the following message elements=20 =20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+ | Network Congestion | Traffic Loading | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+ | Channel interferences | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 As mentioned before, these message elements can be loaded onto the Echo messages. =20 Regards Richard =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Tuesday, April 11, 2006 11:22 PM To: Richard Gwee Cc: capwap Subject: Re: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages =20 Hello Richard, Is the statistics message element that the presentation refers to a new message element, or one/part of one that is already defined? - The CAPWAP Protocol needs regular Statistics exchange - Statistics should be applicable to the overall network, e.g. congestion, traffic loading,channel interferences -Size of statistics element 4-8 bytes If it is a new message element, then we need to agree on the contents of that element, and then the means of its transport. Thanks, Dorothy On 4/10/06, Richard Gwee wrote: Hi Dorothy, =20 I believe that I have mentioned this point during my presentation in the last IETF meeting. While combining messages does reduce overhead significantly (as shown in my powerpoint presentation slides), we should also look at another benefit of combining the keepalive and statistics messages. As I have highlighted before, there is no statistics for the whole WLAN in the CAPWAP protocol. We need to include this in and I feel that putting this statistics element in the Echo Request message is the best bet. While I understand your concern for keeping the echo messages simple, I cannot visualize how much more complicated it can be if we just combine statistics for our keepalive mechanism. =20 Appreciate any comments. =20 Thanks & Regards Richard Gwee =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Tuesday, April 11, 2006 1:20 AM To: capwap Subject: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages =20 All, 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.=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. Recommended resolution: reject the comment, with the explanation in the above paragraph Comments please. Thanks, Dorothy ________________________________ Republic Polytechnic, 9 Woodlands Avenue 9, Singapore 738964 (Near Woodlands MRT/Interchange) . www.rp.sg . Fax: +65 6415-1310 .=20 Republic Polytechnic, the first Institute of Higher Learning to fully adopt the Problem-Based Learning approach in Singapore, continues to strive towards best practices and maintain excellence in service standards with the following certifications: Singapore Innovation Class (SIC), Singapore Quality Class (SQC), People Developer Standards and QEHS (ISO 9001, 14001 and OHSAS 18001) ________________________________ CONFIDENTIALITY CAUTION: This message is intended only for the use of the individual or entity to whom it is addressed and contains information that is privileged and confidential. If you, the reader of this message, are not the intended recipient, you should not disseminate, distribute or copy this communication. If you have received this communication in error, please notify us immediately by return email and delete the original message. Thank you.=20 =20 ------_=_NextPart_001_01C65DD6.3C16DB8D X-EC0D2A8E-5CB7-4969-9C36-46D859D137BE-PartID: 87F65D22-1ADF-4FD1-92C9-921193531095 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Dorothy,

 

Thanks for the email. I will like = to propose the following message elements

 

 0 1 2 3 4 5 6 7 8 9 10 11 12 = 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Network = Congestion          &nb= sp;           =   |  Traffic Loading   =             &= nbsp;           &n= bsp;           &nb= sp;      |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Channel interferences          =             = |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +

 

As mentioned before, these message elements can be loaded onto the Echo messages.

 

Regards

Richard 

From: Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Tuesday, April 11, = 2006 11:22 PM
To: Richard Gwee
Cc: capwap
Subject: Re: [Capwap] = Proposed Resolution to Issue 45 - Issue on combiningmessages

 

Hello = Richard,

Is the statistics message element that the
presentation refers to a new message element, or one/part of one that is already defined?

- The CAPWAP Protocol needs regular Statistics exchange
- Statistics should be applicable to the overall network, e.g. = congestion, traffic loading,channel interferences
-Size of statistics element  4-8 bytes

If it is a new message element, then we need to agree on the
contents of that element, and then the means of its transport.

Thanks,

Dorothy

On 4/10/06, = Richard Gwee <richard_gwee@rp.sg> wrote:

Hi Dorothy,

 

I believe that I have mentioned this point during my presentation in the last IETF meeting. While combining messages does = reduce overhead significantly (as shown in my powerpoint presentation slides), = we should also look at another benefit of combining the keepalive and = statistics messages. As I have highlighted before, there is no statistics for the = whole WLAN in the CAPWAP protocol. We need to include this in and I feel that = putting this statistics element in the Echo Request message is the best bet. = While I understand your concern for keeping the echo messages simple, I cannot visualize how much more complicated it can be if we just combine = statistics for our keepalive mechanism.

 

Appreciate any comments.

 

Thanks & Regards

Richard Gwee

 

From: = Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Tuesday, April 11, = 2006 1:20 AM
To: capwap
Subject: [Capwap] = Proposed Resolution to Issue 45 - Issue on combiningmessages

 

All,

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

Comments please.

Thanks,

Dorothy

Republic Polytechnic, 9 = Woodlands Avenue 9, Singapore 738964 (Near Woodlands MRT/Interchange)
. www.rp.sg= . Fax: +65 6415-1310 .

Republic Polytechnic, the first Institute of Higher Learning to fully adopt the Problem-Based Learning approach in Singapore, continues to strive = towards best practices and maintain excellence in service standards with the following certifications: Singapore Innovation Class (SIC), Singapore = Quality Class (SQC), People Developer Standards and QEHS (ISO 9001, 14001 and = OHSAS 18001)

CONFIDENTIALITY CAUTION: This message is intended = only for the use of the individual or entity to whom it is addressed and = contains information that is privileged and confidential. If you, the reader of = this message, are not the intended recipient, you should not disseminate, distribute or copy this communication. If you have received this = communication in error, please notify us immediately by return email and delete the original message. Thank you.

 

Republic Polytechnic, 9 Woodlands = Avenue 9, Singapore 738964 (Near = Woodlands MRT/Interchange)
. www.rp.sg . Fax: +65 6415-1310 .

Republic Polytechnic, = the first Institute of Higher Learning to fully adopt the Problem-Based = Learning approach in Singapore, continues to strive towards best = practices and maintain excellence in service standards with the = following certifications: Singapore Innovation Class (SIC), Singapore = Quality Class (SQC), People Developer Standards and QEHS (ISO 9001, = 14001 and OHSAS 18001)

CONFIDENTIALITY CAUTION: = This message is intended only for the use of the individual or entity to = whom it is addressed and contains information that is privileged and = confidential. If you, the reader of this message, are not the intended = recipient, you should not disseminate, distribute or copy this = communication. If you have received this communication in error, please = notify us immediately by return email and delete the original message. = Thank you.
------_=_NextPart_001_01C65DD6.3C16DB8D-- --===============0081318662== 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 --===============0081318662==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Apr 12 01:37:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTY2J-0000Jm-QL for capwap-archive@lists.ietf.org; Wed, 12 Apr 2006 01:37:03 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTY2H-000706-9J for capwap-archive@lists.ietf.org; Wed, 12 Apr 2006 01:37:03 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CC8924300DA for ; Tue, 11 Apr 2006 22:37:00 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 59BBA43005A for ; Tue, 11 Apr 2006 22:36:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2E8801448011 for ; Tue, 11 Apr 2006 22:36:40 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 93E83144800C for ; Tue, 11 Apr 2006 22:36:38 -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 k3C5aXTm002630; Tue, 11 Apr 2006 22:36:33 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k3C5aWan002626; Tue, 11 Apr 2006 22:36:32 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 11 Apr 2006 22:36:32 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Dorothy Stanley Subject: Re: [Capwap] Proposed Resolution for Issue 58 - Need to rename Config Request and Config Update Request In-Reply-To: <5bfe7a820604101051s3c1b3060rd7761b985044f93f@mail.gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new-20030616-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: 2857c5c041d6c02d7181d602c22822c8 HI, I believe that the current config model is broken due to the following: 1) Config changes can fail (even when they are "not suppose to"). This may be due to a) resource deletion b) semantic constraints c) hardware failures d) software failures e) lack of authorization In the "configure request/response" (sections 7.2/7.3) , the "response" message specifies configuration settings. As described, there is no mechanism for the WTP to communicate to the AC that some (or part) of the config sent by the AC to WTP failed. Thus, I suggest that the response contain no configuration. 2) I'm not sure that all of the configuration info can fit into one CAPWAP control message. However, a WTP needs to be able to indicate to a AC the "classes" of config info that it supports. SNMP uses the GETNEXT operation to iterate through both all classes and instances of management info (which includes config info). I suggest for CAPWAP that a WTP specify in the "configure request" the classes of configuration info and then allow an AC to use one or more "Update config request" messages to change the WTP config. 3) When an AC changes the WTP config with an "Update config request", the request can fail. The response message needs to indicate which config message element(s) had an error and what was the error. Currently, this is not the case. (The error code in the result, as currently defined makes no sense to me!) Also, I didn't see if a config request was "all or nothing". That is, do the OK config values get applied and the error one not, or none get applied on any failure. 4) There are a lot of stange (too me) and not well defined config elements. I believe that all need to be reviewed, but this is really a separate issue. 5) A get config operation is needed that specifies at least a class of configuration info, and possibly additionally the instance of config info. (Again, this is because not all config info will be able to fit in a single CAPWAP message.) 6) I've ignored what should be done when an WTP has config info that is not supported by an AC, or when an AC tries to modify config info (class or specific values) that is not supported by the WTP. (CAPWAP is suppose to support WTPs and ACs from different vendors, and, thus, there can be no "tight version synchonization" as found in current products. On Mon, 10 Apr 2006, Dorothy Stanley wrote: > All, > > Issue 58 currently has the following discussion in the issues list: > > > > > Page 104, Section 11.8.1. The description for Config-Request > > describes a message sent from the AC to the WTP. In Section > > 7.2, the config request is sent from the AP to the WTP. I > > would prefer the mechanism described in 11.8.1. > > 40. > > There are two types of configuration messages, one that comes from > the WTP to the AC, and is used for the WTP to update the AC with its > config at boot time. The second allows the AC to push down a new > config to the WTP, and this can occur at run time. The former is > called the Configure Request, while the latter is called the Configuration > update Request. That said, I think we should come up with a different > set of names to differentiate them better. > > > In the Configure State, we currently have: > Configure Request - WTP sends AC its boot-time config > Configure Response - AC overrides the current WTP boot-time config > > In the Run state, we currently have > Configure Update Request - AC sends WTP new config parameters > Configure Update Response - WTP acknowledges the Configure Update Request, > includes result code > IEEE 802.11 WLAN Config Request > > Recommended resolution: Accept, make the following changes: > > In the Configure State, rename to > Configuration Status - WTP sends AC its boot-time config > Configuration Status Response - AC overrides the current WTP boot-time > config > > In the Run state, - keep > Configure Update Request - AC sends WTP new config parameters > Configure Update Response - WTP acknowledges the Configure Update Request, > includes result code, and in > IEEE 802.11 WLAN Config Request, update the text in 11.8.1 to reference > usage after Configure Update Request > > Comments please. > > Thanks, > > Dorothy > Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Apr 12 02:09:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTYY4-0005eN-4b for capwap-archive@lists.ietf.org; Wed, 12 Apr 2006 02:09: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 1FTXmP-0006IB-5h for capwap-archive@lists.ietf.org; Wed, 12 Apr 2006 01:20:37 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FTXZG-0007XU-U6 for capwap-archive@lists.ietf.org; Wed, 12 Apr 2006 01:07:08 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A0A66430109 for ; Tue, 11 Apr 2006 22:07:01 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1F53C430073 for ; Tue, 11 Apr 2006 22:06:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0B1AD398012 for ; Tue, 11 Apr 2006 22:06:35 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 33BE939800B for ; Tue, 11 Apr 2006 22:06:33 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k3C56IRg027884; Tue, 11 Apr 2006 22:06:18 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k3C56IPT027879; Tue, 11 Apr 2006 22:06:18 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 11 Apr 2006 22:06:17 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Dorothy Stanley Subject: Re: [Capwap] Proposed Resolution for Issue 46 - WTP Model and Serial number In-Reply-To: <5bfe7a820604101320i7df4e81cyf56b518ba3a95d19@mail.gmail.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 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: 6907f330301e69261fa73bed91449a20 HI, I believe that both the "WTP descriptor" (section 5.1.2) and the "WTP Board data" (section 7.2.4) message elements need work. Previous work has been done that covers both of these elements is in RFC 4133, which contains the Entity MIB module. In it, there are the following definitions which come close the the info in the "WTP descriptor" and "WTP board date" message elements: entPhysicalIndex - index of physical component (an integer) entPhysicalVendorType - hardware type, value is an OID entPhysicalHardwareRev - hardware revision, value encoded in UTF-8 (max length of 255 octets) entPhysicalFirmwareRev - firmware revision, (value encoded same as hardware rev) entPhysicalSoftwareRev - software revision, (value encoded same as hardware rev) entPhysicalSerialNum - serial number,- value encoded in UTF-8 (max length of 32 octets) entPhysicalMfgName - manufacturer name, (value encoded same as hardware rev) entPhysicalModelName - model name, (value encoded same as hardware rev) The entity MIB module allows all of the physical commponents of a device to be described. I can't determine when reading section 7.2 (and section 7.2.4) whether or not multiple "WTP board data" message elements are returned. It's certainly the case that a majority of current WTPs are "nonmodular", but there may be ones that have "field replacable units" for radios or other components. Thus, I suggest that multiple "board data" message elements be returnable. In addition the Entity MIB has the following definitions which I suggest be supported by CAPWAP message "board data" message element: entPhysicalAssetID - asset ID, (value encoded same as serial number) entPhysicalMfgDate - manufacture date, a date/time value encoded in format defined by TC DateAndTime found in RFC 2579 entPhysicalIsFRU - indication if component is a field replacable unit entPhysicalUris - a list of URIs (the intent is to support CLEI codes, see RFC 4152) The Entity MIB also has the following definitions, which I suggest are not too useful: entPhysicalDescr - textual description of the component (its redundant with manufacturer and model name) entPhysicalContainedIn - info on physical containment (WTPs don't have complex physical relationships of components) entPhysicalParentRelPos - info on physical arrangement (WTPs don't have complex physical relationships of components) entPhysicalClass - class of physical component (WTPs will not have different classes) entPhysicalName - name used in CLI commands (not needed by CAPWAP) entPhysicalAlias - an operator specified alternative name (not needed by CAPWAP) Thus, I suggest that the "WTP info" and the "WTP Board data" message elements be change to the following to align with the data model defined in the Entity MIB module: WTP Info would have the following fields: 1) manufacturer name (encoded in UTF-8, max length 255 octets) 2) model name (same encoding as mgt name) 3) serial number (encoded in UTF-8, max length of 32 octets) 4) optional hardware rev (same encoding as mgt name) 5) optional manufacturing date (encoded in text, not binary as defined in DateTime TC) 6) optional firmware rev (note: this is NOT the image rev) (same encoding as mgt name) 7) optional asset ID (encoded the same as serial number) 8) boot software version (same encoding as mgt name) 9) list of images, with fields: a) is running - flag b) source - memory, store1, store2, etc c) version (same encoding as mgt name) 10) Number of radios "Board data" would be renamed "component data" and would only be returned if the WTP contained separatably identifiable components. It would have only fields 1 through 6 of WTP info, plus a "isFRU" field. More on this later in the "boot model" description. On Mon, 10 Apr 2006, Dorothy Stanley wrote: > All, > > Issue 46 - WTP Model and Serial number currently has the following > discussion in the issues list: > > The length of wtpModel in Section 7.2.4 is specified as 8 bytes. I think this > space could be small for some model types. > > Same way, 24 bytes WTP Serial Number could be small depending upon how serial > > number is assigned. > > > Section 7.2.4, WTP Board Data > > The WTP model and serial number value lengths will vary with product and > vendor, and are likely > to have a wide range of lengths. The current spec fixes the lengths at > model number - 8 bytes, and the serial number at 24 bytes. The comment is > that these fixed lengths > are likely to be too small for some vendors. > > We could increase the fixed values, with the risk that the values we select > will not serve some vendor, or make > them excessively long to meet all needs. > Another approach is to give the model and serial number a type/length value > structure, including a vendor identifier, and > allow a variety of lengths. > > Additional comments on other WTP Board data fields: > Need more explicit definition for Card ID and Card Revision values. For > some vendors, these are not applicable. > If not generally applicable, leave as vendor specific. Indicated these as > optional to include, renaming to "board" from "card" > to be consistent with the message element name. Can open a new issue for > this if needed. > . > WTP Board Data also includes the Ethernet MAC address. Why is the layer 2 > MAC address needed? Recommend > removing the Ethernet MAC address field from the WTP Board Data message > element (similar to AC MAC address > in Issue 39) > > Recommendation: Change WTP Board Data definition from: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Card ID | Card > Revision | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | WTP Model > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | WTP Model > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | WTP Serial > Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | WTP Serial > Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| > | WTP Serial > Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | WTP Serial > Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | WTP Serial > Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | WTP Serial > Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | Ethernet MAC Address > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ethernet MAC Address| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++++ > > Type: 50 for WTP Board Data > Length: 26 > Card ID: A 2 byte hardware identifier. > Card Revision: A 2 byte Revision of the card. > WTP Model: 8 byte WTP Model Number. > WTP Serial Number: 24 byte WTP Serial Number. > Ethernet MAC Address: MAC Address of the WTP's Ethernet interface. > > to > > 0 1 2 > 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > | Vendor Identifier > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type=0 | > Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > | Value..... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > | Type=1 | > Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value.... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ > | Optional additional vendor specific WTP board data TLVs > > > Type: 50 for WTP Board Data > Length: >= 3 > Vendor Identifier: A 32-bit value containing the IANA assigned "SMI Network > Management Private Enterprise Codes" > Type: The following values are supported > 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 message element. > 3 - Board Revision, A revision number of the board, which MAY be included in > the WTP Board Data message element. > > Length: The length of the value field > > Value: The value of the indicated field. > > The Vendor Identifier, WTP Model Number and WTP Serial Number are optionally > followed by additional > vendor specific values. > > Comments please. > > Thanks, > > Dorothy > Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Apr 12 11:00:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTgpX-00045l-2T for capwap-archive@lists.ietf.org; Wed, 12 Apr 2006 11:00:27 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTgpV-0000NN-2i for capwap-archive@lists.ietf.org; Wed, 12 Apr 2006 11:00:27 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2F56D4300D7 for ; Wed, 12 Apr 2006 08:00:24 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D6D5343005A for ; Wed, 12 Apr 2006 07:59:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BE6B8431151 for ; Wed, 12 Apr 2006 07:59:45 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.198]) by hermes.tigertech.net (Postfix) with ESMTP id A1A9543114D for ; Wed, 12 Apr 2006 07:59:44 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so987234wxd for ; Wed, 12 Apr 2006 07:59:43 -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=FlGpAlXvQIzehqB7x/5/4kTvAb3Q8lCIQOgVLc0P5CTzuJSJvEg1FK07aVQad/dVlFB93EaKnDt4wZXxUv2cu0BzsykVmzCeZYrXeunPCmQEo6OnCmoDue9TYeuAnV+YzkwN8uUhmywjutAKgfjUnVw5Df59uSxQdiuHj1Mxvp8= Received: by 10.70.42.13 with SMTP id p13mr4983616wxp; Wed, 12 Apr 2006 07:59:43 -0700 (PDT) Received: by 10.70.133.14 with HTTP; Wed, 12 Apr 2006 07:59:43 -0700 (PDT) Message-ID: <5bfe7a820604120759s3dde2f68l7d777f7975a9fc2a@mail.gmail.com> Date: Wed, 12 Apr 2006 07:59:43 -0700 From: "Dorothy Stanley" To: "Saravanan Govindan" Subject: Re: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages In-Reply-To: <5F09D220B62F79418461A978CA0921BDCDBE1A@pslexc01.psl.local> MIME-Version: 1.0 References: <5F09D220B62F79418461A978CA0921BDCDBE1A@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_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="===============0823545884==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.7 (/) X-Scan-Signature: 578029c71870398e30dc7af6a1ae528d --===============0823545884== Content-Type: multipart/alternative; boundary="----=_Part_3495_26429231.1144853983726" ------=_Part_3495_26429231.1144853983726 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Saravanan, Richard, I suggest we set aside the question of how the statistics might be transported for the moment - either in WTP Event Request, Echo Request or some new message, and first agree on the nature/definition of the statistics themselves. We are talking about non-802.11 specific statistics, as the 802.11 specific ones, or new 802.11 ones would go in 11.7.2.1: WPT buffer levels - which buffers? Concern that this would be implementatio= n specific Congestion conditions - congestion on the wireless link? On the WTP to AC link? etc - needs to be specified. Richard suggests Network Congestion - which network, the wireless one or the WTP to AC link. How is the level of congestion measured? Traffic Loading - How is this measured? Which traffic? Channel Interferences - Need to specify. Concern that there is overlap with what will be coming in .11k for radio measurement Thanks, Dorothy On 4/11/06, Saravanan Govindan wrote: > > Hi Dorothy, > > > > WTP Event Request is being positioned for technology-specific statistics > exchange (Section 2.1). So my understanding is that WTP Event Request > would be used for information such as transmission attempts, beacon and > probe counts, decryption errors etc. > > > > In addition to technology-specific information, the AC also needs > big-picture information on factors affecting the WLAN as a whole. This wo= uld > include WTP buffer levels, congestion conditions, etc. This information i= s > not specific to a technology but does affect the WLAN. It is this type of > statistics that I suggest the Echo Request exchange. > > > > Cheers, > > > Saravanan > > > > > > > > > ------------------------------ > > *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] > *Sent:* Tuesday, April 11, 2006 10:50 PM > *To:* Saravanan Govindan > *Cc:* capwap > *Subject:* Re: [Capwap] Proposed Resolution to Issue 45 - Issue on > combiningmessages > > > > Saravanan, Richard, > > First of all, thank you for your comments. > > Clearly, the WTP must have a means to provide statistics and other > relevant data to the AC.. > > The question becomes, what specific mechanism should be used? > Overloading the echo request message is one way. CAPWAP has the WTP even= t > request message, > section 8.5, and already includes the decryption error report, and can > include the .11 specific > statistics report. > > Why is using the WTP event report to report statistics not sufficient? We > should add other applicable CAPWAP message elements > to be included in it. > > Thanks, > > Dorothy > > On 4/10/06, *Saravanan Govindan* > wrote: > > Hi Dorothy, > > > > I think this recommendation add substantial value to the CAPWAP protocol. > There have been discussions on the need for aggregating statistics > information from the WTP to AC. The Echo Request offers a way for achievi= ng > this. The mechanisms for statistics exchanges =96 timer, periodic exchang= e =96 > are available with Echo Request. So I think it is of value to keep Echo > Request and add statistics information fields to it. > > > > Cheers, > > > > Saravanan > > > > > > > ------------------------------ > > *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] > *Sent:* Tuesday, April 11, 2006 1:20 AM > *To:* capwap > *Subject:* [Capwap] Proposed Resolution to Issue 45 - Issue on > combiningmessages > > > > All, > > 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 > > Comments please. > > Thanks, > > Dorothy > > > ------=_Part_3495_26429231.1144853983726 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Saravanan, Richard,

I suggest we set aside the question of how the statistics might be  transported for the moment - either in WTP Event Request, Echo Request or some new
message, and first agree on the nature/definition of the statistics themselves. We are talking about non-802.11 specific statistics, as the 802.11
specific ones, or new 802.11 ones would go in 1= 1.7.2.1:

WPT buffer levels - which buffers? Concern that this would be implementatio= n specific
Congestion conditions - congestion on the wireless link? On the WTP to AC l= ink?
etc - needs to be specified.

Richard suggests
Network Congestion - which network, the wireless one or the WTP to AC link.= How is the level of congestion measured?
Traffic Loading - How is this measured? Which traffic?
Channel Interferences - Need to specify. Concern that there is overlap with= what will be coming in .11k for radio measurement

Thanks,

Dorothy
On 4/11/06, Saravanan Govindan <Saravanan.Govindan@sg.panasonic.com> wrote:=

Hi Dorothy,

 

WTP Event Request is being positioned for technology-specific statistics exchange (Section 2.1). So my understanding = is that WTP Event Request would be used for information such as transmission attempts, beacon and probe counts, decryption errors etc.

 

In addition to technology-specific information, the AC also needs big-picture information on factors affecting the WLAN as a whole. Thi= s would include WTP buffer levels, congestion conditions, etc. This informati= on is not specific to a technology but does affect the WLAN. It is this type o= f statistics that I suggest the Echo Request exchange.

 

Cheers,


Saravanan

 

 

 

 

 

Thanks,

Dorothy

Hi Dorothy,

 

I think this recommendation add substantial value to the CAPWAP protocol. The= re have been discussions on the need for aggregating statistics information fr= om the WTP to AC. The Echo Request offers a way for achieving this. The mechan= isms for statistics exchanges =96 timer, periodic exchange =96 are available with Echo Request. So I think it is of value to keep Echo Request and add statistics information fields to it.

 

Cheers,

 

Saravanan

 

 

 

From: Do= rothy Stanley [mailto: dstanley1389@gmail.com]
Sent: Tuesday, April 11, 2= 006 1:20 AM
To: capwap
Subject: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages

 

All,

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 <=
br>


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





Initial analysis have shown that thes=
e overhead can be reduced significantly 





if the messages can be com=
bined.









Recommen=
dation:








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



thus reducing overhead sign=
ificantly.


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

Comments please.

Thanks,

Dorothy

 


------=_Part_3495_26429231.1144853983726-- --===============0823545884== 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 --===============0823545884==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Apr 12 11:42:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FThTl-0007xN-Vw for capwap-archive@lists.ietf.org; Wed, 12 Apr 2006 11:42:01 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FThTk-0002Oc-H3 for capwap-archive@lists.ietf.org; Wed, 12 Apr 2006 11:42:01 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B33E24300E0 for ; Wed, 12 Apr 2006 08:41:59 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 805D443005A for ; Wed, 12 Apr 2006 08:41:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 741AF398048 for ; Wed, 12 Apr 2006 08:41:40 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 98E0A398044 for ; Wed, 12 Apr 2006 08:41:38 -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 k3CFfb58028898; Wed, 12 Apr 2006 08:41:37 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k3CFfbOa028891; Wed, 12 Apr 2006 08:41:37 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 12 Apr 2006 08:41:37 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Dorothy Stanley Subject: Re: [Capwap] New Issue - Local MAC MUST vs MAY forward association request messages In-Reply-To: <5bfe7a820604111140m201774cep4474fc4f374b29a7@mail.gmail.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 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: 0a7aa2e6e558383d84476dc338324fab HI, In a CAPWAP environment, irregardless of 802.11 association, the AC determines the 1) authentication 2) authorization and provides the management interface for tracking client 1) status 2) statistics And overal system optimization. The above attributes differentiates a coordniated collection of independent APs from a CAPWAP system consisting of a AC and WTPs. So, if changing to MAY does not result in loss of control needed to support any of the above attributes, then the change would be OK. Otherwise, I don't believe it would be a proper change. On Tue, 11 Apr 2006, Dorothy Stanley wrote: > All, > > Section 11.1.2 Local MAC describes the Local MAC operation. It currently > states > (second paragraph below Figure 6): > > While the MAC is terminated on the WTP, it is necessary for the AC to be > aware of mobility events within the WTPs. > As a consequence, the WTP MUST forward the IEEE 802.11 Association Requests > to the AC, and the AC MAY reply > with a failed Association Response if it deems it necessary. > > > Since this is the Local MAC case, it seems that a MAY should be > sufficient. > > Recommended change: > > The MAC is terminated on the WTP, but the AC may need to be aware of > mobility events within the WTPs. > As a consequence, the WTP MAY forward the IEEE 802.11 Association Requests > to the AC, and the AC MAY reply > with a failed Association Response. > > Comments? > > Thanks, > > Dorothy Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Apr 12 22:55:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTrzH-0006ic-7f for capwap-archive@lists.ietf.org; Wed, 12 Apr 2006 22:55:15 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTrzD-0002Fy-KY for capwap-archive@lists.ietf.org; Wed, 12 Apr 2006 22:55:15 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8FC8E4300C9 for ; Wed, 12 Apr 2006 19:55:10 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1C21243006C for ; Wed, 12 Apr 2006 19:54:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0346B39802E for ; Wed, 12 Apr 2006 19:54:25 -0700 (PDT) Received: from webmail.rp.edu.sg (webmail.rp.sg [202.21.158.83]) by zoidberg.tigertech.net (Postfix) with ESMTP id 223DF39802A for ; Wed, 12 Apr 2006 19:54:20 -0700 (PDT) Received: from staff-mail.rp.edu.sg ([202.21.158.80]) by webmail.rp.edu.sg with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Apr 2006 10:54:18 +0800 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] Proposed Resolution to Issue 45 - Issue oncombiningmessages Date: Thu, 13 Apr 2006 10:54:16 +0800 Message-ID: <9C374CF75527504394E573E1937136C402CAF23D@staff-mail.rp.edu.sg> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 45 - Issue oncombiningmessages thread-index: AcZeQeYs0MKqzTmeThqhR0+uQxpzHwAX91ZQ From: "Richard Gwee" To: "Dorothy Stanley" , "Saravanan Govindan" X-OriginalArrivalTime: 13 Apr 2006 02:54:18.0256 (UTC) FILETIME=[8EA6F900:01C65EA5] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.542 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO, HTML_60_70, HTML_MESSAGE, HTML_TAG_EXIST_TBODY, HTML_TEXT_AFTER_BODY, 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="===============1919601782==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 88e8087d1b20b7fe0211e68acd23c714 This is a multi-part message in MIME format. --===============1919601782== Content-Transfer-Encoding: 7bit Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65EA5.8D380FF5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65EA5.8D380FF5 X-EC0D2A8E-5CB7-4969-9C36-46D859D137BE-PartID: 55AA2C78-AB93-4341-96E1-8335B629CDC1 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Dorothy, =20 For network congestion, we should consider the wireless aspect. The metric to be used is frame loss at the WTP end due to channel interference. =20 For traffic loading, the metric to be used is volume of data traffic in both uplink and downlink through the WTP. =20 For channel interference, 802.11k is technology-specific and we should consider general statistics independent of technologies. I will suggest the metric to be used is number of retransmission attempts which can be used to infer the level of channel interference. =20 Appreciate your comments. =20 Thanks and Regards Richard =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Wednesday, April 12, 2006 11:00 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Proposed Resolution to Issue 45 - Issue oncombiningmessages =20 Saravanan, Richard, I suggest we set aside the question of how the statistics might be transported for the moment - either in WTP Event Request, Echo Request or some new message, and first agree on the nature/definition of the statistics themselves. We are talking about non-802.11 specific statistics, as the 802.11 specific ones, or new 802.11 ones would go in 11.7.2.1: WPT buffer levels - which buffers? Concern that this would be implementation specific Congestion conditions - congestion on the wireless link? On the WTP to AC link? etc - needs to be specified. Richard suggests Network Congestion - which network, the wireless one or the WTP to AC link. How is the level of congestion measured? Traffic Loading - How is this measured? Which traffic?=20 Channel Interferences - Need to specify. Concern that there is overlap with what will be coming in .11k for radio measurement Thanks, Dorothy On 4/11/06, Saravanan Govindan wrote: Hi Dorothy, =20 WTP Event Request is being positioned for technology-specific statistics exchange (Section 2.1). So my understanding is that WTP Event Request would be used for information such as transmission attempts, beacon and probe counts, decryption errors etc.=20 =20 In addition to technology-specific information, the AC also needs big-picture information on factors affecting the WLAN as a whole. This would include WTP buffer levels, congestion conditions, etc. This information is not specific to a technology but does affect the WLAN. It is this type of statistics that I suggest the Echo Request exchange. =20 Cheers, Saravanan =20 =20 =20 =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Tuesday, April 11, 2006 10:50 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages =20 Saravanan, Richard,=20 First of all, thank you for your comments. Clearly, the WTP must have a means to provide statistics and other relevant data to the AC.. The question becomes, what specific mechanism should be used?=20 Overloading the echo request message is one way. CAPWAP has the WTP event request message, section 8.5, and already includes the decryption error report, and can include the .11 specific statistics report. Why is using the WTP event report to report statistics not sufficient? We should add other applicable CAPWAP message elements to be included in it. Thanks, Dorothy On 4/10/06, Saravanan Govindan wrote:=20 Hi Dorothy, =20 I think this recommendation add substantial value to the CAPWAP protocol. There have been discussions on the need for aggregating statistics information from the WTP to AC. The Echo Request offers a way for achieving this. The mechanisms for statistics exchanges - timer, periodic exchange - are available with Echo Request. So I think it is of value to keep Echo Request and add statistics information fields to it.=20 =20 Cheers, =20 Saravanan =20 =20 =20 ________________________________ From: Dorothy Stanley [mailto: dstanley1389@gmail.com]=20 Sent: Tuesday, April 11, 2006 1:20 AM To: capwap Subject: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages =20 All, 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.=20 Initial analysis have shown that these overhead can be reduced significantly=20 =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. Recommended resolution: reject the comment, with the explanation in the above paragraph Comments please. Thanks, Dorothy =20 =20 Republic Polytechnic, 9 Woodlands Avenue 9, Singapore 738964 (Near = Woodlands MRT/Interchange) . www.rp.sg . Fax: +65 6415-1310 .=20 Republic Polytechnic, the first Institute of Higher Learning to fully = adopt the Problem-Based Learning approach in Singapore, continues to = strive towards best practices and maintain excellence in service = standards with the following certifications: Singapore Innovation Class = (SIC), Singapore Quality Class (SQC), People Developer Standards and = QEHS (ISO 9001, 14001 and OHSAS 18001) -------------------------------------------------------------------------= ------- CONFIDENTIALITY CAUTION: This message is intended only for the use of = the individual or entity to whom it is addressed and contains = information that is privileged and confidential. If you, the reader of = this message, are not the intended recipient, you should not = disseminate, distribute or copy this communication. If you have received = this communication in error, please notify us immediately by return = email and delete the original message. Thank you. =20 ------_=_NextPart_001_01C65EA5.8D380FF5 X-EC0D2A8E-5CB7-4969-9C36-46D859D137BE-PartID: 8FB3DFA6-E119-4055-8BB6-ECE5B58453B7 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Dorothy,

 

For network congestion, we should = consider the wireless aspect. The metric to be used is frame loss at the WTP end = due to channel interference.

 

For traffic loading, the metric to = be used is volume of data traffic in both uplink and downlink through the = WTP.

 

For channel interference, 802.11k = is technology-specific and we should consider general statistics = independent of technologies. I will suggest the metric to be used is number of = retransmission attempts which can be used to infer the level of channel = interference.

 

Appreciate your = comments.

 

Thanks and = Regards

Richard

 

From: Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Wednesday, April = 12, 2006 11:00 PM
To: Saravanan = Govindan
Cc: capwap
Subject: Re: [Capwap] = Proposed Resolution to Issue 45 - Issue oncombiningmessages

 

Saravanan, Richard,

I suggest we set aside the question of how the statistics might be  transported for the moment - either in WTP Event Request, Echo Request = or some new
message, and first agree on the nature/definition of the statistics = themselves. We are talking about non-802.11 specific statistics, as the 802.11
specific ones, or new 802.11 ones would go in 11.7.2.1:

WPT buffer levels - which buffers? Concern that this would be = implementation specific
Congestion conditions - congestion on the wireless link? On the WTP to = AC link?
etc - needs to be specified.

Richard suggests
Network Congestion - which network, the wireless one or the WTP to AC = link. How is the level of congestion measured?
Traffic Loading - How is this measured? Which traffic?
Channel Interferences - Need to specify. Concern that there is overlap = with what will be coming in .11k for radio measurement

Thanks,

Dorothy

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

Hi Dorothy,

 

WTP Event Request is being positioned for technology-specific statistics = exchange (Section 2.1). So my understanding is that WTP Event Request would be = used for information such as transmission attempts, beacon and probe counts, = decryption errors etc.

 

In addition to technology-specific information, the AC also needs = big-picture information on factors affecting the WLAN as a whole. This would include = WTP buffer levels, congestion conditions, etc. This information is not = specific to a technology but does affect the WLAN. It is this type of statistics = that I suggest the Echo Request exchange.

 

Cheers,


Saravanan

 

 

 

 

From: = Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Tuesday, April 11, = 2006 10:50 PM
To: Saravanan = Govindan
Cc: capwap
Subject: Re: [Capwap] = Proposed Resolution to Issue 45 - Issue on combiningmessages

 

Saravanan, Richard,

First of all, thank you for your comments.

Clearly, the WTP must have a means to provide statistics = and other relevant data to the AC..

The question becomes, what specific mechanism should be = used?
Overloading the echo request message is one way. = CAPWAP  has the WTP event request message,
section 8.5, and already includes the decryption error = report, and can include the .11 specific
statistics report.

Why is using the WTP event report to report statistics = not sufficient? We should add other applicable CAPWAP message = elements
to be included in it.

Thanks,

Dorothy

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

Hi Dorothy,

 

I think this recommendation add substantial value to the CAPWAP protocol. = There have been discussions on the need for aggregating statistics information = from the WTP to AC. The Echo Request offers a way for achieving this. The = mechanisms for statistics exchanges – timer, periodic exchange – are = available with Echo Request. So I think it is of value to keep Echo Request and = add statistics information fields to it.

 

Cheers,

 

Saravanan

 

 

 

From: = Dorothy Stanley [mailto: dstanley1389@gmail.com]
Sent: Tuesday, April 11, = 2006 1:20 AM
To: capwap
Subject: [Capwap] = Proposed Resolution to Issue 45 - Issue on combiningmessages

 

All,

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

Comments please.

Thanks,

Dorothy

 

 

Republic Polytechnic, 9 Woodlands = Avenue 9, Singapore 738964 (Near = Woodlands MRT/Interchange)
. www.rp.sg . Fax: +65 6415-1310 .

Republic Polytechnic, = the first Institute of Higher Learning to fully adopt the Problem-Based = Learning approach in Singapore, continues to strive towards best = practices and maintain excellence in service standards with the = following certifications: Singapore Innovation Class (SIC), Singapore = Quality Class (SQC), People Developer Standards and QEHS (ISO 9001, = 14001 and OHSAS 18001)

CONFIDENTIALITY CAUTION: = This message is intended only for the use of the individual or entity to = whom it is addressed and contains information that is privileged and = confidential. If you, the reader of this message, are not the intended = recipient, you should not disseminate, distribute or copy this = communication. If you have received this communication in error, please = notify us immediately by return email and delete the original message. = Thank you.
------_=_NextPart_001_01C65EA5.8D380FF5-- --===============1919601782== 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 --===============1919601782==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Apr 13 01:49:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTuha-0005b3-5g for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 01:49:10 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTuhU-0007Ck-TI for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 01:49:10 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CDB514300C9 for ; Wed, 12 Apr 2006 22:49:01 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 2FC3643006C for ; Wed, 12 Apr 2006 22:48:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1178B431BD8 for ; Wed, 12 Apr 2006 22:48:09 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id A8D8F431BD4 for ; Wed, 12 Apr 2006 22:48:07 -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 k3D5m5hJ013262 for ; Thu, 13 Apr 2006 14:48:05 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k3D5m5Y13884 for ; Thu, 13 Apr 2006 14:48:05 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with SMTP id k3D5m6X07681 for ; Thu, 13 Apr 2006 14:48:06 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 13 Apr 2006 13:46:27 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDCDC1A5@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 43 - IEEE 802.11i Encryption Thread-Index: AcY+rLfW2utDhtL2SSG/oGVRxDUDpQgEWNLw 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] Issue 43 - IEEE 802.11i Encryption 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="===============0576665529==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: ab6387292ea58ba7ed0706d86883d715 This is a multi-part message in MIME format. --===============0576665529== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65EBD.9B591E1A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65EBD.9B591E1A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 Following from the note below, would appreciate comments on the resolution of Issue 43 - handling IEEE 802.11i encryption in WTP designs.=20 =20 Saravanan =20 =20 =20 =20 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Friday, March 03, 2006 6:25 PM To: capwap@frascone.com Subject: [Capwap] IEEE 802.11i - Encryption =20 All, =20 For the IEEE 802.11 binding, the protocol deals with split-MAC and local-MAC architectures. For both types, there is the design case of having encryption at the WTP and authenticator at the AC. This design case is a mandatory requirement from the Objectives. I think there was a discussion about this in the last meeting.=20 =20 I suggest adding new Key Configuration & Key Configuration Response messages to 11.8 "802.11 Control Messages" in the IEEE 802.11 bindings section and describing the exchange in new subsections 11.8.4 to 11.8.5. =20 The suggested text follows; =20 =20 =20 ----0000---- 11.8.4 IEEE 802.11 Key Configuration =20 The IEEE 802.11 Key Configuration CAPWAP message is used in WTP designs in which IEEE 802.11i authenticator functions are performed by the AC and IEEE 802.11i cryptographic functions (encryption/decryption) are performed by the WTPs.=20 =20 This CAPWAP message is sent from the AC to the WTP. It must contain either of the following 2 message elements.=20 =20 =20 =20 =20 11.8.4.1 IEEE 802.11 4-way Handshake =20 The IEEE 802.11 4-way Handshake message element is sent by the AC to the WTP during the 4-way handshake. It contains Message-3 of the 4-way handshake with unassigned values as the AC is unaware of the prevailing KeyRSC sequence counter maintained by the WTP. =20 =20 Message-1, Message-2 and Message-4 of the 4-way handshake are transported within CAPWAP data packets between AC and WTP.=20 =20 The IEEE 802.11 4-way Handshake message element contains the following values: =20 =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GTK-Flag | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encryption-Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAPoL-Frame | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =20 GTK-Flag: An 8-bit flag that determines the type of KeyMIC calculation =20 0 - New GTK, KeyMIC is calculated with KeyRSC =3D 0 =20 1 - Existing GTK, KeyMIC is calculated with prevailing KeyRSC value =20 Encryption-Data: Contains PTK and/or GTK =20 EAPoL-Frame: Contains Message-3 of 4-way handshake with unassigned fields =20 Upon receipt of the Key Configuration message from the AC, the WTP performs the following operations: =20 i. Assigns the corresponding value to the KeyRSC field of the EAPoL-Frame=20 ii. Calculates KeyMIC with Encrytion-Data and KeyRSC iii. Updates Message-3 of 4-way handshake iv. Continues regular 4-way handshake with wireless terminals =20 =20 =20 =20 11.8.4.2 IEEE 802.11 Group Key Handshake =20 The IEEE 802.11 Group Key Handshake message element is sent by the AC to the WTP during the group key handshake. It contains Message-1 of the group key handshake with unassigned values as the AC is unaware of the prevailing KeyRSC sequence counter maintained by the WTP. =20 =20 Message-2 of the group key handshake is transported within a CAPWAP data packet between AC and WTP.=20 =20 The IEEE 802.11 Group Key Handshake message element contains the following values: =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GTK-Flag | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encryption-Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAPoL-Frame | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =20 GTK-Flag: An 8-bit flag that determines the type of KeyMIC calculation =20 0 - New GTK, KeyMIC is calculated with KeyRSC =3D 0 =20 1 - Existing GTK, KeyMIC is calculated with prevailing KeyRSC value =20 Encryption-Data: Contains PTK and/or GTK =20 EAPoL-Frame: Contains Message-1 of group key handshake with unassigned fields =20 Upon receipt of the Key Configuration message from AC, the WTP performs the following operations: i. Assigns the corresponding value to the KeyRSC field of the EAPoL-Frame=20 ii. Calculates KeyMIC with Encrytion-Data and KeyRSC iii. Updates Message-1 of group key handshake iv. Continues regular group handshake with wireless terminals =20 =20 =20 =20 11.8.5 IEEE 802.11 Key Configuration Response =20 The IEEE 802.11 Key Configuration Response CAPWAP message is sent by the WTP to the AC as an acknowledgement of the receipt of an IEEE 802.11 Key Configuration Request.=20 =20 ----XXXX---- =20 =20 Saravanan ------_=_NextPart_001_01C65EBD.9B591E1A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

Following from the note below, would appreciate = comments on the resolution of Issue 43 – handling IEEE 802.11i encryption in = WTP designs.

 

Saravanan

 

 

 

 

From: = Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: Friday, March 03, = 2006 6:25 PM
To: = capwap@frascone.com
Subject: [Capwap] IEEE = 802.11i - Encryption

 

All,

 

For the IEEE 802.11 binding, the = protocol deals with split-MAC and local-MAC architectures. For both types, there = is the design case of having encryption at the WTP and authenticator at the AC. = This design case is a mandatory requirement from the Objectives. I think = there was a discussion about this in the last meeting.

 

I suggest adding new Key = Configuration & Key Configuration Response messages to 11.8 “802.11 Control Messages” in the IEEE 802.11 bindings section and describing the = exchange in new subsections 11.8.4 to 11.8.5.

 

The suggested text = follows;

 

 

 

----0000----

11.8.4      = IEEE 802.11 Key Configuration

 

The IEEE 802.11 Key Configuration = CAPWAP message is used in WTP designs in which IEEE 802.11i authenticator = functions are performed by the AC and IEEE 802.11i cryptographic functions (encryption/decryption) are performed by the WTPs. =

 

This CAPWAP message is sent from = the AC to the WTP. It must contain either of the following 2 message elements. =

 

 

 

 

11.8.4.1     = IEEE 802.11 4-way Handshake

 

The IEEE 802.11 = 4-way Handshake message element is sent by the AC to the WTP during the 4-way handshake. It contains Message-3 of the 4-way handshake with unassigned = values as the AC is unaware of the prevailing KeyRSC sequence counter = maintained by the WTP.  

 

Message-1, = Message-2 and Message-4 of the 4-way handshake are transported within CAPWAP data = packets between AC and WTP.

 

The IEEE 802.11 = 4-way Handshake message element contains the following = values:

 

 

      0            =        1            =        2            =        3

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

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

     |    GTK-Flag   |             &= nbsp;     Reserved              &= nbsp;     |

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

     |            =             Encryption-Data               &= nbsp;        |<= /font>

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

     |            =               EAPoL-Frame =             &= nbsp;           &n= bsp;|

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

 

 

GTK-Flag: An 8-bit flag that = determines the type of KeyMIC calculation

     =

     0 – = New GTK, KeyMIC is calculated with KeyRSC =3D 0

 

     1 – Existing GTK, KeyMIC is calculated with prevailing KeyRSC = value

 

Encryption-Data: Contains PTK = and/or GTK

 

EAPoL-Frame: Contains Message-3 of = 4-way handshake with unassigned fields

 

Upon receipt of = the Key Configuration message from the AC, the WTP performs the following = operations:

 

    i.           = ; Assigns the = corresponding value to the KeyRSC field of the EAPoL-Frame =

ii.           = ; Calculates = KeyMIC with Encrytion-Data and KeyRSC

iii.           = ; Updates = Message-3 of 4-way handshake

iv.           = ; Continues = regular 4-way handshake with wireless terminals

 

 

 

 

11.8.4.2     = IEEE 802.11 Group Key Handshake

 

The IEEE 802.11 = Group Key Handshake message element is sent by the AC to the WTP during the group = key handshake. It contains Message-1 of the group key handshake with = unassigned values as the AC is unaware of the prevailing KeyRSC sequence counter = maintained by the WTP.  

 

Message-2 of the = group key handshake is transported within a CAPWAP data packet between AC and = WTP.

 

The IEEE 802.11 = Group Key Handshake message element contains the following = values:

 

      0            =        1            =        2            =        3

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

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

     |    GTK-Flag   |             &= nbsp;     Reserved              &= nbsp;     |

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

     |            =             Encryption-Data               &= nbsp;        |<= /font>

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

     |            =               EAPoL-Frame             &= nbsp;           &n= bsp;|

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

 

 

GTK-Flag: An 8-bit flag that = determines the type of KeyMIC calculation

     =

     0 – = New GTK, KeyMIC is calculated with KeyRSC =3D 0

 

     1 – Existing GTK, KeyMIC is calculated with prevailing KeyRSC = value

 

Encryption-Data: Contains PTK = and/or GTK

 

EAPoL-Frame: Contains Message-1 of = group key handshake with unassigned fields

 

Upon receipt of = the Key Configuration message from AC, the WTP performs the following = operations:

    i.           = ; Assigns the = corresponding value to the KeyRSC field of the EAPoL-Frame =

ii.           = ; Calculates = KeyMIC with Encrytion-Data and KeyRSC

iii.           = ; Updates = Message-1 of group key handshake

iv.           = ; Continues = regular group handshake with wireless terminals

 

 

 

 

11.8.5     IEEE = 802.11 Key Configuration Response

 

The IEEE 802.11 Key Configuration = Response CAPWAP message is sent by the WTP to the AC as an acknowledgement of the receipt of an IEEE 802.11 Key Configuration Request. =

 

----XXXX----

 

 


Saravanan

------_=_NextPart_001_01C65EBD.9B591E1A-- --===============0576665529== 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 --===============0576665529==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Apr 13 02:05:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTux4-00050i-4u for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 02:05:10 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTuw3-0007aC-J8 for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 02:04:13 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 252804300E0 for ; Wed, 12 Apr 2006 23:04:07 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B40B84300E9 for ; Wed, 12 Apr 2006 23:01:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8C927398018 for ; Wed, 12 Apr 2006 23:01:52 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 89FC8398012 for ; Wed, 12 Apr 2006 23:01:50 -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 k3D61mFl008418; Thu, 13 Apr 2006 15:01:48 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k3D61d127428; Thu, 13 Apr 2006 15:01:39 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with SMTP id k3D61dG04355; Thu, 13 Apr 2006 15:01:39 +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 - Issue on combiningmessages Date: Thu, 13 Apr 2006 13:59:58 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDCDC1AC@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages Thread-Index: AcZeQYjaFSRyg8znSOy83uhzwH6FbQAWmsRQ From: "Saravanan Govindan" To: "Dorothy Stanley" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.505 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_MESSAGE, NORMAL_HTTP_TO_IP X-Spam-Level: Cc: capwap 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="===============1380903375==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 1f604fef64104b35d98bf17e9534ef0b This is a multi-part message in MIME format. --===============1380903375== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65EBF.7E96284F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65EBF.7E96284F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dorothy, I agree that we should decide the statistics as a first step.=20 =20 Here is my take on what the AC needs for control over the WLAN as a whole; =20 1. WTP buffer levels=20 - Similar to metric used in routers - Percentage occupancy of transmit buffers - Independent of implementation =20 2. Congestion conditions - Wireless segment & AC-WTP segment - Number of transmission failures - Percentage occupancy of transmit buffers =20 =20 The key here is to provide the AC with information that provides broader information than what it gets from technology-specific statistics. This gives the AC more visibility in to the WLAN. And in relation, big-picture information helps set the framework for CAPWAP applicability to manage any future wireless technology. =20 Cheers, =20 Saravanan =20 =20 =20 =20 =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Wednesday, April 12, 2006 11:00 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages =20 Saravanan, Richard, I suggest we set aside the question of how the statistics might be transported for the moment - either in WTP Event Request, Echo Request or some new message, and first agree on the nature/definition of the statistics themselves. We are talking about non-802.11 specific statistics, as the 802.11 specific ones, or new 802.11 ones would go in 11.7.2.1: WPT buffer levels - which buffers? Concern that this would be implementation specific Congestion conditions - congestion on the wireless link? On the WTP to AC link? etc - needs to be specified. Richard suggests Network Congestion - which network, the wireless one or the WTP to AC link. How is the level of congestion measured? Traffic Loading - How is this measured? Which traffic?=20 Channel Interferences - Need to specify. Concern that there is overlap with what will be coming in .11k for radio measurement Thanks, Dorothy On 4/11/06, Saravanan Govindan wrote: Hi Dorothy, =20 WTP Event Request is being positioned for technology-specific statistics exchange (Section 2.1). So my understanding is that WTP Event Request would be used for information such as transmission attempts, beacon and probe counts, decryption errors etc.=20 =20 In addition to technology-specific information, the AC also needs big-picture information on factors affecting the WLAN as a whole. This would include WTP buffer levels, congestion conditions, etc. This information is not specific to a technology but does affect the WLAN. It is this type of statistics that I suggest the Echo Request exchange. =20 Cheers, Saravanan =20 =20 =20 =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Tuesday, April 11, 2006 10:50 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages =20 Saravanan, Richard,=20 First of all, thank you for your comments. Clearly, the WTP must have a means to provide statistics and other relevant data to the AC.. The question becomes, what specific mechanism should be used?=20 Overloading the echo request message is one way. CAPWAP has the WTP event request message, section 8.5, and already includes the decryption error report, and can include the .11 specific statistics report. Why is using the WTP event report to report statistics not sufficient? We should add other applicable CAPWAP message elements to be included in it. Thanks, Dorothy On 4/10/06, Saravanan Govindan wrote:=20 Hi Dorothy, =20 I think this recommendation add substantial value to the CAPWAP protocol. There have been discussions on the need for aggregating statistics information from the WTP to AC. The Echo Request offers a way for achieving this. The mechanisms for statistics exchanges - timer, periodic exchange - are available with Echo Request. So I think it is of value to keep Echo Request and add statistics information fields to it.=20 =20 Cheers, =20 Saravanan =20 =20 =20 ________________________________ From: Dorothy Stanley [mailto: dstanley1389@gmail.com]=20 Sent: Tuesday, April 11, 2006 1:20 AM To: capwap Subject: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages =20 All, 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.=20 Initial analysis have shown that these overhead can be reduced significantly=20 =20 if the messages can be combined. =20 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. Recommended resolution: reject the comment, with the explanation in the above paragraph Comments please. Thanks, Dorothy =20 =20 ------_=_NextPart_001_01C65EBF.7E96284F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dorothy,


I agree that we should decide the statistics as a first step. =

 

Here is my take on what the AC needs for control over = the WLAN as a whole;

 

1. WTP buffer levels

– Similar to metric used in = routers

– Percentage occupancy of transmit = buffers

– Independent of = implementation

 

2. Congestion conditions – Wireless segment = & AC-WTP segment

– Number of transmission = failures

– Percentage occupancy of transmit buffers   

 

The key here is to provide the AC with information = that provides broader information than what it gets from technology-specific = statistics. This gives the AC more visibility in to the WLAN. And in relation, = big-picture information helps set the framework for CAPWAP applicability to manage = any future wireless technology.

 

Cheers,

 

Saravanan

 

 

 

 

 

From: = Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Wednesday, April = 12, 2006 11:00 PM
To: Saravanan = Govindan
Cc: capwap
Subject: Re: [Capwap] = Proposed Resolution to Issue 45 - Issue on = combiningmessages

 

Saravanan, Richard,

I suggest we set aside the question of how the statistics might be  transported for the moment - either in WTP Event Request, Echo Request = or some new
message, and first agree on the nature/definition of the statistics = themselves. We are talking about non-802.11 specific statistics, as the 802.11
specific ones, or new 802.11 ones would go in 11.7.2.1:

WPT buffer levels - which buffers? Concern that this would be = implementation specific
Congestion conditions - congestion on the wireless link? On the WTP to = AC link?
etc - needs to be specified.

Richard suggests
Network Congestion - which network, the wireless one or the WTP to AC = link. How is the level of congestion measured?
Traffic Loading - How is this measured? Which traffic?
Channel Interferences - Need to specify. Concern that there is overlap = with what will be coming in .11k for radio measurement

Thanks,

Dorothy

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

Hi Dorothy,

 

WTP Event Request is being positioned for technology-specific statistics = exchange (Section 2.1). So my understanding is that WTP Event Request would be = used for information such as transmission attempts, beacon and probe counts, = decryption errors etc.

 

In addition to technology-specific information, the AC also needs = big-picture information on factors affecting the WLAN as a whole. This would include = WTP buffer levels, congestion conditions, etc. This information is not = specific to a technology but does affect the WLAN. It is this type of statistics = that I suggest the Echo Request exchange.

 

Cheers,


Saravanan

 

 

 

 

From: Dorothy Stanley = [mailto:dstanley1389@gmail.com]
Sent: Tuesday, April 11, = 2006 10:50 PM
To: Saravanan = Govindan
Cc: capwap
Subject: Re: [Capwap] = Proposed Resolution to Issue 45 - Issue on = combiningmessages

 

Saravanan, = Richard,

First of all, thank you for your comments.

Clearly, the WTP must have a means to provide statistics = and other relevant data to the AC..

The question becomes, what specific mechanism should be = used?
Overloading the echo request message is one way. = CAPWAP  has the WTP event request message,
section 8.5, and already includes the decryption error = report, and can include the .11 specific
statistics report.

Why is using the WTP event report to report statistics = not sufficient? We should add other applicable CAPWAP message = elements
to be included in it.

Thanks,

Dorothy

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

Hi Dorothy,

 

I think this recommendation add substantial value to the CAPWAP protocol. = There have been discussions on the need for aggregating statistics information = from the WTP to AC. The Echo Request offers a way for achieving this. The = mechanisms for statistics exchanges – timer, periodic exchange – are = available with Echo Request. So I think it is of value to keep Echo Request and = add statistics information fields to it.

 

Cheers,

 

Saravanan=

 

 

 

From: Dorothy Stanley [mailto: = dstanley1389@gmail.com]
Sent: Tuesday, April 11, = 2006 1:20 AM
To: capwap
Subject: [Capwap] = Proposed Resolution to Issue 45 - Issue on = combiningmessages

 

All,

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

Comments please.

Thanks,

Dorothy

 

 

------_=_NextPart_001_01C65EBF.7E96284F-- --===============1380903375== 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 --===============1380903375==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Apr 13 02:05:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTuxB-00050i-Pu for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 02:05:17 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTuu9-0007XM-1W for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 02:02:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9F0984300DA for ; Wed, 12 Apr 2006 23:02:08 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D7AE143006C for ; Wed, 12 Apr 2006 23:01:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C3D7939802A for ; Wed, 12 Apr 2006 23:01: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 E9976398012 for ; Wed, 12 Apr 2006 23:01:15 -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 k3D61DBs007953; Thu, 13 Apr 2006 15:01:13 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k3D613a22748; Thu, 13 Apr 2006 15:01:03 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with SMTP id k3D615x21338; Thu, 13 Apr 2006 15:01:05 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 13 Apr 2006 13:59:30 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDCDC1AB@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WTP Mac Type negotiation. Thread-Index: AcZdW2bWuZgNJlWpSy+Hl3qAChESzABZE28Q From: "Saravanan Govindan" To: "sujay" , , "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: Subject: [Capwap] RE: WTP Mac Type negotiation. 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="===============1111565094==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 380268093b6fc584d1ec0b58112528b4 This is a multi-part message in MIME format. --===============1111565094== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65EBF.6E4E92F3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65EBF.6E4E92F3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sujay, =20 I understand your concern of not specifying an AC's modes of operation.=20 =20 So the change would be to let the AC select a WTP's mode of operation but not "how" to select a mode. Would this be ok?=20 Cheers, Saravanan =20 =20 =20 =20 ________________________________ From: sujay [mailto:sujayg@huawei.com]=20 Sent: Tuesday, April 11, 2006 7:32 PM To: Saravanan Govindan; capwap@frascone.com; 'Pat Calhoun (pacalhou)' Subject: RE: WTP Mac Type negotiation. =20 Saravanan, I suggest not to limit the AC's mode of operation, by classifying modes of operation viz Control - bias=20 and Load-bias mode. =20 Keeping it simple; =20 5.2.6. Operating Mode =20 The Operating Mode message element specifies the mode of operation for a WTP capable of =20 operating in both Local-MAC and Split-MAC modes.=20 =20 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Operating Mode | +-+-+-+-+-+-+-+-+ =20 Type: TBD =20 Length: 1 =20 Operating Mode: The selected mode for WTP operation =20 <=20 0: Control-bias mode, WTP operates in Split-MAC mode =20 1: Load-bias mode, WTP operates in Local-MAC mode=20 /> change to; <=20 0: Split-MAC mode, WTP operates in Split-MAC mode =20 1: Local-MAC mode, WTP operates in Local-MAC mode=20 /> =20 =20 Any suggestions? Sujay =20 =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Friday, March 31, 2006 8:14 AM To: sujay; capwap@frascone.com Subject: RE: WTP Mac Type negotiation. Dear All, =20 Following from Sujay G's suggestion, this is text for mode selection in the case where a WTP supports both split-MAC and local-MAC modes and can also support the different tunnel options.=20 =20 Cheers, =09 Saravanan =20 =20 =20 =20 ----oooo---- =20 Introduce how operational mode is selected in Section 2 (Protocol Overview) [Paragraph 3, after 2nd sentence] =20 "The WTPs specify their operational modes in their Discovery Request message, to which the responding AC selects particular operational modes and specifies them in the Discovery Response message." =20 =20 =20 Then in Section 5.2 (Discovery Response) [After Paragraph 2, include following paragraph] =20 =20 " In the case where a requesting WTP is capable of both Local-MAC and Split-MAC operations (MAC Type [Section 5.1.4] value "2") or where a WTP is capable of all types of bridging (Frame Type [Section 5.1.5] value "7"), AC determines the particular operating mode based on the following; =20 i. Control-bias Mode =20 In this mode, the AC has greater control of WTP operations. So the AC instructs the requesting WTP to operate in Split-MAC mode.=20 =20 ii. Load-bias Mode =20 In this mode, the AC reduces processing load of WTP operations. So the AC instructs the requesting WTP to operate in Local-MAC mode. " =20 =20 Introduce Operation Mode message element as Section 5.2.6 (Operating Mode). =20 =20 5.2.6. Operating Mode =20 The Operating Mode message element specifies the mode of operation for a WTP capable of =20 operating in both Local-MAC and Split-MAC modes.=20 =20 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Operating Mode | +-+-+-+-+-+-+-+-+ =20 Type: TBD =20 Length: 1 =20 Operating Mode: The selected mode for WTP operation =20 0: Control-bias mode, WTP operates in Split-MAC mode =20 1: Load-bias mode, WTP operates in Local-MAC mode=20 =20 ----XXXX---- =20 =20 =20 =20 =20 =20 =20 =20 =20 -----Original Message----- From: sujay [mailto:sujayg@huawei.com]=20 Sent: Friday, March 17, 2006 2:32 PM To: capwap@frascone.com Cc: Saravanan Govindan Subject: WTP Mac Type negotiation. =20 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal =20 =20 The CAPWAP does not specify as to how the selection is made if the WTP=20 Can support both Modes Split and Local and Frame (Tunnel ) type. =20 The WTP specifies MAC Type and Frame Type in Discovery Request message, but if it supports=20 both modes , there is no provision for the AC to select the working mode. =20 =20 Recommendation : 1. Add the WTP mode and WTP tunnel type messages in the configure response ? Which makes it binding=20 agnostic. =20 2. The logic for choosing WTP mode type on the AC could depend on the load, and user policy. =20 Solicit comments. =20 Regds, Sujay =20 =20 ------_=_NextPart_001_01C65EBF.6E4E92F3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Hi Sujay,

 

I understand your concern of not specifying an = AC’s modes of operation.

 

So the change would be to let the AC select a = WTP’s mode of operation but not “how” to select a mode. Would this = be ok?


Cheers,

Saravanan

 

 

 

 

From: sujay [mailto:sujayg@huawei.com]
Sent: Tuesday, April 11, = 2006 7:32 PM
To: Saravanan Govindan; capwap@frascone.com; 'Pat Calhoun (pacalhou)'
Subject: RE: WTP Mac Type negotiation.

 

Saravanan,

I suggest not to limit the AC's mode of = operation,

by classifying modes of operation viz Control - bias =

and Load-bias mode.

 

Keeping it simple;

 

5.2.6.   Operating Mode

 

   The = Operating Mode message element specifies the mode of operation for a WTP capable = of  

   = operating in both Local-MAC and Split-MAC modes.

 

      =
0
      0 1 2 3 4 5 6 =
7
     =
+-+-+-+-+-+-+-+-+
     |Operating Mode =
|
     =
+-+-+-+-+-+-+-+-+
 
   =
Type:  TBD
 
   =
Length:  1
 
   =
Operating Mode:  The selected mode for WTP =
operation
 
< 
        0: Control-bias =
mode, WTP operates in Split-MAC =
mode
 =

        1: Load-bias =
mode, WTP operates in Local-MAC mode =

/>
change =
to;
< 
        0: Split-MAC mode, =
WTP operates in Split-MAC mode
 =

        1: Local-MAC =
mode, WTP operates in Local-MAC mode =

/>
 
 
Any suggestions?
Sujay

 

 

-----Original = Message-----
From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: Friday, March 31, = 2006 8:14 AM
To: sujay; = capwap@frascone.com
Subject: RE: WTP Mac Type negotiation.

Dear = All,

 

Following from = Sujay G's suggestion, this is text for mode selection in the case where a WTP = supports both split-MAC and local-MAC modes and can also support the different = tunnel options.

 

Cheers,

Saravanan

 

 

 

 

----oooo----

<NOTE> =

Introduce how = operational mode is selected in Section 2 (Protocol Overview) [Paragraph 3, after = 2nd sentence]

<END = NOTE>

 

"The WTPs = specify their operational modes in their Discovery Request message, to which the responding AC selects particular operational modes and specifies them in = the Discovery Response message."

 

 

<NOTE> =

Then in Section = 5.2 (Discovery Response) [After Paragraph 2, include following = paragraph]

<END = NOTE>

 

 

" In the = case where a requesting WTP is capable of both Local-MAC and Split-MAC operations = (MAC Type [Section 5.1.4] value "2") or where a WTP is capable of = all types of bridging (Frame Type [Section 5.1.5] value "7"), AC determines the particular operating mode based on the = following;

 

i. Control-bias = Mode

 

In this mode, = the AC has greater control of WTP operations. So the AC instructs the requesting = WTP to operate in Split-MAC mode.

 

ii. Load-bias = Mode

 

In this mode, = the AC reduces processing load of WTP operations. So the AC instructs the = requesting WTP to operate in Local-MAC mode. "

 

 

<NOTE>

Introduce = Operation Mode message element as Section 5.2.6 (Operating = Mode).

<END = NOTE>

 

 

5.2.6.   Operating Mode

 

   The Operating Mode message element specifies the mode of operation for a WTP capable of  

   = operating in both Local-MAC and Split-MAC modes.

 

      =
0
      0 1 2 3 4 5 6 =
7
     =
+-+-+-+-+-+-+-+-+
     |Operating Mode =
|
     =
+-+-+-+-+-+-+-+-+
 
   =
Type:  TBD
 
   =
Length:  1
 
   =
Operating Mode:  The selected mode for WTP =
operation
 
        0: Control-bias =
mode, WTP operates in Split-MAC =
mode
 =

        1: Load-bias =
mode, WTP operates in Local-MAC mode

 

----XXXX----

 

 

 

 

 

 

 

 

 

-----Original Message-----
From: sujay [mailto:sujayg@huawei.com]
Sent: Friday, March 17, 2006 2:32 PM
To: capwap@frascone.com
Cc: Saravanan Govindan
Subject: WTP Mac Type negotiation.

 

Importance: Normal

X-Priority: 3 (Normal)

X-MSMail-priority: Normal

 

 

The CAPWAP does not specify as to how the selection is made if = the WTP

Can support both Modes Split and Local and Frame (Tunnel ) = type.

 

The WTP specifies MAC Type and Frame Type  in Discovery = Request message,

but if it supports

both modes , there is no provision for the AC to select the = working

mode.

 

 

Recommendation :

1. Add the WTP mode and WTP tunnel type messages  in = the

configure response ? Which  makes it binding =

agnostic.

 

2. The logic for choosing WTP mode type on the AC could depend = on the

load, and user policy.

 

Solicit comments.

 

Regds,

Sujay

 

 

------_=_NextPart_001_01C65EBF.6E4E92F3-- --===============1111565094== 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 --===============1111565094==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Apr 13 02:05:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTuxL-0005P5-Cd for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 02:05:27 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTunV-0007HK-FA for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 01:55:23 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1BDE94300DA for ; Wed, 12 Apr 2006 22:55:17 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 34E1443006C for ; Wed, 12 Apr 2006 22:54:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1B097431BE4 for ; Wed, 12 Apr 2006 22:54:49 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 33CC4431BD3 for ; Wed, 12 Apr 2006 22:54:47 -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 k3D5sk3i003196 for ; Thu, 13 Apr 2006 14:54:46 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k3D5sa125057 for ; Thu, 13 Apr 2006 14:54:36 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with SMTP id k3D5sbG27460 for ; Thu, 13 Apr 2006 14:54:37 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 13 Apr 2006 13:53:04 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDCDC1A9@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 41 - BSSID WLAN-ID mapping Thread-Index: AcZev1vxmflCvJxDT0yR1TzZFvr+eA== 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] Issue 41 - BSSID WLAN-ID 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: , Content-Type: multipart/mixed; boundary="===============0762332915==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 This is a multi-part message in MIME format. --===============0762332915== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65EBE.883B4573" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65EBE.883B4573 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 This is taken from an earlier post on logical group configuration in CAPWAP (Issue 41). It somewhat relates to Issue 61 on mapping BSSIDs to WLAN-ID.=20 =20 Any comments on resolution? =20 Saravanan =20 =20 =20 =20 =20 Issue:=20 =20 Assign a default mode for configuring logical groups (draft-ietf-capwap- objectives-04.txt) Section 5.1.1 and (draft-ietf-eval-00.txt) Section 6.1=20 across wired and wireless segments. This makes for consistent configuration=20 and management across logical groups.=20 =20 =20 =20 My recommendation: =20 Introduce a message element in the WLAN Config message (draft-ohara-capwap- lwapp-03.txt) Section 11.8.2 to map wired-segment VLANs to wireless-segment=20 BSSIDs. This is the simplest and most common case for logical groups.=20 =20 =20 Then include description of logical group configuration in BSSID to WLAN ID=20 Mapping (draft-ohara-capwap-lwapp-03.txt) in Section 11.4).=20 =20 No agreement on this request. =20 ------_=_NextPart_001_01C65EBE.883B4573 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi =
All,
 
This is =
taken from an earlier post on logical group configuration in CAPWAP =
(Issue 41). It somewhat relates to Issue 61 on mapping BSSIDs to =
WLAN-ID. 
 
Any =
comments on resolution?
 
Saravanan
<=
font
size=3D2 face=3D"Courier New"> 
 
 
 
 
Issue: =

 
Assign a =
default mode for configuring logical groups =
(draft-ietf-capwap-
objectives-04.txt) Section 5.1.1 and =
(draft-ietf-eval-00.txt) Section 6.1 =

across =
wired and wireless segments. This makes for consistent configuration =

and =
management across logical groups. =

 
 =

 
My =
recommendation:
 
Introduce =
a message element in the WLAN Config message =
(draft-ohara-capwap-
lwapp-03.txt) Section 11.8.2 to map =
wired-segment VLANs to wireless-segment =

BSSIDs. =
This is the simplest and most common case for logical groups. =

 
 
Then =
include description of logical group configuration in BSSID to WLAN ID =

Mapping =
(draft-ohara-capwap-lwapp-03.txt) in Section 11.4). =

 
No =
agreement on this request.

 

------_=_NextPart_001_01C65EBE.883B4573-- --===============0762332915== 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 --===============0762332915==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Apr 13 02:19:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTvAq-0002lh-Br for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 02:19:24 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTvAo-0008EN-PI for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 02:19:24 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 26B0543008C for ; Wed, 12 Apr 2006 23:19:22 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id CD28F43006C for ; Wed, 12 Apr 2006 23:18:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B054D431C16 for ; Wed, 12 Apr 2006 23:18:53 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by hermes.tigertech.net (Postfix) with ESMTP id 0B9A0431C15 for ; Wed, 12 Apr 2006 23:18:51 -0700 (PDT) Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 12 Apr 2006 23:18:40 -0700 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id C5A782AF; Wed, 12 Apr 2006 23:18:39 -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 928962AE; Wed, 12 Apr 2006 23:18:39 -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 DHI87882; Wed, 12 Apr 2006 23:18: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 D5B8320501; Wed, 12 Apr 2006 23:18:36 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] Proposed Text for Issue 53 Date: Wed, 12 Apr 2006 23:18:36 -0700 Message-ID: <8954613CA6BB3242A1531D916A527A41A74E82@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [Capwap] Proposed Text for Issue 53 Thread-Index: AcZZ1B0hLZFg+GlZQO6cTP5AesENNQE7ZWaA From: "Puneet Agarwal" To: "Dorothy Stanley" , "Saravanan Govindan" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006041301; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230312E34343344454330452E303030442D412D; ENG=IBF; TS=20060413061840; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006041301_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 682332CA3NG7379569-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.1 tagged_above=-999.0 required=7.0 tests=HTML_50_60, HTML_MESSAGE 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: , Content-Type: multipart/mixed; boundary="===============0011640295==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 This is a multi-part message in MIME format. --===============0011640295== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65EC2.1949858D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65EC2.1949858D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Dorothy, =20 Sorry for the delayed reply (had to take care of uncle sam - ie taxes). >From my point of view "sending the phy info in every packet" capability should be optional to implement. =20 Thanks. =20 -Puneet ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Thursday, April 06, 2006 4:45 PM To: Saravanan Govindan; Puneet Agarwal Cc: Abhijit Choudhury; Bob O'Hara (boohara); Pat Calhoun (pacalhou); capwap Subject: Re: [Capwap] Proposed Text for Issue 53 Puneet, Would WTP support of the "sending the phy info in every packet" capability be=20 (a) mandatory to implement and optional to configure? or=20 (b) optional to implement? Sending the Phy info (RSSI/SNR/Speed) should be optional. By default this info should *NOT* be sent in every CAPWAP data packet. This capability should be negotiated at WTP<->AC handshake time. Thanks, Dorothy =09 =09 Hi Bob, =09 It seems the real issue is what is the default mode of operation. =09 Summary: --------- =09 Pat/Bob: Carry the phy info in every CAPWAP data pkt as at least 1 implementation uses it Abhijit/Saravanan: Carry phy info in control msgs periodically and not in every CAPWAP data frame. =09 My Proposal (Compromise): ------------------------- Sending the Phy info (RSSI/SNR/Speed) should be optional. By default this info should *NOT* be sent in every CAPWAP data packet. This capability should be negotiated at WTP<->AC handshake time. =09 Comments? =09 Thanks. =09 -Puneet =09 =09 =09 ------_=_NextPart_001_01C65EC2.1949858D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Hi Dorothy,
 
Sorry for the delayed reply (had to take care = of uncle sam=20 - ie taxes). From my point of view "sending the phy info in every packet" capability should = be=20 optional to implement.
 
Thanks.
 
-Puneet

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Thursday, April 06, = 2006 4:45=20 PM
To: Saravanan Govindan; Puneet Agarwal
Cc: = Abhijit=20 Choudhury; Bob O'Hara (boohara); Pat Calhoun (pacalhou);=20 capwap
Subject: Re: [Capwap] Proposed Text for Issue=20 53

Puneet,

Would WTP support of the "sending the phy info = in=20 every packet" capability
be

(a) mandatory to implement and = optional=20 to configure?  or
(b) optional to implement?

Sending the Phy info = (RSSI/SNR/Speed)=20 should be optional. By default this info should *NOT* be sent in every = CAPWAP=20 data packet. This capability should be negotiated at WTP<->AC = handshake=20 time.

Thanks,

Dorothy

Hi Bob,

It seems the real issue is what is the default = mode of=20 operation.

Summary:
---------

Pat/Bob: Carry the phy = info in=20 every CAPWAP data pkt as at least 1 implementation uses=20 it
Abhijit/Saravanan: Carry phy info in control msgs periodically = and not=20 in every CAPWAP data frame.

My Proposal=20 (Compromise):
-------------------------
Sending the Phy info=20 (RSSI/SNR/Speed) should be optional. By default this info should *NOT* = be sent=20 in every CAPWAP data packet. This capability should be negotiated at=20 WTP<->AC handshake=20 = time.

Comments?

Thanks.

-Puneet





------_=_NextPart_001_01C65EC2.1949858D-- --===============0011640295== 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 --===============0011640295==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Apr 13 02:24:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTvFb-00049n-Ip for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 02:24:19 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTvFa-0008KE-RI for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 02:24:19 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7AD604300FA for ; Wed, 12 Apr 2006 23:24:18 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id A39E043006C for ; Wed, 12 Apr 2006 23:23:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8B6DA431C22 for ; Wed, 12 Apr 2006 23:23:50 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by hermes.tigertech.net (Postfix) with ESMTP id B0940431C15 for ; Wed, 12 Apr 2006 23:23:48 -0700 (PDT) Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 12 Apr 2006 23:23:38 -0700 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 3B8D22B0; Wed, 12 Apr 2006 23:23: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 012352AE; Wed, 12 Apr 2006 23:23:37 -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 DHI89209; Wed, 12 Apr 2006 23:23: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 21E1A20501; Wed, 12 Apr 2006 23:23:37 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] Proposed Text for Issue 53 Date: Wed, 12 Apr 2006 23:23:36 -0700 Message-ID: <8954613CA6BB3242A1531D916A527A41A74E83@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [Capwap] Proposed Text for Issue 53 Thread-Index: AcZXmiGYKUrUeU/XT1OcZaCvsWKBVgAnw06wAAH/5gAAHicW0AANpnXwAAwoBZABaEdisA== From: "Puneet Agarwal" To: "Bob O'Hara (boohara)" , "capwap" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006041301; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230392E34343344454433392E303031442D412D; ENG=IBF; TS=20060413062342; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006041301_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 682331E00HW6740615-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: 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: fb93e867a11a29ac1dc5018706b412ac Hi Bob, I agree that optional fields are a challenge. One way to get around this would be to make this feature optional to implement and mark those fields as reserved for the normal case. Thanks. -Puneet -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Wednesday, April 05, 2006 7:23 PM To: Puneet Agarwal; capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Puneet, Optional fields in a packet are just plain evil.=20 -Bob =20 -----Original Message----- From: Puneet Agarwal [mailto:pagarwal@broadcom.com] Sent: Wednesday, April 05, 2006 3:49 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Hi Bob, It seems the real issue is what is the default mode of operation. Summary: --------- Pat/Bob: Carry the phy info in every CAPWAP data pkt as at least 1 implementation uses it Abhijit/Saravanan: Carry phy info in control msgs periodically and not in every CAPWAP data frame. My Proposal (Compromise): ------------------------- Sending the Phy info (RSSI/SNR/Speed) should be optional. By default this info should *NOT* be sent in every CAPWAP data packet. This capability should be negotiated at WTP<->AC handshake time. Comments? Thanks. -Puneet -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] Sent: Wednesday, April 05, 2006 7:15 AM To: capwap Subject: RE: [Capwap] Proposed Text for Issue 53 For those AC implementations that want to use per packet data for certain operations, aggregation of the data at the WTP as suggested by Abhijit will preclude this. The assertion by Saravanan that an AC does not process this information is incorrect. I can point to at least one existing implementation that already does process this information on a per packet basis. The current text, with the change I suggested, is the right way to handle this. If we want to ADD a capability that the WTP can provide aggregation, I have no objection to that. -Bob =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Tuesday, April 04, 2006 4:49 PM To: Abhijit Choudhury; Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Hi Abhijit, I am in support of your suggestion. It is true that the AC does not process all data packets. Furthermore, I think for greater control, the AC will need information about the congestion level in the WLAN. This could be a derivative of interference and load factor.=20 As for your suggestion, I think measurement/parameter information from the WTP should be sent over the periodic Echo Request messages. The advantage is that header overhead is reduced.=20 I can prepare text for this approach. Cheers, Saravanan =20 -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com] Sent: Wednesday, April 05, 2006 6:52 AM To: Pat Calhoun (pacalhou); capwap Subject: RE: [Capwap] Proposed Text for Issue 53 Here's another approach... RSSI, SNR, and Data Rate are measurements/parameters of the radio channel that are being reported to the AC for finer control. Carrying them in every data packet on the data channel means some logic or hardware in the AC will have to parse them out of every data packet and send them to the control path (CPU). Typically not every packet will go to the CPU and so this data will have to be stored and periodically sent to or read by the CPU. Note that the AC will be possibly dealing with tens to hundreds of WTPs and hence a potentially large number of STAs. This implies a large amount of per-STA measurement data has to be stored and moved from the data path to the CPU. A more reasonable approach is to let the WTP aggregate such data and periodically send it in the control channel to the AC. Note the WTP has to deal with much much fewer clients - so the storage burden is less. All we'd need is a frame that carries this information to the AC at a specified interval of time. This period could be configurable. Using this approach, we don't need to increase the CAPWAP header every time we need new measurement info. We can retain the current CAPWAP header and flexibly add any measurement information we need by adding it in the control channel. This is particularly important as we move forward to support 802.11n or other non-802.11 technlogies. It decouples the CAPWAP header from the measurement data related information. Any thoughts on this ? Thanks, Abhijit -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Monday, April 03, 2006 8:45 PM To: capwap Subject: [Capwap] Proposed Text for Issue 53 Here is my proposed text for Issue 53, which is the addition of a Data Rate In the CAPWAP header. Please let me know if you have any comments. =20 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |F|L|R| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | <=3D=3D=3D CHANGED!!! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload... | +-+-+-+-+-+-+-+-+ [...] 4.1.8. Reserved This 32 bit field is reserved and may be used by a binding specific extension. Refer to the transport portion of the binding for a specific wireless technology for the definition of this field. [...] 11.3.2. CAPWAP Header Reserved field 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 5.5Mbps would be set to 55, while 11Mbps would be set to 110. 11.3.2.2. Destination WLANs The Destination WLAN field is used to specify the target WLANs for a given frame, and is only used with broadcast and multicast frames. This field allows the AC to transmit a single broadcast or multicast frame to the WTP, and allows the WTP to perform the necessary frame replication services. The field 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WLAN: This bit field indicates the WLAN ID (see section Section 11.8.1.1) which the WTP will transmit the associated frame on. For instance, if a multicast packet is to be transmitted on WLANs 1 and 3, bits 1 and 3 of this field would be enabled. Note this field is to be set to zero for unicast packets and is unused if the WTP is not providing encryption services. Reserved: This field MUST be set to zero. =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 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 Apr 13 09:18:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU1im-0006A0-KA for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 09:18:52 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU1il-0004fr-3g for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 09:18:52 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 45327430109 for ; Thu, 13 Apr 2006 06:18:50 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4EE17430067 for ; Thu, 13 Apr 2006 06:18:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3A4A3430D1B for ; Thu, 13 Apr 2006 06:18:26 -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 A6A93430D18 for ; Thu, 13 Apr 2006 06:18:23 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 13 Apr 2006 06:18:24 -0700 X-IronPort-AV: i="4.04,117,1144047600"; d="scan'208"; a="423717869:sNHT27038966" 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 k3DDIIh6014538; Thu, 13 Apr 2006 06:18:22 -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, 13 Apr 2006 06:18: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 42 - PMK Sharing Date: Thu, 13 Apr 2006 06:18:22 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201B82734@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 42 - PMK Sharing Thread-Index: AcZc1QtI5MCl3B0STx23C5sSqfueHgB0vtfA From: "Pat Calhoun (pacalhou)" To: "T. Charles Clancy" , "Dorothy Stanley" X-OriginalArrivalTime: 13 Apr 2006 13:18:22.0530 (UTC) FILETIME=[BD2DC220:01C65EFC] X-Virus-Scanned: by amavisd-new-20030616-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: 7fa173a723009a6ca8ce575a65a5d813 Similar comment. I never understood the original issue, other than saying that sharing is a bad thing - regardless of whether the protocol does it or not. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: T. Charles Clancy [mailto:clancy@cs.umd.edu]=20 > Sent: Monday, April 10, 2006 12:27 PM > To: Dorothy Stanley > Cc: capwap > Subject: Re: [Capwap] Proposed Resolution to Issue 42 - PMK Sharing >=20 > This was my original point -- CAPWAP doesn't let you share=20 > the PMK, so I never understood why this was an issue. >=20 > [ t. charles clancy ]--[ tcc@umd.edu ]--[=20 > www.cs.umd.edu/~clancy ] [ computer science ]-----[=20 > university of maryland | college park ] >=20 >=20 > On Mon, 10 Apr 2006, Dorothy Stanley wrote: >=20 > > All, > > > > Issue 42 - PMK Sharing has the following discussion in the=20 > issues data base: > > > > Issue: > > > > In the case of an AC managing a same PMK across many WTPs,=20 > IEEE 802.11=20 > > stations cannot distinguish between PMKs that are validly=20 > shared and=20 > > those that have been compromised (I0 of Issues/Recommendations). > > > > My recommendation: > > > > Include text in the Security Considerations=20 > > (draft-ohara-capwap-lwapp-03.txt) Section 15 along the lines; > > > > "The CAPWAP protocol may be used in scenarios in which an=20 > AC manages a=20 > > PMK across many WTPs. In such scenarios, IEEE 802.11=20 > stations moving=20 > > across WTPs cannot distinguish between PMKs that are legitimately=20 > > shared and PMKs that have been compromised. > > The CAPWAP WG recognizes this ambiguity and recommends=20 > implementers of=20 > > the protocol to review the outcome of IEEE 802.11r efforts=20 > for resolution." > > > > No agreement on this request > > > > > > Perhaps we need further clarification on what "manages a PMK across=20 > > many WTPs" means. > > If "manages a PMK across many WTPs" means that it delivers=20 > the PMK to=20 > > more than one WTP, then: > > > > It is not clear that the CAPWAP specification, current draft does=20 > > indeed provide a mechanism to deliver the PMK to the WTPs, to share=20 > > the PMK across WTPs. Below are the message elements that deliver=20 > > keys: > > - The IEEE 802.11 Add WLAN message element (11.8.1.1) - typically=20 > > delivers the GTK > > - The IEEE 802.11 Mobile Session Key message element (11.7.1.2)=20 > > delivers a session key, the PTK > > - The IEEE 802.11 Update WLAN message element (11.8.1.3) -=20 > typically=20 > > delivers the GTK > > > > CAPWAP does support the ability to securely deliver the GTK and PTK=20 > > from the AC to a WTP. > > CAPWAP supports a secure control interface, requiring mutual=20 > > authentication between the AC and WTPs that are connected to it. > > > > Recommended resolution: > > Reject the comment, with the reason that "An implementation which=20 > > delivers PMKs to WTPs is not in compliance with the CAPWAP protocol" > > > > and change the text in 11.8.1.1 and 11.8.1.3 describing the=20 > key that=20 > > is delivered from: > > "Key: A 32 byte Session Key to use with the encryption policy" to > > "Key: A 32 byte key to use with the encryption key,=20 > typically the GTK" > > > > Comments, discussion please. > > > > Thanks, > > > > Dorothy > > > _________________________________________________________________ > 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 Apr 13 09:20:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU1js-0006Tj-A3 for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 09:20:00 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU1jr-0004hG-Ee for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 09:20:00 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 13ABD4300CB for ; Thu, 13 Apr 2006 06:19:59 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B110B4300F5 for ; Thu, 13 Apr 2006 06:18:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9ED8B430D17 for ; Thu, 13 Apr 2006 06:18:30 -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 7CE64430D05 for ; Thu, 13 Apr 2006 06:18:27 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-3.cisco.com with ESMTP; 13 Apr 2006 06:18:24 -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 k3DDIIhA014538; Thu, 13 Apr 2006 06:18: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); Thu, 13 Apr 2006 06:18:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] Proposed Resolution for Issue 46 - WTP Model and Serialnumber Date: Thu, 13 Apr 2006 06:18:22 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201B82737@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution for Issue 46 - WTP Model and Serialnumber Thread-Index: AcZc3GSUIlNyYOJ7RHOElIC0TdTG2gBzPjWA From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "capwap" X-OriginalArrivalTime: 13 Apr 2006 13:18:23.0077 (UTC) FILETIME=[BD813950:01C65EFC] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE 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="===============1319915559==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c4a3535d1556ada67f8703d3d31591 This is a multi-part message in MIME format. --===============1319915559== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65EFC.BD53EAE8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65EFC.BD53EAE8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dorothy, if you could add the MAC address back into the attribute, then I'm happy with the proposal. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Monday, April 10, 2006 1:21 PM To: capwap Subject: [Capwap] Proposed Resolution for Issue 46 - WTP Model and Serialnumber =09 =09 All, =09 Issue 46 - WTP Model and Serial number currently has the following discussion in the issues list: =09 =09 The length of wtpModel in Section 7.2.4 is specified as 8 bytes. I think this=20 space could be small for some model types.=20 =09 Same way, 24 bytes WTP Serial Number could be small depending upon how serial=20 =09 =09 number is assigned. Section 7.2.4, WTP Board Data =09 The WTP model and serial number value lengths will vary with product and vendor, and are likely to have a wide range of lengths. The current spec fixes the lengths at model number - 8 bytes, and the serial number at 24 bytes. The comment is that these fixed lengths are likely to be too small for some vendors. =09 We could increase the fixed values, with the risk that the values we select will not serve some vendor, or make them excessively long to meet all needs. Another approach is to give the model and serial number a type/length value structure, including a vendor identifier, and allow a variety of lengths.=20 =09 Additional comments on other WTP Board data fields: Need more explicit definition for Card ID and Card Revision values. For some vendors, these are not applicable.=20 If not generally applicable, leave as vendor specific. Indicated these as optional to include, renaming to "board" from "card" to be consistent with the message element name. Can open a new issue for this if needed. . WTP Board Data also includes the Ethernet MAC address. Why is the layer 2 MAC address needed? Recommend=20 removing the Ethernet MAC address field from the WTP Board Data message element (similar to AC MAC address in Issue 39) =09 Recommendation: Change WTP Board Data definition from: =09 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 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =09 | Card ID | Card Revision | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | WTP Model | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | WTP Model |=20 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | WTP Serial Number | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | WTP Serial Number | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|=20 | WTP Serial Number | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | WTP Serial Number | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | WTP Serial Number | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | WTP Serial Number | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=20 | Ethernet MAC Address | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Ethernet MAC Address| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++++ =09 Type: 50 for WTP Board Data Length: 26=20 Card ID: A 2 byte hardware identifier.=20 Card Revision: A 2 byte Revision of the card.=20 WTP Model: 8 byte WTP Model Number.=20 WTP Serial Number: 24 byte WTP Serial Number.=20 Ethernet MAC Address: MAC Address of the WTP's Ethernet interface.=20 =09 to =09 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Vendor Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=3D0 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Value..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type=3D1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =09 | Value.... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+=20 | Optional additional vendor specific WTP board data TLVs =09 =09 Type: 50 for WTP Board Data Length: >=3D 3 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI Network Management Private Enterprise Codes" Type: The following values are supported 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 message element. 3 - Board Revision, A revision number of the board, which MAY be included in the WTP Board Data message element. =09 Length: The length of the value field =09 Value: The value of the indicated field. =09 The Vendor Identifier, WTP Model Number and WTP Serial Number are optionally followed by additional=20 vendor specific values. =09 Comments please. =09 Thanks, =09 Dorothy =09 ------_=_NextPart_001_01C65EFC.BD53EAE8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dorothy, if you could add the MAC address back into the = attribute, then=20 I'm happy with the proposal.
 

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

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Monday, April 10, = 2006 1:21=20 PM
To: capwap
Subject: [Capwap] Proposed = Resolution for=20 Issue 46 - WTP Model and Serialnumber

All,

Issue 46 - WTP Model and Serial number = currently has=20 the following discussion in the issues list:

The length of =
wtpModel in Section 7.2.4 is specified as 8 bytes. I think this =

space could be small for some model types. 

Same way, 24 =
bytes WTP Serial Number could be small depending upon how serial 


number is assigned.

Section 7.2.4, WTP Board = Data

The WTP=20 model and serial number value lengths will vary with product and = vendor, and=20 are likely
to have a wide range of lengths. The current spec fixes = the=20 lengths at
model number - 8 bytes, and the serial number at 24 = bytes. The=20 comment is that these fixed lengths
are likely to be too small for = some=20 vendors.

We could increase the fixed values, with the risk that = the=20 values we select will not serve some vendor, or make
them = excessively long=20 to meet all needs.
Another approach is to give the model and serial = number=20 a type/length value structure, including a vendor identifier, = and
allow a=20 variety of lengths.

Additional comments on other WTP Board = data=20 fields:
Need more explicit definition for  Card ID and Card = Revision=20 values. For some vendors, these are not applicable.
If not = generally=20 applicable, leave as vendor specific. Indicated these as optional to = include,=20 renaming to "board" from "card"
to be consistent with the message = element=20 name. Can open a new issue for this if needed.
.
WTP Board Data = also=20 includes the Ethernet MAC address. Why is the layer 2 MAC address = needed?=20 Recommend
removing the Ethernet MAC address field from the WTP = Board Data=20 message element (similar to AC MAC address
in Issue=20 39)

Recommendation: Change WTP Board Data definition=20 = from:

0          = ;            =     =20 1                   =    =20    2                 =  =20        3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9=20 0 1 2 3 4 5 6 7 8 9 0 1=20 =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&nbs= p;=20
|           &= nbsp;          =20 Card ID        =20 |           Card=20 = Revision           = ;          =20 = |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+=20 =
|           &n= bsp;           &nb= sp;           &nbs= p;=20 WTP Model                =    =20                    =20   =20 = |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+=20 =
|           &n= bsp;           &nb= sp;           &nbs= p;=20 WTP Model                 =  =20                     =  =20   | =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =
|           &n= bsp;           &nb= sp;    =20 WTP Serial=20 = Number           &= nbsp;           &n= bsp;           &nb= sp;  =20 = |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+=20 =
|           &n= bsp;           &nb= sp;    =20 WTP Serial=20 = Number           &= nbsp;           &n= bsp;           &nb= sp;  =20 = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|=20 =
|           &n= bsp;           &nb= sp;    =20 WTP Serial=20 = Number           &= nbsp;           &n= bsp;           &nb= sp;  =20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = =
|           &n= bsp;           &nb= sp;    =20 WTP Serial=20 = Number           &= nbsp;           &n= bsp;           &nb= sp;  =20 = |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+=20 =
|           &n= bsp;           &nb= sp;    =20 WTP Serial=20 = Number           &= nbsp;           &n= bsp;           &nb= sp;  =20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = =
|           &n= bsp;           &nb= sp;    =20 WTP Serial=20 = Number           &= nbsp;           &n= bsp;           &nb= sp;  =20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=20 =
|           &n= bsp;          =20 Ethernet MAC Address =20 =             &= nbsp;           &n= bsp;           =20 = |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+=20 =
|           &n= bsp;           =20 Ethernet MAC Address|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = ++++

Type:=20 50 for WTP Board Data
 Length: 26
Card ID: A 2 byte = hardware=20 identifier.
Card Revision: A 2 byte Revision of the card.
WTP = Model: 8=20 byte WTP Model Number.
WTP Serial Number: 24 byte WTP Serial = Number.=20
Ethernet MAC Address: MAC Address of the WTP's Ethernet interface. = =

to

0         =             &= nbsp;    =20 1                   =    =20    2                 =  =20        3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9=20 0 1 2 3 4 5 6 7 8 9 0 1=20 =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|&nbs= p;            = ;            =       =20 Vendor Identifier               =  =20                 =20 = |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|            = ;     =20 Type=3D0            =  =20 |           =20 = Length           &= nbsp;         =20  =20 = |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|           &nbs= p;            = ;         =20 Value.....                =  =20                     =  =20              =     =20 =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|&nbs= p;            = ;    =20 Type=3D1            =  =20 |           =20 = Length           &= nbsp;          =20   = |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
|           &= nbsp;           &n= bsp;         =20 Value....                =    =20                     =  =20            =20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ = |=20 Optional additional vendor specific WTP board data = TLVs


Type: 50=20 for WTP Board Data
Length: >=3D 3
Vendor Identifier: A 32-bit = value=20 containing the IANA assigned "SMI Network Management Private = Enterprise=20 Codes"
Type: The following values are supported
0 - WTP Model = Number;=20 The WTP Model Number MUST be included in the WTP Board Data message=20 element.
1 - WTP Serial Number; The WTP Serial Number MUST be = included in=20 the WTP Board Data message element.
2 - Board ID; A  hardware=20 identifier, which MAY be included in the WTP Board Data message = element.
3=20 - Board Revision, A revision number of the board, which MAY be = included in the=20 WTP Board Data message element.

Length: The length of the value = field

Value: The value of the indicated field.

The = Vendor=20 Identifier, WTP Model Number and WTP Serial Number are optionally = followed by=20 additional
vendor specific values.

Comments=20 = please.

Thanks,

Dorothy
------_=_NextPart_001_01C65EFC.BD53EAE8-- --===============1319915559== 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 --===============1319915559==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Apr 13 09:21:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU1ku-0007Aq-Ky for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 09:21:04 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU1kt-0004iv-Go for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 09:21:04 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1B9A8430110 for ; Thu, 13 Apr 2006 06:21:03 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id C20E4430067 for ; Thu, 13 Apr 2006 06:18:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id B44AB398010 for ; Thu, 13 Apr 2006 06:18:27 -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 7B1A439802F for ; Thu, 13 Apr 2006 06:18:25 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-2.cisco.com with ESMTP; 13 Apr 2006 06:18:25 -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 k3DDIIhI014538; Thu, 13 Apr 2006 06:18:25 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Apr 2006 06:18:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 13 Apr 2006 06:18:22 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201B82736@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WTP Mac Type negotiation. Thread-Index: AcZdW7Mbv8wWL/q5Q9max+mTMYNcRQBTVk2Q From: "Pat Calhoun (pacalhou)" To: "sujay" , "Saravanan Govindan" , X-OriginalArrivalTime: 13 Apr 2006 13:18:22.0859 (UTC) FILETIME=[BD5FF5B0:01C65EFC] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.375 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE X-Spam-Level: Cc: Subject: [Capwap] RE: WTP Mac Type negotiation. 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="===============1038406188==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: dd9ffe26482d533f4d1fa531728a7327 This is a multi-part message in MIME format. --===============1038406188== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65EFC.BD3C1364" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65EFC.BD3C1364 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Could you please define these new modes of operation? =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: sujay [mailto:sujayg@huawei.com]=20 Sent: Tuesday, April 11, 2006 4:32 AM To: 'Saravanan Govindan'; capwap@frascone.com; Pat Calhoun (pacalhou) Subject: RE: WTP Mac Type negotiation. =09 =09 Saravanan, I suggest not to limit the AC's mode of operation, by classifying modes of operation viz Control - bias=20 and Load-bias mode. =20 Keeping it simple; =20 5.2.6. Operating Mode =20 The Operating Mode message element specifies the mode of operation for a WTP capable of =20 operating in both Local-MAC and Split-MAC modes.=20 =20 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Operating Mode | +-+-+-+-+-+-+-+-+ =20 Type: TBD =20 Length: 1 =20 Operating Mode: The selected mode for WTP operation =20 < 0: Control-bias mode, WTP operates in Split-MAC mode =20 1: Load-bias mode, WTP operates in Local-MAC mode=20 /> change to; =09 < 0: Split-MAC mode, WTP operates in Split-MAC mode =20 1: Local-MAC mode, WTP operates in Local-MAC mode=20 /> =20 =09 Any suggestions? Sujay =20 =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Friday, March 31, 2006 8:14 AM To: sujay; capwap@frascone.com Subject: RE: WTP Mac Type negotiation. =09 =09 Dear All, =20 Following from Sujay G's suggestion, this is text for mode selection in the case where a WTP supports both split-MAC and local-MAC modes and can also support the different tunnel options.=20 =20 Cheers, =09 Saravanan =20 =20 =20 =20 ----oooo---- =20 Introduce how operational mode is selected in Section 2 (Protocol Overview) [Paragraph 3, after 2nd sentence] =20 "The WTPs specify their operational modes in their Discovery Request message, to which the responding AC selects particular operational modes and specifies them in the Discovery Response message." =20 =20 =20 Then in Section 5.2 (Discovery Response) [After Paragraph 2, include following paragraph] =20 =20 " In the case where a requesting WTP is capable of both Local-MAC and Split-MAC operations (MAC Type [Section 5.1.4] value "2") or where a WTP is capable of all types of bridging (Frame Type [Section 5.1.5] value "7"), AC determines the particular operating mode based on the following; =20 i. Control-bias Mode =20 In this mode, the AC has greater control of WTP operations. So the AC instructs the requesting WTP to operate in Split-MAC mode.=20 =20 ii. Load-bias Mode =20 In this mode, the AC reduces processing load of WTP operations. So the AC instructs the requesting WTP to operate in Local-MAC mode. " =20 =20 Introduce Operation Mode message element as Section 5.2.6 (Operating Mode). =20 =20 5.2.6. Operating Mode =20 The Operating Mode message element specifies the mode of operation for a WTP capable of =20 operating in both Local-MAC and Split-MAC modes.=20 =20 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Operating Mode | +-+-+-+-+-+-+-+-+ =20 Type: TBD =20 Length: 1 =20 Operating Mode: The selected mode for WTP operation =20 0: Control-bias mode, WTP operates in Split-MAC mode =20 1: Load-bias mode, WTP operates in Local-MAC mode=20 =20 ----XXXX---- =20 =20 =20 =20 =20 =20 =20 =20 =20 -----Original Message----- From: sujay [mailto:sujayg@huawei.com]=20 Sent: Friday, March 17, 2006 2:32 PM To: capwap@frascone.com Cc: Saravanan Govindan Subject: WTP Mac Type negotiation. =20 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal =20 =20 The CAPWAP does not specify as to how the selection is made if the WTP=20 Can support both Modes Split and Local and Frame (Tunnel ) type. =20 The WTP specifies MAC Type and Frame Type in Discovery Request message, but if it supports=20 both modes , there is no provision for the AC to select the working mode. =20 =20 Recommendation : 1. Add the WTP mode and WTP tunnel type messages in the configure response ? Which makes it binding=20 agnostic. =20 2. The logic for choosing WTP mode type on the AC could depend on the load, and user policy. =20 Solicit comments. =20 Regds, Sujay =20 =20 ------_=_NextPart_001_01C65EFC.BD3C1364 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message=
Could=20 you please define these new modes of operation?
 

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

 

From: sujay = [mailto:sujayg@huawei.com]=20
Sent: Tuesday, April 11, 2006 4:32 AM
To: = 'Saravanan=20 Govindan'; capwap@frascone.com; Pat Calhoun = (pacalhou)
Subject: RE:=20 WTP Mac Type negotiation.

Saravanan,
I suggest not to = limit the=20 AC's mode of operation,
by classifying = modes of=20 operation viz Control - bias
and Load-bias=20 mode.
 
Keeping it=20 simple;
 

5.2.6.  =20 Operating Mode

 

   = The=20 Operating Mode message element specifies the mode of operation for a = WTP=20 capable of  

   = operating=20 in both Local-MAC and Split-MAC modes.

 

      =
0
      0 1 2 3 4 5 6 =
7
     =
+-+-+-+-+-+-+-+-+
     |Operating Mode =
|
     =
+-+-+-+-+-+-+-+-+
 
   Type:  =
TBD
 
   Length:  =
1
 
   Operating Mode:  The selected mode for WTP =
operation
 
<
        0: Control-bias =
mode, WTP operates in Split-MAC mode
 =

        1: Load-bias =
mode, WTP operates in Local-MAC mode 
/>
change to;
<
        0: Split-MAC mode, =
WTP operates in Split-MAC mode
 =

        1: Local-MAC =
mode, WTP operates in Local-MAC mode 
/>
 
Any =
suggestions?
Sujay
 
 
-----Original Message-----
From: = Saravanan=20 Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] =
Sent:=20 Friday, March 31, 2006 8:14 AM
To: sujay;=20 capwap@frascone.com
Subject: RE: WTP Mac Type=20 negotiation.

Dear=20 All,

 

Following = from Sujay=20 G's suggestion, this is text for mode selection in the case where a = WTP=20 supports both split-MAC and local-MAC modes and can also support the = different tunnel options.

 

Cheers,

Saravanan

 

 

 

 

----oooo----

<NOTE>=20

Introduce = how=20 operational mode is selected in Section 2 (Protocol Overview) = [Paragraph 3,=20 after 2nd sentence]

<END=20 NOTE>

 

"The WTPs = specify=20 their operational modes in their Discovery Request message, to which = the=20 responding AC selects particular operational modes and specifies = them in the=20 Discovery Response message."

 

 

<NOTE>=20

Then in = Section 5.2=20 (Discovery Response) [After Paragraph 2, include following=20 paragraph]

<END=20 NOTE>

 

 

" In the = case where a=20 requesting WTP is capable of both Local-MAC and Split-MAC operations = (MAC=20 Type [Section 5.1.4] value "2") or where a WTP is capable of all = types of=20 bridging (Frame Type [Section 5.1.5] value "7"), AC determines the=20 particular operating mode based on the=20 following;

 

i. = Control-bias=20 Mode

 

In this = mode, the AC=20 has greater control of WTP operations. So the AC instructs the = requesting=20 WTP to operate in Split-MAC mode.

 

ii. = Load-bias=20 Mode

 

In this = mode, the AC=20 reduces processing load of WTP operations. So the AC instructs the=20 requesting WTP to operate in Local-MAC mode. = "

 

 

<NOTE>

Introduce = Operation=20 Mode message element as Section 5.2.6 (Operating=20 Mode).

<END=20 NOTE>

 

 

5.2.6.  =20 Operating Mode

 

   The=20 Operating Mode message element specifies the mode of operation for a = WTP=20 capable of  

  =20 operating in both Local-MAC and Split-MAC modes.=20

 

      =
0
      0 1 2 3 4 5 6 =
7
     =
+-+-+-+-+-+-+-+-+
     |Operating Mode =
|
     =
+-+-+-+-+-+-+-+-+
 
   Type:  =
TBD
 
   Length:  =
1
 
   Operating Mode:  The selected mode for WTP =
operation
 
        0: Control-bias =
mode, WTP operates in Split-MAC =
mode
 =

        1: Load-bias =
mode, WTP operates in Local-MAC mode

 

----XXXX----

 

 

 

 

 

 

 

 

 

-----Original Message-----
From: sujay=20 [mailto:sujayg@huawei.com]
Sent: Friday, March 17, 2006 2:32 = PM
To:=20 capwap@frascone.com
Cc: Saravanan Govindan
Subject: WTP Mac = Type=20 negotiation.

 

Importance: Normal

X-Priority: 3 (Normal)

X-MSMail-priority: Normal

 

 

The CAPWAP does not specify as to how the = selection=20 is made if the WTP

Can support both Modes Split and Local and = Frame=20 (Tunnel ) type.

 

The WTP specifies MAC Type and Frame = Type  in=20 Discovery Request message,

but if it supports =

both modes , there is no provision for the = AC to=20 select the working

mode.

 

 

Recommendation = :

1. Add the WTP mode and WTP tunnel type=20 messages  in the

configure response ? Which  makes it = binding=20

agnostic.

 

2. The logic for choosing WTP mode type on = the AC=20 could depend on the

load, and user = policy.

 

Solicit = comments.

 

Regds,

Sujay

 

 

= ------_=_NextPart_001_01C65EFC.BD3C1364-- --===============1038406188== 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 --===============1038406188==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Apr 13 09:22:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU1lv-0007Vn-EC for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 09:22:07 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU1lu-0004kI-Af for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 09:22:07 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E72314300E8 for ; Thu, 13 Apr 2006 06:22:05 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4A69143009A for ; Thu, 13 Apr 2006 06:18:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 383E2430D18 for ; Thu, 13 Apr 2006 06:18:28 -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 0C0FF430D05 for ; Thu, 13 Apr 2006 06:18:24 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-3.cisco.com with ESMTP; 13 Apr 2006 06:18:24 -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 k3DDIIh8014538; Thu, 13 Apr 2006 06:18: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); Thu, 13 Apr 2006 06:18:22 -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 - Issue oncombiningmessages Date: Thu, 13 Apr 2006 06:18:22 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201B82735@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 45 - Issue oncombiningmessages Thread-Index: AcZeQdnfdBSaZ/ISTVa6x5iue6ADJAAZrVVw From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "Saravanan Govindan" X-OriginalArrivalTime: 13 Apr 2006 13:18:22.0749 (UTC) FILETIME=[BD4F2CD0:01C65EFC] X-Virus-Scanned: by amavisd-new-20030616-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, 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="===============1294041271==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 8949cc4fd406a34204d26327803246d1 This is a multi-part message in MIME format. --===============1294041271== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65EFC.BD1D14D2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65EFC.BD1D14D2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe the request is for a *new* set of statistics to be sent from the WTP to the AC. If this is the case, then a separate issue is required that describes this request. I think I was just as confused as Dorothy that the request was to include the existing dot11 statistics within the echo request, which didn't seem to make sense to me. =20 Having said that, I believe that sending an echo should not require digging everywhere around the system to collect various statistics, as I believe this would create overhead on the WTP. If this is localized information, and limited in nature, then perhaps the impact is minimal. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Wednesday, April 12, 2006 8:00 AM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Proposed Resolution to Issue 45 - Issue oncombiningmessages =09 =09 Saravanan, Richard, =09 I suggest we set aside the question of how the statistics might be transported for the moment - either in WTP Event Request, Echo Request or some new message, and first agree on the nature/definition of the statistics themselves. We are talking about non-802.11 specific statistics, as the 802.11 specific ones, or new 802.11 ones would go in 11.7.2.1: =09 WPT buffer levels - which buffers? Concern that this would be implementation specific Congestion conditions - congestion on the wireless link? On the WTP to AC link? etc - needs to be specified. =09 Richard suggests Network Congestion - which network, the wireless one or the WTP to AC link. How is the level of congestion measured? Traffic Loading - How is this measured? Which traffic?=20 Channel Interferences - Need to specify. Concern that there is overlap with what will be coming in .11k for radio measurement =09 Thanks, =09 Dorothy =09 On 4/11/06, Saravanan Govindan wrote:=20 Hi Dorothy, =20 WTP Event Request is being positioned for technology-specific statistics exchange (Section 2.1). So my understanding is that WTP Event Request would be used for information such as transmission attempts, beacon and probe counts, decryption errors etc.=20 =20 In addition to technology-specific information, the AC also needs big-picture information on factors affecting the WLAN as a whole. This would include WTP buffer levels, congestion conditions, etc. This information is not specific to a technology but does affect the WLAN. It is this type of statistics that I suggest the Echo Request exchange. =20 Cheers, =09 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Tuesday, April 11, 2006 10:50 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages =20 =09 Saravanan, Richard,=20 =09 First of all, thank you for your comments. =09 Clearly, the WTP must have a means to provide statistics and other relevant data to the AC.. =09 The question becomes, what specific mechanism should be used?=20 Overloading the echo request message is one way. CAPWAP has the WTP event request message, section 8.5, and already includes the decryption error report, and can include the .11 specific statistics report. =09 Why is using the WTP event report to report statistics not sufficient? We should add other applicable CAPWAP message elements to be included in it. =09 =09 Thanks, =09 Dorothy=20 =09 On 4/10/06, Saravanan Govindan wrote:=20 =09 Hi Dorothy, =20 I think this recommendation add substantial value to the CAPWAP protocol. There have been discussions on the need for aggregating statistics information from the WTP to AC. The Echo Request offers a way for achieving this. The mechanisms for statistics exchanges - timer, periodic exchange - are available with Echo Request. So I think it is of value to keep Echo Request and add statistics information fields to it.=20 =20 Cheers, =20 Saravanan =20 =20 =20 =09 ________________________________ From: Dorothy Stanley [mailto: dstanley1389@gmail.com]=20 Sent: Tuesday, April 11, 2006 1:20 AM To: capwap Subject: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages =20 All, =09 Issue 45, Issue on Combining messages currently has the following discussion in the issues database: Currently, the keepalive and statistics messages are separated. Separate=20 =09 =09 =09 messages for keepalive signaling and statistics can lead to high overhead.=20 =09 =09 =09 =09 =09 Initial analysis have shown that these overhead can be reduced significantly=20 =09 =09 =09 =09 =09 if the messages can be combined. =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 Recommendation: =09 =09 =09 =09 =09 =09 =09 =09 To combine the keepalive and statistics message into one combined message,=20 =09 =09 =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. =09 Recommended resolution: reject the comment, with the explanation in the above paragraph =09 Comments please. =09 Thanks, =09 Dorothy =20 ------_=_NextPart_001_01C65EFC.BD1D14D2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 believe the request is for a *new* set of statistics to be sent from the = WTP to=20 the AC. If this is the case, then a
separate issue is required that describes this request. I think = I was=20 just as confused as Dorothy that the request
was to=20 include the existing dot11 statistics within the echo request, which = didn't seem=20 to make sense to me.
 
Having=20 said that, I believe that sending an echo should not require digging = everywhere=20 around the system to collect various
statistics, as I believe this would create overhead on the WTP. = If this=20 is localized information, and limited in nature,
then=20 perhaps the impact is minimal.

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

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Wednesday, April 12, = 2006=20 8:00 AM
To: Saravanan Govindan
Cc:=20 capwap
Subject: Re: [Capwap] Proposed Resolution to Issue 45 = - Issue=20 oncombiningmessages

Saravanan, Richard,

I suggest we set aside the = question of=20 how the statistics might be  transported for the moment - either = in WTP=20 Event Request, Echo Request or some new
message, and first agree on = the=20 nature/definition of the statistics themselves. We are talking about=20 non-802.11 specific statistics, as the 802.11
specific ones, or new = 802.11=20 ones would go in 11.7.2.1:

WPT = buffer=20 levels - which buffers? Concern that this would be implementation=20 specific
Congestion conditions - congestion on the wireless link? = On the=20 WTP to AC link?
etc - needs to be specified.

Richard=20 suggests
Network Congestion - which network, the wireless one or = the WTP to=20 AC link. How is the level of congestion measured?
Traffic Loading - = How is=20 this measured? Which traffic?
Channel Interferences - Need to = specify.=20 Concern that there is overlap with what will be coming in .11k for = radio=20 measurement

Thanks,

Dorothy
On 4/11/06, Saravanan=20 Govindan <Saravanan.Govindan@sg= .panasonic.com>=20 wrote:=20

Hi = Dorothy,

 

WTP Event Request is = being=20 positioned for technology-specific statistics exchange (Section = 2.1). So my=20 understanding is that WTP Event Request would be used for = information such=20 as transmission attempts, beacon and probe counts, decryption errors = etc.=20

 

In addition to=20 technology-specific information, the AC also needs big-picture = information=20 on factors affecting the WLAN as a whole. This would include WTP = buffer=20 levels, congestion conditions, etc. This information is not specific = to a=20 technology but does affect the WLAN. It is this type of statistics = that I=20 suggest the Echo Request exchange.

 

Cheers,


Saravanan

 

 

 

 

From:=20 Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Tuesday, April 11, 2006 = 10:50=20 PM
To: Saravanan=20 Govindan
Cc:=20 capwap
Subject: = Re:=20 [Capwap] Proposed Resolution to Issue 45 - Issue on=20 combiningmessages

 

Saravanan, Richard,

First of all, thank you for = your=20 comments.

Clearly, the WTP must have a means to provide = statistics=20 and other relevant data to the AC..

The question becomes, = what=20 specific mechanism should be used?
Overloading the echo request = message=20 is one way. CAPWAP  has the WTP event request = message,
section 8.5,=20 and already includes the decryption error report, and can include = the .11=20 specific
statistics report.

Why is using the WTP event = report to=20 report statistics not sufficient? We should add other applicable = CAPWAP=20 message elements
to be included in = it.

Thanks,

Dorothy=20

On 4/10/06, Saravanan Govindan <Saravanan.Govindan@sg.panasonic.com>=20 wrote:

Hi = Dorothy,

 

I think this = recommendation add=20 substantial value to the CAPWAP protocol. There have been = discussions on the=20 need for aggregating statistics information from the WTP to AC. The = Echo=20 Request offers a way for achieving this. The mechanisms for = statistics=20 exchanges – timer, periodic exchange – are available = with Echo Request. So I=20 think it is of value to keep Echo Request and add statistics = information=20 fields to it.

 

Cheers,

 

Saravanan

 

 

 

From:=20 Dorothy Stanley [mailto: dstanley1389@gmail.com]
Sent: Tuesday, April 11, 2006 = 1:20=20 AM
To: = capwap
Subject: [Capwap] Proposed = Resolution=20 to Issue 45 - Issue on = combiningmessages

 

All,

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

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 =






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=20 Response Messages, which are used for keep-alive
purposes, and do = not=20 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 = statistics related measurement elements must be reported
to the = AC from=20 the 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=20 some benefit in keeping the echo messages simple,
rather than=20 complicating the processing of those messages.  It is true that = small=20 messages (echo request, response) have high overhead.
In this = case, the=20 design choice is to accept the overhead as the cost of simplicity in = design=20 and implementation.

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

Comments=20 please.

Thanks,

Dorothy

 


------_=_NextPart_001_01C65EFC.BD1D14D2-- --===============1294041271== 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 --===============1294041271==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Apr 13 09:22:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU1mY-0008A6-A1 for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 09:22:46 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU1mX-0004l8-HC for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 09:22:46 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1A39D430165 for ; Thu, 13 Apr 2006 06:22:45 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 96D0D4300EC for ; Thu, 13 Apr 2006 06:18:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8956039802F for ; Thu, 13 Apr 2006 06:18:30 -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 7080A398007 for ; Thu, 13 Apr 2006 06:18:27 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-3.cisco.com with ESMTP; 13 Apr 2006 06:18:24 -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 k3DDIIhC014538; Thu, 13 Apr 2006 06:18: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); Thu, 13 Apr 2006 06:18:23 -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 for Issue 46 - WTP Model and Serialnumber Date: Thu, 13 Apr 2006 06:15:08 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201B82738@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution for Issue 46 - WTP Model and Serialnumber Thread-Index: AcZd7vWwjbXfySCySgmMQA06bEYqJQBDU/og From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" , "Dorothy Stanley" X-OriginalArrivalTime: 13 Apr 2006 13:18:23.0312 (UTC) FILETIME=[BDA51500:01C65EFC] 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: f60fbf3dbcaca652b6d10036f0630412 This works for me as well. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com]=20 > Sent: Tuesday, April 11, 2006 10:06 PM > To: Dorothy Stanley > Cc: capwap > Subject: Re: [Capwap] Proposed Resolution for Issue 46 - WTP=20 > Model and Serialnumber >=20 > HI, >=20 > I believe that both the "WTP descriptor" (section 5.1.2) and=20 > the "WTP Board data" (section 7.2.4) message elements need work. >=20 > Previous work has been done that covers both of these=20 > elements is in RFC 4133, which contains the Entity MIB=20 > module. In it, there are the following definitions which come=20 > close the the info in the "WTP descriptor" and "WTP board date" > message elements: > entPhysicalIndex - index of physical component (an integer) > entPhysicalVendorType - hardware type, value is an OID > entPhysicalHardwareRev - hardware revision, value encoded=20 > in UTF-8 (max length of 255 octets) > entPhysicalFirmwareRev - firmware revision, (value encoded > same as hardware rev) > entPhysicalSoftwareRev - software revision, (value encoded > same as hardware rev) > entPhysicalSerialNum - serial number,- value encoded in=20 > UTF-8 (max length of 32 octets) > entPhysicalMfgName - manufacturer name, (value encoded > same as hardware rev) > entPhysicalModelName - model name, (value encoded > same as hardware rev) >=20 > The entity MIB module allows all of the physical commponents=20 > of a device to be described. I can't determine when reading section > 7.2 (and section 7.2.4) whether or not multiple "WTP board data" > message elements are returned. It's certainly the case that a=20 > majority of current WTPs are "nonmodular", but there may be=20 > ones that have "field replacable units" for radios or other=20 > components. Thus, I suggest that multiple "board data"=20 > message elements be returnable. >=20 > In addition the Entity MIB has the following definitions=20 > which I suggest be supported by CAPWAP message "board data"=20 > message element: > entPhysicalAssetID - asset ID, (value encoded > same as serial number) > entPhysicalMfgDate - manufacture date, a date/time value > encoded in format defined by > TC DateAndTime found in RFC 2579 > entPhysicalIsFRU - indication if component is a field > replacable unit > entPhysicalUris - a list of URIs (the intent is to support=20 > CLEI codes, see RFC 4152) >=20 > The Entity MIB also has the following definitions, which I=20 > suggest are not too useful: > entPhysicalDescr - textual description of the component > (its redundant with manufacturer > and model name) > entPhysicalContainedIn - info on physical containment > (WTPs don't have complex physical > relationships of components) > entPhysicalParentRelPos - info on physical arrangement > (WTPs don't have complex physical > relationships of components) > entPhysicalClass - class of physical component (WTPs > will not have different classes) > entPhysicalName - name used in CLI commands (not needed by > CAPWAP) > entPhysicalAlias - an operator specified alternative name > (not needed by CAPWAP) >=20 > Thus, I suggest that the "WTP info" and the "WTP Board data" > message elements be change to the following to align with the=20 > data model defined in the Entity MIB module: >=20 > WTP Info would have the following fields: > 1) manufacturer name (encoded in UTF-8, max length 255 octets) > 2) model name (same encoding as mgt name) > 3) serial number (encoded in UTF-8, max length of 32 octets) > 4) optional hardware rev (same encoding as mgt name) > 5) optional manufacturing date (encoded in text, not binary > as defined in DateTime TC) > 6) optional firmware rev (note: this is NOT the image > rev) (same encoding as mgt name) > 7) optional asset ID (encoded the same as serial number) > 8) boot software version (same encoding as mgt name) > 9) list of images, with fields: > a) is running - flag > b) source - memory, store1, store2, etc > c) version (same encoding as mgt name) > 10) Number of radios >=20 > "Board data" would be renamed "component data" and would only=20 > be returned if the WTP contained separatably identifiable=20 > components. It would have only fields > 1 through 6 of WTP info, plus a "isFRU" field. > =20 > More on this later in the "boot model" description. > =20 > On Mon, 10 Apr 2006, Dorothy Stanley wrote: > > All, > >=20 > > Issue 46 - WTP Model and Serial number currently has the following=20 > > discussion in the issues list: > >=20 > > The length of wtpModel in Section 7.2.4 is specified as 8 bytes. I=20 > > think this space could be small for some model types. > >=20 > > Same way, 24 bytes WTP Serial Number could be small=20 > depending upon how=20 > > serial > >=20 > > number is assigned. > >=20 > >=20 > > Section 7.2.4, WTP Board Data > >=20 > > The WTP model and serial number value lengths will vary=20 > with product=20 > > and vendor, and are likely to have a wide range of lengths. The=20 > > current spec fixes the lengths at model number - 8 bytes, and the=20 > > serial number at 24 bytes. The comment is that these fixed=20 > lengths are=20 > > likely to be too small for some vendors. > >=20 > > We could increase the fixed values, with the risk that the=20 > values we=20 > > select will not serve some vendor, or make them excessively long to=20 > > meet all needs. > > Another approach is to give the model and serial number a=20 > type/length=20 > > value structure, including a vendor identifier, and allow a=20 > variety of=20 > > lengths. > >=20 > > Additional comments on other WTP Board data fields: > > Need more explicit definition for Card ID and Card=20 > Revision values.=20 > > For some vendors, these are not applicable. > > If not generally applicable, leave as vendor specific.=20 > Indicated these=20 > > as optional to include, renaming to "board" from "card" > > to be consistent with the message element name. Can open a=20 > new issue=20 > > for this if needed. > > . > > WTP Board Data also includes the Ethernet MAC address. Why is the=20 > > layer 2 MAC address needed? Recommend removing the Ethernet MAC=20 > > address field from the WTP Board Data message element=20 > (similar to AC=20 > > MAC address in Issue 39) > >=20 > > Recommendation: Change WTP Board Data definition from: > >=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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Card ID | Card > > Revision | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | WTP Model > > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | WTP Model > > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | WTP Serial > > Number | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | WTP Serial > > Number | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| > > | WTP Serial > > Number | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | WTP Serial > > Number | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | WTP Serial > > Number | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | WTP Serial > > Number | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > > | Ethernet MAC Address > > | =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ethernet MAC Address| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++++ > >=20 > > Type: 50 for WTP Board Data > > Length: 26 > > Card ID: A 2 byte hardware identifier. > > Card Revision: A 2 byte Revision of the card. > > WTP Model: 8 byte WTP Model Number. > > WTP Serial Number: 24 byte WTP Serial Number. > > Ethernet MAC Address: MAC Address of the WTP's Ethernet interface. > >=20 > > to > >=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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > | Vendor Identifier > > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type=3D0 | > > Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > | Value..... > >=20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > | Type=3D1 | > > Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Value.... > >=20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ > > | Optional additional vendor specific WTP board data TLVs > >=20 > >=20 > > Type: 50 for WTP Board Data > > Length: >=3D 3 > > Vendor Identifier: A 32-bit value containing the IANA assigned "SMI=20 > > Network Management Private Enterprise Codes" > > Type: The following values are supported 0 - WTP Model=20 > Number; The WTP=20 > > Model Number MUST be included in the WTP Board Data message element. > > 1 - WTP Serial Number; The WTP Serial Number MUST be=20 > included in the=20 > > WTP Board Data message element. > > 2 - Board ID; A hardware identifier, which MAY be included=20 > in the WTP=20 > > Board Data message element. > > 3 - Board Revision, A revision number of the board, which MAY be=20 > > included in the WTP Board Data message element. > >=20 > > Length: The length of the value field > >=20 > > Value: The value of the indicated field. > >=20 > > The Vendor Identifier, WTP Model Number and WTP Serial Number are=20 > > optionally followed by additional vendor specific values. > >=20 > > Comments please. > >=20 > > Thanks, > >=20 > > Dorothy > >=20 > Regards, > /david t. perkins >=20 >=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 >=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 Apr 13 09:48:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU2BT-0003b0-7i for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 09:48:31 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU2BR-0005KR-8p for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 09:48:31 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9AF434300FB for ; Thu, 13 Apr 2006 06:48:28 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 18CEC430067 for ; Thu, 13 Apr 2006 06:47:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id F32BE430D5C for ; Thu, 13 Apr 2006 06:47:56 -0700 (PDT) Received: from stlssgcorpmailfw2.anheuser-busch.com (stlssgcorpmailfw2.anheuser-busch.com [151.145.63.132]) by hermes.tigertech.net (Postfix) with ESMTP id 03807430D57 for ; Thu, 13 Apr 2006 06:47: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" Subject: Re: [Capwap] New Issue - Local MAC MUST vs MAY forward association request messages Date: Thu, 13 Apr 2006 08:47:51 -0500 Message-ID: <89525CB1203D7346BBBDFCE9CECB47CF01CD8F35@STLEXGUSR31.abc.corp.anheuser-busch.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Capwap] New Issue - Local MAC MUST vs MAY forward association request messages thread-index: AcZfANsw4Rm6YtYNQ1yLDcLZdEvbnA== From: "Kraus, Michael" To: X-OriginalArrivalTime: 13 Apr 2006 13:47:51.0795 (UTC) FILETIME=[DBBE2C30:01C65F00] X-MessageInspectorSig: 80970756750fcdaf827a212f8aeff604 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_50_60, HTML_MESSAGE 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.1 (/) X-Scan-Signature: 872695ea777a517bf5717e5acc69f8be ----344510-7129147-1017340393=:3379 Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65F00.DB8F2911" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65F00.DB8F2911 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David, I agree technically that in local MAC operation that this could be a MAY f= rom a functionality perspective. However, then a provision for the WTP to repor= t summaries of when the association requests are received might be warranted t= o be considered. Without this information, troubleshooting association requests and the WTP/AC's failure to respond (bugs) become more difficult. That being the ca= se, it might be a lesser evil to just forward on the association requests to the= AC even with a WTP in local MAC operation. (Which would keep this statement a MUST). 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 In response to: Message: 2 Date: Wed, 12 Apr 2006 08:41:37 -0700 (PDT) From: =22David T. Perkins=22 Subject: Re: =5BCapwap=5D New Issue - Local MAC MUST vs MAY forward association request messages To: Dorothy Stanley Cc: capwap Message-ID: Content-Type: TEXT/PLAIN; charset=3DUS-ASCII HI, In a CAPWAP environment, irregardless of 802.11 association, the AC determin= es the 1) authentication 2) authorization and provides the management interface for tracking client 1) status 2) statistics And overal system optimization. The above attributes differentiates a coordniated collection of independent = APs from a CAPWAP system consisting of a AC and WTPs. So, if changing to MAY does not result in loss of control needed to support = any of the above attributes, then the change would be OK. Otherwise, I don't bel= ieve it would be a proper change. On Tue, 11 Apr 2006, Dorothy Stanley wrote: > All, > > Section 11.1.2 Local MAC describes the Local MAC operation. It > currently states (second paragraph below Figure 6): > > While the MAC is terminated on the WTP, it is necessary for the AC to > be aware of mobility events within the WTPs. > As a consequence, the WTP MUST forward the IEEE 802.11 Association > Requests to the AC, and the AC MAY reply with a failed Association > Response if it deems it necessary. > > > Since this is the Local MAC case, it seems that a MAY should be > sufficient. > > Recommended change: > > The MAC is terminated on the WTP, but the AC may need to be aware of > mobility events within the WTPs. > As a consequence, the WTP MAY forward the IEEE 802.11 Association > Requests to the AC, and the AC MAY reply with a failed Association > Response. > > Comments? > > Thanks, > > Dorothy Regards, /david t. perkins 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 ------_=_NextPart_001_01C65F00.DB8F2911 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <=21DOCTYPE HTML PUBLIC =22-//W3C//DTD HTML 3.2//EN=22> Re: =5BCapwap=5D New Issue - Local MAC MUST vs MAY forward associatio= n request messages <=21-- Converted from text/rtf format -->

David,
  I agree technically that in loc= al MAC operation that this could be a MAY from a functionality perspective.&= nbsp; However, then a provision for the WTP to report summaries of when the = association requests are received might be warranted to be considered.

  Without this information, troubl= eshooting association requests and the WTP/AC's failure to respond (bugs) be= come more difficult.  That being the case, it might be a lesser evil to= just forward on the association requests to the AC even with a WTP in local= MAC operation. (Which would keep this statement a MUST).

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


In response to:

Message: 2
Date: Wed, 12 Apr 2006 08:41:37 = -0700 (PDT)
From: "David T. Perkins&quo= t; <dperkins=40dsperkins.com>
Subject: Re: =5BCapwap=5D New Is= sue - Local MAC MUST vs MAY forward
        association     request messages
To: Dorothy Stanley <dstanley= 1389=40gmail.com>
Cc: capwap <capwap=40frascone= .com>
Message-ID:
        <Pine.LNX.4.10.10604120829240.20437-100000=40shell4.bayarea.ne= t>
Content-Type: TEXT/PLAIN; charse= t=3DUS-ASCII

HI,

In a CAPWAP environment, irregard= less of 802.11 association, the AC determines the
 1) authentication
 2) authorization
and provides the management inte= rface for tracking client
 1) status
 2) statistics
And overal system optimization.<= /FONT>

The above attributes differentiat= es a coordniated collection of independent APs from a CAPWAP system consisti= ng of a AC and WTPs.

So, if changing to MAY does not r= esult in loss of control needed to support any of the above attributes, then= the change would be OK. Otherwise, I don't believe it would be a proper cha= nge. 

On Tue, 11 Apr 2006, Dorothy Stan= ley wrote:
> All,
>
> Section 11.1.2 Local MAC de= scribes the Local MAC operation. It
> currently states (second pa= ragraph below Figure 6):
>
> While the MAC is terminated= on the WTP, it is necessary for the AC to
> be aware of mobility events= within the WTPs.
> As a consequence, the WTP M= UST forward the IEEE 802.11 Association
> Requests to the AC, and the= AC MAY reply with a failed Association
> Response if it deems it nec= essary.
>
>
> Since this is the Local MAC= case, it seems that a MAY should be
> sufficient.
>
> Recommended change: =
>
> The MAC is terminated on th= e WTP, but the AC may need to be aware of
> mobility events within the = WTPs.
> As a consequence, the WTP M= AY forward the IEEE 802.11 Association
> Requests to the AC, and the= AC MAY reply with a failed Association
> Response.
>
> Comments?
>
> Thanks,
>
> Dorothy
Regards,
/david t. perkins


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


------_=_NextPart_001_01C65F00.DB8F2911-- ----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 Apr 13 10:38:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU2y5-0004pV-UQ for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 10:38:45 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU2xw-0006zd-Aa for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 10:38:37 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7CDD54300DB for ; Thu, 13 Apr 2006 07:38:35 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A5144430067 for ; Thu, 13 Apr 2006 07:38:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 942F6398010 for ; Thu, 13 Apr 2006 07:38:05 -0700 (PDT) Received: from hotmail.com (bay20-f13.bay20.hotmail.com [64.4.54.102]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4F9BD398051 for ; Thu, 13 Apr 2006 07:37:49 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 13 Apr 2006 07:37:48 -0700 Message-ID: Received: from 80.15.249.148 by by20fd.bay20.hotmail.msn.com with HTTP; Thu, 13 Apr 2006 14:37:44 GMT X-Originating-IP: [202.156.6.20] X-Originating-Email: [saravanang@hotmail.com] X-Sender: saravanang@hotmail.com In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201B82734@xmb-sjc-235.amer.cisco.com> From: "Saravanan Govindan" To: pcalhoun@cisco.com, clancy@cs.umd.edu, dstanley1389@gmail.com Subject: RE: [Capwap] Proposed Resolution to Issue 42 - PMK Sharing Date: Thu, 13 Apr 2006 22:37:44 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 13 Apr 2006 14:37:48.0903 (UTC) FILETIME=[D6288F70:01C65F07] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER 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: 87a3f533bb300b99e2a18357f3c1563d All, This issue goes back to the Architecture Taxonomy. I remember it coming up in a security review for the document. Subsequently, someone in the group wanted to see reference to it in CAPWAP documents - even if the reference was to say that it was not within the scope of CAPWAP. This is the basis for the original proposal - reference followed by out-of-scope disclaimer. Saravanan ----Original Message Follows---- From: "Pat Calhoun (pacalhou)" To: "T. Charles Clancy" ,"Dorothy Stanley" CC: capwap Subject: RE: [Capwap] Proposed Resolution to Issue 42 - PMK Sharing Date: Thu, 13 Apr 2006 06:18:22 -0700 Similar comment. I never understood the original issue, other than saying that sharing is a bad thing - regardless of whether the protocol does it or not. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Monday, April 10, 2006 12:27 PM > To: Dorothy Stanley > Cc: capwap > Subject: Re: [Capwap] Proposed Resolution to Issue 42 - PMK Sharing > > This was my original point -- CAPWAP doesn't let you share > the PMK, so I never understood why this was an issue. > > [ t. charles clancy ]--[ tcc@umd.edu ]--[ > www.cs.umd.edu/~clancy ] [ computer science ]-----[ > university of maryland | college park ] > > > On Mon, 10 Apr 2006, Dorothy Stanley wrote: > > > All, > > > > Issue 42 - PMK Sharing has the following discussion in the > issues data base: > > > > Issue: > > > > In the case of an AC managing a same PMK across many WTPs, > IEEE 802.11 > > stations cannot distinguish between PMKs that are validly > shared and > > those that have been compromised (I0 of Issues/Recommendations). > > > > My recommendation: > > > > Include text in the Security Considerations > > (draft-ohara-capwap-lwapp-03.txt) Section 15 along the lines; > > > > "The CAPWAP protocol may be used in scenarios in which an > AC manages a > > PMK across many WTPs. In such scenarios, IEEE 802.11 > stations moving > > across WTPs cannot distinguish between PMKs that are legitimately > > shared and PMKs that have been compromised. > > The CAPWAP WG recognizes this ambiguity and recommends > implementers of > > the protocol to review the outcome of IEEE 802.11r efforts > for resolution." > > > > No agreement on this request > > > > > > Perhaps we need further clarification on what "manages a PMK across > > many WTPs" means. > > If "manages a PMK across many WTPs" means that it delivers > the PMK to > > more than one WTP, then: > > > > It is not clear that the CAPWAP specification, current draft does > > indeed provide a mechanism to deliver the PMK to the WTPs, to share > > the PMK across WTPs. Below are the message elements that deliver > > keys: > > - The IEEE 802.11 Add WLAN message element (11.8.1.1) - typically > > delivers the GTK > > - The IEEE 802.11 Mobile Session Key message element (11.7.1.2) > > delivers a session key, the PTK > > - The IEEE 802.11 Update WLAN message element (11.8.1.3) - > typically > > delivers the GTK > > > > CAPWAP does support the ability to securely deliver the GTK and PTK > > from the AC to a WTP. > > CAPWAP supports a secure control interface, requiring mutual > > authentication between the AC and WTPs that are connected to it. > > > > Recommended resolution: > > Reject the comment, with the reason that "An implementation which > > delivers PMKs to WTPs is not in compliance with the CAPWAP protocol" > > > > and change the text in 11.8.1.1 and 11.8.1.3 describing the > key that > > is delivered from: > > "Key: A 32 byte Session Key to use with the encryption policy" to > > "Key: A 32 byte key to use with the encryption key, > typically the GTK" > > > > Comments, discussion please. > > > > Thanks, > > > > Dorothy > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ Find just what you are after with the more precise, more powerful new MSN Search. http://search.msn.com.sg/ Try it now. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Apr 13 10:47:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU36U-0002W5-FQ for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 10:47:26 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU36T-0007J8-Pw for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 10:47:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6C14343010C for ; Thu, 13 Apr 2006 07:47:25 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id CC07E430067 for ; Thu, 13 Apr 2006 07:46:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BB379431D1A for ; Thu, 13 Apr 2006 07:46:58 -0700 (PDT) Received: from hotmail.com (bay20-f14.bay20.hotmail.com [64.4.54.103]) by hermes.tigertech.net (Postfix) with ESMTP id DDDB7431D19 for ; Thu, 13 Apr 2006 07:46:56 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 13 Apr 2006 07:46:55 -0700 Message-ID: Received: from 64.86.106.209 by by20fd.bay20.hotmail.msn.com with HTTP; Thu, 13 Apr 2006 14:46:54 GMT X-Originating-IP: [202.156.6.20] X-Originating-Email: [saravanang@hotmail.com] X-Sender: saravanang@hotmail.com In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201B82735@xmb-sjc-235.amer.cisco.com> From: "Saravanan Govindan" To: pcalhoun@cisco.com, dstanley1389@gmail.com, Saravanan.Govindan@sg.panasonic.com Subject: RE: [Capwap] Proposed Resolution to Issue 45 - Issueoncombiningmessages Date: Thu, 13 Apr 2006 22:46:54 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 13 Apr 2006 14:46:55.0738 (UTC) FILETIME=[1C18F5A0:01C65F09] X-Virus-Scanned: by amavisd-new-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.8 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER 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: d11a451997816a91a305dcb5ab1b85dd Pat, I hope to help clarify any confusion. My concern is that CAPWAP does need a set of statistics that are indicative of the WLAN as a whole. Such big-picture statistics are currently not in the specifications - the current statistics are specific to the technology binding (802.11). I am ok with discussing this as a separate issue. Having said this, I think this set of general statistics does not complicate Echo Request exchanges. In many implementations, this information is already available - buffer levels, transmission failures, etc. As I mentioned earlier, such big-picture information provides greater visibility to the AC and adds value to its control operations. Saravanan ----Original Message Follows---- From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" ,"Saravanan Govindan" CC: capwap Subject: RE: [Capwap] Proposed Resolution to Issue 45 - Issueoncombiningmessages Date: Thu, 13 Apr 2006 06:18:22 -0700 I believe the request is for a *new* set of statistics to be sent from the WTP to the AC. If this is the case, then a separate issue is required that describes this request. I think I was just as confused as Dorothy that the request was to include the existing dot11 statistics within the echo request, which didn't seem to make sense to me. Having said that, I believe that sending an echo should not require digging everywhere around the system to collect various statistics, as I believe this would create overhead on the WTP. If this is localized information, and limited in nature, then perhaps the impact is minimal. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com] Sent: Wednesday, April 12, 2006 8:00 AM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Proposed Resolution to Issue 45 - Issue oncombiningmessages Saravanan, Richard, I suggest we set aside the question of how the statistics might be transported for the moment - either in WTP Event Request, Echo Request or some new message, and first agree on the nature/definition of the statistics themselves. We are talking about non-802.11 specific statistics, as the 802.11 specific ones, or new 802.11 ones would go in 11.7.2.1: WPT buffer levels - which buffers? Concern that this would be implementation specific Congestion conditions - congestion on the wireless link? On the WTP to AC link? etc - needs to be specified. Richard suggests Network Congestion - which network, the wireless one or the WTP to AC link. How is the level of congestion measured? Traffic Loading - How is this measured? Which traffic? Channel Interferences - Need to specify. Concern that there is overlap with what will be coming in .11k for radio measurement Thanks, Dorothy On 4/11/06, Saravanan Govindan wrote: Hi Dorothy, WTP Event Request is being positioned for technology-specific statistics exchange (Section 2.1). So my understanding is that WTP Event Request would be used for information such as transmission attempts, beacon and probe counts, decryption errors etc. In addition to technology-specific information, the AC also needs big-picture information on factors affecting the WLAN as a whole. This would include WTP buffer levels, congestion conditions, etc. This information is not specific to a technology but does affect the WLAN. It is this type of statistics that I suggest the Echo Request exchange. Cheers, Saravanan ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com] Sent: Tuesday, April 11, 2006 10:50 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages Saravanan, Richard, First of all, thank you for your comments. Clearly, the WTP must have a means to provide statistics and other relevant data to the AC.. The question becomes, what specific mechanism should be used? Overloading the echo request message is one way. CAPWAP has the WTP event request message, section 8.5, and already includes the decryption error report, and can include the .11 specific statistics report. Why is using the WTP event report to report statistics not sufficient? We should add other applicable CAPWAP message elements to be included in it. Thanks, Dorothy On 4/10/06, Saravanan Govindan wrote: Hi Dorothy, I think this recommendation add substantial value to the CAPWAP protocol. There have been discussions on the need for aggregating statistics information from the WTP to AC. The Echo Request offers a way for achieving this. The mechanisms for statistics exchanges - timer, periodic exchange - are available with Echo Request. So I think it is of value to keep Echo Request and add statistics information fields to it. Cheers, Saravanan ________________________________ From: Dorothy Stanley [mailto: dstanley1389@gmail.com] Sent: Tuesday, April 11, 2006 1:20 AM To: capwap Subject: [Capwap] Proposed Resolution to Issue 45 - Issue on combiningmessages All, 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 Comments please. Thanks, Dorothy _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Apr 13 10:50:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU39O-0003iw-1s for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 10:50:26 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU39L-0007M8-F4 for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 10:50:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1EB8D4300C9 for ; Thu, 13 Apr 2006 07:50:23 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3A53A430067 for ; Thu, 13 Apr 2006 07:49:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2F56F398007 for ; Thu, 13 Apr 2006 07:49:49 -0700 (PDT) Received: from hotmail.com (bay20-f12.bay20.hotmail.com [64.4.54.101]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4648D39802E for ; Thu, 13 Apr 2006 07:49:46 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 13 Apr 2006 07:49:45 -0700 Message-ID: Received: from 64.86.106.211 by by20fd.bay20.hotmail.msn.com with HTTP; Thu, 13 Apr 2006 14:49:40 GMT X-Originating-IP: [202.156.6.20] X-Originating-Email: [saravanang@hotmail.com] X-Sender: saravanang@hotmail.com In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201B82736@xmb-sjc-235.amer.cisco.com> From: "Saravanan Govindan" To: pcalhoun@cisco.com, sujayg@huawei.com, Saravanan.Govindan@sg.panasonic.com, capwap@frascone.com Subject: RE: [Capwap] RE: WTP Mac Type negotiation. Date: Thu, 13 Apr 2006 22:49:40 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 13 Apr 2006 14:49:45.0901 (UTC) FILETIME=[8185C5D0:01C65F09] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER 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: 32a65c0bf5eb4ec26489239c7cdd0636 Pat, >From an earlier post, " In the case where a requesting WTP is capable of both Local-MAC and Split-MAC operations (MAC Type [Section 5.1.4] value "2") or where a WTP is capable of all types of bridging (Frame Type [Section 5.1.5] value "7"), AC determines the particular operating mode based on the following; i. Control-bias Mode In this mode, the AC has greater control of WTP operations. So the AC instructs the requesting WTP to operate in Split-MAC mode. ii. Load-bias Mode In this mode, the AC reduces processing load of WTP operations. So the AC instructs the requesting WTP to operate in Local-MAC mode. " Saravanan ----Original Message Follows---- From: "Pat Calhoun (pacalhou)" To: "sujay" ,"Saravanan Govindan" , Subject: [Capwap] RE: WTP Mac Type negotiation. Date: Thu, 13 Apr 2006 06:18:22 -0700 Could you please define these new modes of operation? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: sujay [mailto:sujayg@huawei.com] Sent: Tuesday, April 11, 2006 4:32 AM To: 'Saravanan Govindan'; capwap@frascone.com; Pat Calhoun (pacalhou) Subject: RE: WTP Mac Type negotiation. Saravanan, I suggest not to limit the AC's mode of operation, by classifying modes of operation viz Control - bias and Load-bias mode. Keeping it simple; 5.2.6. Operating Mode The Operating Mode message element specifies the mode of operation for a WTP capable of operating in both Local-MAC and Split-MAC modes. 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Operating Mode | +-+-+-+-+-+-+-+-+ Type: TBD Length: 1 Operating Mode: The selected mode for WTP operation < 0: Control-bias mode, WTP operates in Split-MAC mode 1: Load-bias mode, WTP operates in Local-MAC mode /> change to; < 0: Split-MAC mode, WTP operates in Split-MAC mode 1: Local-MAC mode, WTP operates in Local-MAC mode /> Any suggestions? Sujay -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Friday, March 31, 2006 8:14 AM To: sujay; capwap@frascone.com Subject: RE: WTP Mac Type negotiation. Dear All, Following from Sujay G's suggestion, this is text for mode selection in the case where a WTP supports both split-MAC and local-MAC modes and can also support the different tunnel options. Cheers, Saravanan ----oooo---- Introduce how operational mode is selected in Section 2 (Protocol Overview) [Paragraph 3, after 2nd sentence] "The WTPs specify their operational modes in their Discovery Request message, to which the responding AC selects particular operational modes and specifies them in the Discovery Response message." Then in Section 5.2 (Discovery Response) [After Paragraph 2, include following paragraph] " In the case where a requesting WTP is capable of both Local-MAC and Split-MAC operations (MAC Type [Section 5.1.4] value "2") or where a WTP is capable of all types of bridging (Frame Type [Section 5.1.5] value "7"), AC determines the particular operating mode based on the following; i. Control-bias Mode In this mode, the AC has greater control of WTP operations. So the AC instructs the requesting WTP to operate in Split-MAC mode. ii. Load-bias Mode In this mode, the AC reduces processing load of WTP operations. So the AC instructs the requesting WTP to operate in Local-MAC mode. " Introduce Operation Mode message element as Section 5.2.6 (Operating Mode). 5.2.6. Operating Mode The Operating Mode message element specifies the mode of operation for a WTP capable of operating in both Local-MAC and Split-MAC modes. 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Operating Mode | +-+-+-+-+-+-+-+-+ Type: TBD Length: 1 Operating Mode: The selected mode for WTP operation 0: Control-bias mode, WTP operates in Split-MAC mode 1: Load-bias mode, WTP operates in Local-MAC mode ----XXXX---- -----Original Message----- From: sujay [mailto:sujayg@huawei.com] Sent: Friday, March 17, 2006 2:32 PM To: capwap@frascone.com Cc: Saravanan Govindan Subject: WTP Mac Type negotiation. Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal The CAPWAP does not specify as to how the selection is made if the WTP Can support both Modes Split and Local and Frame (Tunnel ) type. The WTP specifies MAC Type and Frame Type in Discovery Request message, but if it supports both modes , there is no provision for the AC to select the working mode. Recommendation : 1. Add the WTP mode and WTP tunnel type messages in the configure response ? Which makes it binding agnostic. 2. The logic for choosing WTP mode type on the AC could depend on the load, and user policy. Solicit comments. Regds, Sujay _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ Find love on MSN Personals http://personals.msn.com.sg/ _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Apr 13 12:21:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU4Z4-0002No-Dj for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 12:21:02 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU4Z2-0002FZ-C0 for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 12:21:02 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7F08F4300A2 for ; Thu, 13 Apr 2006 09:20:59 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8765C430067 for ; Thu, 13 Apr 2006 09:20:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4ABE2431E49 for ; Thu, 13 Apr 2006 09:20:33 -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 1ADE2431E24 for ; Thu, 13 Apr 2006 09:20:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=UsPzBAPNh3MY/aCywB1dkatz23A8+szIx3dZi2Nt0YK6Xt8as9mG1WS9EoYB6qT7; h=Received: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.34] (helo=elwamui-hound.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FU4YU-0006wo-6N; Thu, 13 Apr 2006 12:20:27 -0400 Message-ID: <2758361.1144945226229.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> Date: Thu, 13 Apr 2006 09:20:26 -0700 (GMT-07:00) From: "Scott G. Kelly" To: pcalhoun@cisco.com, dstanley1389@gmail.com, Saravanan.Govindan@sg.panasonic.com Subject: RE: [Capwap] Proposed Resolution to Issue 45 - Issueoncombiningmessages 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: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710a01d139b589a5aa932a6e357e61496b6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.34 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=3.0 tagged_above=-999.0 required=7.0 tests=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 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: 1.8 (+) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 I agree heartily with Pat. Implementers know that one implicit purpose of the echo req/reply is to facilite fast recovery in case of a lost capwap "connection". Hence, these may be sent *very* frequently, e.g. the interval may even be as small as 1 second (or even less!) An echo request may be automagically turned around by the AC in the fastpath (without bothering the control processor), but if you add stats to this message, that is no longer the case. The WTP will have to run around and collect everything to assemble the messages, and the AC will have to punt these to the control processor. This does not sound like a scalable design. -----Original Message----- >From: Saravanan Govindan >Sent: Apr 13, 2006 7:46 AM >To: pcalhoun@cisco.com, dstanley1389@gmail.com, Saravanan.Govindan@sg.panasonic.com >Cc: capwap@frascone.com >Subject: RE: [Capwap] Proposed Resolution to Issue 45 - Issueoncombiningmessages > >Pat, > >I hope to help clarify any confusion. My concern is that CAPWAP does need a >set of statistics that are indicative of the WLAN as a whole. Such >big-picture statistics are currently not in the specifications - the current >statistics are specific to the technology binding (802.11). > >I am ok with discussing this as a separate issue. > >Having said this, I think this set of general statistics does not complicate >Echo Request exchanges. In many implementations, this information is already >available - buffer levels, transmission failures, etc. As I mentioned >earlier, such big-picture information provides greater visibility to the AC >and adds value to its control operations. > >Saravanan > > > > >----Original Message Follows---- >From: "Pat Calhoun (pacalhou)" >To: "Dorothy Stanley" ,"Saravanan Govindan" > >CC: capwap >Subject: RE: [Capwap] Proposed Resolution to Issue 45 - >Issueoncombiningmessages >Date: Thu, 13 Apr 2006 06:18:22 -0700 > >I believe the request is for a *new* set of statistics to be sent from >the WTP to the AC. If this is the case, then a >separate issue is required that describes this request. I think I was >just as confused as Dorothy that the request >was to include the existing dot11 statistics within the echo request, >which didn't seem to make sense to me. > >Having said that, I believe that sending an echo should not require >digging everywhere around the system to collect various >statistics, as I believe this would create overhead on the WTP. If this >is localized information, and limited in nature, >then perhaps the impact is minimal. > >Pat Calhoun >CTO, Wireless Networking Business Unit >Cisco Systems > > > > >________________________________ > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > Sent: Wednesday, April 12, 2006 8:00 AM > To: Saravanan Govindan > Cc: capwap > Subject: Re: [Capwap] Proposed Resolution to Issue 45 - Issue >oncombiningmessages > > > Saravanan, Richard, > > I suggest we set aside the question of how the statistics might >be transported for the moment - either in WTP Event Request, Echo >Request or some new > message, and first agree on the nature/definition of the >statistics themselves. We are talking about non-802.11 specific >statistics, as the 802.11 > specific ones, or new 802.11 ones would go in 11.7.2.1: > > WPT buffer levels - which buffers? Concern that this would be >implementation specific > Congestion conditions - congestion on the wireless link? On the >WTP to AC link? > etc - needs to be specified. > > Richard suggests > Network Congestion - which network, the wireless one or the WTP >to AC link. How is the level of congestion measured? > Traffic Loading - How is this measured? Which traffic? > Channel Interferences - Need to specify. Concern that there is >overlap with what will be coming in .11k for radio measurement > > Thanks, > > Dorothy > > On 4/11/06, Saravanan Govindan > wrote: > > Hi Dorothy, > > > > WTP Event Request is being positioned for >technology-specific statistics exchange (Section 2.1). So my >understanding is that WTP Event Request would be used for information >such as transmission attempts, beacon and probe counts, decryption >errors etc. > > > > In addition to technology-specific information, the AC >also needs big-picture information on factors affecting the WLAN as a >whole. This would include WTP buffer levels, congestion conditions, etc. >This information is not specific to a technology but does affect the >WLAN. It is this type of statistics that I suggest the Echo Request >exchange. > > > > Cheers, > > > Saravanan > > > > > > > > > > >________________________________ > > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > Sent: Tuesday, April 11, 2006 10:50 PM > To: Saravanan Govindan > Cc: capwap > Subject: Re: [Capwap] Proposed Resolution to Issue 45 - >Issue on combiningmessages > > > > > > Saravanan, Richard, > > First of all, thank you for your comments. > > Clearly, the WTP must have a means to provide statistics >and other relevant data to the AC.. > > The question becomes, what specific mechanism should be >used? > Overloading the echo request message is one way. CAPWAP >has the WTP event request message, > section 8.5, and already includes the decryption error >report, and can include the .11 specific > statistics report. > > Why is using the WTP event report to report statistics >not sufficient? We should add other applicable CAPWAP message elements > to be included in it. > > > Thanks, > > Dorothy > > > > On 4/10/06, Saravanan Govindan > wrote: > > > > Hi Dorothy, > > > > I think this recommendation add substantial value to the >CAPWAP protocol. There have been discussions on the need for aggregating >statistics information from the WTP to AC. The Echo Request offers a way >for achieving this. The mechanisms for statistics exchanges - timer, >periodic exchange - are available with Echo Request. So I think it is of >value to keep Echo Request and add statistics information fields to it. > > > > Cheers, > > > > Saravanan > > > > > > > > >________________________________ > > From: Dorothy Stanley [mailto: dstanley1389@gmail.com] > Sent: Tuesday, April 11, 2006 1:20 AM > To: capwap > Subject: [Capwap] Proposed Resolution to Issue 45 - >Issue on combiningmessages > > > > All, > > 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 > > Comments please. > > Thanks, > > Dorothy > > > > > > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/capwap > >Archives: http://lists.frascone.com/pipermail/capwap > >_________________________________________________________________ >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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Apr 13 13:37:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU5kA-0002YV-7K for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 13:36:34 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU5Vy-000407-DK for capwap-archive@lists.ietf.org; Thu, 13 Apr 2006 13:21:55 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 733EC4300DB for ; Thu, 13 Apr 2006 10:21:51 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 40BE1430067 for ; Thu, 13 Apr 2006 10:21:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2EE2339802F for ; Thu, 13 Apr 2006 10:21:32 -0700 (PDT) Received: from trpz.com (mail1.trpz.com [66.7.225.38]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0CB4039803A for ; Thu, 13 Apr 2006 10:21:29 -0700 (PDT) Received: from [127.0.0.1] ([192.168.12.194]) by trpz.com (8.13.5/8.11.6) with ESMTP id k3DHLD2J003051 for ; Thu, 13 Apr 2006 10:21:14 -0700 Message-ID: <443E8894.7050508@trapezenetworks.com> Date: Thu, 13 Apr 2006 10:21:24 -0700 From: Jim Murphy User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: capwap 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: Subject: [Capwap] Data Tunneling 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: a87a9cdae4ac5d3fbeee75cd0026d632 I would like to propose the following Data Tunnel header for CAPWAP to address the following issues with the existing header: 1. It includes RF information that is 802.11 specific. CAPWAP goals are that the protocol be extensible to arbitrary wireless protocols. 2. The RID is 3 bits but elsewhere in the document it is 8 bits. The RID is also RF specific information which should be in the RF specific part. 3. The Length field is redundant with the UDP header's length field. 4. It does not specify the payload type. The following header is proposed to overcome these issues. This header includes three parts, the base header, the security header and the RF header. The base header is defined as follows: [NOTE: I am not sure that the security header is of any use, I am including it to solicit comments.] Base tunnel 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| HLEN |S|R| TYPE | RESV |F|L| Frag ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ VER: Same as CAPWAP-00 HLEN: Length of CAPWAP tunnel header in 4 byte words. (Similar to IP header length). The maximum total header size is therefore 15*4 = 60 bytes. This length includes the optional security header and RF headers. S: Security bit. If set the tunnel header includes a security encapsulation. The security encapsulation follows immediately after the base CAPWAP tunnel header. If not set, there is no security header. The security header must be padded to a 4 byte boundary. R: RF bit. If set, the tunnel header includes RF information. The RF information in the tunnel header follows immediately after the security header. If no security header exists, the RF information follows immediately after the base tunnel header. TYPE: This is the payload type. The following types are defined: 0x00 Reserved 0x01 802.3 0x02 802.11 0x03 - 0xFF Reserved RESV: Reserved bits. F, L, Frag ID - Same as CAPWAP-00. Security Tunnel 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SHLEN | TBD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SHLEN: Length of security header RF tunnel header: The RF tunnel header includes payload type specific RF information. It is defined specifically for each payload type. It must include its length if units of 4 bytes in the first nibble as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RHLEN | TBD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RHLEN: Length of the RF tunnel header. [NOTE: If there is no security header, there is no need for a RHLEN field.] Method of operation: When a switch receives a packet it check the version. If VER == 0 continue; else drop If S == 1 decrypt If R == 1 do RF processing If TYPE == 1, deencap HLEN * 4 bytes and 802.3 switch. If TYPE == 2, deencap HLEN * 4 bytes and 802.11 switch. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Apr 14 03:28:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUIji-0002jy-Qj for capwap-archive@lists.ietf.org; Fri, 14 Apr 2006 03:28:58 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUIja-0007Lc-7D for capwap-archive@lists.ietf.org; Fri, 14 Apr 2006 03:28:54 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 60DBD430117 for ; Fri, 14 Apr 2006 00:28:49 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 36559430067 for ; Fri, 14 Apr 2006 00:28:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 18EC0430665 for ; Fri, 14 Apr 2006 00:28:25 -0700 (PDT) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.186]) by hermes.tigertech.net (Postfix) with ESMTP id 253BE43065A for ; Fri, 14 Apr 2006 00:28:22 -0700 (PDT) Received: by nproxy.gmail.com with SMTP id o63so10198nfa for ; Fri, 14 Apr 2006 00:28:21 -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=q0UkMPlg+vUoV/rNr1vLvomyE8G3OiCiVVCyFoLcD4A7x0ehpEBmGgjuuklOM7jRn6h+BSNcqJp9RLA/M4xIWhvumINRF9woNbO6sPT8tUXdFB5/+BVwk25ecF/uBeBrT4LtCQPO7rFxfk8TsiY8dOM4BQQ6w2WDafzykO75x20= Received: by 10.49.93.4 with SMTP id v4mr376895nfl; Fri, 14 Apr 2006 00:28:21 -0700 (PDT) Received: by 10.48.204.2 with HTTP; Fri, 14 Apr 2006 00:28:21 -0700 (PDT) Message-ID: <1013407b0604140028s19895135p9e5ecb101864c9c5@mail.gmail.com> Date: Fri, 14 Apr 2006 00:28:21 -0700 From: Puneet To: capwap@frascone.com 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.2 tagged_above=-999.0 required=7.0 tests=HTML_00_10, HTML_MESSAGE, RCVD_BY_IP X-Spam-Level: Subject: [Capwap] 802.11d / 802.11h support 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="===============0304155719==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 --===============0304155719== Content-Type: multipart/alternative; boundary="----=_Part_31222_25872824.1144999701606" ------=_Part_31222_25872824.1144999701606 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 1. Section 11.9.3 'IEEE 802.11 Multi-domain Capability': The length of this element is fixed at 8 bytes, but if there are multiple, disjoint bands that are supported in the regulatory domain does the AC use multiple such elements? It might be cleaner to make the length of this element variable, and allow multiple triplets 1. Section 11.9.3 'IEEE 802.11 Multi-domain Capability': The length of this element is fixed at 8 bytes, but if there are multiple, disjoint bands that are supported in the regulatory domain does the AC use multiple such elements? It might be cleaner to make the length of this element variable, and allow multiple triplets <first_channel,num_channel,max_power) to be added one after the other. (like the Country-Information element in 802.11d)

2. How does CAPWAP plan to support 802.11h? Does the WTP handle everything on its own or is the channel switching etc controlled by the AC? In either case there might be a need for message elements with which the WTP to report the detection of radar to the AC.

Thanks,
Puneet.
------=_Part_31222_25872824.1144999701606-- --===============0304155719== 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 --===============0304155719==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 14 03:29:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUIkR-0004kv-Ny for capwap-archive@lists.ietf.org; Fri, 14 Apr 2006 03:29:43 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUIkO-0007NC-8g for capwap-archive@lists.ietf.org; Fri, 14 Apr 2006 03:29:43 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E8B67430112 for ; Fri, 14 Apr 2006 00:29:39 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id ED3D0430109 for ; Fri, 14 Apr 2006 00:28:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D7B94430665 for ; Fri, 14 Apr 2006 00:28:36 -0700 (PDT) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.187]) by hermes.tigertech.net (Postfix) with ESMTP id EC03A43065A for ; Fri, 14 Apr 2006 00:28:33 -0700 (PDT) Received: by nproxy.gmail.com with SMTP id l23so13432nfc for ; Fri, 14 Apr 2006 00:28:32 -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=FpaPg2+eNjThKuCy2Szo/QeIVtsU/YR524CEaiBGUgzLgqMcl58uSZ7MY8RdmqxAnzC1XPpTBFHOpM/eUEmxEmj71lM7FvM+FeoUn1yKMBRB+MTd75qOcbYNlmb+GOmlYMKwzpad6lJkv9qe3yOLptbA4f1JCxIHIdmQN9HR0P4= Received: by 10.48.42.20 with SMTP id p20mr479091nfp; Fri, 14 Apr 2006 00:28:32 -0700 (PDT) Received: by 10.48.204.2 with HTTP; Fri, 14 Apr 2006 00:28:32 -0700 (PDT) Message-ID: <1013407b0604140028h6e64226agcc25f34ab8e6bc41@mail.gmail.com> Date: Fri, 14 Apr 2006 00:28:32 -0700 From: Puneet To: capwap@frascone.com 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.2 tagged_above=-999.0 required=7.0 tests=HTML_00_10, HTML_MESSAGE, RCVD_BY_IP X-Spam-Level: Subject: [Capwap] Section 11.8.1.1 'IEEE 802.11 Add WLAN' 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="===============1723634435==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 --===============1723634435== Content-Type: multipart/alternative; boundary="----=_Part_31226_32368208.1144999712437" ------=_Part_31226_32368208.1144999712437 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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? 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). 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. 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.11Broadcast Probe Mode' in section 11.9.12? Also, why is this IE global for the WTP? The AC might configure th= e WTP with 10 WLANs, but it may want probe responses generated for only four of those when a broadcast probe request comes in. 5. maybe rename WME to WMM? Thanks, Puneet ------=_Part_31226_32368208.1144999712437 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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?

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).

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.

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.

5. maybe rename WME to WMM?

Thanks,
Puneet
------=_Part_31226_32368208.1144999712437-- --===============1723634435== 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 --===============1723634435==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 14 03:30:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUIkw-0004xS-J7 for capwap-archive@lists.ietf.org; Fri, 14 Apr 2006 03:30:14 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUIkt-0007OV-5V for capwap-archive@lists.ietf.org; Fri, 14 Apr 2006 03:30:14 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D20F4430119 for ; Fri, 14 Apr 2006 00:30:10 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 2C7A94300E8 for ; Fri, 14 Apr 2006 00:28:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1A5F539800C for ; Fri, 14 Apr 2006 00:28:40 -0700 (PDT) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.189]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0C3C0398027 for ; Fri, 14 Apr 2006 00:28:37 -0700 (PDT) Received: by nproxy.gmail.com with SMTP id o25so12268nfa for ; Fri, 14 Apr 2006 00:28:36 -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=olZvY0101poBYQztD+xjX+7rR3KVAGSc4B/KJ7tP94yAMkEnw+bq+SLfx+G5VxAZg3OJsC2xteWloZDPZaCh0Rt5I+RvXBFHpwo280PdsORTjSPsQOIhAy14K+bJvURwXd3wh+7Bqe5nSsqKqfp5che9TCEXwqS5UcAxLbNGPCo= Received: by 10.48.242.20 with SMTP id p20mr480549nfh; Fri, 14 Apr 2006 00:28:36 -0700 (PDT) Received: by 10.48.204.2 with HTTP; Fri, 14 Apr 2006 00:28:36 -0700 (PDT) Message-ID: <1013407b0604140028i15c76b9cv89e0d8962b24e589@mail.gmail.com> Date: Fri, 14 Apr 2006 00:28:36 -0700 From: Puneet To: capwap@frascone.com MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.163 tagged_above=-999 required=7 tests=HTML_00_10, HTML_MESSAGE, RCVD_BY_IP X-Spam-Level: Subject: [Capwap] BSSID-WLAN mappings 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="===============0114920547==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 --===============0114920547== Content-Type: multipart/alternative; boundary="----=_Part_31230_1709826.1144999716835" ------=_Part_31230_1709826.1144999716835 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline the BSSID description in Section 11.9.1 'WTP Radio Configuration' notes tha= t 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 ------=_Part_31230_1709826.1144999716835 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 di= fferent 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
------=_Part_31230_1709826.1144999716835-- --===============0114920547== 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 --===============0114920547==-- From speakmanbotum@dornier.com Fri Apr 14 10:15:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUP57-0008KE-50 for capwap-archive@ietf.org; Fri, 14 Apr 2006 10:15:29 -0400 Received: from dialin-212-144-216-064.pools.arcor-ip.net ([212.144.216.64] helo=dornier.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FUP50-00035Z-HJ for capwap-archive@ietf.org; Fri, 14 Apr 2006 10:15:28 -0400 Message-ID: <000001c65fcd$d19c3e90$3fb0a8c0@mzz82> Reply-To: "Botum Speakman" From: "Botum Speakman" To: capwap-archive@ietf.org Subject: Re: kojyhi news Date: Fri, 14 Apr 2006 10:15:01 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C65FAC.4A8A9E90" 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.1 (++) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C65FAC.4A8A9E90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable De q=20 ar Home O i=20 wne z=20 r ,=20 =20 Your c m=20 re s=20 di a=20 t doesn't matter to us !=20 =20 If you O v=20 WN real e l=20 st b=20 at u=20 e and want=20 I a=20 MME r=20 DI x=20 AT v=20 E c a=20 as l=20 h to s i=20 pen b=20 d ANY way you like,=20 or simply wish to L v=20 OWE p=20 R your monthly=20 p e=20 ayme n=20 nt j=20 s by a third or more,=20 here are the d n=20 eal q=20 s we have T v=20 ODA s=20 Y :=20 =20 $ 48 z=20 8 , 000 at a 3 , f=20 67 % f b=20 ixe w=20 d - r k=20 at z=20 e=20 $ 3 o=20 72 , 000 at a 3 , l=20 90 % v f=20 ari h=20 ab a=20 le - r k=20 at m=20 e=20 $ 49 j=20 2 , 000 at a 3=20 o=20 , 21 % in w=20 te x=20 res g=20 t - only=20 $ 24 j=20 8 , 000 at a 3 ,=20 e=20 36 % f m=20 ixe c=20 d - r r=20 at m=20 e=20 $ 1 m=20 98 , 000 at a 3=20 t=20 , 55 % v z=20 ari r=20 ab n=20 le - r g=20 at p=20 e=20 =20 V =20 b=20 is a=20 it our si g=20 te =20 H i=20 urr b=20 y, when these d a=20 ea u=20 ls are gone,=20 they are gone ! =20 Don't worry about a p=20 ppr k=20 ova f=20 l, your=20 c b=20 re g=20 di b=20 t will not d h=20 isqua a=20 lify you !=20 =20 Sincerely, Botum Speakman=20 =20 A x=20 pp k=20 rov x=20 al Manager ------=_NextPart_000_0001_01C65FAC.4A8A9E90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
De
q
ar Home O
i
wne
z =
r ,
 
Your c
m
re
s
di
a
t = doesn't matter to us !
 
If you O
v
WN real e
l
st
b
at
u
e and want
=20 I
a
MME
r
DI
x
AT
v
E c
a =
as
l
h to s
i
pen
b
d ANY = way you like,
or simply wish to L
v
OWE
p
R your monthly
=20 p
e
ayme
n
nt
j
s by a third or = more,
=20 here are the d
n
eal
q
s we have T
v =
ODA
s
Y :
 
$ 48
z
8 , 000 at a 3 ,
f
67 % f
= b
ixe
w
d - r
k
at
z
e
$ 3
o
72 , 000 at a 3 ,
l
90 % v
= f
ari
h
ab
a
le - r
k
at
m
e
$ 49
j
2 , 000 at a 3
o
, 21 % in
w =
te
x
res
g
t - only
$ 24
j
8 , 000 at a 3 ,
e
36 % f
m =
ixe
c
d - r
r
at
m
e
$ 1
m
98 , 000 at a 3
t
, 55 % v
z =
ari
r
ab
n
le - r
g
at
p
e
 
V
b =
is
a
it our si
g
te
 
H
i
urr
b
y, when these d
a =
ea
u
ls are gone,
they = are gone !
 
Don't worry about a
p
ppr
k
ova
f =
l, your
c
b
re
g
di
b =
t will=20 not d
h
isqua
a
lify you !
 
=20 Sincerely, Botum Speakman
 
A
x
pp
= k
rov
x
al = Manager
------=_NextPart_000_0001_01C65FAC.4A8A9E90-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 14 12:59:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FURdu-0000FY-Vp for capwap-archive@lists.ietf.org; Fri, 14 Apr 2006 12:59:34 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FURdl-0008N5-DN for capwap-archive@lists.ietf.org; Fri, 14 Apr 2006 12:59:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 71C394300FB for ; Fri, 14 Apr 2006 09:59:24 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 2517A4300A2 for ; Fri, 14 Apr 2006 09:58:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 09EE539803E for ; Fri, 14 Apr 2006 09:58:58 -0700 (PDT) Received: from aruba-mx.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by zoidberg.tigertech.net (Postfix) with SMTP id 690D639800C for ; Fri, 14 Apr 2006 09:58:55 -0700 (PDT) Received: from aruba-mx1.arubanetworks.com ([10.1.1.17]) by aruba-mx.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Apr 2006 09:58:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] BSSID-WLAN mappings Date: Fri, 14 Apr 2006 09:58:52 -0700 Message-ID: <99C8B9B2AD99664A87E12C839A2E9093024690C7@aruba-mx1.arubanetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] BSSID-WLAN mappings Thread-Index: AcZflUgO5bVMNkIKRs+IQFJTq5aOjwAOflkA From: "Partha Narasimhan" To: "Puneet" , X-OriginalArrivalTime: 14 Apr 2006 16:58:54.0173 (UTC) FILETIME=[B64400D0:01C65FE4] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.001 tagged_above=-999 required=7 tests=HTML_MESSAGE X-Spam-Level: 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="===============0545221136==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 This is a multi-part message in MIME format. --===============0545221136== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65FE4.B63B953E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65FE4.B63B953E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree. Here is one more reason why the WLAN ID to BSSID mapping should be determined by the WTP and not be mandated by the protocol. And we should not exclude implementations that can map multiple SSIDs onto a single BSSID. =20 Thanks partha =20 ________________________________ 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 =20 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 ------_=_NextPart_001_01C65FE4.B63B953E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree. Here is one more reason = why the WLAN ID to BSSID mapping should be determined by the WTP and not be = mandated by the protocol. And we should not exclude implementations that can map = multiple SSIDs onto a single BSSID.

 

Thanks

partha

 

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

------_=_NextPart_001_01C65FE4.B63B953E-- --===============0545221136== 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 --===============0545221136==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 14 15:14:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUTkV-0003UV-SG for capwap-archive@lists.ietf.org; Fri, 14 Apr 2006 15:14:31 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUTkU-0004oC-1x for capwap-archive@lists.ietf.org; Fri, 14 Apr 2006 15:14:31 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3C2224300E4 for ; Fri, 14 Apr 2006 12:14:29 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D07F54300A5 for ; Fri, 14 Apr 2006 12:13:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B8F8D144800C for ; Fri, 14 Apr 2006 12:13:58 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id 188A61448006 for ; Fri, 14 Apr 2006 12:13:56 -0700 (PDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 14 Apr 2006 12:13:56 -0700 X-IronPort-AV: i="4.04,121,1144047600"; d="scan'208,217"; a="1795123699:sNHT52958444" 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 k3EJDuVI023047 for ; Fri, 14 Apr 2006 12:13:56 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Apr 2006 12:13:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] BSSID-WLAN mappings Date: Fri, 14 Apr 2006 12:13:26 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC01672B74@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] BSSID-WLAN mappings Thread-Index: AcZflT19dTUBlUo+S+2H6OIY6J/dbAAYf2/w From: "Bob O'Hara (boohara)" To: X-OriginalArrivalTime: 14 Apr 2006 19:13:56.0322 (UTC) FILETIME=[9385D420:01C65FF7] X-Virus-Scanned: by amavisd-new-20030616-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 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: , Content-Type: multipart/mixed; boundary="===============0192210495==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a This is a multi-part message in MIME format. --===============0192210495== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65FF7.9363A8DA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65FF7.9363A8DA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Puneet, =20 The 1:1 mapping of WLAN to BSSID is all that is described in the 802.11 standard. There is no method in that standard defined to support more than a single BSS on a BSSID. Adding such a mechanism to CAPWAP would only serve to promote noninteroperable implementations of 802.11 on various WTPs. -Bob =20 =20 ________________________________ 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 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 ------_=_NextPart_001_01C65FF7.9363A8DA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Puneet,
 
The 1:1 mapping of WLAN to BSSID is all that is = described=20 in the 802.11 standard.  There is no method in that standard = defined to=20 support more than a single BSS on a BSSID.  Adding such a mechanism = to=20 CAPWAP would only serve to promote noninteroperable implementations of = 802.11 on=20 various WTPs.

 -Bob
 

 

From: Puneet = [mailto:pb.ietf@gmail.com]=20
Sent: Friday, April 14, 2006 12:29 AM
To:=20 capwap@frascone.com
Subject: [Capwap] BSSID-WLAN=20 mappings

the BSSID description in Section 11.9.1 'WTP Radio = Configuration'=20 notes that a WTP that supports 16 WLANS MUST have 16 MAC addresses = reserved for=20 it. Why? ie. what part of the protocol does not work if we have multiple = SSIDs=20 on a single BSSID? (whether thats good design or bad is a different = matter).=20 Since the WLAN ID could be used in all such places to convey WLAN = information=20 back to the AC, why do we need to mandate this 1:1 BSSID-WLAN=20 mapping?

Thanks,
Puneet
------_=_NextPart_001_01C65FF7.9363A8DA-- --===============0192210495== 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 --===============0192210495==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 14 20:01:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUYEP-0000hw-Ua for capwap-archive@lists.ietf.org; Fri, 14 Apr 2006 20:01:41 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUYEO-0006eo-BG for capwap-archive@lists.ietf.org; Fri, 14 Apr 2006 20:01:41 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7D1A3430109 for ; Fri, 14 Apr 2006 17:01:39 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C3C714300B7 for ; Fri, 14 Apr 2006 17:01:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A7CA11448002 for ; Fri, 14 Apr 2006 17:01:05 -0700 (PDT) X-Greylist-Status: Bypassed (other successful deliveries from server) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.184]) by hermes.tigertech.net (Postfix) with ESMTP id 74DA51448001 for ; Fri, 14 Apr 2006 17:01:03 -0700 (PDT) Received: by nproxy.gmail.com with SMTP id k26so125311nfc for ; Fri, 14 Apr 2006 17:01: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=C7zUFwA46AjH2uuNGrSTnMH/FCG0qwzvMB3IwiyP5dsEBIHfRTK+1rk/6m6ne171pE0IDaCQ2UJMGQcMdfM8B7AXfwHg1pb+TUtdyLc4hNrBHTgScc9+fdNGRkHA9x1D1I3Yq6Cuugsipl772mGAGrp6n8bxengp6GkH5HWSLtg= Received: by 10.49.8.5 with SMTP id l5mr1011365nfi; Fri, 14 Apr 2006 17:01:01 -0700 (PDT) Received: by 10.48.204.2 with HTTP; Fri, 14 Apr 2006 17:01:01 -0700 (PDT) Message-ID: <1013407b0604141701k2a40884am7daca9cff30b6676@mail.gmail.com> Date: Fri, 14 Apr 2006 17:01:01 -0700 From: Puneet To: "Bob O'Hara (boohara)" Subject: Re: [Capwap] BSSID-WLAN mappings In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC01672B74@xmb-sjc-237.amer.cisco.com> MIME-Version: 1.0 References: <17B8C6DE4E228348B4939BDA6B05A9DC01672B74@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=3.1 tagged_above=-999.0 required=7.0 tests=HTML_40_50, HTML_MESSAGE, 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: , Content-Type: multipart/mixed; boundary="===============0534907822==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.9 (+) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 --===============0534907822== Content-Type: multipart/alternative; boundary="----=_Part_2808_16130363.1145059261881" ------=_Part_2808_16130363.1145059261881 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Bob, >From the CAPWAP protocols point of view, what messages cannot handle this mode? (ie. over the air 802.11 interoperability issues aside, is there a problem between the WTP-AC in this mode). There are many APs/WTPs today tha= t use this mechanism, and mandating a 1:1 mapping excludes all of them, maybe unnecessarily. If there is no message in CAPWAP that cannot handle (or, cannot be made to easily handle) multiple SSIDs on a single BSSID, then maybe that sentence should be a recommendation instead. That would serve both purposes (lets people know that its nice to have a 1:1 mapping, allows those WTPs that use multiple SSIDs on a single BSS to be a part of CAPWAP). thanks, Puneet On 4/14/06, Bob O'Hara (boohara) wrote: > > Puneet, > > The 1:1 mapping of WLAN to BSSID is all that is described in the 802.11st= andard. There is no method in that standard defined to support more than > a single BSS on a BSSID. Adding such a mechanism to CAPWAP would only se= rve > to promote noninteroperable implementations of 802.11 on various WTPs. > > -Bob > > > > ------------------------------ > *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 WLA= N > 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 > > ------=_Part_2808_16130363.1145059261881 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Bob,

From the CAPWAP protocols point of view, what messages cannot handle th= is mode? (ie. over the air 802.11 interoperability issues aside, is there a pr= oblem between the WTP-AC in this mode). There are many APs/WTP= s today that use this mechanism, and mandating a 1:1 mapping excludes all of = them, maybe unnecessarily.

If there is no message in CAPWAP that cannot handle (or, cannot be made to easily handle) multiple SSIDs on a single BSSID, then maybe that sentence should be a recommendation instead. That would serve both purposes (lets people know that its nice to have a 1:1 mapping, allows those WTPs that use multiple SSIDs on a single BSS to be a part of CAPWAP).

thanks,
Puneet


On 4/14/06, Bob O'Hara (boohara) <b= oohara@cisco.com > wrote:
Puneet,
 
The 1:1 mapping of WLAN to BSSID is all that is described=20 in the 802.11 standard.  There is no method in that standard defined t= o=20 support more than a single BSS on a BSSID.  Adding such a mechanism to= =20 CAPWAP would only serve to promote noninteroperable implementations of 802.= 11 on=20 various WTPs.

 -Bob
 

 

From: Puneet [mailto:pb.ietf@gmail.com]=20
Sent: Friday, April 14, 2006 12:29 AM
To:=20 capwap@frascone.com
Subjec= t: [Capwap] BSSID-WLAN=20 mappings

the BSSID description in Section 11.9.1 'WTP Radio Configuration= '=20 notes that a WTP that supports 16 WLANS MUST have 16 MAC addresses reserved= for=20 it. Why? ie. what part of the protocol does not work if we have multiple SS= IDs=20 on a single BSSID? (whether thats good design or bad is a different matter)= .=20 Since the WLAN ID could be used in all such places to convey WLAN informati= on=20 back to the AC, why do we need to mandate this 1:1 BSSID-WLAN=20 mapping?

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_2808_16130363.1145059261881-- --===============0534907822== 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 --===============0534907822==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 14 20:03:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUYFh-0002Qz-Eb for capwap-archive@lists.ietf.org; Fri, 14 Apr 2006 20:03:01 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUYFg-0006gN-VB for capwap-archive@lists.ietf.org; Fri, 14 Apr 2006 20:03:01 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A035D430106 for ; Fri, 14 Apr 2006 17:03:00 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 34DFD4300BC for ; Fri, 14 Apr 2006 17:02:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2418E1448002 for ; Fri, 14 Apr 2006 17:02:29 -0700 (PDT) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.185]) by hermes.tigertech.net (Postfix) with ESMTP id 1FE821448001 for ; Fri, 14 Apr 2006 17:02:24 -0700 (PDT) Received: by nproxy.gmail.com with SMTP id o25so119897nfa for ; Fri, 14 Apr 2006 17:02:23 -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=UQ2zP37Gj5qCeo/blgE9PVeoKqYlGaHoH89xS58q0BGuyuGc0L60phW/uS30BO9iR54rAHJyq0BCUFQVaULPDQimjWiz2LQ6Ku0OJZszEyhrx2g1O3gTJlkJmFH1lA+G8AgO6yzD63tfKfo7ojpqCD+6kUkxg2T2ndQFqDyWxa0= Received: by 10.48.157.12 with SMTP id f12mr1027907nfe; Fri, 14 Apr 2006 17:02:23 -0700 (PDT) Received: by 10.48.204.2 with HTTP; Fri, 14 Apr 2006 17:02:23 -0700 (PDT) Message-ID: <1013407b0604141702j7cb17da1w9d1d9a046a78476b@mail.gmail.com> Date: Fri, 14 Apr 2006 17:02:23 -0700 From: Puneet To: "Dorothy Stanley" Subject: Re: [Capwap] New Issue - 11.9.1 WTP WLAN Radio Configuration Changes In-Reply-To: <5bfe7a820604111326w589a36a5ua844aaa1b64b85a4@mail.gmail.com> MIME-Version: 1.0 References: <5bfe7a820604111326w589a36a5ua844aaa1b64b85a4@mail.gmail.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_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="===============1091516239==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f --===============1091516239== Content-Type: multipart/alternative; boundary="----=_Part_2816_29866089.1145059343502" ------=_Part_2816_29866089.1145059343502 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > 2. Delete country code. The FCC does not allow the country code to be changed from a controller. Is there a specific FCC document that references this? Also, if the AC handles all channel and power level assignments (ie. makes sure those are i= n compliance in the current regulatory domain), can the country-code be sent to the WTP for advertisement in beacons/probes? thanks, Puneet On 4/11/06, Dorothy Stanley < dstanley1389@gmail.com> wrote: > > All, > > Section 11.9.1 describes a WTP WLAN Radio configuration message element, > used by the AC to configure a > radio on the WTP. > > Suggested changes: > > 1. Change the name of the message element to "WTP WLAN Configuration" > message element, since it is the > WLAN on the radio that is being configured. > > 2. Delete country code. The FCC does not allow the country code to be > changed from a controller. > > 3. PCF is often not supported, and is not used widely - used in the > downlink more than in the uplink, not > reliably supported on clients. Delete CFP Maximum duration, CFP Period > and Occupancy Limit. > > Comments? > > Thanks, > > Dorothy > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_2816_29866089.1145059343502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > 2. Delete country code. The FCC does not allow the country code to be = changed from a controller.

Is there a specific FCC document that references this? Also, if the AC handles all channel and power level assignments (ie. makes sure those are in compliance in the current regulatory domain), can the country-code be sent to the WTP for advertisement in beacons/probes?

thanks,
Puneet

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

Section 11.9.1 describes a WTP WLAN Radio configuration message element, us= ed by the AC to configure a
radio on the WTP.

Suggested changes:

1. Change the name of the message element to "WTP WLAN Configuration&q= uot; message element, since it is the
WLAN on the radio that is being configured.

2. Delete country code. The FCC does not allow the country code to be chang= ed from a controller.

3. PCF is often not supported, and is not used widely - used in the downlin= k more than in the uplink, not
reliably supported on clients.  Delete CFP Maximum duration, CFP Perio= d and Occupancy Limit.

Comments?

Thanks,

Dorothy

__________________________________________________________= _______
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_2816_29866089.1145059343502-- --===============1091516239== 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 --===============1091516239==-- From rhi@xperts.hu Fri Apr 14 23:20:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUbKU-00047H-Uf for capwap-archive@ietf.org; Fri, 14 Apr 2006 23:20:10 -0400 Received: from pd9518092.dip0.t-ipconnect.de ([217.81.128.146] helo=xperts.hu) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FUbKP-0004VN-HJ for capwap-archive@ietf.org; Fri, 14 Apr 2006 23:20:10 -0400 Message-ID: <000001c6603b$5dc81b10$85d3a8c0@rhb36> Reply-To: "Rhian Beckmann" From: "Rhian Beckmann" To: capwap-archive@ietf.org Subject: Re: AMBEN news Date: Fri, 14 Apr 2006 23:19:11 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C66019.D6B67B10" 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.9 (+++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C66019.D6B67B10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 X A N A q X $ 1, 42=20 =20 C I m A L I S $ 3, 75=20 =20 V I A G q R A $ 3, 33=20 =20 V A L I U q M $ 1, 21=20 =20 A z M B I E N $ 2, 89=20 =20 http://www.wescosto.com ------=_NextPart_000_0001_01C66019.D6B67B10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
X A N A q X   $ 1, 42
 
C I m A L I S   $ 3, 75
 
V I A G q R A   $ 3, 33
 
V A L I U q M   $ 1, 21
 
A z M B I E N   $ 2, 89
 
= ------=_NextPart_000_0001_01C66019.D6B67B10-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Apr 15 20:08:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUuoV-00036D-2o for capwap-archive@lists.ietf.org; Sat, 15 Apr 2006 20:08:27 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUuoQ-00037M-TL for capwap-archive@lists.ietf.org; Sat, 15 Apr 2006 20:08:24 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E55A74300F7 for ; Sat, 15 Apr 2006 17:08:21 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 92A2443005F for ; Sat, 15 Apr 2006 17:07:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7249F398044 for ; Sat, 15 Apr 2006 17:07:54 -0700 (PDT) Received: from hotmail.com (bay20-f4.bay20.hotmail.com [64.4.54.93]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6063E398032 for ; Sat, 15 Apr 2006 17:07:51 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 15 Apr 2006 17:07:50 -0700 Message-ID: Received: from 63.236.6.198 by by20fd.bay20.hotmail.msn.com with HTTP; Sun, 16 Apr 2006 00:07:46 GMT X-Originating-IP: [202.156.6.21] X-Originating-Email: [saravanang@hotmail.com] X-Sender: saravanang@hotmail.com In-Reply-To: <2758361.1144945226229.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> From: "Saravanan Govindan" To: scott@hyperthought.com, pcalhoun@cisco.com, dstanley1389@gmail.com, Saravanan.Govindan@sg.panasonic.com Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Date: Sun, 16 Apr 2006 08:07:46 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 16 Apr 2006 00:07:50.0862 (UTC) FILETIME=[CCF0D6E0:01C660E9] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.75 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER 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: 58b614506802734014829a093beb6879 Scott, I understand your concerns regarding Echo Request. However, I believe using Echo Requests as a transport offers advantages that exceed your stated concerns below. We've seen substantial overhead reduction in exchanging statistics with Echo Request. This alone should be enough to for its inclusion in CAPWAP. Furthermore, there are implementations currently available that indeed use Echo Requests to exchange some sort of information between APs and AC. Saravanan ----Original Message Follows---- From: "Scott G. Kelly" Reply-To: "Scott G. Kelly" To: pcalhoun@cisco.com, dstanley1389@gmail.com,Saravanan.Govindan@sg.panasonic.com CC: capwap@frascone.com Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Date: Thu, 13 Apr 2006 09:20:26 -0700 (GMT-07:00) I agree heartily with Pat. Implementers know that one implicit purpose of the echo req/reply is to facilite fast recovery in case of a lost capwap "connection". Hence, these may be sent *very* frequently, e.g. the interval may even be as small as 1 second (or even less!) An echo request may be automagically turned around by the AC in the fastpath (without bothering the control processor), but if you add stats to this message, that is no longer the case. The WTP will have to run around and collect everything to assemble the messages, and the AC will have to punt these to the control processor. This does not sound like a scalable design. -----Original Message----- >From: Saravanan Govindan >Sent: Apr 13, 2006 7:46 AM >To: pcalhoun@cisco.com, dstanley1389@gmail.com, Saravanan.Govindan@sg.panasonic.com >Cc: capwap@frascone.com >Subject: RE: [Capwap] Proposed Resolution to Issue 45 - Issueoncombiningmessages > >Pat, > >I hope to help clarify any confusion. My concern is that CAPWAP does need a >set of statistics that are indicative of the WLAN as a whole. Such >big-picture statistics are currently not in the specifications - the current >statistics are specific to the technology binding (802.11). > >I am ok with discussing this as a separate issue. > >Having said this, I think this set of general statistics does not complicate >Echo Request exchanges. In many implementations, this information is already >available - buffer levels, transmission failures, etc. As I mentioned >earlier, such big-picture information provides greater visibility to the AC >and adds value to its control operations. > >Saravanan > > > > >----Original Message Follows---- >From: "Pat Calhoun (pacalhou)" >To: "Dorothy Stanley" ,"Saravanan Govindan" > >CC: capwap >Subject: RE: [Capwap] Proposed Resolution to Issue 45 - >Issueoncombiningmessages >Date: Thu, 13 Apr 2006 06:18:22 -0700 > >I believe the request is for a *new* set of statistics to be sent from >the WTP to the AC. If this is the case, then a >separate issue is required that describes this request. I think I was >just as confused as Dorothy that the request >was to include the existing dot11 statistics within the echo request, >which didn't seem to make sense to me. > >Having said that, I believe that sending an echo should not require >digging everywhere around the system to collect various >statistics, as I believe this would create overhead on the WTP. If this >is localized information, and limited in nature, >then perhaps the impact is minimal. > >Pat Calhoun >CTO, Wireless Networking Business Unit >Cisco Systems > > > > >________________________________ > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > Sent: Wednesday, April 12, 2006 8:00 AM > To: Saravanan Govindan > Cc: capwap > Subject: Re: [Capwap] Proposed Resolution to Issue 45 - Issue >oncombiningmessages > > > Saravanan, Richard, > > I suggest we set aside the question of how the statistics might >be transported for the moment - either in WTP Event Request, Echo >Request or some new > message, and first agree on the nature/definition of the >statistics themselves. We are talking about non-802.11 specific >statistics, as the 802.11 > specific ones, or new 802.11 ones would go in 11.7.2.1: > > WPT buffer levels - which buffers? Concern that this would be >implementation specific > Congestion conditions - congestion on the wireless link? On the >WTP to AC link? > etc - needs to be specified. > > Richard suggests > Network Congestion - which network, the wireless one or the WTP >to AC link. How is the level of congestion measured? > Traffic Loading - How is this measured? Which traffic? > Channel Interferences - Need to specify. Concern that there is >overlap with what will be coming in .11k for radio measurement > > Thanks, > > Dorothy > > On 4/11/06, Saravanan Govindan > wrote: > > Hi Dorothy, > > > > WTP Event Request is being positioned for >technology-specific statistics exchange (Section 2.1). So my >understanding is that WTP Event Request would be used for information >such as transmission attempts, beacon and probe counts, decryption >errors etc. > > > > In addition to technology-specific information, the AC >also needs big-picture information on factors affecting the WLAN as a >whole. This would include WTP buffer levels, congestion conditions, etc. >This information is not specific to a technology but does affect the >WLAN. It is this type of statistics that I suggest the Echo Request >exchange. > > > > Cheers, > > > Saravanan > > > > > > > > > > >________________________________ > > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > Sent: Tuesday, April 11, 2006 10:50 PM > To: Saravanan Govindan > Cc: capwap > Subject: Re: [Capwap] Proposed Resolution to Issue 45 - >Issue on combiningmessages > > > > > > Saravanan, Richard, > > First of all, thank you for your comments. > > Clearly, the WTP must have a means to provide statistics >and other relevant data to the AC.. > > The question becomes, what specific mechanism should be >used? > Overloading the echo request message is one way. CAPWAP >has the WTP event request message, > section 8.5, and already includes the decryption error >report, and can include the .11 specific > statistics report. > > Why is using the WTP event report to report statistics >not sufficient? We should add other applicable CAPWAP message elements > to be included in it. > > > Thanks, > > Dorothy > > > > On 4/10/06, Saravanan Govindan > wrote: > > > > Hi Dorothy, > > > > I think this recommendation add substantial value to the >CAPWAP protocol. There have been discussions on the need for aggregating >statistics information from the WTP to AC. The Echo Request offers a way >for achieving this. The mechanisms for statistics exchanges - timer, >periodic exchange - are available with Echo Request. So I think it is of >value to keep Echo Request and add statistics information fields to it. > > > > Cheers, > > > > Saravanan > > > > > > > > >________________________________ > > From: Dorothy Stanley [mailto: dstanley1389@gmail.com] > Sent: Tuesday, April 11, 2006 1:20 AM > To: capwap > Subject: [Capwap] Proposed Resolution to Issue 45 - >Issue on combiningmessages > > > > All, > > 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 > > Comments please. > > Thanks, > > Dorothy > > > > > > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/capwap > >Archives: http://lists.frascone.com/pipermail/capwap > >_________________________________________________________________ >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 _________________________________________________________________ Get MSN Hotmail alerts on your mobile. http://mobile.msn.com/ac.aspx?cid=uuhp_hotmail _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Apr 15 20:27:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUv6o-0006cE-Ex for capwap-archive@lists.ietf.org; Sat, 15 Apr 2006 20:27:22 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUv6l-0003ot-WC for capwap-archive@lists.ietf.org; Sat, 15 Apr 2006 20:27:22 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9EB8A4300CD for ; Sat, 15 Apr 2006 17:27:19 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id DCFA543005F for ; Sat, 15 Apr 2006 17:26:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AF2B41448011 for ; Sat, 15 Apr 2006 17:26:58 -0700 (PDT) Received: from hotmail.com (bay20-f18.bay20.hotmail.com [64.4.54.107]) by hermes.tigertech.net (Postfix) with ESMTP id 1DEED144800D for ; Sat, 15 Apr 2006 17:26:57 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 15 Apr 2006 17:26:56 -0700 Message-ID: Received: from 63.236.6.198 by by20fd.bay20.hotmail.msn.com with HTTP; Sun, 16 Apr 2006 00:26:52 GMT X-Originating-IP: [202.156.6.21] X-Originating-Email: [saravanang@hotmail.com] X-Sender: saravanang@hotmail.com In-Reply-To: <1013407b0604141701k2a40884am7daca9cff30b6676@mail.gmail.com> From: "Saravanan Govindan" To: pb.ietf@gmail.com Subject: Re: [Capwap] BSSID-WLAN mappings Date: Sun, 16 Apr 2006 08:26:52 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 16 Apr 2006 00:26:56.0848 (UTC) FILETIME=[78006D00:01C660EC] X-Virus-Scanned: by amavisd-new-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.8 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER 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: 02ec665d00de228c50c93ed6b5e4fc1a 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Apr 15 21:17:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUvt5-0004a8-1T for capwap-archive@lists.ietf.org; Sat, 15 Apr 2006 21:17:15 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUvt2-00055L-UA for capwap-archive@lists.ietf.org; Sat, 15 Apr 2006 21:17:14 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E76E4430075 for ; Sat, 15 Apr 2006 18:17:11 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id DF54043005F for ; Sat, 15 Apr 2006 18:16:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id CAD58398024 for ; Sat, 15 Apr 2006 18:16:41 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.151]) by zoidberg.tigertech.net (Postfix) with ESMTP id C4C5139801F for ; Sat, 15 Apr 2006 18:16:40 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (rwcrmhc11) with ESMTP id <20060416011639m11005ceime>; Sun, 16 Apr 2006 01:16:39 +0000 Message-ID: <44419AF7.30807@hyperthought.com> Date: Sat, 15 Apr 2006 18:16:39 -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 Subject: Re: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages References: In-Reply-To: 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@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: 6379955759c38e2371a49573a0932fc7 Hi Saravanan, Saravanan Govindan wrote: > Scott, > > I understand your concerns regarding Echo Request. However, I believe > using Echo Requests as a transport offers advantages that exceed your > stated concerns below. Show me the arithmetic. > We've seen substantial overhead reduction in exchanging statistics with > Echo Request. This alone should be enough to for its inclusion in CAPWAP. Again, show me the arithmetic. Along with the bandwidth savings, include the WTP processor overhead involved with gathering the stats (potentially every second) and the AC fastpath-to-cp overhead this incurs. I don't recall seeing this demonstrated on this list. And exactly what statistics are we talking about here? As far as I can tell, these statistics remain largely undefined, aside from a few suggestions. Until (and unless) they are fully specified, these arguments cannot be fully evaluated. > Furthermore, there are implementations currently available that indeed > use Echo Requests to exchange some sort of information between APs and AC. This is irrelevant. Existence is not a technical justification. The purpose of echo requests (as they have been defined thus far) is to detect a dead peer. One of the primary reasons for this detection is to enable rapid recovery (e.g. AC failover). That implies that echo requests may be sent *very* frequently, as I said below. If you want to make a convincing argument, please show us the math and other arguments that demonstrate we really want to send stats as frequently as we send dead peer detection probes (echo requests), and that there is a compelling justification for combining these (and forcing the echo requests of hundreds of (or more) WTPs to be punted to the control processor every name-yer-favorite-interval seconds) Scott > > Saravanan > > > > ----Original Message Follows---- > From: "Scott G. Kelly" > Reply-To: "Scott G. Kelly" > To: pcalhoun@cisco.com, > dstanley1389@gmail.com,Saravanan.Govindan@sg.panasonic.com > CC: capwap@frascone.com > Subject: RE: [Capwap] Proposed Resolution to Issue 45 > -Issueoncombiningmessages > Date: Thu, 13 Apr 2006 09:20:26 -0700 (GMT-07:00) > > I agree heartily with Pat. Implementers know that one implicit purpose > of the echo req/reply is to facilite fast recovery in case of a lost > capwap "connection". Hence, these may be sent *very* frequently, e.g. > the interval may even be as small as 1 second (or even less!) > > An echo request may be automagically turned around by the AC in the > fastpath (without bothering the control processor), but if you add stats > to this message, that is no longer the case. The WTP will have to run > around and collect everything to assemble the messages, and the AC will > have to punt these to the control processor. This does not sound like a > scalable design. > > -----Original Message----- > >From: Saravanan Govindan > >Sent: Apr 13, 2006 7:46 AM > >To: pcalhoun@cisco.com, dstanley1389@gmail.com, > Saravanan.Govindan@sg.panasonic.com > >Cc: capwap@frascone.com > >Subject: RE: [Capwap] Proposed Resolution to Issue 45 - > Issueoncombiningmessages > > > >Pat, > > > >I hope to help clarify any confusion. My concern is that CAPWAP does > need a > >set of statistics that are indicative of the WLAN as a whole. Such > >big-picture statistics are currently not in the specifications - the > current > >statistics are specific to the technology binding (802.11). > > > >I am ok with discussing this as a separate issue. > > > >Having said this, I think this set of general statistics does not > complicate > >Echo Request exchanges. In many implementations, this information is > already > >available - buffer levels, transmission failures, etc. As I mentioned > >earlier, such big-picture information provides greater visibility to > the AC > >and adds value to its control operations. > > > >Saravanan > > > > > > > > > >----Original Message Follows---- > >From: "Pat Calhoun (pacalhou)" > >To: "Dorothy Stanley" ,"Saravanan Govindan" > > > >CC: capwap > >Subject: RE: [Capwap] Proposed Resolution to Issue 45 - > >Issueoncombiningmessages > >Date: Thu, 13 Apr 2006 06:18:22 -0700 > > > >I believe the request is for a *new* set of statistics to be sent from > >the WTP to the AC. If this is the case, then a > >separate issue is required that describes this request. I think I was > >just as confused as Dorothy that the request > >was to include the existing dot11 statistics within the echo request, > >which didn't seem to make sense to me. > > > >Having said that, I believe that sending an echo should not require > >digging everywhere around the system to collect various > >statistics, as I believe this would create overhead on the WTP. If this > >is localized information, and limited in nature, > >then perhaps the impact is minimal. > > > >Pat Calhoun > >CTO, Wireless Networking Business Unit > >Cisco Systems > > > > > > > > > >________________________________ > > > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > > Sent: Wednesday, April 12, 2006 8:00 AM > > To: Saravanan Govindan > > Cc: capwap > > Subject: Re: [Capwap] Proposed Resolution to Issue 45 - Issue > >oncombiningmessages > > > > > > Saravanan, Richard, > > > > I suggest we set aside the question of how the statistics might > >be transported for the moment - either in WTP Event Request, Echo > >Request or some new > > message, and first agree on the nature/definition of the > >statistics themselves. We are talking about non-802.11 specific > >statistics, as the 802.11 > > specific ones, or new 802.11 ones would go in 11.7.2.1: > > > > WPT buffer levels - which buffers? Concern that this would be > >implementation specific > > Congestion conditions - congestion on the wireless link? On the > >WTP to AC link? > > etc - needs to be specified. > > > > Richard suggests > > Network Congestion - which network, the wireless one or the WTP > >to AC link. How is the level of congestion measured? > > Traffic Loading - How is this measured? Which traffic? > > Channel Interferences - Need to specify. Concern that there is > >overlap with what will be coming in .11k for radio measurement > > > > Thanks, > > > > Dorothy > > > > On 4/11/06, Saravanan Govindan > > wrote: > > > > Hi Dorothy, > > > > > > > > WTP Event Request is being positioned for > >technology-specific statistics exchange (Section 2.1). So my > >understanding is that WTP Event Request would be used for information > >such as transmission attempts, beacon and probe counts, decryption > >errors etc. > > > > > > > > In addition to technology-specific information, the AC > >also needs big-picture information on factors affecting the WLAN as a > >whole. This would include WTP buffer levels, congestion conditions, etc. > >This information is not specific to a technology but does affect the > >WLAN. It is this type of statistics that I suggest the Echo Request > >exchange. > > > > > > > > Cheers, > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > > >________________________________ > > > > > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > > Sent: Tuesday, April 11, 2006 10:50 PM > > To: Saravanan Govindan > > Cc: capwap > > Subject: Re: [Capwap] Proposed Resolution to Issue 45 - > >Issue on combiningmessages > > > > > > > > > > > > Saravanan, Richard, > > > > First of all, thank you for your comments. > > > > Clearly, the WTP must have a means to provide statistics > >and other relevant data to the AC.. > > > > The question becomes, what specific mechanism should be > >used? > > Overloading the echo request message is one way. CAPWAP > >has the WTP event request message, > > section 8.5, and already includes the decryption error > >report, and can include the .11 specific > > statistics report. > > > > Why is using the WTP event report to report statistics > >not sufficient? We should add other applicable CAPWAP message elements > > to be included in it. > > > > > > Thanks, > > > > Dorothy > > > > > > > > On 4/10/06, Saravanan Govindan > > wrote: > > > > > > > > Hi Dorothy, > > > > > > > > I think this recommendation add substantial value to the > >CAPWAP protocol. There have been discussions on the need for aggregating > >statistics information from the WTP to AC. The Echo Request offers a way > >for achieving this. The mechanisms for statistics exchanges - timer, > >periodic exchange - are available with Echo Request. So I think it is of > >value to keep Echo Request and add statistics information fields to it. > > > > > > > > Cheers, > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > >________________________________ > > > > From: Dorothy Stanley [mailto: dstanley1389@gmail.com] > > Sent: Tuesday, April 11, 2006 1:20 AM > > To: capwap > > Subject: [Capwap] Proposed Resolution to Issue 45 - > >Issue on combiningmessages > > > > > > > > All, > > > > 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 > > > > Comments please. > > > > Thanks, > > > > Dorothy > > > > > > > > > > > > > >_________________________________________________________________ > >To unsubscribe or modify your subscription options, please visit: > >http://lists.frascone.com/mailman/listinfo/capwap > > > >Archives: http://lists.frascone.com/pipermail/capwap > > > >_________________________________________________________________ > >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 > > _________________________________________________________________ > Get MSN Hotmail alerts on your mobile. > http://mobile.msn.com/ac.aspx?cid=uuhp_hotmail > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Apr 16 02:42:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FV0xp-0004bm-1h for capwap-archive@lists.ietf.org; Sun, 16 Apr 2006 02:42:29 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FV0xi-0007Zj-Po for capwap-archive@lists.ietf.org; Sun, 16 Apr 2006 02:42:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D223F4300C2 for ; Sat, 15 Apr 2006 23:42:21 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9A07A43005F for ; Sat, 15 Apr 2006 23:41:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 882931448013 for ; Sat, 15 Apr 2006 23:41:48 -0700 (PDT) Received: from hotmail.com (bay20-f14.bay20.hotmail.com [64.4.54.103]) by hermes.tigertech.net (Postfix) with ESMTP id 7D447144800C for ; Sat, 15 Apr 2006 23:41:46 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 15 Apr 2006 23:41:45 -0700 Message-ID: Received: from 63.236.6.204 by by20fd.bay20.hotmail.msn.com with HTTP; Sun, 16 Apr 2006 06:41:42 GMT X-Originating-IP: [202.156.6.20] X-Originating-Email: [saravanang@hotmail.com] X-Sender: saravanang@hotmail.com In-Reply-To: <44419AF7.30807@hyperthought.com> From: "Saravanan Govindan" To: scott@hyperthought.com Subject: Re: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Date: Sun, 16 Apr 2006 14:41:42 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 16 Apr 2006 06:41:45.0638 (UTC) FILETIME=[D45D7460:01C66120] X-Virus-Scanned: by amavisd-new-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.8 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER 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: 6e8a3b85ef670172081194f0b0f68e6f Hi Scott, I'll point you to the presentation Richard made during the meeting in Dallas. The slide on peformance results clearly shows the math you are looking for - exchanging statistics through Echo Request substantially reduces overhead. Your note seems to suggests that Echo signals cannot be configured with statistics. This is not the case. Saravanan ----Original Message Follows---- From: Scott G Kelly To: Saravanan Govindan CC: capwap@frascone.com Subject: Re: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Date: Sat, 15 Apr 2006 18:16:39 -0700 Hi Saravanan, Saravanan Govindan wrote: >Scott, > >I understand your concerns regarding Echo Request. However, I believe using >Echo Requests as a transport offers advantages that exceed your stated >concerns below. Show me the arithmetic. >We've seen substantial overhead reduction in exchanging statistics with >Echo Request. This alone should be enough to for its inclusion in CAPWAP. Again, show me the arithmetic. Along with the bandwidth savings, include the WTP processor overhead involved with gathering the stats (potentially every second) and the AC fastpath-to-cp overhead this incurs. I don't recall seeing this demonstrated on this list. And exactly what statistics are we talking about here? As far as I can tell, these statistics remain largely undefined, aside from a few suggestions. Until (and unless) they are fully specified, these arguments cannot be fully evaluated. >Furthermore, there are implementations currently available that indeed use >Echo Requests to exchange some sort of information between APs and AC. This is irrelevant. Existence is not a technical justification. The purpose of echo requests (as they have been defined thus far) is to detect a dead peer. One of the primary reasons for this detection is to enable rapid recovery (e.g. AC failover). That implies that echo requests may be sent *very* frequently, as I said below. If you want to make a convincing argument, please show us the math and other arguments that demonstrate we really want to send stats as frequently as we send dead peer detection probes (echo requests), and that there is a compelling justification for combining these (and forcing the echo requests of hundreds of (or more) WTPs to be punted to the control processor every name-yer-favorite-interval seconds) Scott > >Saravanan > > > >----Original Message Follows---- >From: "Scott G. Kelly" >Reply-To: "Scott G. Kelly" >To: pcalhoun@cisco.com, >dstanley1389@gmail.com,Saravanan.Govindan@sg.panasonic.com >CC: capwap@frascone.com >Subject: RE: [Capwap] Proposed Resolution to Issue 45 >-Issueoncombiningmessages >Date: Thu, 13 Apr 2006 09:20:26 -0700 (GMT-07:00) > >I agree heartily with Pat. Implementers know that one implicit purpose of >the echo req/reply is to facilite fast recovery in case of a lost capwap >"connection". Hence, these may be sent *very* frequently, e.g. the interval >may even be as small as 1 second (or even less!) > >An echo request may be automagically turned around by the AC in the >fastpath (without bothering the control processor), but if you add stats to >this message, that is no longer the case. The WTP will have to run around >and collect everything to assemble the messages, and the AC will have to >punt these to the control processor. This does not sound like a scalable >design. > >-----Original Message----- > >From: Saravanan Govindan > >Sent: Apr 13, 2006 7:46 AM > >To: pcalhoun@cisco.com, dstanley1389@gmail.com, >Saravanan.Govindan@sg.panasonic.com > >Cc: capwap@frascone.com > >Subject: RE: [Capwap] Proposed Resolution to Issue 45 - >Issueoncombiningmessages > > > >Pat, > > > >I hope to help clarify any confusion. My concern is that CAPWAP does >need a > >set of statistics that are indicative of the WLAN as a whole. Such > >big-picture statistics are currently not in the specifications - the >current > >statistics are specific to the technology binding (802.11). > > > >I am ok with discussing this as a separate issue. > > > >Having said this, I think this set of general statistics does not >complicate > >Echo Request exchanges. In many implementations, this information is >already > >available - buffer levels, transmission failures, etc. As I mentioned > >earlier, such big-picture information provides greater visibility to the >AC > >and adds value to its control operations. > > > >Saravanan > > > > > > > > > >----Original Message Follows---- > >From: "Pat Calhoun (pacalhou)" > >To: "Dorothy Stanley" ,"Saravanan Govindan" > > > >CC: capwap > >Subject: RE: [Capwap] Proposed Resolution to Issue 45 - > >Issueoncombiningmessages > >Date: Thu, 13 Apr 2006 06:18:22 -0700 > > > >I believe the request is for a *new* set of statistics to be sent from > >the WTP to the AC. If this is the case, then a > >separate issue is required that describes this request. I think I was > >just as confused as Dorothy that the request > >was to include the existing dot11 statistics within the echo request, > >which didn't seem to make sense to me. > > > >Having said that, I believe that sending an echo should not require > >digging everywhere around the system to collect various > >statistics, as I believe this would create overhead on the WTP. If this > >is localized information, and limited in nature, > >then perhaps the impact is minimal. > > > >Pat Calhoun > >CTO, Wireless Networking Business Unit > >Cisco Systems > > > > > > > > > >________________________________ > > > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > > Sent: Wednesday, April 12, 2006 8:00 AM > > To: Saravanan Govindan > > Cc: capwap > > Subject: Re: [Capwap] Proposed Resolution to Issue 45 - Issue > >oncombiningmessages > > > > > > Saravanan, Richard, > > > > I suggest we set aside the question of how the statistics might > >be transported for the moment - either in WTP Event Request, Echo > >Request or some new > > message, and first agree on the nature/definition of the > >statistics themselves. We are talking about non-802.11 specific > >statistics, as the 802.11 > > specific ones, or new 802.11 ones would go in 11.7.2.1: > > > > WPT buffer levels - which buffers? Concern that this would be > >implementation specific > > Congestion conditions - congestion on the wireless link? On the > >WTP to AC link? > > etc - needs to be specified. > > > > Richard suggests > > Network Congestion - which network, the wireless one or the WTP > >to AC link. How is the level of congestion measured? > > Traffic Loading - How is this measured? Which traffic? > > Channel Interferences - Need to specify. Concern that there is > >overlap with what will be coming in .11k for radio measurement > > > > Thanks, > > > > Dorothy > > > > On 4/11/06, Saravanan Govindan > > wrote: > > > > Hi Dorothy, > > > > > > > > WTP Event Request is being positioned for > >technology-specific statistics exchange (Section 2.1). So my > >understanding is that WTP Event Request would be used for information > >such as transmission attempts, beacon and probe counts, decryption > >errors etc. > > > > > > > > In addition to technology-specific information, the AC > >also needs big-picture information on factors affecting the WLAN as a > >whole. This would include WTP buffer levels, congestion conditions, etc. > >This information is not specific to a technology but does affect the > >WLAN. It is this type of statistics that I suggest the Echo Request > >exchange. > > > > > > > > Cheers, > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > > >________________________________ > > > > > > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > > Sent: Tuesday, April 11, 2006 10:50 PM > > To: Saravanan Govindan > > Cc: capwap > > Subject: Re: [Capwap] Proposed Resolution to Issue 45 - > >Issue on combiningmessages > > > > > > > > > > > > Saravanan, Richard, > > > > First of all, thank you for your comments. > > > > Clearly, the WTP must have a means to provide statistics > >and other relevant data to the AC.. > > > > The question becomes, what specific mechanism should be > >used? > > Overloading the echo request message is one way. CAPWAP > >has the WTP event request message, > > section 8.5, and already includes the decryption error > >report, and can include the .11 specific > > statistics report. > > > > Why is using the WTP event report to report statistics > >not sufficient? We should add other applicable CAPWAP message elements > > to be included in it. > > > > > > Thanks, > > > > Dorothy > > > > > > > > On 4/10/06, Saravanan Govindan > > wrote: > > > > > > > > Hi Dorothy, > > > > > > > > I think this recommendation add substantial value to the > >CAPWAP protocol. There have been discussions on the need for aggregating > >statistics information from the WTP to AC. The Echo Request offers a way > >for achieving this. The mechanisms for statistics exchanges - timer, > >periodic exchange - are available with Echo Request. So I think it is of > >value to keep Echo Request and add statistics information fields to it. > > > > > > > > Cheers, > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > >________________________________ > > > > From: Dorothy Stanley [mailto: dstanley1389@gmail.com] > > Sent: Tuesday, April 11, 2006 1:20 AM > > To: capwap > > Subject: [Capwap] Proposed Resolution to Issue 45 - > >Issue on combiningmessages > > > > > > > > All, > > > > 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 > > > > Comments please. > > > > Thanks, > > > > Dorothy > > > > > > > > > > > > > >_________________________________________________________________ > >To unsubscribe or modify your subscription options, please visit: > >http://lists.frascone.com/mailman/listinfo/capwap > > > >Archives: http://lists.frascone.com/pipermail/capwap > > > >_________________________________________________________________ > >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 > >_________________________________________________________________ >Get MSN Hotmail alerts on your mobile. >http://mobile.msn.com/ac.aspx?cid=uuhp_hotmail > > _________________________________________________________________ Get MSN Hotmail alerts on your mobile. http://mobile.msn.com/ac.aspx?cid=uuhp_hotmail _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Apr 16 09:30:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FV7Ka-0003a9-Oi for capwap-archive@lists.ietf.org; Sun, 16 Apr 2006 09:30:24 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FV7KW-0007qb-FU for capwap-archive@lists.ietf.org; Sun, 16 Apr 2006 09:30:22 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6816C430082 for ; Sun, 16 Apr 2006 06:30:19 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id EBF2B430059 for ; Sun, 16 Apr 2006 06:29:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B6121431124 for ; Sun, 16 Apr 2006 06:29:41 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.152]) by hermes.tigertech.net (Postfix) with ESMTP id B868743111C for ; Sun, 16 Apr 2006 06:29:39 -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 <20060416132938m12003o46ee>; Sun, 16 Apr 2006 13:29:38 +0000 Message-ID: <444246C2.9030800@hyperthought.com> Date: Sun, 16 Apr 2006 06:29:38 -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 Subject: Re: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages References: In-Reply-To: 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@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: 6fd498969019220b4f904725504c12a0 Hi Saravanan, Saravanan Govindan wrote: > Hi Scott, > > I'll point you to the presentation Richard made during the meeting in > Dallas. The slide on peformance results clearly shows the math you are > looking for - exchanging statistics through Echo Request substantially > reduces overhead. I saw Richard's presentation (and I just reviewed it again in the proceedings), but it doesn't actually do the math I asked for. Instead, it presents a graph that shows two diverging lines, and makes no attempt to explain what is being measured, or why it is reasonable to expect that these values should diverge over time when plotted linearly. An important point: this plot is the result of a simulation. What are the assumptions upon which that simulation is based? I think it probably looks at packet header savings when you eliminate the separate transport headers (which, incidentally, assumes you want to send these statistics at the same interval you want to send echoes), but that doesn't account for the divergence. Maybe Richard can enlighten us a bit here. It also seems to assume a perfect processing world - that is, it ignores the increased processing overhead and complexity at either end when you combine these. And based on Richard's accompanying comments, it also seems to assume a very small statistics payload. As an aside, I think real-world network trace data would be far more enlightening. As a practical matter, there are more than a few questions I have about this. For example, Richard's presentation the size of a statistics element is 4-8 bytes. What are the contents of these 4-8 bytes? One of Richard's emails to the list says the element should look like this: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-\ | Network Congestion | Traffic Loading +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-\ | Channel interferences | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (sorry, but it was apparently posted in html, and didn't render well when I cut-pasted it) This is indeed compact (6 bytes?), but what is the meaning of these values (how are they computed), why is this the best representation for those quantities, and why are these the only relevant statistics? Dorothy Stanley pointed out that we are also interested in transmission attempts, beacon and probe counts, decryption errors, and other things. Where will those values go? I think (and I believe Dorothy already suggested this) that we need a comprehensive enumeration of all relevant statistics, along with some estimation of the appropriate reporting interval(s). > Your note seems to suggests that Echo signals cannot be configured with > statistics. This is not the case. I didn't mean to say it can't be done. Of course it can, but that doesn't mean it's a good design choice. I think this will become more evident once we have an enumeration of necessary statistics and some idea of typical collection intervals (which, by the way, may not be uniform across statistics). --Scott > > Saravanan > > > > > ----Original Message Follows---- > From: Scott G Kelly > To: Saravanan Govindan > CC: capwap@frascone.com > Subject: Re: [Capwap] Proposed Resolution to Issue 45 > -Issueoncombiningmessages > Date: Sat, 15 Apr 2006 18:16:39 -0700 > > Hi Saravanan, > > Saravanan Govindan wrote: > >> Scott, >> >> I understand your concerns regarding Echo Request. However, I believe >> using Echo Requests as a transport offers advantages that exceed your >> stated concerns below. > > > Show me the arithmetic. > >> We've seen substantial overhead reduction in exchanging statistics >> with Echo Request. This alone should be enough to for its inclusion in >> CAPWAP. > > > Again, show me the arithmetic. Along with the bandwidth savings, include > the WTP processor overhead involved with gathering the stats > (potentially every second) and the AC fastpath-to-cp overhead this > incurs. I don't recall seeing this demonstrated on this list. > > And exactly what statistics are we talking about here? As far as I can > tell, these statistics remain largely undefined, aside from a few > suggestions. Until (and unless) they are fully specified, these > arguments cannot be fully evaluated. > >> Furthermore, there are implementations currently available that indeed >> use Echo Requests to exchange some sort of information between APs and >> AC. > > > This is irrelevant. Existence is not a technical justification. > > The purpose of echo requests (as they have been defined thus far) is to > detect a dead peer. One of the primary reasons for this detection is to > enable rapid recovery (e.g. AC failover). That implies that echo > requests may be sent *very* frequently, as I said below. > > If you want to make a convincing argument, please show us the math and > other arguments that demonstrate we really want to send stats as > frequently as we send dead peer detection probes (echo requests), and > that there is a compelling justification for combining these (and > forcing the echo requests of hundreds of (or more) WTPs to be punted to > the control processor every name-yer-favorite-interval seconds) > > Scott > >> >> Saravanan >> >> >> >> ----Original Message Follows---- >> From: "Scott G. Kelly" >> Reply-To: "Scott G. Kelly" >> To: pcalhoun@cisco.com, >> dstanley1389@gmail.com,Saravanan.Govindan@sg.panasonic.com >> CC: capwap@frascone.com >> Subject: RE: [Capwap] Proposed Resolution to Issue 45 >> -Issueoncombiningmessages >> Date: Thu, 13 Apr 2006 09:20:26 -0700 (GMT-07:00) >> >> I agree heartily with Pat. Implementers know that one implicit purpose >> of the echo req/reply is to facilite fast recovery in case of a lost >> capwap "connection". Hence, these may be sent *very* frequently, e.g. >> the interval may even be as small as 1 second (or even less!) >> >> An echo request may be automagically turned around by the AC in the >> fastpath (without bothering the control processor), but if you add >> stats to this message, that is no longer the case. The WTP will have >> to run around and collect everything to assemble the messages, and the >> AC will have to punt these to the control processor. This does not >> sound like a scalable design. >> >> -----Original Message----- >> >From: Saravanan Govindan >> >Sent: Apr 13, 2006 7:46 AM >> >To: pcalhoun@cisco.com, dstanley1389@gmail.com, >> Saravanan.Govindan@sg.panasonic.com >> >Cc: capwap@frascone.com >> >Subject: RE: [Capwap] Proposed Resolution to Issue 45 - >> Issueoncombiningmessages >> > >> >Pat, >> > >> >I hope to help clarify any confusion. My concern is that CAPWAP does >> need a >> >set of statistics that are indicative of the WLAN as a whole. Such >> >big-picture statistics are currently not in the specifications - the >> current >> >statistics are specific to the technology binding (802.11). >> > >> >I am ok with discussing this as a separate issue. >> > >> >Having said this, I think this set of general statistics does not >> complicate >> >Echo Request exchanges. In many implementations, this information is >> already >> >available - buffer levels, transmission failures, etc. As I mentioned >> >earlier, such big-picture information provides greater visibility to >> the AC >> >and adds value to its control operations. >> > >> >Saravanan >> > >> > >> > >> > >> >----Original Message Follows---- >> >From: "Pat Calhoun (pacalhou)" >> >To: "Dorothy Stanley" ,"Saravanan Govindan" >> > >> >CC: capwap >> >Subject: RE: [Capwap] Proposed Resolution to Issue 45 - >> >Issueoncombiningmessages >> >Date: Thu, 13 Apr 2006 06:18:22 -0700 >> > >> >I believe the request is for a *new* set of statistics to be sent from >> >the WTP to the AC. If this is the case, then a >> >separate issue is required that describes this request. I think I was >> >just as confused as Dorothy that the request >> >was to include the existing dot11 statistics within the echo request, >> >which didn't seem to make sense to me. >> > >> >Having said that, I believe that sending an echo should not require >> >digging everywhere around the system to collect various >> >statistics, as I believe this would create overhead on the WTP. If this >> >is localized information, and limited in nature, >> >then perhaps the impact is minimal. >> > >> >Pat Calhoun >> >CTO, Wireless Networking Business Unit >> >Cisco Systems >> > >> > >> > >> > >> >________________________________ >> > >> > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] >> > Sent: Wednesday, April 12, 2006 8:00 AM >> > To: Saravanan Govindan >> > Cc: capwap >> > Subject: Re: [Capwap] Proposed Resolution to Issue 45 - Issue >> >oncombiningmessages >> > >> > >> > Saravanan, Richard, >> > >> > I suggest we set aside the question of how the statistics might >> >be transported for the moment - either in WTP Event Request, Echo >> >Request or some new >> > message, and first agree on the nature/definition of the >> >statistics themselves. We are talking about non-802.11 specific >> >statistics, as the 802.11 >> > specific ones, or new 802.11 ones would go in 11.7.2.1: >> > >> > WPT buffer levels - which buffers? Concern that this would be >> >implementation specific >> > Congestion conditions - congestion on the wireless link? On the >> >WTP to AC link? >> > etc - needs to be specified. >> > >> > Richard suggests >> > Network Congestion - which network, the wireless one or the WTP >> >to AC link. How is the level of congestion measured? >> > Traffic Loading - How is this measured? Which traffic? >> > Channel Interferences - Need to specify. Concern that there is >> >overlap with what will be coming in .11k for radio measurement >> > >> > Thanks, >> > >> > Dorothy >> > >> > On 4/11/06, Saravanan Govindan >> > wrote: >> > >> > Hi Dorothy, >> > >> > >> > >> > WTP Event Request is being positioned for >> >technology-specific statistics exchange (Section 2.1). So my >> >understanding is that WTP Event Request would be used for information >> >such as transmission attempts, beacon and probe counts, decryption >> >errors etc. >> > >> > >> > >> > In addition to technology-specific information, the AC >> >also needs big-picture information on factors affecting the WLAN as a >> >whole. This would include WTP buffer levels, congestion conditions, >> etc. >> >This information is not specific to a technology but does affect the >> >WLAN. It is this type of statistics that I suggest the Echo Request >> >exchange. >> > >> > >> > >> > Cheers, >> > >> > >> > Saravanan >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> >________________________________ >> > >> > >> > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] >> > Sent: Tuesday, April 11, 2006 10:50 PM >> > To: Saravanan Govindan >> > Cc: capwap >> > Subject: Re: [Capwap] Proposed Resolution to Issue 45 - >> >Issue on combiningmessages >> > >> > >> > >> > >> > >> > Saravanan, Richard, >> > >> > First of all, thank you for your comments. >> > >> > Clearly, the WTP must have a means to provide statistics >> >and other relevant data to the AC.. >> > >> > The question becomes, what specific mechanism should be >> >used? >> > Overloading the echo request message is one way. CAPWAP >> >has the WTP event request message, >> > section 8.5, and already includes the decryption error >> >report, and can include the .11 specific >> > statistics report. >> > >> > Why is using the WTP event report to report statistics >> >not sufficient? We should add other applicable CAPWAP message elements >> > to be included in it. >> > >> > >> > Thanks, >> > >> > Dorothy >> > >> > >> > >> > On 4/10/06, Saravanan Govindan >> > wrote: >> > >> > >> > >> > Hi Dorothy, >> > >> > >> > >> > I think this recommendation add substantial value to the >> >CAPWAP protocol. There have been discussions on the need for >> aggregating >> >statistics information from the WTP to AC. The Echo Request offers a >> way >> >for achieving this. The mechanisms for statistics exchanges - timer, >> >periodic exchange - are available with Echo Request. So I think it >> is of >> >value to keep Echo Request and add statistics information fields to it. >> > >> > >> > >> > Cheers, >> > >> > >> > >> > Saravanan >> > >> > >> > >> > >> > >> > >> > >> > >> >________________________________ >> > >> > From: Dorothy Stanley [mailto: dstanley1389@gmail.com] >> > Sent: Tuesday, April 11, 2006 1:20 AM >> > To: capwap >> > Subject: [Capwap] Proposed Resolution to Issue 45 - >> >Issue on combiningmessages >> > >> > >> > >> > All, >> > >> > 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 >> > >> > Comments please. >> > >> > Thanks, >> > >> > Dorothy >> > >> > >> > >> > >> > >> > >> >_________________________________________________________________ >> >To unsubscribe or modify your subscription options, please visit: >> >http://lists.frascone.com/mailman/listinfo/capwap >> > >> >Archives: http://lists.frascone.com/pipermail/capwap >> > >> >_________________________________________________________________ >> >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 >> >> _________________________________________________________________ >> Get MSN Hotmail alerts on your mobile. >> http://mobile.msn.com/ac.aspx?cid=uuhp_hotmail >> >> > > _________________________________________________________________ > Get MSN Hotmail alerts on your mobile. > http://mobile.msn.com/ac.aspx?cid=uuhp_hotmail > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Apr 16 11:19:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FV924-0002xb-H8 for capwap-archive@lists.ietf.org; Sun, 16 Apr 2006 11:19:24 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FV921-0003dP-S4 for capwap-archive@lists.ietf.org; Sun, 16 Apr 2006 11:19:24 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C7AA94300A4 for ; Sun, 16 Apr 2006 08:19:14 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1309E430059 for ; Sun, 16 Apr 2006 08:18:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EA85A4315CB for ; Sun, 16 Apr 2006 08:18:36 -0700 (PDT) Received: from webmail.rp.edu.sg (webmail.rp.sg [202.21.158.83]) by hermes.tigertech.net (Postfix) with ESMTP id 8B6DD4315CC for ; Sun, 16 Apr 2006 08:18:32 -0700 (PDT) Received: from staff-mail.rp.edu.sg ([202.21.158.80]) by webmail.rp.edu.sg with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Apr 2006 23:18:29 +0800 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 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: Sun, 16 Apr 2006 23:18:30 +0800 Message-ID: <9C374CF75527504394E573E1937136C402CEE1E6@staff-mail.rp.edu.sg> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages thread-index: AcZhWeVE7V7ApX13R9CNCmFV/+FXTwACjGFw From: "Richard Gwee" To: "Scott G Kelly" , "Saravanan Govindan" X-OriginalArrivalTime: 16 Apr 2006 15:18:29.0604 (UTC) FILETIME=[042B3A40:01C66169] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: capwap@frascone.com 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: b148ead9c6581b10314b24a9438d3a5f Hi Scott and Saravanan, Sorry that I cannot get into the discussion earlier. Please see my comments inline. Thanks and regards Richard -----Original Message----- From: Scott G Kelly [mailto:scott@hyperthought.com]=20 Sent: Sunday, April 16, 2006 9:30 PM To: Saravanan Govindan Cc: capwap@frascone.com Subject: Re: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Hi Saravanan, Saravanan Govindan wrote: > Hi Scott, >=20 > I'll point you to the presentation Richard made during the meeting in=20 > Dallas. The slide on peformance results clearly shows the math you are > looking for - exchanging statistics through Echo Request substantially > reduces overhead. I saw Richard's presentation (and I just reviewed it again in the proceedings), but it doesn't actually do the math I asked for. Instead,=20 it presents a graph that shows two diverging lines, and makes no attempt to explain what is being measured, or why it is reasonable to expect=20 that these values should diverge over time when plotted linearly. =20 Hi Scott, I am not sure what maths are you really asking for. Is it queueing analysis you are referring to? I am not really clear about your maths requirement. Appreciate if you can enlighten me on this aspect. My simulation results mainly show a comparison between two scenarios. The first scenario denotes a case in which I have separate statistics messages and Echo request messages being exchanged between AC and WTP. The second scenario denotes a case in which I have combined both statistics and echo messages being exchanged between AC and WTP. Over a long period of time, it is reasonable that these values should diverge due to the reduction in overhead when the two messages are combined. An important point: this plot is the result of a simulation. What are=20 the assumptions upon which that simulation is based? The simulation is based on a basic scenario in which I have a model of AC connected to a model of WTP and assume no mobile terminals. I mainly focus on the basic interaction between an AC and a WTP. I think it probably looks at packet header savings when you eliminate=20 the separate transport headers (which, incidentally, assumes you want to send these statistics at the same interval you want to send echoes), but that doesn't account for the divergence. Maybe Richard can enlighten us=20 a bit here. I am a bit confused over your reasoning that the packet header savings doesn't account for the divergence. My thinking (as well as my results have shown) has been that if I have managed to reduce some overhead due to packet header savings, I will definitely see a divergence. Appreciate if you can share with me more specifically your reasoning behind this. I am interested to know. Thanks. It also seems to assume a perfect processing world - that is, it ignores the increased processing overhead and complexity at either end when you=20 combine these. And based on Richard's accompanying comments, it also=20 seems to assume a very small statistics payload. As an aside, I think=20 real-world network trace data would be far more enlightening. I do agree that we have to consider many factors such as processing overhead and complexity. Unfortunately, my resources are limited. But to be fair, there are few simulations that can really model a real scenario. If you feel my simulation is insufficient, I will appreciate if you can propose some scenarios for me to simulate and study or can point me to some resources where I can gather more enlightening data. Thanks. =20 As a practical matter, there are more than a few questions I have about=20 this. For example, Richard's presentation the size of a statistics=20 element is 4-8 bytes. What are the contents of these 4-8 bytes? One of Richard's emails to the list says the element should look like this: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-\ | Network Congestion | Traffic Loading +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-\ | Channel interferences | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (sorry, but it was apparently posted in html, and didn't render well=20 when I cut-pasted it) This is indeed compact (6 bytes?), but what is the meaning of these=20 values (how are they computed), why is this the best representation for=20 those quantities, and why are these the only relevant statistics? I believe I have mentioned how my parameters are computed. I will repeat them again. For network congestion, we should consider the wireless aspect. The metric to be used is frame loss at the WTP end due to channel interference. For traffic loading, the metric to be used is volume of data traffic in both uplink and downlink through the WTP. For channel interference, 802.11k is technology-specific and we should consider general statistics independent of technologies. I will suggest the metric to be used is number of retransmission attempts which can be used to infer the level of channel interference. I have not really claimed that they are the best representations as far as I can remember. I choose them as I felt that they can be sufficiently effective representations for my proposed parameters. I believe I have asked for comments and I will look forward to your counterproposal if any. I am sure that we can discuss and work this out somehow. =20 Dorothy Stanley pointed out that we are also interested in transmission=20 attempts, beacon and probe counts, decryption errors, and other things.=20 Where will those values go? I will definitely look forward to any of your proposal regarding the above if you have any. I believe that we can always discuss this more in details in our working group. I think (and I believe Dorothy already suggested this) that we need a=20 comprehensive enumeration of all relevant statistics, along with some=20 estimation of the appropriate reporting interval(s). > Your note seems to suggests that Echo signals cannot be configured with=20 > statistics. This is not the case. I didn't mean to say it can't be done. Of course it can, but that=20 doesn't mean it's a good design choice. I think this will become more=20 evident once we have an enumeration of necessary statistics and some=20 idea of typical collection intervals (which, by the way, may not be=20 uniform across statistics). --Scott >=20 > Saravanan >=20 >=20 >=20 >=20 > ----Original Message Follows---- > From: Scott G Kelly > To: Saravanan Govindan > CC: capwap@frascone.com > Subject: Re: [Capwap] Proposed Resolution to Issue 45=20 > -Issueoncombiningmessages > Date: Sat, 15 Apr 2006 18:16:39 -0700 >=20 > Hi Saravanan, >=20 > Saravanan Govindan wrote: >=20 >> Scott, >> >> I understand your concerns regarding Echo Request. However, I believe >> using Echo Requests as a transport offers advantages that exceed your >> stated concerns below. >=20 >=20 > Show me the arithmetic. >=20 >> We've seen substantial overhead reduction in exchanging statistics=20 >> with Echo Request. This alone should be enough to for its inclusion in=20 >> CAPWAP. >=20 >=20 > Again, show me the arithmetic. Along with the bandwidth savings, include=20 > the WTP processor overhead involved with gathering the stats=20 > (potentially every second) and the AC fastpath-to-cp overhead this=20 > incurs. I don't recall seeing this demonstrated on this list. >=20 > And exactly what statistics are we talking about here? As far as I can > tell, these statistics remain largely undefined, aside from a few=20 > suggestions. Until (and unless) they are fully specified, these=20 > arguments cannot be fully evaluated. >=20 >> Furthermore, there are implementations currently available that indeed=20 >> use Echo Requests to exchange some sort of information between APs and=20 >> AC. >=20 >=20 > This is irrelevant. Existence is not a technical justification. >=20 > The purpose of echo requests (as they have been defined thus far) is to=20 > detect a dead peer. One of the primary reasons for this detection is to=20 > enable rapid recovery (e.g. AC failover). That implies that echo=20 > requests may be sent *very* frequently, as I said below. >=20 > If you want to make a convincing argument, please show us the math and > other arguments that demonstrate we really want to send stats as=20 > frequently as we send dead peer detection probes (echo requests), and=20 > that there is a compelling justification for combining these (and=20 > forcing the echo requests of hundreds of (or more) WTPs to be punted to=20 > the control processor every name-yer-favorite-interval seconds) >=20 > Scott >=20 >> >> Saravanan >> >> >> >> ----Original Message Follows---- >> From: "Scott G. Kelly" >> Reply-To: "Scott G. Kelly" >> To: pcalhoun@cisco.com,=20 >> dstanley1389@gmail.com,Saravanan.Govindan@sg.panasonic.com >> CC: capwap@frascone.com >> Subject: RE: [Capwap] Proposed Resolution to Issue 45=20 >> -Issueoncombiningmessages >> Date: Thu, 13 Apr 2006 09:20:26 -0700 (GMT-07:00) >> >> I agree heartily with Pat. Implementers know that one implicit purpose=20 >> of the echo req/reply is to facilite fast recovery in case of a lost=20 >> capwap "connection". Hence, these may be sent *very* frequently, e.g. >> the interval may even be as small as 1 second (or even less!) >> >> An echo request may be automagically turned around by the AC in the=20 >> fastpath (without bothering the control processor), but if you add=20 >> stats to this message, that is no longer the case. The WTP will have=20 >> to run around and collect everything to assemble the messages, and the=20 >> AC will have to punt these to the control processor. This does not=20 >> sound like a scalable design. >> >> -----Original Message----- >> >From: Saravanan Govindan >> >Sent: Apr 13, 2006 7:46 AM >> >To: pcalhoun@cisco.com, dstanley1389@gmail.com,=20 >> Saravanan.Govindan@sg.panasonic.com >> >Cc: capwap@frascone.com >> >Subject: RE: [Capwap] Proposed Resolution to Issue 45 - =20 >> Issueoncombiningmessages >> > >> >Pat, >> > >> >I hope to help clarify any confusion. My concern is that CAPWAP does=20 >> need a >> >set of statistics that are indicative of the WLAN as a whole. Such >> >big-picture statistics are currently not in the specifications - the=20 >> current >> >statistics are specific to the technology binding (802.11). >> > >> >I am ok with discussing this as a separate issue. >> > >> >Having said this, I think this set of general statistics does not=20 >> complicate >> >Echo Request exchanges. In many implementations, this information is=20 >> already >> >available - buffer levels, transmission failures, etc. As I mentioned >> >earlier, such big-picture information provides greater visibility to=20 >> the AC >> >and adds value to its control operations. >> > >> >Saravanan >> > >> > >> > >> > >> >----Original Message Follows---- >> >From: "Pat Calhoun (pacalhou)" >> >To: "Dorothy Stanley" ,"Saravanan Govindan" >> > >> >CC: capwap >> >Subject: RE: [Capwap] Proposed Resolution to Issue 45 - >> >Issueoncombiningmessages >> >Date: Thu, 13 Apr 2006 06:18:22 -0700 >> > >> >I believe the request is for a *new* set of statistics to be sent from >> >the WTP to the AC. If this is the case, then a >> >separate issue is required that describes this request. I think I was >> >just as confused as Dorothy that the request >> >was to include the existing dot11 statistics within the echo request, >> >which didn't seem to make sense to me. >> > >> >Having said that, I believe that sending an echo should not require >> >digging everywhere around the system to collect various >> >statistics, as I believe this would create overhead on the WTP. If this >> >is localized information, and limited in nature, >> >then perhaps the impact is minimal. >> > >> >Pat Calhoun >> >CTO, Wireless Networking Business Unit >> >Cisco Systems >> > >> > >> > >> > >> >________________________________ >> > >> > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] >> > Sent: Wednesday, April 12, 2006 8:00 AM >> > To: Saravanan Govindan >> > Cc: capwap >> > Subject: Re: [Capwap] Proposed Resolution to Issue 45 - Issue >> >oncombiningmessages >> > >> > >> > Saravanan, Richard, >> > >> > I suggest we set aside the question of how the statistics might >> >be transported for the moment - either in WTP Event Request, Echo >> >Request or some new >> > message, and first agree on the nature/definition of the >> >statistics themselves. We are talking about non-802.11 specific >> >statistics, as the 802.11 >> > specific ones, or new 802.11 ones would go in 11.7.2.1: >> > >> > WPT buffer levels - which buffers? Concern that this would be >> >implementation specific >> > Congestion conditions - congestion on the wireless link? On the >> >WTP to AC link? >> > etc - needs to be specified. >> > >> > Richard suggests >> > Network Congestion - which network, the wireless one or the WTP >> >to AC link. How is the level of congestion measured? >> > Traffic Loading - How is this measured? Which traffic? >> > Channel Interferences - Need to specify. Concern that there is >> >overlap with what will be coming in .11k for radio measurement >> > >> > Thanks, >> > >> > Dorothy >> > >> > On 4/11/06, Saravanan Govindan >> > wrote: >> > >> > Hi Dorothy, >> > >> > >> > >> > WTP Event Request is being positioned for >> >technology-specific statistics exchange (Section 2.1). So my >> >understanding is that WTP Event Request would be used for information >> >such as transmission attempts, beacon and probe counts, decryption >> >errors etc. >> > >> > >> > >> > In addition to technology-specific information, the AC >> >also needs big-picture information on factors affecting the WLAN as a >> >whole. This would include WTP buffer levels, congestion conditions, >> etc. >> >This information is not specific to a technology but does affect the >> >WLAN. It is this type of statistics that I suggest the Echo Request >> >exchange. >> > >> > >> > >> > Cheers, >> > >> > >> > Saravanan >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> >________________________________ >> > >> > >> > From: Dorothy Stanley [mailto:dstanley1389@gmail.com] >> > Sent: Tuesday, April 11, 2006 10:50 PM >> > To: Saravanan Govindan >> > Cc: capwap >> > Subject: Re: [Capwap] Proposed Resolution to Issue 45 - >> >Issue on combiningmessages >> > >> > >> > >> > >> > >> > Saravanan, Richard, >> > >> > First of all, thank you for your comments. >> > >> > Clearly, the WTP must have a means to provide statistics >> >and other relevant data to the AC.. >> > >> > The question becomes, what specific mechanism should be >> >used? >> > Overloading the echo request message is one way. CAPWAP >> >has the WTP event request message, >> > section 8.5, and already includes the decryption error >> >report, and can include the .11 specific >> > statistics report. >> > >> > Why is using the WTP event report to report statistics >> >not sufficient? We should add other applicable CAPWAP message elements >> > to be included in it. >> > >> > >> > Thanks, >> > >> > Dorothy >> > >> > >> > >> > On 4/10/06, Saravanan Govindan >> > wrote: >> > >> > >> > >> > Hi Dorothy, >> > >> > >> > >> > I think this recommendation add substantial value to the >> >CAPWAP protocol. There have been discussions on the need for=20 >> aggregating >> >statistics information from the WTP to AC. The Echo Request offers a=20 >> way >> >for achieving this. The mechanisms for statistics exchanges - timer, >> >periodic exchange - are available with Echo Request. So I think it=20 >> is of >> >value to keep Echo Request and add statistics information fields to it. >> > >> > >> > >> > Cheers, >> > >> > >> > >> > Saravanan >> > >> > >> > >> > >> > >> > >> > >> > >> >________________________________ >> > >> > From: Dorothy Stanley [mailto: dstanley1389@gmail.com] >> > Sent: Tuesday, April 11, 2006 1:20 AM >> > To: capwap >> > Subject: [Capwap] Proposed Resolution to Issue 45 - >> >Issue on combiningmessages >> > >> > >> > >> > All, >> > >> > 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 >> > >> > Comments please. >> > >> > Thanks, >> > >> > Dorothy >> > >> > >> > >> > >> > >> > >> >_________________________________________________________________ >> >To unsubscribe or modify your subscription options, please visit: >> >http://lists.frascone.com/mailman/listinfo/capwap >> > >> >Archives: http://lists.frascone.com/pipermail/capwap >> > >> >_________________________________________________________________ >> >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 >> >> _________________________________________________________________ >> Get MSN Hotmail alerts on your mobile.=20 >> http://mobile.msn.com/ac.aspx?cid=3Duuhp_hotmail >> >> >=20 > _________________________________________________________________ > Get MSN Hotmail alerts on your mobile.=20 > http://mobile.msn.com/ac.aspx?cid=3Duuhp_hotmail >=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 Republic Polytechnic, 9 Woodlands Avenue 9, Singapore 738964 (Near = Woodlands MRT/Interchange) . www.rp.sg . Fax: +65 6415-1310 .=20 Republic Polytechnic, the first Institute of Higher Learning to fully = adopt the Problem-Based Learning approach in Singapore, continues to = strive towards best practices and maintain excellence in service = standards with the following certifications: Singapore Innovation Class = (SIC), Singapore Quality Class (SQC), People Developer Standards and = QEHS (ISO 9001, 14001 and OHSAS 18001) -------------------------------------------------------------------------= ------- CONFIDENTIALITY CAUTION: This message is intended only for the use of = the individual or entity to whom it is addressed and contains = information that is privileged and confidential. If you, the reader of = this message, are not the intended recipient, you should not = disseminate, distribute or copy this communication. If you have received = this communication in error, please notify us immediately by return = email and delete the original message. Thank you. =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 Sun Apr 16 13:58:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVBVv-0000HC-T6 for capwap-archive@lists.ietf.org; Sun, 16 Apr 2006 13:58:23 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVBVm-0000iM-6h for capwap-archive@lists.ietf.org; Sun, 16 Apr 2006 13:58:15 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6001A4300AD for ; Sun, 16 Apr 2006 10:58:13 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 94657430059 for ; Sun, 16 Apr 2006 10:57:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7B6D7398017 for ; Sun, 16 Apr 2006 10:57:50 -0700 (PDT) Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [204.127.192.84]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4814139801B for ; Sun, 16 Apr 2006 10:57:47 -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 <20060416175746m1400ra1s1e>; Sun, 16 Apr 2006 17:57:47 +0000 Message-ID: <4442859A.4050007@hyperthought.com> Date: Sun, 16 Apr 2006 10:57:46 -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: Richard Gwee Subject: Re: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages References: <9C374CF75527504394E573E1937136C402CEE1E6@staff-mail.rp.edu.sg> In-Reply-To: <9C374CF75527504394E573E1937136C402CEE1E6@staff-mail.rp.edu.sg> 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@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: 42e3ed3f10a1d8bef690f09da16f507a Hi Richard, This is a very difficult conversation to have in email, due to its complexity. I'll try to be succinct. I'm trimming much of the surrounding context below, as the mixed reply styles (some with '>' preceding reply lines, some not) is becoming really confusing. Comments inlined below. Richard Gwee wrote: > > I saw Richard's presentation (and I just reviewed it again in the > proceedings), but it doesn't actually do the math I asked for. Instead, > it presents a graph that shows two diverging lines, and makes no attempt > > to explain what is being measured, or why it is reasonable to expect > that these values should diverge over time when plotted linearly. > > > Hi Scott, I am not sure what maths are you really asking for. Is it > queueing analysis you are referring to? I am not really clear about your > maths requirement. Appreciate if you can enlighten me on this aspect. See response below regarding scenarios... > The second scenario denotes a case in which I have combined both > statistics and echo messages being exchanged between AC and WTP. Over a > long period of time, it is reasonable that these values should diverge > due to the reduction in overhead when the two messages are combined. > To put this simply, the graph only shows bytes received. There are other interesting quantities relating to overhead - for example, the additional processing requirements this imposes under various conditions. You have to think about scaling on the AC side. That would be very difficult to account for in a simulation, and depends on the implementation. > An important point: this plot is the result of a simulation. What are > the assumptions upon which that simulation is based? > > > The simulation is based on a basic scenario in which I have a model of > AC connected to a model of WTP and assume no mobile terminals. I mainly > focus on the basic interaction between an AC and a WTP. > First, is this really a valid model, with no STA's connected? Adding STAs will increase congestion on the LAN side, and perhaps even contribute to dropped echo frames. > I think it probably looks at packet header savings when you eliminate > the separate transport headers (which, incidentally, assumes you want to > > send these statistics at the same interval you want to send echoes), but > > that doesn't account for the divergence. Maybe Richard can enlighten us > a bit here. > > > I am a bit confused over your reasoning that the packet header savings > doesn't account for the divergence. My thinking (as well as my results > have shown) has been that if I have managed to reduce some overhead due > to packet header savings, I will definitely see a divergence. > > Appreciate if you can share with me more specifically your reasoning > behind this. I am interested to know. Thanks. > Your assumptions aren't clear from the graph. Here's a simple summary of a few ways to look at this: Scenario 1: echoes and stats are sent at the same intervals. The redundancy here is in L2, L3, L4, and capwap transport headers. In this case, combining the messages should produce a precisely linear result across time (e.g. 52 bytes saved per combined message). No divergence. Scenario 2: echoes are sent more frequently than stats. Combining these may be worse if your echo interval is much shorter than your stats interval, because now you're sending way more stats than you would have been otherwise, for a net loss in efficiency (convergence with crossover, followed by negative divergence). Scenario 3: stats are sent more frequently than echos. Combining these may better in some scenarios (looking only at bits on the wire), but this seems like an unrealistic approach. Assuming you really would want to do this, you'd get divergence with crossover. What assumptions did you make in your simulation? It is not clear from the graph. The only thing I think is clear is that it could not have been scenario 1, because this would clearly yield a linear result (i.e. parallel lines with no divergence). > It also seems to assume a perfect processing world - that is, it ignores > the increased processing overhead and complexity at either end when you > combine these. And based on Richard's accompanying comments, it also > seems to assume a very small statistics payload. As an aside, I think > real-world network trace data would be far more enlightening. > > > I do agree that we have to consider many factors such as processing > overhead and complexity. Unfortunately, my resources are limited. But to > be fair, there are few simulations that can really model a real > scenario. ...which is why we shouldn't base our decision on simulation results alone. > If you feel my simulation is insufficient, I will appreciate > if you can propose some scenarios for me to simulate and study or can > point me to some resources where I can gather more enlightening data. > Thanks. > Well, this may seem a bit tongue-in-cheek, but perhaps you could try running and measuring real traffic? Short of that, it would be nice to see results for all three scenarios described above. ------------------ I've trimmed the rest, because I think we're going rather far afield here. Dorothy Stanley suggested that we should set aside the question of combining these questions and first discuss what stats we are interested in. You have suggested a few, as has Saravan. I am in the process of polling folks I work with to see if anything is missing. I would suggest that all interested vendors do this, and that we try to close on that question within a day or two (say, Tuesday?) I think a critical question we have to answer is, which of the 3 scenarios I described above is the average case for capwap, i.e. stats with every echo, more echoes than stats, or more stats than echoes? Personally, I think more echoes than stats is the most likely, but I'd like to hear other points of view. Only when we know the answer to that question can we reasonably discuss the implications of any particular optimization strategy. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Apr 16 19:09:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVGNT-000391-NW for capwap-archive@lists.ietf.org; Sun, 16 Apr 2006 19:09:59 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVGNP-000441-W9 for capwap-archive@lists.ietf.org; Sun, 16 Apr 2006 19:09:57 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 339074300CB for ; Sun, 16 Apr 2006 16:09:55 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 01185430059 for ; Sun, 16 Apr 2006 16:09:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BB6341448008 for ; Sun, 16 Apr 2006 16:09:36 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 405F21448002 for ; Sun, 16 Apr 2006 16:09:35 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k3GN9SbZ014077; Sun, 16 Apr 2006 16:09:28 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k3GN9FFT014037; Sun, 16 Apr 2006 16:09:21 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Sun, 16 Apr 2006 16:09:15 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Scott G Kelly Subject: Re: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages In-Reply-To: <4442859A.4050007@hyperthought.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new-20030616-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: 52e1467c2184c31006318542db5614d5 HI, There are a few issues that seem to be over looked in this discussion about echos. First, in other protocols, a keep alive (which is the primary purpose for the Echo Request/Response) is sent only after no network traffic has been sent and is not sent periodically as specified in CAPWAP-00. I believe that CAPWAP-00 should be changed so that an echo request is sent only after no traffic has been sent or received. Also note that CAPWAP-00 appears (but I can't really determine) to have application level timeout and retry for operations. That is, if no operation confirmation is received after the configured timeout, then the operation is retried upto a configured count. If the retry is not successful, then the AC (and WTP) mark the connection as down and a WTP restarts the Discovery cycle. So, please, let's clean up these issues, and when we do I believe that the answer for whether or not statistics should be piggy backed on echo responses will be very clear. 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 Sun Apr 16 19:47:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVGyB-0002P6-IB for capwap-archive@lists.ietf.org; Sun, 16 Apr 2006 19:47:55 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVGy9-0005FK-Tw for capwap-archive@lists.ietf.org; Sun, 16 Apr 2006 19:47:55 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 530B34300AE for ; Sun, 16 Apr 2006 16:47:53 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8723B430059 for ; Sun, 16 Apr 2006 16:47:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6EA921448011 for ; Sun, 16 Apr 2006 16:47:21 -0700 (PDT) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.191]) by hermes.tigertech.net (Postfix) with ESMTP id 2828A1448008 for ; Sun, 16 Apr 2006 16:47:18 -0700 (PDT) Received: by nproxy.gmail.com with SMTP id k26so341518nfc for ; Sun, 16 Apr 2006 16:47:17 -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=utEU2ya7oL1ki6RzxIZLGNpXB3D186m4MHY5/P6N/6U0SHzey5I8UhBR7cf1vhqxVO4bVXlZMQTHIOT3QZSlycBTQB9lXx68qEQD/wuyjFuLItxvFxl17PuSLBf0EjekA/dvxcR6+B3Wp71YIo283tRVqkTMuMIwWBWMTNOMV30= Received: by 10.49.8.5 with SMTP id l5mr2143968nfi; Sun, 16 Apr 2006 16:47:17 -0700 (PDT) Received: by 10.48.204.2 with HTTP; Sun, 16 Apr 2006 16:47:17 -0700 (PDT) Message-ID: <1013407b0604161647j37ec3c2akc8179683c7bc07a7@mail.gmail.com> Date: Sun, 16 Apr 2006 16:47:17 -0700 From: Puneet To: "Saravanan Govindan" Subject: Re: [Capwap] BSSID-WLAN mappings In-Reply-To: MIME-Version: 1.0 References: <1013407b0604141701k2a40884am7daca9cff30b6676@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.5 tagged_above=-999.0 required=7.0 tests=HTML_20_30, HTML_MESSAGE, 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="===============0820955031==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 --===============0820955031== Content-Type: multipart/alternative; boundary="----=_Part_17002_27641924.1145231237084" ------=_Part_17002_27641924.1145231237084 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 thi= s > 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 multipl= e > > 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 > > ------=_Part_17002_27641924.1145231237084 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 <saravanang@hotmail.com> wrote:
Hi Puneet,

My concern regarding the BSSID - WLAN mapping is based on= the mandatory
Objective "Logical Groups" (Section 5.1.1 of CA= PWAP Objectives).

The Objective requires that WTP traffic be kept lo= gically distinct among
logical groups. This arises from the commercial need of service provide= rs
sharing WLAN infrastructure equipment. Service providers want their t= raffic
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 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<= /a>
> *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 m= ultiple
> SSIDs on a single BSSID? (whether thats good design or bad= is a different
> matter). Since the WLAN ID could be used in all su= ch places to convey
WLAN
> information back to the AC, why do we need to mandate thi= s 1:1 BSSID-WLAN
> mapping?
>
> Thanks,
> Punee= t
>
> _______________________________________________________= __________
> To unsubscribe or modify your subscription options, please visit:=
> htt= p://lists.frascone.com/mailman/listinfo/capwap
>
> Archiv= es:=20 http://lists.frascon= e.com/pipermail/capwap
>

________________________________= _________________________________
Get an advanced look at the new versio= n of MSN Messenger.
http://messen= ger.msn.com.sg/Beta/Default.aspx


------=_Part_17002_27641924.1145231237084-- --===============0820955031== 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 --===============0820955031==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Apr 17 02:30:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVNFu-0004bU-J8 for capwap-archive@lists.ietf.org; Mon, 17 Apr 2006 02:30:38 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVNFl-0003fg-Rd for capwap-archive@lists.ietf.org; Mon, 17 Apr 2006 02:30:32 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C14274300EA for ; Sun, 16 Apr 2006 23:30:28 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D1F74430059 for ; Sun, 16 Apr 2006 23:29:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B74D1144800C for ; Sun, 16 Apr 2006 23:29:59 -0700 (PDT) Received: from mail.u4eatech.com (blackhole.u4eatech.com [195.188.241.2]) by hermes.tigertech.net (Postfix) with ESMTP id B8189144800B for ; Sun, 16 Apr 2006 23:29:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.u4eatech.com (Postfix) with ESMTP id 800D63608C7; Mon, 17 Apr 2006 07:14:46 +0100 (BST) Received: FROM mail.u4eatech.com ([127.0.0.1]) BY localhost WITH ESMTP ; Mon, 17 Apr 2006 07:14:46 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.u4eatech.com (Postfix) with ESMTP id 5489C3608C3; Mon, 17 Apr 2006 07:14:46 +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 20012-01; Mon, 17 Apr 2006 07:14:42 +0100 (BST) Received: from [192.168.254.5] (ppp-71-139-194-19.dsl.snfc21.pacbell.net [71.139.194.19]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.u4eatech.com (Postfix) with ESMTP id A5A073608C1; Mon, 17 Apr 2006 07:14:40 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Message-Id: <95481622-4CCC-4A33-BB60-5704A9461D9E@u4eatech.com> From: Philip Rakity Subject: Re: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Date: Sun, 16 Apr 2006 23:29:46 -0700 To: "David T. Perkins" X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: amavisd-new at u4eatech.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap@frascone.com 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="===============1292546911==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c --===============1292546911== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--555538194; protocol="application/pkcs7-signature" --Apple-Mail-2--555538194 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed David, I concur. Also, the link should NOT be timed out if traffic is happening on the data path even if no echo requests get though. I am reminded of a frame relay test I failed (in an earlier life) where the link was 100% saturated and the LMI traffic got dropped. We failed the test and modified the code to pass but at the 100,000 foot level it was totally wrong. If bi-directional traffic was working THE link WAS UP. Philip On Apr 16, 2006, at 4:09 PM, David T. Perkins wrote: > HI, > > There are a few issues that seem to be over looked in > this discussion about echos. > > First, in other protocols, a keep alive (which is the > primary purpose for the Echo Request/Response) is > sent only after no network traffic has been sent > and is not sent periodically as specified in CAPWAP-00. > > I believe that CAPWAP-00 should be changed so that > an echo request is sent only after no traffic has > been sent or received. > > Also note that CAPWAP-00 appears (but I can't really > determine) to have application level timeout and > retry for operations. That is, if no operation > confirmation is received after the configured timeout, > then the operation is retried upto a configured count. > If the retry is not successful, then the AC (and WTP) > mark the connection as down and a WTP restarts the > Discovery cycle. > > So, please, let's clean up these issues, and when we do > I believe that the answer for whether or not statistics > should be piggy backed on echo responses will be very > clear. > > 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 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--555538194 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 DTA2MDQxNzA2Mjk0NlowIwYJKoZIhvcNAQkEMRYEFOmKzuALFzz/5Wq4IsOPebI5vjEkMIGVBgkr BgEEAYI3EAQxgYcwgYQwfzEiMCAGA1UEAxMZZmx5aW5nbW9ua2V5LnU0ZWF0ZWNoLmNvbTEaMBgG A1UEChMRVTRFQSBUZWNobm9sb2dpZXMxHjAcBgkqhkiG9w0BCQEWD2l0QHU0ZWF0ZWNoLmNvbTEL MAkGA1UEBhMCVUsxEDAOBgNVBAcTB0JyaXN0b2wCASUwgZcGCyqGSIb3DQEJEAILMYGHoIGEMH8x IjAgBgNVBAMTGWZseWluZ21vbmtleS51NGVhdGVjaC5jb20xGjAYBgNVBAoTEVU0RUEgVGVjaG5v bG9naWVzMR4wHAYJKoZIhvcNAQkBFg9pdEB1NGVhdGVjaC5jb20xCzAJBgNVBAYTAlVLMRAwDgYD VQQHEwdCcmlzdG9sAgElMA0GCSqGSIb3DQEBAQUABIGABLjM7B8Ug96NlhYaf4YyKTTOL+0XxKG2 TMwvGB6DrW67g/vtu++cvRxmIeHLBLekfTt50i/3yKU3wvGTs+9w26SwgbBH2uEjZ/wcDqnBWBrt DcZhoB86gXgI1fVqiFp5y4TdZSCiCxBesOdzumKDiN6rzxdFKCpA0NzVJBJPatoAAAAAAAA= --Apple-Mail-2--555538194-- --===============1292546911== 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 --===============1292546911==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Apr 17 09:22:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVTg1-0003L6-8V for capwap-archive@lists.ietf.org; Mon, 17 Apr 2006 09:22:01 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVTfz-000586-P9 for capwap-archive@lists.ietf.org; Mon, 17 Apr 2006 09:22:01 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E32C843011F for ; Mon, 17 Apr 2006 06:21:58 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A2D26430093 for ; Mon, 17 Apr 2006 06:21:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8C703398070 for ; Mon, 17 Apr 2006 06:21:37 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.192.81]) by zoidberg.tigertech.net (Postfix) with ESMTP id B434D398023 for ; Mon, 17 Apr 2006 06:21:35 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (rwcrmhc11) with ESMTP id <20060417132134m11005fehte>; Mon, 17 Apr 2006 13:21:35 +0000 Message-ID: <4443965E.5000402@hyperthought.com> Date: Mon, 17 Apr 2006 06:21:34 -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: Philip Rakity , "David T. Perkins" Subject: Re: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages References: <95481622-4CCC-4A33-BB60-5704A9461D9E@u4eatech.com> In-Reply-To: <95481622-4CCC-4A33-BB60-5704A9461D9E@u4eatech.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@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: c83ccb5cc10e751496398f1233ca9c3a Philip Rakity wrote: > > David, > > I concur. Also, the link should NOT be timed out if traffic is > happening on the data path even if no echo requests get though. I am > reminded of a frame relay test I failed (in an earlier life) where the > link was 100% saturated and the LMI traffic got dropped. We failed the > test and modified the code to pass but at the 100,000 foot level it was > totally wrong. If bi-directional traffic was working THE link WAS UP. > > Philip I've been thinking about this ever since David posted. While I think this is sound reasoning under many conditions, I think there are reasons we may want to look slightly differently at things in our case. In particular, I don't think we can (securely) infer AC liveness based on the presence of data traffic. Assume we don't have a separate statistics message (which is the case today): in this case there will be relatively sporadic control channel data after initial join and configuration traffic (802.11 associates, event requests), and if no STA's are associating, there will likely be no control (or data) traffic. Also note that in the case of local MAC, there will be no data channel traffic in any case. Second, in the non-local MAC cases note that the control channel is authenticated, while the data channel is not. I think this means that under some circumstances we could be seeing what, from the perspective of the WTP, is data traffic (proof of AC liveness?), but in fact, is well-formatted garbage. I haven't thought all the way through the implications of 'properly formatted' 802.11i garbage at the STA (would it dissasociate?), but if 802.11i is terminated at the WTP, it could also be real traffic flowing to/from a session hijacker. Alternatively, a STA could be sending unidirectional (i.e. syslog) traffic, which meets the 'traffic on the link test'. That is, the AC could be down, but the WTP would not know it based on this metric. Am I missing something here? If not, this means we can't use data traffic to infer AC liveness. However, it doesn't address David's point, which I think I agree is a good one. We really don't need to be sending echoes if control traffic is present during the echo interval. And as David suggests, that answers the question about combining echoes and stats. Scott > > On Apr 16, 2006, at 4:09 PM, David T. Perkins wrote: > >> HI, >> >> There are a few issues that seem to be over looked in >> this discussion about echos. >> >> First, in other protocols, a keep alive (which is the >> primary purpose for the Echo Request/Response) is >> sent only after no network traffic has been sent >> and is not sent periodically as specified in CAPWAP-00. >> >> I believe that CAPWAP-00 should be changed so that >> an echo request is sent only after no traffic has >> been sent or received. >> >> Also note that CAPWAP-00 appears (but I can't really >> determine) to have application level timeout and >> retry for operations. That is, if no operation >> confirmation is received after the configured timeout, >> then the operation is retried upto a configured count. >> If the retry is not successful, then the AC (and WTP) >> mark the connection as down and a WTP restarts the >> Discovery cycle. >> >> So, please, let's clean up these issues, and when we do >> I believe that the answer for whether or not statistics >> should be piggy backed on echo responses will be very >> clear. >> >> 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 > > > 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. > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Apr 17 13:07:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVXCA-0001ON-AH for capwap-archive@lists.ietf.org; Mon, 17 Apr 2006 13:07:26 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVXC8-0000xQ-II for capwap-archive@lists.ietf.org; Mon, 17 Apr 2006 13:07:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id BD86D430094 for ; Mon, 17 Apr 2006 10:07:23 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E734E430093 for ; Mon, 17 Apr 2006 10:06:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BFB7B431078 for ; Mon, 17 Apr 2006 10:06:29 -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 6F2324310C8 for ; Mon, 17 Apr 2006 10:06:24 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-2.cisco.com with ESMTP; 17 Apr 2006 10:06:23 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3HH6Nw1019373 for ; Mon, 17 Apr 2006 10:06:23 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Apr 2006 10:06:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] BSSID-WLAN mappings Date: Mon, 17 Apr 2006 10:06:21 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC01672F00@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] BSSID-WLAN mappings Thread-Index: AcZhsCcb5TKfV+QHSkekia4Q/zZXkgAkJ/8A From: "Bob O'Hara (boohara)" To: X-OriginalArrivalTime: 17 Apr 2006 17:06:23.0043 (UTC) FILETIME=[410D6130:01C66241] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_30_40, HTML_MESSAGE 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: , Content-Type: multipart/mixed; boundary="===============1905591007==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e This is a multi-part message in MIME format. --===============1905591007== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66241.40DBE27A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66241.40DBE27A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 We should not be implementing, or requiring an CAPWAP implementation to implement a method that lowers the security of the WLAN. -Bob =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 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:=20 Hi Puneet, =09 My concern regarding the BSSID - WLAN mapping is based on the mandatory Objective "Logical Groups" (Section 5.1.1 of CAPWAP Objectives). =09 The Objective requires that WTP traffic be kept logically distinct among=20 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=20 over the AC-WTP environment (e.g. WLANs). =09 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,=20 CAPWAP frames of different logical groups (WLANs) can be distinctly exchanged. =09 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 =09 Cheers, =09 Saravanan =09 =09 =09 =09 > ------------------------------ > *From:* Puneet [mailto:pb.ietf@gmail.com] > *Sent:* Friday, April 14, 2006 12:29 AM=20 > *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=20 > 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=20 WLAN > information back to the AC, why do we need to mandate this 1:1 BSSID-WLAN > mapping? > > Thanks, > Puneet > > _________________________________________________________________=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 =09 _________________________________________________________________ Get an advanced look at the new version of MSN Messenger.=20 http://messenger.msn.com.sg/Beta/Default.aspx =09 =09 ------_=_NextPart_001_01C66241.40DBE27A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There are also security issues when there is = not a 1:1=20 mapping of WLAN to BSSID.  Without this restriction, a station will = not=20 have any assurance that traffic it believes is encrypted and protected = according=20 to the policy of the WLAN to which it is associated is not being = decrypted by an=20 oracle (the AP) and rebroadcast to other stations without the same = requirements=20 for abiding with the same security policies.
 
We should not be implementing, or requiring = an CAPWAP=20 implementation to implement a method that lowers the security of the=20 WLAN.

 -Bob
 

 

From: Puneet = [mailto:pb.ietf@gmail.com]=20
Sent: Sunday, April 16, 2006 4:47 PM
To: Saravanan=20 Govindan
Cc: capwap@frascone.com
Subject: Re: = [Capwap]=20 BSSID-WLAN mappings

Hi Saravanan,

I see your point, but this seems to = address a=20 very specific deployment scenario (service providers sharing WLAN = equipment). If=20 nothing else in the CAPWAP messages is dependent on this, then this = should be a=20 recommendation instead of a mandate. That way the protocol remains = inclusive,=20 and also meets its objective.

I think it is very important that = existing=20 implementations are not excluded just because they dont seem to meet one = specific need in a specific deployment=20 scenario.

Thanks,
Puneet


On 4/15/06, Saravanan=20 Govindan <saravanang@hotmail.com>=20 wrote:
Hi=20 Puneet,

My concern regarding the BSSID - WLAN mapping is based = on the=20 mandatory
Objective "Logical Groups" (Section 5.1.1 of CAPWAP=20 Objectives).

The Objective requires that WTP traffic be kept = logically=20 distinct among
logical groups. This arises from the commercial = need of=20 service providers
sharing WLAN infrastructure equipment. Service = providers=20 want their traffic
to be distinguished both over the wireless = environment=20 (e.g. BSSIDS) and
over the AC-WTP environment (e.g. = WLANs).

The=20 BSSID-WLAN mapping issue is the technical requirement coming from=20 this
commercial need. It allows an AC - or WTP - to decide how = logical=20 groups are
separated over the wireless and AC-WTP segments. So by = making=20 this mapping,
CAPWAP frames of different logical groups (WLANs) = can be=20 distinctly
exchanged.

I agree with others that this mapping = should=20 not exclude any implementation
- my concern is that the mapping be=20 including in the first place.=20 =

Cheers,

Saravanan




>  -----= -------------------------
>=20 *From:* Puneet [mailto:pb.ietf@gmail.com]
> = *Sent:* Friday,=20 April 14, 2006 12:29 AM
> *To:* capwap@frascone.com
> = *Subject:*=20 [Capwap] BSSID-WLAN mappings
>
> the BSSID description in = Section=20 11.9.1 'WTP Radio Configuration' notes
> that a WTP that = supports 16=20 WLANS MUST have 16 MAC addresses reserved for
> it. Why? ie. = what part=20 of the protocol does not work if we have multiple
> SSIDs on a = single=20 BSSID? (whether thats good design or bad is a different
> = matter). Since=20 the WLAN ID could be used in all such places to convey =
WLAN
>=20 information back to the AC, why do we need to mandate this 1:1=20 BSSID-WLAN
> mapping?
>
> Thanks,
>=20 Puneet
>
>=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
>

________________________________= _________________________________
Get=20 an advanced look at the new version of MSN Messenger.
http://messenger.m= sn.com.sg/Beta/Default.aspx


------_=_NextPart_001_01C66241.40DBE27A-- --===============1905591007== 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 --===============1905591007==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Apr 17 13:39:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVXhN-0005Ao-IN for capwap-archive@lists.ietf.org; Mon, 17 Apr 2006 13:39:41 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVXhL-0002yU-Cm for capwap-archive@lists.ietf.org; Mon, 17 Apr 2006 13:39:41 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 53DD84300C5 for ; Mon, 17 Apr 2006 10:39:38 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 062B1430093 for ; Mon, 17 Apr 2006 10:39:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E457043115E for ; Mon, 17 Apr 2006 10:39:03 -0700 (PDT) X-Greylist-Status: Sender first seen 2 days 17:37:58 ago Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.184]) by hermes.tigertech.net (Postfix) with ESMTP id 6CC76431158 for ; Mon, 17 Apr 2006 10:39:01 -0700 (PDT) Received: by nproxy.gmail.com with SMTP id b2so392235nfe for ; Mon, 17 Apr 2006 10:38:59 -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=E3dBdi8wFzIRyy0Cu+qDUdUZe3W+ZFANf3OG/HqIslrMjkYRuxeS/eTd6KX2Al8Nw7GsBjhVR4yARAwfU9XwBvzELA4V3NvKbu1T7eg+YTkuYI1Te3kuNnn6tlFZaGIwjaJ0m1rI9Fal8oVco/R50Z0yZZZ4SbI1tHUlgs6WPcs= Received: by 10.48.162.10 with SMTP id k10mr804684nfe; Mon, 17 Apr 2006 10:38:59 -0700 (PDT) Received: by 10.48.204.2 with HTTP; Mon, 17 Apr 2006 10:38:59 -0700 (PDT) Message-ID: <1013407b0604171038wa045339h7049be4ba8fa088@mail.gmail.com> Date: Mon, 17 Apr 2006 10:38:59 -0700 From: Puneet To: "Bob O'Hara (boohara)" Subject: Re: [Capwap] BSSID-WLAN mappings In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC01672F00@xmb-sjc-237.amer.cisco.com> MIME-Version: 1.0 References: <17B8C6DE4E228348B4939BDA6B05A9DC01672F00@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=3.1 tagged_above=-999.0 required=7.0 tests=HTML_40_50, HTML_MESSAGE, 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: , Content-Type: multipart/mixed; boundary="===============1779684703==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.9 (+) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec --===============1779684703== Content-Type: multipart/alternative; boundary="----=_Part_6702_21984943.1145295539429" ------=_Part_6702_21984943.1145295539429 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 ove= r 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 t= hat > 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 (t= he > 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 t= he > CAPWAP messages is dependent on this, then this should be a recommendatio= n > 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 speci= fic > 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 amon= g > > > > 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) an= d > > > > 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 group= s > > 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 > > ------=_Part_6702_21984943.1145295539429 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Bob,

> We should not be implementing, or requiring an CAPWAP=20 implementation to implement a method
> that lowers the security of the=20 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) <boohara@cisco.com> wrote:
There are also security issues when there is not a 1:1=20 mapping of WLAN to BSSID.  Without this restriction, a station will no= t=20 have any assurance that traffic it believes is encrypted and protected acco= rding=20 to the policy of the WLAN to which it is associated is not being decrypted = by an=20 oracle (the AP) and rebroadcast to other stations without the same requirem= ents=20 for abiding with the same security policies.
 
We should not be implementing, or requiring an CAPWAP=20 implementation to implement a method that lowers the security of the=20 WLAN.

 -Bob
 

 

From: Puneet [m= ailto: pb.ietf@gmail.com]=20
Sent: Sunday, = April 16, 2006 4:47 PM
To: Saravanan=20 Govindan
Cc: capwap@frasco= ne.com
Subject: Re: [Capwap]=20 BSSID-WLAN mappings

Hi Saravanan,

I see your point, but this seems to address= a=20 very specific deployment scenario (service providers sharing WLAN equipment= ). If=20 nothing else in the CAPWAP messages is dependent on this, then this should = be a=20 recommendation instead of a mandate. That way the protocol remains inclusiv= e,=20 and also meets its objective.

I think it is very important that exis= ting=20 implementations are not excluded just because they dont seem to meet one=20 specific need in a specific deployment=20 scenario.

Thanks,
Puneet


On 4/15/06, = Saravanan=20 Govindan <saravanang@hotma= il.com>=20 wrote:
Hi=20 Puneet,

My concern regarding the BSSID - WLAN mapping is based on = the=20 mandatory
Objective "Logical Groups" (Section 5.1.1 of CAPWA= P=20 Objectives).

The Objective requires that WTP traffic be kept logic= ally=20 distinct among
logical groups. This arises from the commercial need o= f=20 service providers
sharing WLAN infrastructure equipment. Service provi= ders=20 want their traffic
to be distinguished both over the wireless environm= ent=20 (e.g. BSSIDS) and
over the AC-WTP environment (e.g. WLANs).

Th= e=20 BSSID-WLAN mapping issue is the technical requirement coming from=20 this
commercial need. It allows an AC - or WTP - to decide how logical= =20 groups are
separated over the wireless and AC-WTP segments. So by maki= ng=20 this mapping,
CAPWAP frames of different logical groups (WLANs) can b= e=20 distinctly
exchanged.

I agree with others that this mapping sho= uld=20 not exclude any implementation
- my concern is that the mapping be=20 including in the first place.=20

Cheers,

Saravanan




>  -----= -------------------------
>=20 *From:* Puneet [mailto:pb.ietf@gmail= .com]
> *Sent:* Friday,=20 April 14, 2006 12:29 AM
> *To:* capwap@frascone.com
> *Subject:*=20 [Capwap] BSSID-WLAN mappings
>
> the BSSID description in Sec= tion=20 11.9.1 'WTP Radio Configuration' notes
> that a WTP that supports 1= 6=20 WLANS MUST have 16 MAC addresses reserved for
> it. Why? ie. what = part=20 of the protocol does not work if we have multiple
> SSIDs on a sing= le=20 BSSID? (whether thats good design or bad is a different
> matter). = Since=20 the WLAN ID could be used in all such places to convey
WLAN
>= =20 information back to the AC, why do we need to mandate this 1:1=20 BSSID-WLAN
> mapping?
>
> Thanks,
>=20 Puneet
>
>=20 _________________________________________________________________
>= ; To=20 unsubscribe or modify your subscription options, please visit:
> http://lists.fr= ascone.com/mailman/listinfo/capwap
>
>=20 Archives: http:/= /lists.frascone.com/pipermail/capwap
>

___________________= ______________________________________________
Get=20 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.co= m/pipermail/capwap


------=_Part_6702_21984943.1145295539429-- --===============1779684703== 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 --===============1779684703==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Apr 17 21:00:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVeaB-0001dZ-1g for capwap-archive@lists.ietf.org; Mon, 17 Apr 2006 21:00:43 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVea9-0001V0-6c for capwap-archive@lists.ietf.org; Mon, 17 Apr 2006 21:00:43 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3DD184300C0 for ; Mon, 17 Apr 2006 18:00:40 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E5A27430073 for ; Mon, 17 Apr 2006 17:59:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D000D144801E for ; Mon, 17 Apr 2006 17:59:58 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 975911448017 for ; Mon, 17 Apr 2006 17:59:55 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060308/3.7W/kings) with ESMTP id k3I0xqa8022175; Tue, 18 Apr 2006 09:59:52 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k3I0xiE09634; Tue, 18 Apr 2006 09:59:44 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with SMTP id k3I0xiC20719; Tue, 18 Apr 2006 09:59:44 +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] BSSID-WLAN mappings Date: Tue, 18 Apr 2006 08:58:09 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDCDC4A1@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] BSSID-WLAN mappings Thread-Index: AcZhr/vTlRgBv+fRRlq2QpqwAPwdFQA0uoJg From: "Saravanan Govindan" To: "Puneet" X-Virus-Scanned: by amavisd-new-20030616-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@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="===============0933486871==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7cb76adb986247703cbb5582da68b5fc This is a multi-part message in MIME format. --===============0933486871== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66283.28FB2D25" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66283.28FB2D25 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Puneet, =20 I agree that the CAPWAP should not exclude any particular implementation. However, the fact remains that the shared deployment scenario is a mandatory requirement for the protocol.=20 =20 There was a note from one of the IESG reviewers about giving due importance to service provider concerns in the CAPWAP Objectives; we had to change the sequence in which service provider requirements were presented in that document so as not to imply lesser value!=20 =20 So I think it is important that the CAPWAP specifications be consistent with the requirements that were reviewed.=20 Cheers, Saravanan =20 =20 =20 =20 ________________________________ From: Puneet [mailto:pb.ietf@gmail.com]=20 Sent: Monday, April 17, 2006 7:47 AM To: Saravanan Govindan Cc: capwap@frascone.com Subject: Re: [Capwap] BSSID-WLAN mappings =20 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,=20 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.=20 Cheers, Saravanan > ------------------------------ > *From:* Puneet [mailto:pb.ietf@gmail.com] > *Sent:* Friday, April 14, 2006 12:29 AM=20 > *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=20 > 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=20 WLAN > information back to the AC, why do we need to mandate this 1:1 BSSID-WLAN > mapping? > > Thanks, > Puneet > > _________________________________________________________________=20 > 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.=20 http://messenger.msn.com.sg/Beta/Default.aspx =20 ------_=_NextPart_001_01C66283.28FB2D25 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Puneet,

 

I agree that the CAPWAP should not exclude any = particular implementation. However, the fact remains that the shared deployment = scenario is a mandatory requirement for the protocol. =

 

There was a note from one of the IESG reviewers about = giving due importance to service provider concerns in the CAPWAP Objectives; we = had to change the sequence in which service provider requirements were = presented in that document so as not to imply lesser value! =

 

So I think it is important that the CAPWAP = specifications be consistent with the requirements that were reviewed. =


Cheers,


Saravanan

 

 

 

 

From: = Puneet [mailto:pb.ietf@gmail.com]
Sent: Monday, April 17, = 2006 7:47 AM
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 <saravanang@hotmail.com> = 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.f= rascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone= .com/pipermail/capwap
>

_________________________________________________________________
Get an advanced look at the new version of MSN Messenger.
http://messenger.m= sn.com.sg/Beta/Default.aspx

 

------_=_NextPart_001_01C66283.28FB2D25-- --===============0933486871== 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 --===============0933486871==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Apr 18 00:58:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FViIc-0002v7-Dr for capwap-archive@lists.ietf.org; Tue, 18 Apr 2006 00:58:50 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FViIY-0003rv-Dq for capwap-archive@lists.ietf.org; Tue, 18 Apr 2006 00:58:50 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7BFB14300CE for ; Mon, 17 Apr 2006 21:58:45 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 5BDDE43005A for ; Mon, 17 Apr 2006 21:58:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3B0E2144800D for ; Mon, 17 Apr 2006 21:58:17 -0700 (PDT) Received: from webmail.rp.edu.sg (webmail.rp.sg [202.21.158.83]) by hermes.tigertech.net (Postfix) with ESMTP id 5CE061448002 for ; Mon, 17 Apr 2006 21:58:13 -0700 (PDT) Received: from staff-mail.rp.edu.sg ([202.21.158.80]) by webmail.rp.edu.sg with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 12:58:10 +0800 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 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: Tue, 18 Apr 2006 12:58:08 +0800 Message-ID: <9C374CF75527504394E573E1937136C402D3AB3E@staff-mail.rp.edu.sg> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages thread-index: AcZhf0amBqHQsGVBQVy9cRrEVoW8wQBJPS1A From: "Richard Gwee" To: "Scott G Kelly" X-OriginalArrivalTime: 18 Apr 2006 04:58:10.0187 (UTC) FILETIME=[B07E65B0:01C662A4] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: capwap@frascone.com 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: 612a16ba5c5f570bfc42b3ac5606ac53 Hi, Just like to add in a note.=20 In most implementation, the AC does process Echo requests in the sense that it needs to keep track of which WTP sent it and how often. Thus the AC is already processing echo requests instead of just acknowledging back. In reality, scalability should not be an issue. Regards Richard -----Original Message----- From: Scott G Kelly [mailto:scott@hyperthought.com]=20 Sent: Monday, April 17, 2006 1:58 AM To: Richard Gwee Cc: Saravanan Govindan; capwap@frascone.com Subject: Re: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Hi Richard, This is a very difficult conversation to have in email, due to its=20 complexity. I'll try to be succinct. I'm trimming much of the=20 surrounding context below, as the mixed reply styles (some with '>'=20 preceding reply lines, some not) is becoming really confusing. Comments=20 inlined below. Richard Gwee wrote: >=20 > I saw Richard's presentation (and I just reviewed it again in the > proceedings), but it doesn't actually do the math I asked for. Instead,=20 > it presents a graph that shows two diverging lines, and makes no attempt >=20 > to explain what is being measured, or why it is reasonable to expect=20 > that these values should diverge over time when plotted linearly. >=20 > =20 > Hi Scott, I am not sure what maths are you really asking for. Is it > queueing analysis you are referring to? I am not really clear about your > maths requirement. Appreciate if you can enlighten me on this aspect. See response below regarding scenarios... > The second scenario denotes a case in which I have combined both > statistics and echo messages being exchanged between AC and WTP. Over a > long period of time, it is reasonable that these values should diverge > due to the reduction in overhead when the two messages are combined. > To put this simply, the graph only shows bytes received. There are other interesting quantities relating to overhead - for example, the=20 additional processing requirements this imposes under various=20 conditions. You have to think about scaling on the AC side. That would=20 be very difficult to account for in a simulation, and depends on the=20 implementation. > An important point: this plot is the result of a simulation. What are=20 > the assumptions upon which that simulation is based? >=20 > > The simulation is based on a basic scenario in which I have a model of > AC connected to a model of WTP and assume no mobile terminals. I mainly > focus on the basic interaction between an AC and a WTP. > First, is this really a valid model, with no STA's connected? Adding=20 STAs will increase congestion on the LAN side, and perhaps even=20 contribute to dropped echo frames. > I think it probably looks at packet header savings when you eliminate=20 > the separate transport headers (which, incidentally, assumes you want to >=20 > send these statistics at the same interval you want to send echoes), but >=20 > that doesn't account for the divergence. Maybe Richard can enlighten us=20 > a bit here. >=20 > > I am a bit confused over your reasoning that the packet header savings > doesn't account for the divergence. My thinking (as well as my results > have shown) has been that if I have managed to reduce some overhead due > to packet header savings, I will definitely see a divergence. >=20 > Appreciate if you can share with me more specifically your reasoning > behind this. I am interested to know. Thanks. > Your assumptions aren't clear from the graph. Here's a simple summary of a few ways to look at this: Scenario 1: echoes and stats are sent at the same intervals. The redundancy here is=20 in L2, L3, L4, and capwap transport headers. In this case, combining the messages should produce a precisely linear result across time (e.g. 52=20 bytes saved per combined message). No divergence. Scenario 2: echoes are sent more frequently than stats. Combining these may be worse if your echo interval is much shorter than your stats interval, because=20 now you're sending way more stats than you would have been otherwise,=20 for a net loss in efficiency (convergence with crossover, followed by=20 negative divergence). Scenario 3: stats are sent more frequently than echos. Combining these may better in some scenarios (looking only at bits on the wire), but this seems like=20 an unrealistic approach. Assuming you really would want to do this,=20 you'd get divergence with crossover. What assumptions did you make in your simulation? It is not clear from=20 the graph. The only thing I think is clear is that it could not have=20 been scenario 1, because this would clearly yield a linear result (i.e.=20 parallel lines with no divergence). > It also seems to assume a perfect processing world - that is, it ignores > the increased processing overhead and complexity at either end when you=20 > combine these. And based on Richard's accompanying comments, it also=20 > seems to assume a very small statistics payload. As an aside, I think=20 > real-world network trace data would be far more enlightening. >=20 > > I do agree that we have to consider many factors such as processing > overhead and complexity. Unfortunately, my resources are limited. But to > be fair, there are few simulations that can really model a real > scenario.=20 ...which is why we shouldn't base our decision on simulation results alone. > If you feel my simulation is insufficient, I will appreciate > if you can propose some scenarios for me to simulate and study or can > point me to some resources where I can gather more enlightening data. > Thanks. > =20 Well, this may seem a bit tongue-in-cheek, but perhaps you could try=20 running and measuring real traffic? Short of that, it would be nice to=20 see results for all three scenarios described above. ------------------ I've trimmed the rest, because I think we're going rather far afield=20 here. Dorothy Stanley suggested that we should set aside the question of combining these questions and first discuss what stats we are interested in. You have suggested a few, as has Saravan. I am in the process of=20 polling folks I work with to see if anything is missing. I would suggest that all interested vendors do this, and that we try to close on that=20 question within a day or two (say, Tuesday?) I think a critical question we have to answer is, which of the 3=20 scenarios I described above is the average case for capwap, i.e. stats=20 with every echo, more echoes than stats, or more stats than echoes? Personally, I think more echoes than stats is the most likely, but I'd=20 like to hear other points of view. Only when we know the answer to that=20 question can we reasonably discuss the implications of any particular=20 optimization strategy. Scott Republic Polytechnic, 9 Woodlands Avenue 9, Singapore 738964 (Near = Woodlands MRT/Interchange) . www.rp.sg . Fax: +65 6415-1310 .=20 Republic Polytechnic, the first Institute of Higher Learning to fully = adopt the Problem-Based Learning approach in Singapore, continues to = strive towards best practices and maintain excellence in service = standards with the following certifications: Singapore Innovation Class = (SIC), Singapore Quality Class (SQC), People Developer Standards and = QEHS (ISO 9001, 14001 and OHSAS 18001) -------------------------------------------------------------------------= ------- CONFIDENTIALITY CAUTION: This message is intended only for the use of = the individual or entity to whom it is addressed and contains = information that is privileged and confidential. If you, the reader of = this message, are not the intended recipient, you should not = disseminate, distribute or copy this communication. If you have received = this communication in error, please notify us immediately by return = email and delete the original message. Thank you. =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 Apr 18 08:43:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVpYP-0005hs-O4 for capwap-archive@lists.ietf.org; Tue, 18 Apr 2006 08:43:37 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVpYO-0004YQ-8l for capwap-archive@lists.ietf.org; Tue, 18 Apr 2006 08:43:37 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 79E7F4300F2 for ; Tue, 18 Apr 2006 05:43:35 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8369A430063 for ; Tue, 18 Apr 2006 05:43:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 52F29144800F for ; Tue, 18 Apr 2006 05:43:00 -0700 (PDT) Received: from huawei-3com.com (pop.huawei-3com.com [219.133.0.18]) by hermes.tigertech.net (Postfix) with ESMTP id 745C9144800D for ; Tue, 18 Apr 2006 05:42:56 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXX009PX4XK16@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Tue, 18 Apr 2006 20:48:56 +0800 (CST) Received: from RichardYoung ([10.18.7.90]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IXX00H4V4XJUF@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Tue, 18 Apr 2006 20:48:56 +0800 (CST) Date: Tue, 18 Apr 2006 18:12:46 +0530 From: young To: pcalhoun@cisco.com Message-id: <000001c662e5$99235420$5a07120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE X-Spam-Level: Cc: capwap@frascone.com Subject: [Capwap] About Admin state & Change State Event 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="===============1990412998==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. --===============1990412998== Content-type: multipart/alternative; boundary="Boundary_(ID_1xBnUk6zmY44R6lHsmqE8A)" This is a multi-part message in MIME format. --Boundary_(ID_1xBnUk6zmY44R6lHsmqE8A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all: I suggest that " 7.3.2. Change State Event" in the configure response message should be replaced by "administrator state" TLV. The "change state event" is to carry operation status of radios, and it should always be sent from AP to AC. If place the "Change State Event" in the configure response, it thought it will be difficult to understand. As the similar idea, I thought it is not good way to place "Change State Event" in the "Configuration Update Request", removing it is better. Regards Richard --Boundary_(ID_1xBnUk6zmY44R6lHsmqE8A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi all:

I suggest that “ 7.3.2.  Change State Event” in the configure response message should be replaced by “administrator state” TLV.

The “change state event” is to carry operation status of radios, and it should always be sent from AP to AC.

If place the “Change State Event” in the configure response, it thought it will be difficult to understand.

As the similar idea, I thought it is not good way to place “Change State Event” in the “Configuration Update Request”, removing it is better.

 

Regards

 

Richard

--Boundary_(ID_1xBnUk6zmY44R6lHsmqE8A)-- --===============1990412998== 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 --===============1990412998==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Apr 18 13:51:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVuLy-0007zg-19 for capwap-archive@lists.ietf.org; Tue, 18 Apr 2006 13:51:06 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVuLw-0005Gh-J8 for capwap-archive@lists.ietf.org; Tue, 18 Apr 2006 13:51:06 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id AA3364300B7 for ; Tue, 18 Apr 2006 10:51:03 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 44503430082 for ; Tue, 18 Apr 2006 10:50:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2D62F398039 for ; Tue, 18 Apr 2006 10:50:44 -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 F2347398008 for ; Tue, 18 Apr 2006 10:50:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=VcyjjsEew+fRCcxdNcxYb4aDijXy+3bFD4moFBAzHLIxYkRdAVrbk2ZSaBddlm37; h=Received: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.32] (helo=elwamui-cypress.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FVuLP-0000F2-42 for capwap@frascone.com; Tue, 18 Apr 2006 13:50:31 -0400 Message-ID: <18344553.1145382631137.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Date: Tue, 18 Apr 2006 10:50:31 -0700 (GMT-07:00) From: "Scott G. Kelly" To: capwap Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages 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: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710a3c569017856516fea8957cc5c3752d8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.32 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: 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: 68c8cc8a64a9d0402e43b8eee9fc4199 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Apr 18 21:38:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW1eh-0005VU-2D for capwap-archive@lists.ietf.org; Tue, 18 Apr 2006 21:38:55 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FW1ef-000418-E8 for capwap-archive@lists.ietf.org; Tue, 18 Apr 2006 21:38:55 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 88D9F4300CB for ; Tue, 18 Apr 2006 18:38:52 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 82F7E43006B for ; Tue, 18 Apr 2006 18:38:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 672C01448002 for ; Tue, 18 Apr 2006 18:38:20 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.206]) by hermes.tigertech.net (Postfix) with ESMTP id 420C31448008 for ; Tue, 18 Apr 2006 18:38:17 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so602009wxd for ; Tue, 18 Apr 2006 18:38:17 -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=iYsfwojzKEU+kC9FhTcH2bI3HRmhbc1xt+cUe2YUBkxm7ohYvqw0dmjFcA5imT6+YBo5RIhKWCV4YRf5HYl6eMptAXDGOY1+rW9jnbG46BKjonU0ZhO3FCEsR010sIOxnwmPZsYeLjauRvHYR6yaqOoexaho+pJwvF9pebWAmH4= Received: by 10.70.7.14 with SMTP id 14mr1039870wxg; Tue, 18 Apr 2006 18:38:17 -0700 (PDT) Received: by 10.70.133.14 with HTTP; Tue, 18 Apr 2006 18:38:16 -0700 (PDT) Message-ID: <5bfe7a820604181838h5f2db440ua71fe8bfddb06d19@mail.gmail.com> Date: Tue, 18 Apr 2006 18:38:16 -0700 From: "Dorothy Stanley" To: Puneet Subject: Re: [Capwap] New Issue - 11.9.1 WTP WLAN Radio Configuration Changes In-Reply-To: <1013407b0604141702j7cb17da1w9d1d9a046a78476b@mail.gmail.com> MIME-Version: 1.0 References: <5bfe7a820604111326w589a36a5ua844aaa1b64b85a4@mail.gmail.com> <1013407b0604141702j7cb17da1w9d1d9a046a78476b@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_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="===============0505746745==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 --===============0505746745== Content-Type: multipart/alternative; boundary="----=_Part_7220_30595966.1145410696988" ------=_Part_7220_30595966.1145410696988 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Puneet, It is more accurate to say that while the FCC does allow the country code t= o be changed from the access controller, if the country code is changed by the AC, then the device fall= s into the category of software defined radios, and must meet SDR rules. See section 51 in the following document: http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-05-57A1.pdf Support of CAPWAP should not result in the WTPs being classified as SDRs. My understanding is that If the WTP tells the AC what country it is in, and the AC configures appropriate channels and power levels, that is ok. But if the AC tells the WTP what country it is in, and the WTP configures/uses this info, then the WTP radio is an SDR. The configuration of the country on the WTP should be outside the scope of CAPWAP. Thanks, Dorothy On 4/14/06, Puneet wrote: > > > 2. Delete country code. The FCC does not allow the country code to be > changed from a controller. > > Is there a specific FCC document that references this? Also, if the AC > handles all channel and power level assignments (ie. makes sure those are= in > compliance in the current regulatory domain), can the country-code be sen= t > to the WTP for advertisement in beacons/probes? > > thanks, > Puneet > > On 4/11/06, Dorothy Stanley < dstanley1389@gmail.com> wrote: > > > All, > > Section 11.9.1 describes a WTP WLAN Radio configuration message element, > used by the AC to configure a > radio on the WTP. > > Suggested changes: > > 1. Change the name of the message element to "WTP WLAN Configuration" > message element, since it is the > WLAN on the radio that is being configured. > > 2. Delete country code. The FCC does not allow the country code to be > changed from a controller. > > 3. PCF is often not supported, and is not used widely - used in the > downlink more than in the uplink, not > reliably supported on clients. Delete CFP Maximum duration, CFP Period > and Occupancy Limit. > > Comments? > > Thanks, > > > Dorothy > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > > > ------=_Part_7220_30595966.1145410696988 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Puneet,
 
It is more accurate to say that while the FCC does allow the coun= try code to be changed from the access
controller,  if the country code is changed by the AC, then the d= evice falls into the category of
software defined radios, and must meet SDR rules. See section 51 in th= e following document:
 
Support of CAPWAP should not result in the WTPs being classified as SD= Rs.
My understanding is that If the WTP tells the AC what country it = is in, and the
AC configures appropriate channels and power levels, that is ok. But i= f the AC tells the
WTP what country it is in, and the WTP configures/uses this info, then= the WTP radio is an SDR. The configuration of the
country on the WTP should be outside the scope of CAPWAP.
 
Thanks,
 
Dorothy

 
On 4/14/06, = Puneet <pb.ietf@gmail.com&g= t; wrote:
> 2. Delete country code= . The FCC does not allow the country code to be changed from a controller.<= br>
Is there a specific FCC document that referen= ces this? Also, if the AC handles all channel and power level assignments (= ie. makes sure those are in compliance in the current regulatory domain), c= an the country-code be sent to the WTP for advertisement in beacons/probes?

thanks,
Puneet

On 4/11/06, Doro= thy Stanley < dstanley1389@gmail.com> wrote:
All,

Section 11.9.1 describes a WTP WL= AN Radio configuration message element, used by the AC to configure a
ra= dio on the WTP.

Suggested changes:

1. Change the name of the = message element to "WTP WLAN Configuration" message element, sinc= e it is the
WLAN on the radio that is being configured.

2. Delete country c= ode. The FCC does not allow the country code to be changed from a controlle= r.

3. PCF is often not supported, and is not used widely - used in t= he downlink more than in the uplink, not
reliably supported on clients.  Delete CFP Maximum duration, CFP P= eriod and Occupancy Limit.

Comments?

Thanks,
 

Dorothy

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

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


 

------=_Part_7220_30595966.1145410696988-- --===============0505746745== 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 --===============0505746745==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Apr 18 21:46:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW1lw-0007AR-Ot for capwap-archive@lists.ietf.org; Tue, 18 Apr 2006 21:46:24 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FW1lv-0004Tm-93 for capwap-archive@lists.ietf.org; Tue, 18 Apr 2006 21:46:24 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E32904300CB for ; Tue, 18 Apr 2006 18:46:22 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9D8DF43006B for ; Tue, 18 Apr 2006 18:45:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8D5841448011 for ; Tue, 18 Apr 2006 18:45:50 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.206]) by hermes.tigertech.net (Postfix) with ESMTP id AD0C91448002 for ; Tue, 18 Apr 2006 18:45:49 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so602945wxd for ; Tue, 18 Apr 2006 18:45:49 -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=O9fk/JfPzRp3PvvNv3tyTJOBqmBma7Xmb5o3wUHkM8EeHOyNwvBMQyeBGT9f6DJXdLJmEtRFFct9odl1BmXJT75mVAXoGMoaYOYiAWvs0/zPdta6ItJxyzyREtEIOAMI4FJ3UkIzJqqevFvxhz8sIdNhOPUi2CfozhnHHbellj4= Received: by 10.70.9.19 with SMTP id 19mr3227183wxi; Tue, 18 Apr 2006 18:45:49 -0700 (PDT) Received: by 10.70.133.14 with HTTP; Tue, 18 Apr 2006 18:45:49 -0700 (PDT) Message-ID: <5bfe7a820604181845g2c4599a8p312de3e84f9c910b@mail.gmail.com> Date: Tue, 18 Apr 2006 18:45:49 -0700 From: "Dorothy Stanley" To: young Subject: Re: [Capwap] About Admin state & Change State Event In-Reply-To: <000001c662e5$99235420$5a07120a@china.huawei.com> MIME-Version: 1.0 References: <000001c662e5$99235420$5a07120a@china.huawei.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_MESSAGE, 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="===============0696830691==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 --===============0696830691== Content-Type: multipart/alternative; boundary="----=_Part_7284_19460451.1145411149009" ------=_Part_7284_19460451.1145411149009 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, Issue 103 has been opened to track this item. Comments, discussion please. Thanks, Dorothy Stanley On 4/18/06, young wrote: > > Hi all: > > I suggest that " 7.3.2. Change State Event" in the configure response > message should be replaced by "administrator state" TLV. > > The "change state event" is to carry operation status of radios, and it > should always be sent from AP to AC. > > If place the "Change State Event" in the configure response, it thought i= t > will be difficult to understand. > > As the similar idea, I thought it is not good way to place "Change State > Event" in the "*Configuration Update Request*", removing it is better. > > > > Regards > > > > Richard > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_7284_19460451.1145411149009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
All,
 
Issue 103 has been opened to track this item.
 
Comments, discussion please.
 
Thanks,
 
Dorothy Stanley

 
On 4/18/06, = young <young@huawei-3com.co= m> wrote:

Hi all:

I suggest that= " 7.3.2.  Change State Event" in the config= ure response message should be replaced by "administrator state" TLV.

The "change st= ate event" is to carry operation status of radios, and it should always be = sent from AP to AC.=20

If place the "= Change State Event" in the configure response, it thought it will be diffic= ult to understand.

As the similar= idea, I thought it is not good way to place "Change State Event" in the "<= /span> Configura= tion Update Request ", removing it= is better.

 

Regards=

 <= /font>

Richard=


________________________________________________= _________________
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_7284_19460451.1145411149009-- --===============0696830691== 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 --===============0696830691==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Apr 18 22:11:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW2AA-0003me-3Q for capwap-archive@lists.ietf.org; Tue, 18 Apr 2006 22:11:26 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FW2A8-0005wH-G6 for capwap-archive@lists.ietf.org; Tue, 18 Apr 2006 22:11:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D7BC94300AE for ; Tue, 18 Apr 2006 19:11:23 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E8C8143006B for ; Tue, 18 Apr 2006 19:10:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D862D144800B for ; Tue, 18 Apr 2006 19:10:50 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.200]) by hermes.tigertech.net (Postfix) with ESMTP id E8E461448008 for ; Tue, 18 Apr 2006 19:10:49 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so605707wxd for ; Tue, 18 Apr 2006 19:10:49 -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=Fedb8HY/KpUPU12ZeSp+cBzKpE2Mp4xpMyG/Y+F2uyDZUtSlWQa9yZXRCoCqQJhSSNpfK9RPAR3CR6pH1/vhsiGPH7ZvdArFyJ+S/TT46pgA769hT5L8enJlcfXhlyrMAYWCg+mqmomD4b+AxsOkpfcIjpOg+QV/fE2BGqrU9W8= Received: by 10.70.133.2 with SMTP id g2mr1444858wxd; Tue, 18 Apr 2006 19:10:49 -0700 (PDT) Received: by 10.70.133.14 with HTTP; Tue, 18 Apr 2006 19:10:49 -0700 (PDT) Message-ID: <5bfe7a820604181910o3ad8398as3c6f0e83f438391e@mail.gmail.com> Date: Tue, 18 Apr 2006 19:10:49 -0700 From: "Dorothy Stanley" To: Puneet Subject: Re: [Capwap] Section 11.8.1.1 'IEEE 802.11 Add WLAN' In-Reply-To: <1013407b0604140028h6e64226agcc25f34ab8e6bc41@mail.gmail.com> MIME-Version: 1.0 References: <1013407b0604140028h6e64226agcc25f34ab8e6bc41@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.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@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="===============0626279664==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.7 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f --===============0626279664== Content-Type: multipart/alternative; boundary="----=_Part_7532_21935558.1145412649101" ------=_Part_7532_21935558.1145412649101 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Puneet, For the moment, I've included these questions in issue 101, since all are related to 11.8.1.1, but can open a new issue if needed. Comments inline Dorothy On 4/14/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 enable= d > at the same type on the WLAN, in that case how is the encryption-policy > field filled in? > It's likely broadcast only. A single key is included - the GTK? But since the WPAIE and RSNIE are included, it's not clear the encryption policy is needed, since the valid ciphersuites to advertize in the beacons - unicast and broadcast are included in the IEs. 2. for the encryption policies we could use the format used in the RSN IEs > (OUI + encryption_type); that allows support for different vendor specifi= c > 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). > Agreed, see Issue 101 3. why are the lengths of the IEs (WPA, RSN etc) fixed at 32 bytes? If eac= h > of those IEs is preceded by an element that specifies their lengths, then > the IEs could be made variable length. > Also see issue 101. New IEs should not be defined here, but the existing 802.11 IE definitions re-used 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.11Bro= adcast 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. > Agree, need to retain flexibility for the AC to customize the probe responses generated. 5. maybe rename WME to WMM? > Agreed 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_7532_21935558.1145412649101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Puneet,
 
For the moment, I've included these questions in issue 101, since= all are
related to 11.8.1.1, but can open a ne= w issue
if needed. Comments inline
 
Dorothy

 
On 4/14/06, = Puneet <pb.ietf@gmail.com&g= t; wrote:
1. does the encryption policy refer to broadc= ast traffic or unicast too? If its also unicast, then there could be multip= le encryption types enabled at the same type on the WLAN, in that case how = is the encryption-policy field filled in?
 
It's likely broadcast only. A single key is included - the GTK?
But since the WPAIE and RSNIE are included, it's not clear the encrypt= ion policy is needed, since the
valid ciphersuites to advertize in the beacons - unicast and broadcast= are included in the IEs.

2. for the encryption policies we could use t= he 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 wit= h the other 'standard' encryption types; and it makes it easier for vendors= to not step on each others toes).
 
Agreed, see Issue 101

3. why are the lengths of the IEs (WPA, RSN e= tc) 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.
 
Also see issue 101. New IEs should not be defined here, but the e= xisting 802.11 IE definitions re-used

4. Does the 'Suppress SSID' field also disabl= e 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 i= s 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 br= oadcast probe request comes in.
 
Agree, need to retain flexibility for the AC to customize the probe re= sponses generated.

5. maybe rename WME to WMM?
 
Agreed

Thanks,
 
Puneet
_________________________________________________________________
To un= subscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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


------=_Part_7532_21935558.1145412649101-- --===============0626279664== 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 --===============0626279664==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Apr 18 22:14:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW2Cu-0003tW-C6 for capwap-archive@lists.ietf.org; Tue, 18 Apr 2006 22:14:16 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FW2Ct-00063n-TM for capwap-archive@lists.ietf.org; Tue, 18 Apr 2006 22:14:16 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8FC444300B6 for ; Tue, 18 Apr 2006 19:14:15 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 29FB443006B for ; Tue, 18 Apr 2006 19:13:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0B5141448008 for ; Tue, 18 Apr 2006 19:13:46 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.202]) by hermes.tigertech.net (Postfix) with ESMTP id DE58C1448011 for ; Tue, 18 Apr 2006 19:13:43 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so606065wxd for ; Tue, 18 Apr 2006 19:13:43 -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=P4qlNZq1mK+3YZ9amoIM8WFKEKKWlBuTw5VKSMoYxpZ9O5YT6CcBAIkmTHIEJWNn5yH8snH2t+xmaZMtzsNHLLaho0+gMomAOlyq14rodjfBxKZqqpcrtndWw8k6x7NUs1Kvr2IjiGYB7AgnLSJBHALmJ9VstEktV0Y79KYAyu4= Received: by 10.70.14.2 with SMTP id 2mr6953091wxn; Tue, 18 Apr 2006 19:13:43 -0700 (PDT) Received: by 10.70.133.14 with HTTP; Tue, 18 Apr 2006 19:13:43 -0700 (PDT) Message-ID: <5bfe7a820604181913m429d1cadk94ef52cf083ae055@mail.gmail.com> Date: Tue, 18 Apr 2006 19:13:43 -0700 From: "Dorothy Stanley" To: Puneet Subject: Re: [Capwap] 802.11d / 802.11h support In-Reply-To: <1013407b0604140028s19895135p9e5ecb101864c9c5@mail.gmail.com> MIME-Version: 1.0 References: <1013407b0604140028s19895135p9e5ecb101864c9c5@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@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="===============1015469346==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 --===============1015469346== Content-Type: multipart/alternative; boundary="----=_Part_7576_28136877.1145412823257" ------=_Part_7576_28136877.1145412823257 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Puneet, This is assigned to a new issue, 104. All- comments, discussion please. Thanks, Dorothy Stanley On 4/14/06, Puneet wrote: > > 1. Section 11.9.3 'IEEE 802.11 Multi-domain Capability': The length of > this element is fixed at 8 bytes, but if there are multiple, disjoint ban= ds > that are supported in the regulatory domain does the AC use multiple such > elements? It might be cleaner to make the length of this element variable= , > and allow multiple triplets added one after the other. (like the Country-Information element in > 802.11d) > > 2. How does CAPWAP plan to support 802.11h? Does the WTP handle everythin= g > on its own or is the channel switching etc controlled by the AC? In eithe= r > case there might be a need for message elements with which the WTP to rep= ort > the detection of radar to the AC. > > 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_7576_28136877.1145412823257 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Puneet,
 
This is assigned to a new issue, 104.
 
All- comments, discussion please.
 
Thanks,
 
Dorothy Stanley

 
On 4/14/06, = Puneet <pb.ietf@gmail.com&g= t; wrote:
1. Section 11.9.3 'IEEE 802.11 Multi-do= main Capability': The length of this element is fixed at 8 bytes, but if th= ere are multiple, disjoint bands that are supported in the regulatory domai= n does the AC use multiple such elements? It might be cleaner to make the l= ength of this element variable, and allow multiple triplets <first_chann= el,num_channel,max_power) to be added one after the other. (like the Countr= y-Information element in=20 802.11d)

2. How does CAPWAP plan to support 802.11h? Does the WTP ha= ndle everything on its own or is the channel switching etc controlled by th= e AC? In either case there might be a need for message elements with which = the WTP to report the detection of radar to the AC.

Thanks,
Puneet.

____________________________= _____________________________________
To unsubscribe or modify your subs= cription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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


------=_Part_7576_28136877.1145412823257-- --===============1015469346== 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 --===============1015469346==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Apr 18 23:26:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW3KS-0004WH-FZ for capwap-archive@lists.ietf.org; Tue, 18 Apr 2006 23:26:08 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FW3KQ-0000Yv-1z for capwap-archive@lists.ietf.org; Tue, 18 Apr 2006 23:26:08 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E2F904300D1 for ; Tue, 18 Apr 2006 20:26:04 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 5CF4F43006B for ; Tue, 18 Apr 2006 20:25:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 511BA398011 for ; Tue, 18 Apr 2006 20:25:45 -0700 (PDT) Received: from aruba-mx.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by zoidberg.tigertech.net (Postfix) with SMTP id 83716398008 for ; Tue, 18 Apr 2006 20:25:43 -0700 (PDT) Received: from [172.18.8.114] ([172.18.8.114] RDNS failed) by aruba-mx.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 20:25:42 -0700 Date: Tue, 18 Apr 2006 20:25:39 -0700 (PDT) From: Partha Narasimhan X-X-Sender: partha@localhost.localdomain To: Dorothy Stanley Subject: Re: [Capwap] 802.11d / 802.11h support In-Reply-To: <5bfe7a820604181913m429d1cadk94ef52cf083ae055@mail.gmail.com> Message-ID: References: <1013407b0604140028s19895135p9e5ecb101864c9c5@mail.gmail.com> <5bfe7a820604181913m429d1cadk94ef52cf083ae055@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 19 Apr 2006 03:25:42.0826 (UTC) FILETIME=[F06C08A0:01C66360] 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: 4d87d2aa806f79fed918a62e834505ca For #1, why dont we use the IEs as defined by IEEE 802.11? Why do we need to re-define something that is already defined in 802.11? This is probably true for the 11d, RSN, WPA, WMM, 11e IEs, and anything else that has a corresponding 802.11 definition. There is code that exists to parse 802.11 IEs elsewhere in the WTP, so we get code reuse too. :-) For #2, my vote would be for the WTP to switch channels on detecting radar and notify the AC of the radar detect and the resulting channel change events. This keeps it simple and WTPs have the ability to detect radar already. Thanks partha On Tue, 18 Apr 2006, Dorothy Stanley wrote: > Hi Puneet, > > This is assigned to a new issue, 104. > > All- comments, discussion please. > > Thanks, > > Dorothy Stanley > > > On 4/14/06, Puneet wrote: > > 1. Section 11.9.3 'IEEE 802.11 Multi-domain Capability': The length of this element is fixed at 8 bytes, but if there are multiple, disjoint bands that are supported in the regulatory domain does the AC use multiple such elements? It might be cleaner to make the length of this element variable, and allow multiple triplets > 2. How does CAPWAP plan to support 802.11h? Does the WTP handle everything on its own or is the channel switching etc controlled by the AC? In either case there might be a need for message elements with which the WTP to report the detection of radar to the AC. > > 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 > > > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Apr 19 01:58:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW5gd-0005Zz-Kc for capwap-archive@lists.ietf.org; Wed, 19 Apr 2006 01:57:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FW5Tg-0005Fn-KB for capwap-archive@lists.ietf.org; Wed, 19 Apr 2006 01:43:52 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1CAA14300D8 for ; Tue, 18 Apr 2006 22:43:44 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E9BA843006C for ; Tue, 18 Apr 2006 22:43:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D46C01448008 for ; Tue, 18 Apr 2006 22:43:16 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 454521448004 for ; Tue, 18 Apr 2006 22:43:14 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k3J5hCIA022434; Tue, 18 Apr 2006 22:43:12 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k3J5hC90022431; Tue, 18 Apr 2006 22:43:12 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 18 Apr 2006 22:43:12 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Partha Narasimhan Subject: Re: [Capwap] 802.11d / 802.11h support In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new-20030616-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: 41c17b4b16d1eedaa8395c26e9a251c4 HI, For #2, I believe that a WTP should only report the detection or radar, and let the AC switch channels (and make any other configuration changes). Otherwise, you may end up with a nonstable RF environment. Regards, /david t. perkins On Tue, 18 Apr 2006, Partha Narasimhan wrote: > For #1, why dont we use the IEs as defined by IEEE 802.11? Why do we need > to re-define something that is already defined in 802.11? This is probably > true for the 11d, RSN, WPA, WMM, 11e IEs, and anything else that has a > corresponding 802.11 definition. There is code that exists to parse 802.11 > IEs elsewhere in the WTP, so we get code reuse too. :-) > > For #2, my vote would be for the WTP to switch channels on detecting radar > and notify the AC of the radar detect and the resulting channel change > events. This keeps it simple and WTPs have the ability to detect radar > already. > > Thanks > partha > > On Tue, 18 Apr 2006, Dorothy Stanley wrote: > > > Hi Puneet, > > > > This is assigned to a new issue, 104. > > > > All- comments, discussion please. > > > > Thanks, > > > > Dorothy Stanley > > > > > > On 4/14/06, Puneet wrote: > > > > 1. Section 11.9.3 'IEEE 802.11 Multi-domain Capability': The length of this element is fixed at 8 bytes, but if there are multiple, disjoint bands that are supported in the regulatory domain does the AC use multiple such elements? It might be cleaner to make the length of this element variable, and allow multiple triplets > > > 2. How does CAPWAP plan to support 802.11h? Does the WTP handle everything on its own or is the channel switching etc controlled by the AC? In either case there might be a need for message elements with which the WTP to report the detection of radar to the AC. > > > > 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 > > > > > > > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/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 Apr 20 01:08:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWROu-0004AC-08 for capwap-archive@lists.ietf.org; Thu, 20 Apr 2006 01:08:20 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWROq-00075q-Eu for capwap-archive@lists.ietf.org; Thu, 20 Apr 2006 01:08:19 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6FAD44300AA for ; Wed, 19 Apr 2006 22:08:11 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 21C7D430064 for ; Wed, 19 Apr 2006 22:07:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0A409398020 for ; Wed, 19 Apr 2006 22:07:42 -0700 (PDT) Received: from huawei-3com.com (pop.huawei-3com.com [219.133.0.18]) by zoidberg.tigertech.net (Postfix) with ESMTP id B57CF398012 for ; Wed, 19 Apr 2006 22:07:38 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IY000LOL96X40@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Thu, 20 Apr 2006 13:13:45 +0800 (CST) Received: from RichardYoung ([10.18.7.90]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IY0001HJ96WEU@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Thu, 20 Apr 2006 13:13:45 +0800 (CST) Date: Thu, 20 Apr 2006 10:37:32 +0530 From: young To: pcalhoun@cisco.com Message-id: <000001c66438$55219c10$5a07120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.375 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE X-Spam-Level: Cc: capwap@frascone.com Subject: [Capwap] some suggestion for 802.11 binding TLV 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="===============1156626738==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc This is a multi-part message in MIME format. --===============1156626738== Content-type: multipart/alternative; boundary="Boundary_(ID_u083KYfdnyuCVC188RhWCQ)" This is a multi-part message in MIME format. --Boundary_(ID_u083KYfdnyuCVC188RhWCQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT 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" 2) Because CAPWAP provide the definition of 802.11 binding, the common configuration for AP came from different vendors should defined by draft. I felt something like "Preamble-length" configuration need to be added into draft. 3) Now, in the draft, IEEE 802.11 Broadcast Probe Mode is configured for AP, while Supress SSID (section 11.8.1) is for specific radio. I suggest both Broadcast Probe Mode and Supress SSID could be configured for a specific radio. Regards Richard --Boundary_(ID_u083KYfdnyuCVC188RhWCQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

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”

 

2) Because CAPWAP provide the definition of 802.11 binding, the common configuration for AP came from different vendors should defined by draft. I felt something like “Preamble-length” configuration need to be added into draft.

 

3) Now, in the draft, IEEE 802.11 Broadcast Probe Mode is configured for AP, while Supress SSID (section 11.8.1) is for specific radio.

I suggest both Broadcast Probe Mode and Supress SSID could be configured for a specific radio.

 

Regards

 

Richard

--Boundary_(ID_u083KYfdnyuCVC188RhWCQ)-- --===============1156626738== 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 --===============1156626738==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Apr 20 01:29:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWRjo-0000FN-Fe for capwap-archive@lists.ietf.org; Thu, 20 Apr 2006 01:29:56 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWReh-0007r2-1O for capwap-archive@lists.ietf.org; Thu, 20 Apr 2006 01:24:40 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id AA9CF4300AD for ; Wed, 19 Apr 2006 22:24:38 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 6B97843006D for ; Wed, 19 Apr 2006 22:24:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4B7DF14481F4 for ; Wed, 19 Apr 2006 22:24:11 -0700 (PDT) Received: from huawei-3com.com (pop.huawei-3com.com [219.133.0.18]) by hermes.tigertech.net (Postfix) with ESMTP id 8E0D6144800F for ; Wed, 19 Apr 2006 22:24:09 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IY000LQZ9YJ40@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Thu, 20 Apr 2006 13:30:19 +0800 (CST) Received: from RichardYoung ([10.18.7.90]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IY0001E99YIEU@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Thu, 20 Apr 2006 13:30:19 +0800 (CST) Date: Thu, 20 Apr 2006 10:54:07 +0530 From: young To: pcalhoun@cisco.com Message-id: <000001c6643a$a5d888b0$5a07120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE X-Spam-Level: Cc: capwap@frascone.com Subject: [Capwap] CAPWAP need new TLV to configure Radio Type 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="===============0183929129==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f This is a multi-part message in MIME format. --===============0183929129== Content-type: multipart/alternative; boundary="Boundary_(ID_gkpsJutLEksuctKyRnL3pQ)" This is a multi-part message in MIME format. --Boundary_(ID_gkpsJutLEksuctKyRnL3pQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear all: At present, only one TLV of "WTP Radio Information" is related to radio type, and only carried during the discovery phase. But there is no TLV to configure radio type. So I suggest CAPWAP could add new TLV for radio type configuration. Regards Richard --Boundary_(ID_gkpsJutLEksuctKyRnL3pQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dear all:

 

At present, only one TLV of  “WTP Radio Information” is related to radio type, and only carried during the discovery phase.

But there is no TLV to configure radio type.

So I suggest CAPWAP could add new TLV for radio type configuration.

 

Regards

Richard

--Boundary_(ID_gkpsJutLEksuctKyRnL3pQ)-- --===============0183929129== 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 --===============0183929129==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Apr 20 01:56:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWS9o-0007tv-Nl for capwap-archive@lists.ietf.org; Thu, 20 Apr 2006 01:56:48 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWS9n-0000od-8o for capwap-archive@lists.ietf.org; Thu, 20 Apr 2006 01:56:48 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A75E54300C7 for ; Wed, 19 Apr 2006 22:56:46 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3EF11430067 for ; Wed, 19 Apr 2006 22:56:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 20CAA1448010 for ; Wed, 19 Apr 2006 22:56:25 -0700 (PDT) Received: from aruba-mx.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by hermes.tigertech.net (Postfix) with SMTP id 65125144800F for ; Wed, 19 Apr 2006 22:56:23 -0700 (PDT) Received: from [172.18.8.114] ([172.18.8.114] RDNS failed) by aruba-mx.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Apr 2006 22:56:22 -0700 Date: Wed, 19 Apr 2006 22:56:19 -0700 (PDT) From: Partha Narasimhan X-X-Sender: partha@localhost.localdomain To: "David T. Perkins" Subject: Re: [Capwap] 802.11d / 802.11h support In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 20 Apr 2006 05:56:22.0306 (UTC) FILETIME=[26C8F820:01C6643F] X-Virus-Scanned: by amavisd-new-20030616-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: 32b73d73e8047ed17386f9799119ce43 David Could you please explain how you think we may end up with an "nonstable RF environment"? There is more to supporting 11h than merely changing channels on detecting radar. The "AP" has to maintain state on every channel that it detected radar on for a certain period of time following the radar event. There are also strict time constraints on how soon one has to get off the channel following the detection of radar. Your proposal would split this state between the two entities. We need to work at modifying the CAPWAP state machine and/or messages to ensure the two are in sync. My vote is still for the simpler mechanism of letting the WTP manage radar detection and the subsequent channel change. Thanks partha On Tue, 18 Apr 2006, David T. Perkins wrote: > HI, > > For #2, I believe that a WTP should only report the detection > or radar, and let the AC switch channels (and make > any other configuration changes). Otherwise, you may end > up with a nonstable RF environment. > > Regards, > /david t. perkins > On Tue, 18 Apr 2006, Partha Narasimhan wrote: >> For #1, why dont we use the IEs as defined by IEEE 802.11? Why do we need >> to re-define something that is already defined in 802.11? This is probably >> true for the 11d, RSN, WPA, WMM, 11e IEs, and anything else that has a >> corresponding 802.11 definition. There is code that exists to parse 802.11 >> IEs elsewhere in the WTP, so we get code reuse too. :-) >> >> For #2, my vote would be for the WTP to switch channels on detecting radar >> and notify the AC of the radar detect and the resulting channel change >> events. This keeps it simple and WTPs have the ability to detect radar >> already. >> >> Thanks >> partha >> >> On Tue, 18 Apr 2006, Dorothy Stanley wrote: >> >>> Hi Puneet, >>> >>> This is assigned to a new issue, 104. >>> >>> All- comments, discussion please. >>> >>> Thanks, >>> >>> Dorothy Stanley >>> >>> >>> On 4/14/06, Puneet wrote: >>> >>> 1. Section 11.9.3 'IEEE 802.11 Multi-domain Capability': The length of this element is fixed at 8 bytes, but if there are multiple, disjoint bands that are supported in the regulatory domain does the AC use multiple such elements? It might be cleaner to make the length of this element variable, and allow multiple triplets >> >>> 2. How does CAPWAP plan to support 802.11h? Does the WTP handle everything on its own or is the channel switching etc controlled by the AC? In either case there might be a need for message elements with which the WTP to report the detection of radar to the AC. >>> >>> 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 >>> >>> >>> >>> >>> >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/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 calvinyfaa@thegrid.net Thu Apr 20 08:43:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWYUw-0008Bn-VP for capwap-archive@ietf.org; Thu, 20 Apr 2006 08:43:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWYUw-0005Cl-Tt for capwap-archive@ietf.org; Thu, 20 Apr 2006 08:43:02 -0400 Received: from i220-221-176-104.s02.a001.ap.plala.or.jp ([220.221.176.104] helo=thegrid.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FWYOp-0000Rj-Qd for capwap-archive@ietf.org; Thu, 20 Apr 2006 08:36:45 -0400 Message-ID: <000001c66477$142c4810$86e6a8c0@gju11> Reply-To: "Calvin Faas" From: "Calvin Faas" To: capwap-archive@ietf.org Subject: Re: byzoe one Date: Thu, 20 Apr 2006 08:36:42 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C66455.8D1AA810" 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.1 (++) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C66455.8D1AA810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable De w ar Home Ow v ne v r ,=20 =20 Your c p redi k t doesn't matter to us !=20 If you OW o N real e y st z at o e and want IM o MED o IAT v E=20 c v ash to sp b en r d ANY way you like,=20 or simply wish to LO l WER your monthly p z ayme y nts=20 by a third or more, here are the dea o ls=20 we have T j OD c AY :=20 =20 $ 4 w 88 , 000 - 3 k , 67% fi i xed - ra r te=20 $ 37 k 2 , 000 - 3 l , 90% va h ria u ble - rat e e=20 $ 4 l 92 , 000 - 3 y , 21% inte i re d st - only=20 $ 2 v 48 , 000 - 3 n , 36% f t ixed - rat l e=20 $ 19 k 8 , 000 - 3 f , 55% vari a able - ra v te=20 =20 Hur a ry, when these d y eal b s are gone, they are gone ! =20 Don't worry about ap q pr h ov k al,=20 your c o re g dit will not di c squ p al j ify you !=20 =20 compl a ete ea q sy we n b f d orm =20 =20 Sincerely, Calvin Faas=20 =20 A n ppr b ova i l Manager ------=_NextPart_000_0001_01C66455.8D1AA810 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
De w ar Home Ow v ne v r ,
 
Your c p redi k t doesn't matter to us !
If you OW o N real e y st z at o e and want IM o MED o IAT v E
c v ash to sp b en r d ANY way you like,
or simply wish to LO l WER your monthly p z ayme y nts
by a third or more, here are the dea o ls
we have T j OD c AY :
 
$ 4 w 88 , 000 - 3 k , 67% fi i xed - ra r te
$ 37 k 2 , 000 - 3 l , 90% va h ria u ble - rat e e
$ 4 l 92 , 000 - 3 y , 21% inte i re d st - only
$ 2 v 48 , 000 - 3 n , 36% f t ixed - rat l e
$ 19 k 8 , 000 - 3 f , 55% vari a able - ra v te
 
Hur a ry, when these d y eal b s are gone, they are gone !
 
Don't worry about ap q pr h ov k al,
your c o re g dit will=20 not di c squ p al j ify you !
 
=20 compl a ete ea q sy we n b f d orm
 
Sincerely, Calvin Faas
 
A n ppr b ova i l Manager
------=_NextPart_000_0001_01C66455.8D1AA810-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Apr 20 11:14:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWarR-0001Sh-Rk for capwap-archive@lists.ietf.org; Thu, 20 Apr 2006 11:14:25 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWarQ-0004Zi-Aj for capwap-archive@lists.ietf.org; Thu, 20 Apr 2006 11:14:25 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 55BF14300E1 for ; Thu, 20 Apr 2006 08:14:23 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 53AE7430075 for ; Thu, 20 Apr 2006 08:13:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3DFD44310B7 for ; Thu, 20 Apr 2006 08:13:59 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9D51C4310C7 for ; Thu, 20 Apr 2006 08:13:57 -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 k3KFDtdr018623; Thu, 20 Apr 2006 08:13:55 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k3KFDsRm018620; Thu, 20 Apr 2006 08:13:55 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 20 Apr 2006 08:13:53 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Partha Narasimhan Subject: Re: [Capwap] 802.11d / 802.11h support In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new-20030616-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: 5ebbf074524e58e662bc8209a6235027 HI, There are 3 cases that I know of that affect channel (power and other configurations assignments related to the RF environment). These include: 1) assignments to other WTPs controlled by the AC (or in future CAPWAP versions - cooperating ACs). WTPs in a "WiFi cloud" must have coordinated configuration assignments so that they do not interfer with each other and provide an acceptable (and ideally, optimal) RF environment for the STAs that communicate with the WTPs. The AC(s) have the "big picture" about the RF environment using data from the WTPs, possibly RF monitors, and possibly input from the "WiFi cloud" designer. 2) assignments to RF devices (APs and WTPs) controlled by neighbors. In many environments, "WiFi clouds" managed by different organizations have overlaps. To allow peaceful coexistance, the organizations must create "power and channel sharing agreements". In configuring WTPs controlled by AC(s), such agreements would be called "configuration setting pollicies". These need to be factored into the process when the AC(s) determine the configuration assignments for the WTPs in a "WiFi cloud". 3) RF interference by nonWiFi devices and by rogues. An individual WTP does not "know" the big picture and if it changes it's configuration assignments without coordination by the AC, then it's changes could interfer with other WTPs (which if they changed could affect other WTPs, etc), or could violate policy (such as use a channel reserved for a neighbor), or result in degraded operation (using configuration assignements that result in RF interference). On Wed, 19 Apr 2006, Partha Narasimhan wrote: > David > > Could you please explain how you think we may end up with an "nonstable RF > environment"? > > There is more to supporting 11h than merely changing channels on detecting > radar. The "AP" has to maintain state on every channel that it detected > radar on for a certain period of time following the radar event. There are > also strict time constraints on how soon one has to get off the channel > following the detection of radar. Your proposal would split this state > between the two entities. We need to work at modifying the CAPWAP state > machine and/or messages to ensure the two are in sync. > > My vote is still for the simpler mechanism of letting the WTP manage radar > detection and the subsequent channel change. > > Thanks > partha > > On Tue, 18 Apr 2006, David T. Perkins wrote: > > > HI, > > > > For #2, I believe that a WTP should only report the detection > > or radar, and let the AC switch channels (and make > > any other configuration changes). Otherwise, you may end > > up with a nonstable RF environment. > > > > Regards, > > /david t. perkins > > On Tue, 18 Apr 2006, Partha Narasimhan wrote: > >> For #1, why dont we use the IEs as defined by IEEE 802.11? Why do we need > >> to re-define something that is already defined in 802.11? This is probably > >> true for the 11d, RSN, WPA, WMM, 11e IEs, and anything else that has a > >> corresponding 802.11 definition. There is code that exists to parse 802.11 > >> IEs elsewhere in the WTP, so we get code reuse too. :-) > >> > >> For #2, my vote would be for the WTP to switch channels on detecting radar > >> and notify the AC of the radar detect and the resulting channel change > >> events. This keeps it simple and WTPs have the ability to detect radar > >> already. > >> > >> Thanks > >> partha > >> > >> On Tue, 18 Apr 2006, Dorothy Stanley wrote: > >> > >>> Hi Puneet, > >>> > >>> This is assigned to a new issue, 104. > >>> > >>> All- comments, discussion please. > >>> > >>> Thanks, > >>> > >>> Dorothy Stanley > >>> > >>> > >>> On 4/14/06, Puneet wrote: > >>> > >>> 1. Section 11.9.3 'IEEE 802.11 Multi-domain Capability': The length of this element is fixed at 8 bytes, but if there are multiple, disjoint bands that are supported in the regulatory domain does the AC use multiple such elements? It might be cleaner to make the length of this element variable, and allow multiple triplets >>> > >>> 2. How does CAPWAP plan to support 802.11h? Does the WTP handle everything on its own or is the channel switching etc controlled by the AC? In either case there might be a need for message elements with which the WTP to report the detection of radar to the AC. > >>> > >>> Thanks, > >>> Puneet. 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 Apr 20 12:04:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWbdU-0002gO-FF for capwap-archive@lists.ietf.org; Thu, 20 Apr 2006 12:04:04 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWbdS-0007hJ-SY for capwap-archive@lists.ietf.org; Thu, 20 Apr 2006 12:04:04 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4805A4300D1 for ; Thu, 20 Apr 2006 09:04:02 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 9242F430077 for ; Thu, 20 Apr 2006 09:03:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 79C16431197 for ; Thu, 20 Apr 2006 09:03:31 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.205]) by hermes.tigertech.net (Postfix) with ESMTP id 89ABB43118F for ; Thu, 20 Apr 2006 09:03:28 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so124868wxd for ; Thu, 20 Apr 2006 09:03:27 -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=qpEzZ+ZRmmQTTuDXqBPU9kt3GIhLPP6VUWII73El8nsPJBRo6/4RRLxT1izQghoXZuBqEqgT9yC0VHtQwGRPPczik0BphZGoRxut689V9J47VfF8q681yBhTdtL8W+CRdKs8sBRPprNlHcuyeOVy4oxkz/Tt5w/Fq3+BiPDzIbs= Received: by 10.70.87.18 with SMTP id k18mr1002379wxb; Thu, 20 Apr 2006 09:03:27 -0700 (PDT) Received: by 10.70.133.14 with HTTP; Thu, 20 Apr 2006 09:03:27 -0700 (PDT) Message-ID: <5bfe7a820604200903qcb7ba6aj7b2a55ef96f71388@mail.gmail.com> Date: Thu, 20 Apr 2006 09:03:27 -0700 From: "Dorothy Stanley" To: young Subject: Re: [Capwap] some suggestion for 802.11 binding TLV In-Reply-To: <000001c66438$55219c10$5a07120a@china.huawei.com> MIME-Version: 1.0 References: <000001c66438$55219c10$5a07120a@china.huawei.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.6 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_60_70, HTML_MESSAGE, 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="===============1688067239==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 --===============1688067239== Content-Type: multipart/alternative; boundary="----=_Part_27851_16954642.1145549007717" ------=_Part_27851_16954642.1145549007717 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Richard, Status and comments inline 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? I= n which message elements and messages would it be included? 2) Because CAPWAP provide the definition of 802.11 binding, the common > configuration for AP came from different vendors should defined by draft.= I > felt something like "Preamble-length" configuration need to be added into > draft. > Issue 106 has been opened for item (2) Where would you add "pre-amble length"? In the WTP Radio information? Is this info provided by the WTP to the AC on what is supported? 3) Now, in the draft, IEEE 802.11 Broadcast Probe Mode is configured for AP= , > while Supress SSID (section 11.8.1) is for specific radio. > > I suggest both Broadcast Probe Mode and Supress SSID could be configured > for a specific radio. > Issue 107 has been opened for item (3). Regards > > > > Richard > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_27851_16954642.1145549007717 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Richard,

Status and comments inline 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"

<= /div>

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 statis= tics collection counters?
Is it included in the statistics message element? A new message element?  In which message elements and messages would it be included?



2) Be= cause CAPWAP provide the definition of 802.11 binding, the common configuration f= or AP came from different vendors should defined by draft. I felt something li= ke "Preamble-length" configuration need = to be added into draft.


Issue 106 has been opened for item (2)

Where would you add "pre-amble length"? In the WTP Radio informat= ion?
Is this info provided by the WTP to the AC on what is supported?

3) Now, in the draft, IEEE 802.11 Broadcast Probe Mode is configured for AP, while Supress SSID (section 11.8.1) is for specific radio.

I suggest both Broad= cast Probe Mode and = Supress SSID could be configured for a specific radio.


Issue 107 has been opened for item (3). 

Regar= ds

 <= /p>

Richard=


_________________________________________________________________=
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_27851_16954642.1145549007717-- --===============1688067239== 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 --===============1688067239==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Apr 20 12:39:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWcBO-0005RE-9G for capwap-archive@lists.ietf.org; Thu, 20 Apr 2006 12:39:06 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWcBM-0001Bg-O9 for capwap-archive@lists.ietf.org; Thu, 20 Apr 2006 12:39:06 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A7C304300FB for ; Thu, 20 Apr 2006 09:39:03 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id DBB61430075 for ; Thu, 20 Apr 2006 09:38:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C827243120C for ; Thu, 20 Apr 2006 09:38:35 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.204]) by hermes.tigertech.net (Postfix) with ESMTP id C8691431216 for ; Thu, 20 Apr 2006 09:38:33 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so131534wxd for ; Thu, 20 Apr 2006 09:38:32 -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=NsRnBSBFY/9DgJ/tpv1gLNjoP+WEvVKUxoin3Kh+gzF4LFCMN75tILxAi25BMe69kwt+Mb6IFHm15H1TRARCzrJcwrVTipWIK/afBLuDW3Cey3/U9n+AyWt0uw25drse67mtLfU2oNJ9AYjZKLAV4/PsEAHk5xS+znBRECItLyM= Received: by 10.70.48.5 with SMTP id v5mr1089173wxv; Thu, 20 Apr 2006 09:38:32 -0700 (PDT) Received: by 10.70.133.14 with HTTP; Thu, 20 Apr 2006 09:38:32 -0700 (PDT) Message-ID: <5bfe7a820604200938h1c64df46lb3496eee546728d@mail.gmail.com> Date: Thu, 20 Apr 2006 09:38:32 -0700 From: "Dorothy Stanley" To: young Subject: Re: [Capwap] CAPWAP need new TLV to configure Radio Type In-Reply-To: <000001c6643a$a5d888b0$5a07120a@china.huawei.com> MIME-Version: 1.0 References: <000001c6643a$a5d888b0$5a07120a@china.huawei.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.6 tagged_above=-999.0 required=7.0 tests=FROM_ENDS_IN_NUMS, HTML_60_70, HTML_MESSAGE, 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="===============0503653995==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 --===============0503653995== Content-Type: multipart/alternative; boundary="----=_Part_28683_12425997.1145551112504" ------=_Part_28683_12425997.1145551112504 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Richard, I suggest including discussion of this as part of issue 102, WTP WLAN Radi= o Configuration Changes. Section 11.9.1, "IEEE 802.11 WTP Radio Configuration" is the message elemen= t used to configure the radio. This message element is currently included in the Configuration request, Configuration response and Configuration update messages. So, is the proposed change that a new field be added: Radio Type - with definitions as per those in 5.1.3? Thanks, Dorothy On 4/19/06, young wrote: > > Dear all: > > > > At present, only one TLV of " WTP Radio Information" is related to radio > type, and only carried during the discovery phase. > > But there is no TLV to configure radio type. > > So I suggest CAPWAP could add new TLV for radio type configuration. > > > > Regards > > Richard > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_28683_12425997.1145551112504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Richard,

I suggest including discussion of  this as part of issue 102, WTP WLAN= Radio Configuration Changes.
Section 11.9.1, "IEEE 802.11 WTP Radio Configuration" is the mess= age element used to
configure the radio. This message element is currently included in the Conf= iguration request,
Configuration response and Configuration update messages.

So, is the proposed change that a new field be added:

Radio Type - with definitions as per those in 5.1.3?

Thanks,

Dorothy

On 4/19/06, young <young= @huawei-3com.com > wrote:

Dear all:

 

At present, only one TLV of  "<= /font> WTP Radio Information" is related to radio type, and only carried during the discovery phase.<= /font>

But there is no TLV to configure radio type.

So I suggest CAPWAP could add new TLV for radio type configuration.

 <= /p>

Regards=

Richard=


_________________________________________________________________=
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_28683_12425997.1145551112504-- --===============0503653995== 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 --===============0503653995==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Apr 20 13:18:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWcnA-0003fS-8p for capwap-archive@lists.ietf.org; Thu, 20 Apr 2006 13:18:08 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWcn8-0003Lp-Kw for capwap-archive@lists.ietf.org; Thu, 20 Apr 2006 13:18:08 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 127C54300CE for ; Thu, 20 Apr 2006 10:18:03 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3949E430075 for ; Thu, 20 Apr 2006 10:17:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1D953144800A for ; Thu, 20 Apr 2006 10:17:29 -0700 (PDT) X-Greylist-Status: Sender first seen 5 days 17:16:24 ago Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.184]) by hermes.tigertech.net (Postfix) with ESMTP id 46392144800C for ; Thu, 20 Apr 2006 10:17:26 -0700 (PDT) Received: by nproxy.gmail.com with SMTP id l36so146641nfa for ; Thu, 20 Apr 2006 10:17: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=l5PfqfdHzR+wRhcXxJa0SMveT5fUAg60eSfYt1CjjLe6pPromFCF1t4GaXZVl7jJ6/zxSQFD3HohkOXsdYDagrv/vKeW+l5Xl85irmbikyczozfwUdJs0NlvaoBQ+6zCnY0cLBd14O53/aNux7vK8GM5tmRICiiHEyexq4jz1Ag= Received: by 10.48.211.17 with SMTP id j17mr645611nfg; Thu, 20 Apr 2006 10:17:25 -0700 (PDT) Received: by 10.48.204.2 with HTTP; Thu, 20 Apr 2006 10:17:25 -0700 (PDT) Message-ID: <1013407b0604201017n54b69a54o85b3111d1cf42ccd@mail.gmail.com> Date: Thu, 20 Apr 2006 10:17:25 -0700 From: Puneet To: "Partha Narasimhan" Subject: Re: [Capwap] 802.11d / 802.11h support In-Reply-To: MIME-Version: 1.0 References: <1013407b0604140028s19895135p9e5ecb101864c9c5@mail.gmail.com> <5bfe7a820604181913m429d1cadk94ef52cf083ae055@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=3.5 tagged_above=-999.0 required=7.0 tests=HTML_20_30, HTML_MESSAGE, 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: , Content-Type: multipart/mixed; boundary="===============1855021690==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 2.4 (++) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 --===============1855021690== Content-Type: multipart/alternative; boundary="----=_Part_31289_5320679.1145553445388" ------=_Part_31289_5320679.1145553445388 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Partha, for #1 I agree with you, we should just use the 802.11 IE (802.11d). That I= E is what will finally go out in the beacons/probe-responses. No need for the WTP to have to translate and construct that IE. for #2 it might be simpler if the WTP reports radar to the AC, and the AC makes the decision about what channel to jump to. As David also mentions, the channel to move to might be determined by policy or by some channel-selection logic on the AC which takes into account neighbouring channels etc. A 'future' channel can either be provided to the WTP at configuration time (if the timing constraints seem so tight), or as soon as it reports radar. Thanks, Puneet On 4/18/06, Partha Narasimhan wrote: > > For #1, why dont we use the IEs as defined by IEEE 802.11? Why do we need > to re-define something that is already defined in 802.11? This is probabl= y > true for the 11d, RSN, WPA, WMM, 11e IEs, and anything else that has a > corresponding 802.11 definition. There is code that exists to parse 802.1= 1 > IEs elsewhere in the WTP, so we get code reuse too. :-) > > For #2, my vote would be for the WTP to switch channels on detecting rada= r > and notify the AC of the radar detect and the resulting channel change > events. This keeps it simple and WTPs have the ability to detect radar > already. > > Thanks > partha > > On Tue, 18 Apr 2006, Dorothy Stanley wrote: > > > Hi Puneet, > > > > This is assigned to a new issue, 104. > > > > All- comments, discussion please. > > > > Thanks, > > > > Dorothy Stanley > > > > > > On 4/14/06, Puneet wrote: > > > > 1. Section 11.9.3 'IEEE 802.11 Multi-domain Capability': The > length of this element is fixed at 8 bytes, but if there are multiple, > disjoint bands that are supported in the regulatory domain does the AC us= e > multiple such elements? It might be cleaner to make the length of this > element variable, and allow multiple triplets > the Country-Information element in 802.11d) > > > > 2. How does CAPWAP plan to support 802.11h? Does the WTP handle > everything on its own or is the channel switching etc controlled by the A= C? > In either case there might be a need for message elements with which the = WTP > to report the detection of radar to the AC. > > > > Thanks, > > Puneet. > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap < > http://lists.frascone.com/mailman/listinfo/capwap> > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > > > > ------=_Part_31289_5320679.1145553445388 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Partha,

for #1 I agree with you, we should just use the 802.11 IE (8= 02.11d). That IE is what will finally go out in the beacons/probe-responses= . No need for the WTP to have to translate and construct that IE.

for #2 it might be simpler if the WTP reports radar to the AC, and the AC m= akes the decision about what channel to jump to. As David also mentions, th= e channel to move to might be determined by policy or by some channel-selec= tion logic on the AC which takes into account neighbouring channels etc. A = 'future' channel can either be provided to the WTP at configuration time (i= f the timing constraints seem so tight), or as soon as it reports radar.

Thanks,
Puneet

On 4/18/0= 6, Partha Narasimhan <partha@arubanetworks.com> wrote:<= blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 2= 04, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> For #1, why dont we use the IEs as defined by IEEE 802.11? Why do we needto re-define something that is already defined in 802.11? This is probabl= y
true for the 11d, RSN, WPA, WMM, 11e IEs, and anything else that has a
corresponding 802.11 definition. There is code that exists to parse 802= .11
IEs elsewhere in the WTP, so we get code reuse too. :-)

For #= 2, my vote would be for the WTP to switch channels on detecting radar
and notify the AC of the radar detect and the resulting channel change
e= vents. This keeps it simple and WTPs have the ability to detect radar
al= ready.

Thanks
partha

On Tue, 18 Apr 2006, Dorothy Stanley = wrote:

> Hi Puneet,
>
> This is assigned to a new issue, 10= 4.
>
> All- comments, discussion please.
>
> Thanks= ,
>
> Dorothy Stanley
>
>
> On 4/14/06, Punee= t < pb.ietf@gmail.com> wrote:
&g= t;
>       1. Section 11.9.3 'IEEE 802.= 11 Multi-domain Capability': The length of this element is fixed at 8 bytes= , but if there are multiple, disjoint bands that are supported in the regul= atory domain does the AC use multiple such elements? It might be cleaner to= make the length of this element variable, and allow multiple triplets <= first_channel,num_channel,max_power) to be added one after the other. (like= the Country-Information element in=20 802.11d)
>
>       2. How does CA= PWAP plan to support 802.11h? Does the WTP handle everything on its own or = is the channel switching etc controlled by the AC? In either case there mig= ht be a need for message elements with which the WTP to report the detectio= n of radar to the AC.
>
>       Thanks,
> &= nbsp;     Puneet.
>
>
>  &n= bsp;    ____________________________________________________= _____________
>       To unsubscribe or= modify your subscription options, please visit:
>       http://lists.frascone.com/mailman/listinfo/= capwap <http://lists.frascone.com/mailman/listinfo/capwap >
>
>       Archives: http://lists.frascone.co= m/pipermail/capwap
>
>
>
>
>

------=_Part_31289_5320679.1145553445388-- --===============1855021690== 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 --===============1855021690==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Apr 20 13:25:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWcul-0006IW-Fr for capwap-archive@lists.ietf.org; Thu, 20 Apr 2006 13:25:59 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWcuk-0003bK-Or for capwap-archive@lists.ietf.org; Thu, 20 Apr 2006 13:25:59 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 64DA94300E5 for ; Thu, 20 Apr 2006 10:25:58 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8DD8B430075 for ; Thu, 20 Apr 2006 10:25:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 733DE431306 for ; Thu, 20 Apr 2006 10:25:27 -0700 (PDT) X-Greylist-Status: Sender first seen 5 days 17:24:22 ago Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.188]) by hermes.tigertech.net (Postfix) with ESMTP id 37718431305 for ; Thu, 20 Apr 2006 10:25:25 -0700 (PDT) Received: by nproxy.gmail.com with SMTP id l36so148340nfa for ; Thu, 20 Apr 2006 10:25:24 -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=Oo9mN5IkVssrs3c7q+bCYEzqhvUThttR7cRqLymtjChcQr+SOKp8PUIY6Qlqtxfngm/a7HVYfGnGfqt+kGiDzZuQv1u+bKPMZOdLk717bchK3D21xNZQXdBHRrPFtxEJFdCFoBIUpm0QEaCfdBbxOD5Lpe43cPwj3uHmKvhO86g= Received: by 10.48.211.17 with SMTP id j17mr651199nfg; Thu, 20 Apr 2006 10:25:22 -0700 (PDT) Received: by 10.48.204.2 with HTTP; Thu, 20 Apr 2006 10:25:22 -0700 (PDT) Message-ID: <1013407b0604201025n41ece1d2ta30c7d1ad305f541@mail.gmail.com> Date: Thu, 20 Apr 2006 10:25:22 -0700 From: Puneet To: "Dorothy Stanley" Subject: Re: [Capwap] Section 11.8.1.1 'IEEE 802.11 Add WLAN' In-Reply-To: <5bfe7a820604181910o3ad8398as3c6f0e83f438391e@mail.gmail.com> MIME-Version: 1.0 References: <1013407b0604140028h6e64226agcc25f34ab8e6bc41@mail.gmail.com> <5bfe7a820604181910o3ad8398as3c6f0e83f438391e@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=3.2 tagged_above=-999.0 required=7.0 tests=HTML_50_60, HTML_MESSAGE, NORMAL_HTTP_TO_IP, 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: , Content-Type: multipart/mixed; boundary="===============2083490080==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 2.0 (++) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 --===============2083490080== Content-Type: multipart/alternative; boundary="----=_Part_31529_23534144.1145553922414" ------=_Part_31529_23534144.1145553922414 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > > For the moment, I've included these questions in issue 101, since all are > related to 11.8.1.1, but can open a new issue if needed. Comments inline > thanks, I think a single issue is fine. 1. does the encryption policy refer to broadcast traffic or unicast too? I= f > its also unicast, then there could be multiple encryption types enabled a= t > the same type on the WLAN, in that case how is the encryption-policy fiel= d > filled in? > > It's likely broadcast only. A single key is included - the GTK? > But since the WPAIE and RSNIE are included, it's not clear the encryption > policy is needed, since the > valid ciphersuites to advertize in the beacons - unicast and broadcast ar= e > included in the IEs. > If its broadcast-only, can we change the text from: Encryption Policy: A 32-bit value specifying the encryption scheme to apply to *traffic to and from* the mobile station to: Encryption Policy: A 32-bit value specifying the encryption scheme to apply to *broadcast trafic to* the mobile stations Thanks, Puneet 2. for the encryption policies we could use the format used in the RSN IEs > > (OUI + encryption_type); that allows support for different vendor speci= fic > > 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 eac= h > > others toes). > > > > Agreed, see Issue 101 > > 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 length= s, > > then the IEs could be made variable length. > > > > Also see issue 101. New IEs should not be defined here, but the existing > 802.11 IE definitions re-used > > 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.11B= roadcast Probe Mode' in section > > 11.9.12? Also, why is this IE global for the WTP? The AC might configur= e > > the WTP with 10 WLANs, but it may want probe responses generated for on= ly > > four of those when a broadcast probe request comes in. > > > > Agree, need to retain flexibility for the AC to customize the probe > responses generated. > > 5. maybe rename WME to WMM? > > > > Agreed > > 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_31529_23534144.1145553922414 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
For the moment, I've included these questions in issue 101, since= all are
related to 11.8.1.1, but can open a ne= w issue if needed. Comments inline


thanks, I think a single issue is fine.
1. does the encryption policy refer to broad= cast traffic or unicast too? If its also unicast, then there could be multi= ple encryption types enabled at the same type on the WLAN, in that case how= is the encryption-policy field filled in?
 
It's likely broadcast only. A single key is included - the GTK?
But since the WPAIE and RSNIE are included, it's not clear the encrypt= ion policy is needed, since the
valid ciphersuites to advertize in the beacons - unicast and broadcast= are included in the IEs.


If its= broadcast-only, can we change the text from:
Encryption Policy:  A=
 32-bit value specifying the encryption scheme to apply to *traffic to and =
from* the mobile station
to:
Encryption Policy:  A 32-bit value specifying the e=
ncryption scheme to apply to *broadcast trafic to* the mobile stations
<=
br>
Thanks,
Puneet


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 wi= th the other 'standard' encryption types; and it makes it easier for vendor= s to not step on each others toes).
 
Agreed, see Issue 101

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.
 
Also see issue 101. New IEs should not be defined here, but the e= xisting 802.11 IE definitions re-used

4. Does the 'Suppress SSID' field also disab= le 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 b= roadcast probe request comes in.
 
Agree, need to retain flexibility for the AC to customize the probe re= sponses generated.

5. maybe rename WME to WMM?
 
Agreed

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_31529_23534144.1145553922414-- --===============2083490080== 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 --===============2083490080==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Apr 20 14:58:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWeMK-00036g-Ts for capwap-archive@lists.ietf.org; Thu, 20 Apr 2006 14:58:32 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWeMH-0008JK-4K for capwap-archive@lists.ietf.org; Thu, 20 Apr 2006 14:58:32 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 367D44300AA for ; Thu, 20 Apr 2006 11:58:24 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7C66D430075 for ; Thu, 20 Apr 2006 11:57:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6C26939802E for ; Thu, 20 Apr 2006 11:57:48 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2B0E2398009 for ; Thu, 20 Apr 2006 11:57:45 -0700 (PDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 20 Apr 2006 11:57:46 -0700 X-IronPort-AV: i="4.04,141,1144047600"; d="scan'208,217"; a="1797158156:sNHT59592348" 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 k3KIvjYg008260 for ; Thu, 20 Apr 2006 11:57:45 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Apr 2006 11:57:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] 802.11d / 802.11h support Date: Thu, 20 Apr 2006 11:57:45 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC016C71A7@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] 802.11d / 802.11h support Thread-Index: AcZknlvtstqZoyRjRWmEvX/q+pxaoQADJ1YQ From: "Bob O'Hara (boohara)" To: X-OriginalArrivalTime: 20 Apr 2006 18:57:45.0185 (UTC) FILETIME=[4F289510:01C664AC] 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: 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="===============0286599637==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd This is a multi-part message in MIME format. --===============0286599637== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C664AC.4F0EAB12" This is a multi-part message in MIME format. ------_=_NextPart_001_01C664AC.4F0EAB12 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On the issue of radar detection, the proposal to have the WTP inform the AC, then have the AC make the decision about channel change will probably run into either regulatory problems or cost of certification problems, or both. Because radar detection is a regulatory issue, it must be tested to certify a device to operate in a band requiring radar avoidance. If the WTP defers to the AC for some part of the radar avoidance operation, certification will require that both the WTP and AC be certified as a system. =20 Given that the goal of CAPWAP is to promote multi-vendor interoperability between WTP and AC, system certification to meet radar avoidance regulatory requirements will result in one or more of the following outcomes: 1. WTPs will have to maintain a list of ACs for which they are certified to operate and meet radar avoidance requirements. 2. WTPs will have to be certified with every AC. 3. WTP certification will be extraordinarily costly. 4. Multi-vendor interoperability will be impaired. =20 I would recommend that the WTP, alone make the decision, then inform the AC when it has changed channels. -Bob =20 =20 ________________________________ From: Puneet [mailto:pb.ietf@gmail.com]=20 Sent: Thursday, April 20, 2006 10:17 AM To: Partha Narasimhan Cc: capwap@frascone.com Subject: Re: [Capwap] 802.11d / 802.11h support Partha, for #1 I agree with you, we should just use the 802.11 IE (802.11d). That IE is what will finally go out in the beacons/probe-responses. No need for the WTP to have to translate and construct that IE. for #2 it might be simpler if the WTP reports radar to the AC, and the AC makes the decision about what channel to jump to. As David also mentions, the channel to move to might be determined by policy or by some channel-selection logic on the AC which takes into account neighbouring channels etc. A 'future' channel can either be provided to the WTP at configuration time (if the timing constraints seem so tight), or as soon as it reports radar.=20 Thanks, Puneet On 4/18/06, Partha Narasimhan wrote:=20 For #1, why dont we use the IEs as defined by IEEE 802.11? Why do we need to re-define something that is already defined in 802.11? This is probably true for the 11d, RSN, WPA, WMM, 11e IEs, and anything else that has a=20 corresponding 802.11 definition. There is code that exists to parse 802.11 IEs elsewhere in the WTP, so we get code reuse too. :-) =09 For #2, my vote would be for the WTP to switch channels on detecting radar and notify the AC of the radar detect and the resulting channel change events. This keeps it simple and WTPs have the ability to detect radar already. =09 Thanks partha =09 On Tue, 18 Apr 2006, Dorothy Stanley wrote:=20 =09 > Hi Puneet, > > This is assigned to a new issue, 104. > > All- comments, discussion please. > > Thanks, > > Dorothy Stanley > > > On 4/14/06, Puneet < pb.ietf@gmail.com> wrote: > > 1. Section 11.9.3 'IEEE 802.11 Multi-domain Capability': The length of this element is fixed at 8 bytes, but if there are multiple, disjoint bands that are supported in the regulatory domain does the AC use multiple such elements? It might be cleaner to make the length of this element variable, and allow multiple triplets > 2. How does CAPWAP plan to support 802.11h? Does the WTP handle everything on its own or is the channel switching etc controlled by the AC? In either case there might be a need for message elements with which the WTP to report the detection of radar to the AC.=20 > > Thanks, > Puneet. > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit:=20 > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > =09 ------_=_NextPart_001_01C664AC.4F0EAB12 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On the issue of radar detection, the proposal = to have=20 the WTP inform the AC, then have the AC make the decision about channel = change=20 will probably run into either regulatory problems or cost of = certification=20 problems, or both.  Because radar detection is a regulatory issue, = it must=20 be tested to certify a device to operate in a band requiring radar=20 avoidance.  If the WTP defers to the AC for some part of the radar=20 avoidance operation, certification will require that both the WTP and AC = be=20 certified as a system.
 
Given that the goal of CAPWAP is to promote=20 multi-vendor interoperability between WTP and AC, system certification = to meet=20 radar avoidance regulatory requirements will result in one or more of = the=20 following outcomes:
1. WTPs will have to maintain a list of ACs = for which=20 they are certified to operate and meet radar avoidance=20 requirements.
2. WTPs will have to be certified with every=20 AC.
3. WTP certification will be extraordinarily=20 costly.
4. Multi-vendor interoperability will be=20 impaired.
 
I=20 would recommend that the WTP, alone make the decision, then inform the = AC when=20 it has changed channels.

 -Bob
 

 

From: Puneet = [mailto:pb.ietf@gmail.com]=20
Sent: Thursday, April 20, 2006 10:17 AM
To: Partha=20 Narasimhan
Cc: capwap@frascone.com
Subject: Re: = [Capwap]=20 802.11d / 802.11h support

Partha,

for #1 I agree with you, we should just use = the 802.11=20 IE (802.11d). That IE is what will finally go out in the=20 beacons/probe-responses. No need for the WTP to have to translate and = construct=20 that IE.

for #2 it might be simpler if the WTP reports radar to = the AC,=20 and the AC makes the decision about what channel to jump to. As David = also=20 mentions, the channel to move to might be determined by policy or by = some=20 channel-selection logic on the AC which takes into account neighbouring = channels=20 etc. A 'future' channel can either be provided to the WTP at = configuration time=20 (if the timing constraints seem so tight), or as soon as it reports = radar.=20

Thanks,
Puneet

On 4/18/06, Partha=20 Narasimhan <partha@arubanetworks.com>= =20 wrote:
For=20 #1, why dont we use the IEs as defined by IEEE 802.11? Why do we = need
to=20 re-define something that is already defined in 802.11? This is=20 probably
true for the 11d, RSN, WPA, WMM, 11e IEs, and anything = else that=20 has a
corresponding 802.11 definition. There is code that exists = to parse=20 802.11
IEs elsewhere in the WTP, so we get code reuse too. = :-)

For=20 #2, my vote would be for the WTP to switch channels on detecting = radar
and=20 notify the AC of the radar detect and the resulting channel = change
events.=20 This keeps it simple and WTPs have the ability to detect=20 radar
already.

Thanks
partha

On Tue, 18 Apr 2006, = Dorothy=20 Stanley wrote:

> Hi Puneet,
>
> This is = assigned to a=20 new issue, 104.
>
> All- comments, discussion=20 please.
>
> Thanks,
>
> Dorothy=20 Stanley
>
>
> On 4/14/06, Puneet < pb.ietf@gmail.com>=20 wrote:
>
>       1. Section = 11.9.3=20 'IEEE 802.11 Multi-domain Capability': The length of this element is = fixed at=20 8 bytes, but if there are multiple, disjoint bands that are supported = in the=20 regulatory domain does the AC use multiple such elements? It might be = cleaner=20 to make the length of this element variable, and allow multiple = triplets=20 <first_channel,num_channel,max_power) to be added one after the = other.=20 (like the Country-Information element in=20 802.11d)
>
>       2. How = does=20 CAPWAP plan to support 802.11h? Does the WTP handle everything on its = own or=20 is the channel switching etc controlled by the AC? In either case = there might=20 be a need for message elements with which the WTP to report the = detection of=20 radar to the AC.
>
>      =20 Thanks,
>      =20 Puneet.
>
>
>      =20 = _________________________________________________________________
>=       =20 To unsubscribe or modify your subscription options, please visit:=20
>       http://lists.f= rascone.com/mailman/listinfo/capwap=20 <http://lists.f= rascone.com/mailman/listinfo/capwap=20 >
>
>       Archives: = http://lists.frascone= .com/pipermail/capwap
>
>
>
>
>

------_=_NextPart_001_01C664AC.4F0EAB12-- --===============0286599637== 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 --===============0286599637==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Apr 20 15:36:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWexR-00010r-EF for capwap-archive@lists.ietf.org; Thu, 20 Apr 2006 15:36:53 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWexP-0001qQ-SI for capwap-archive@lists.ietf.org; Thu, 20 Apr 2006 15:36:53 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0B3884300F9 for ; Thu, 20 Apr 2006 12:36:51 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 845F2430075 for ; Thu, 20 Apr 2006 12:36:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 721231448010 for ; Thu, 20 Apr 2006 12:36:26 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id BC2F61448012 for ; Thu, 20 Apr 2006 12:36:24 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k3KJaOHO002837; Thu, 20 Apr 2006 12:36:24 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k3KJaNNw002830; Thu, 20 Apr 2006 12:36:24 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 20 Apr 2006 12:36:23 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Bob O'Hara (boohara)" Subject: RE: [Capwap] 802.11d / 802.11h support In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC016C71A7@xmb-sjc-237.amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new-20030616-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: 2ed806e2f53ff1a061ad4f97e00345ac HI, Interesting info Bob. Given what you say below, I would suggest that the best action is to disable the radio and inform the AC of the event. The AC can then use it's big picture knowledge to configure an appropriate channel (and power level and other attributes of the WTPs that it controls). Your info brings up a question. That is, what are the certication requirements between ACs and WTPs for an AC to configure the RF attributes of a WTP? Thanks again for being on top of the regulatory issues. Regards, /david t. perkins On Thu, 20 Apr 2006, Bob O'Hara (boohara) wrote: > On the issue of radar detection, the proposal to have the WTP inform the > AC, then have the AC make the decision about channel change will > probably run into either regulatory problems or cost of certification > problems, or both. Because radar detection is a regulatory issue, it > must be tested to certify a device to operate in a band requiring radar > avoidance. If the WTP defers to the AC for some part of the radar > avoidance operation, certification will require that both the WTP and AC > be certified as a system. > > Given that the goal of CAPWAP is to promote multi-vendor > interoperability between WTP and AC, system certification to meet radar > avoidance regulatory requirements will result in one or more of the > following outcomes: > 1. WTPs will have to maintain a list of ACs for which they are certified > to operate and meet radar avoidance requirements. > 2. WTPs will have to be certified with every AC. > 3. WTP certification will be extraordinarily costly. > 4. Multi-vendor interoperability will be impaired. > > I would recommend that the WTP, alone make the decision, then inform the > AC when it has changed channels. > > -Bob > ________________________________ > > From: Puneet [mailto:pb.ietf@gmail.com] > Sent: Thursday, April 20, 2006 10:17 AM > To: Partha Narasimhan > Cc: capwap@frascone.com > Subject: Re: [Capwap] 802.11d / 802.11h support > > > Partha, > > for #1 I agree with you, we should just use the 802.11 IE (802.11d). > That IE is what will finally go out in the beacons/probe-responses. No > need for the WTP to have to translate and construct that IE. > > for #2 it might be simpler if the WTP reports radar to the AC, and the > AC makes the decision about what channel to jump to. As David also > mentions, the channel to move to might be determined by policy or by > some channel-selection logic on the AC which takes into account > neighbouring channels etc. A 'future' channel can either be provided to > the WTP at configuration time (if the timing constraints seem so tight), > or as soon as it reports radar. > > Thanks, > Puneet > > > On 4/18/06, Partha Narasimhan wrote: > > For #1, why dont we use the IEs as defined by IEEE 802.11? Why > do we need > to re-define something that is already defined in 802.11? This > is probably > true for the 11d, RSN, WPA, WMM, 11e IEs, and anything else that > has a > corresponding 802.11 definition. There is code that exists to > parse 802.11 > IEs elsewhere in the WTP, so we get code reuse too. :-) > > For #2, my vote would be for the WTP to switch channels on > detecting radar > and notify the AC of the radar detect and the resulting channel > change > events. This keeps it simple and WTPs have the ability to detect > radar > already. > > Thanks > partha > > On Tue, 18 Apr 2006, Dorothy Stanley wrote: > > > Hi Puneet, > > > > This is assigned to a new issue, 104. > > > > All- comments, discussion please. > > > > Thanks, > > > > Dorothy Stanley > > > > > > On 4/14/06, Puneet < pb.ietf@gmail.com> wrote: > > > > 1. Section 11.9.3 'IEEE 802.11 Multi-domain Capability': > The length of this element is fixed at 8 bytes, but if there are > multiple, disjoint bands that are supported in the regulatory domain > does the AC use multiple such elements? It might be cleaner to make the > length of this element variable, and allow multiple triplets > (like the Country-Information element in 802.11d) > > > > 2. How does CAPWAP plan to support 802.11h? Does the WTP > handle everything on its own or is the channel switching etc controlled > by the AC? In either case there might be a need for message elements > with which the WTP to report the detection of radar to the AC. > > > > 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 > > > > > > > > > > > > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Apr 21 03:55:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWqUK-00032H-UB for capwap-archive@lists.ietf.org; Fri, 21 Apr 2006 03:55:36 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWqUJ-0006jd-HI for capwap-archive@lists.ietf.org; Fri, 21 Apr 2006 03:55:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 87CC24300C0 for ; Fri, 21 Apr 2006 00:55:30 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 597A3430092 for ; Fri, 21 Apr 2006 00:55:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 34F16398039 for ; Fri, 21 Apr 2006 00:55:09 -0700 (PDT) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 88FDA398021 for ; Fri, 21 Apr 2006 00:55:05 -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 k3L7t1wj011713; Fri, 21 Apr 2006 16:55:01 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k3L7t3o20792; Fri, 21 Apr 2006 16:55:03 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with SMTP id k3L7t4X11113; Fri, 21 Apr 2006 16:55:04 +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] Proposed Resolution to Issue 45 -Issueoncombiningmessages Date: Fri, 21 Apr 2006 15:53:16 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BDD51FAD@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages Thread-Index: AcZjEHGxj2KcjkyjT5yc2kh4CYjhAAB+xi2g From: "Saravanan Govindan" To: "Scott G. Kelly" , "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: 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: 538aad3a3c4f01d8b6a6477ca4248793 Hi Scott, I think David's note does address the issue on hand.=20 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 alone for this purpose, reason being that statistics are periodically exchanged.=20 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.=20 So I suggest keeping it simple - arrival of statistics message from WTP means WTP is alive.=20 Saravanan -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com]=20 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 21 05:44:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWsBR-0005vE-9h for capwap-archive@lists.ietf.org; Fri, 21 Apr 2006 05:44:13 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWsBP-00043W-Cu for capwap-archive@lists.ietf.org; Fri, 21 Apr 2006 05:44:13 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7C41B430092 for ; Fri, 21 Apr 2006 02:44:10 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 5E6C2430092 for ; Fri, 21 Apr 2006 02:43:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 43B274309DB for ; Fri, 21 Apr 2006 02:43:21 -0700 (PDT) X-Greylist-Status: Sender first seen 6 days 09:42:15 ago Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.190]) by hermes.tigertech.net (Postfix) with ESMTP id 8EE704309D6 for ; Fri, 21 Apr 2006 02:43:18 -0700 (PDT) Received: by nproxy.gmail.com with SMTP id k27so298886nfc for ; Fri, 21 Apr 2006 02:43:17 -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=qKCqmggr+d0sw7l2+0klSu6mu9sNLeTPvdKSgWQFvBlm2qwCpP8CY9UQHVD1A5rxBtbqwq4j96WjxVz9aLIrS9u1RWcxoH5KM/NdDWnk2Ewnx6fisnpHHxY6j9hRy7/TE3N8h9TYyY8oqHqX5S19gsf9/L0bJdKn7Ocv80KKQuw= Received: by 10.48.209.18 with SMTP id h18mr1202155nfg; Fri, 21 Apr 2006 02:43:17 -0700 (PDT) Received: by 10.48.204.2 with HTTP; Fri, 21 Apr 2006 02:43:16 -0700 (PDT) Message-ID: <1013407b0604210243s2b3292dck5d89a42841cbf37@mail.gmail.com> Date: Fri, 21 Apr 2006 02:43:16 -0700 From: Puneet To: "Bob O'Hara (boohara)" Subject: Re: [Capwap] 802.11d / 802.11h support In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC016C71A7@xmb-sjc-237.amer.cisco.com> MIME-Version: 1.0 References: <17B8C6DE4E228348B4939BDA6B05A9DC016C71A7@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=3.1 tagged_above=-999.0 required=7.0 tests=HTML_40_50, HTML_MESSAGE, 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: , Content-Type: multipart/mixed; boundary="===============0406296359==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.9 (+) X-Scan-Signature: 1a2f5df4c6f30e0d5df43748fb095119 --===============0406296359== Content-Type: multipart/alternative; boundary="----=_Part_43973_13029011.1145612596942" ------=_Part_43973_13029011.1145612596942 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline For the channel move the WTP can probably handle things on its own (detect radar, hop to a new channel and inform the AC before and after it changes channels), but 802.11h also requires "testing channel for radar before usin= g it". Given a channel and power level from an AC, how does the WTP decide if it needs to carry out a test or not? >From what I understand the DFS/TPC requirements (& consequently the need to test channels before use) change both per-band as well as with time in different regulatory domains. Would the WTP have to track all those regulatory requirements on its own? If so, how is this information updated? I would think it would be updated by the AC, either by downloading a new image to the WTP, or as part of configuration, again bringing the AC into this... thanks, Puneet On 4/20/06, Bob O'Hara (boohara) wrote: > > On the issue of radar detection, the proposal to have the WTP inform the > AC, then have the AC make the decision about channel change will probably > run into either regulatory problems or cost of certification problems, or > both. Because radar detection is a regulatory issue, it must be tested t= o > certify a device to operate in a band requiring radar avoidance. If the = WTP > defers to the AC for some part of the radar avoidance operation, > certification will require that both the WTP and AC be certified as a > system. > > Given that the goal of CAPWAP is to promote multi-vendor interoperability > between WTP and AC, system certification to meet radar avoidance regulato= ry > requirements will result in one or more of the following outcomes: > 1. WTPs will have to maintain a list of ACs for which they are certified > to operate and meet radar avoidance requirements. > 2. WTPs will have to be certified with every AC. > 3. WTP certification will be extraordinarily costly. > 4. Multi-vendor interoperability will be impaired. > > I would recommend that the WTP, alone make the decision, then inform the > AC when it has changed channels. > > -Bob > > > > ------------------------------ > *From:* Puneet [mailto:pb.ietf@gmail.com] > *Sent:* Thursday, April 20, 2006 10:17 AM > *To:* Partha Narasimhan > *Cc:* capwap@frascone.com > *Subject:* Re: [Capwap] 802.11d / 802.11h support > > Partha, > > for #1 I agree with you, we should just use the 802.11 IE (802.11d). That > IE is what will finally go out in the beacons/probe-responses. No need fo= r > the WTP to have to translate and construct that IE. > > for #2 it might be simpler if the WTP reports radar to the AC, and the AC > makes the decision about what channel to jump to. As David also mentions, > the channel to move to might be determined by policy or by some > channel-selection logic on the AC which takes into account neighbouring > channels etc. A 'future' channel can either be provided to the WTP at > configuration time (if the timing constraints seem so tight), or as soon = as > it reports radar. > > Thanks, > Puneet > > On 4/18/06, Partha Narasimhan wrote: > > > > For #1, why dont we use the IEs as defined by IEEE 802.11? Why do we > > need > > to re-define something that is already defined in 802.11? This is > > probably > > true for the 11d, RSN, WPA, WMM, 11e IEs, and anything else that has a > > corresponding 802.11 definition. There is code that exists to parse > > 802.11 > > IEs elsewhere in the WTP, so we get code reuse too. :-) > > > > For #2, my vote would be for the WTP to switch channels on detecting > > radar > > and notify the AC of the radar detect and the resulting channel change > > events. This keeps it simple and WTPs have the ability to detect radar > > already. > > > > Thanks > > partha > > > > On Tue, 18 Apr 2006, Dorothy Stanley wrote: > > > > > Hi Puneet, > > > > > > This is assigned to a new issue, 104. > > > > > > All- comments, discussion please. > > > > > > Thanks, > > > > > > Dorothy Stanley > > > > > > > > > On 4/14/06, Puneet < pb.ietf@gmail.com> wrote: > > > > > > 1. Section 11.9.3 'IEEE 802.11 Multi-domain Capability': The > > length of this element is fixed at 8 bytes, but if there are multiple, > > disjoint bands that are supported in the regulatory domain does the AC = use > > multiple such elements? It might be cleaner to make the length of this > > element variable, and allow multiple triplets > > > the Country-Information element in 802.11d) > > > > > > 2. How does CAPWAP plan to support 802.11h? Does the WTP handle > > everything on its own or is the channel switching etc controlled by the= AC? > > In either case there might be a need for message elements with which th= e WTP > > to report the detection of radar to the AC. > > > > > > 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 > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_43973_13029011.1145612596942 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline For the channel move the WTP can probably handle things on its own (detect radar, hop to a new channel and inform the AC before and after it changes channels), but 802.11h also requires "testing channel for radar before using it". Given a channel and power level from an AC, ho= w does the WTP decide if it needs to carry out a test or not?

>From what I understand the DFS/TPC requirements (& consequently the need to test channels before use) change both per-band as well as with time in different regulatory domains. Would the WTP have to track all those regulatory requirements on its own? If so, how is this information updated? I would think it would be updated by the AC, either by downloading a new image to the WTP, or as part of configuration, again bringing the AC into this...

thanks,
Puneet

On 4/20/06, Bob O'Hara (boohara) <boohara@cisco.com> wrote:
On the issue of radar detection, the proposal to have=20 the WTP inform the AC, then have the AC make the decision about channel cha= nge=20 will probably run into either regulatory problems or cost of certification= =20 problems, or both.  Because radar detection is a regulatory issue, it = must=20 be tested to certify a device to operate in a band requiring radar=20 avoidance.  If the WTP defers to the AC for some part of the radar=20 avoidance operation, certification will require that both the WTP and AC be= =20 certified as a system.
 
Given that the goal of CAPWAP is to promote=20 multi-vendor interoperability between WTP and AC, system certification to m= eet=20 radar avoidance regulatory requirements will result in one or more of the= =20 following outcomes:
1. WTPs will have to maintain a list of ACs for which=20 they are certified to operate and meet radar avoidance=20 requirements.
2. WTPs will have to be certified with every=20 AC.
3. WTP certification will be extraordinarily=20 costly.
4. Multi-vendor interoperability will be=20 impaired.
 
I=20 would recommend that the WTP, alone make the decision, then inform the AC w= hen=20 it has changed channels.

 -Bob
 

 

From: Puneet [mailto:pb.ietf@gmail.com]=20
Sent: Thursday, April 20, 2006 10:17 AM
To: Partha=20 Narasimhan
Cc: capwap@fras= cone.com
Subject: Re: [Capwap]=20 802.11d / 802.11h support

Partha,

for #1 I agree with you, we should just use the 8= 02.11=20 IE (802.11d). That IE is what will finally go out in the=20 beacons/probe-responses. No need for the WTP to have to translate and const= ruct=20 that IE.

for #2 it might be simpler if the WTP reports radar to the = AC,=20 and the AC makes the decision about what channel to jump to. As David also= =20 mentions, the channel to move to might be determined by policy or by some= =20 channel-selection logic on the AC which takes into account neighbouring cha= nnels=20 etc. A 'future' channel can either be provided to the WTP at configuration = time=20 (if the timing constraints seem so tight), or as soon as it reports radar.= =20

Thanks,
Puneet

On 4/18/06, = Partha=20 Narasimhan <partha@aruba= networks.com>=20 wrote:
For=20 #1, why dont we use the IEs as defined by IEEE 802.11? Why do we need
= to=20 re-define something that is already defined in 802.11? This is=20 probably
true for the 11d, RSN, WPA, WMM, 11e IEs, and anything else t= hat=20 has a
corresponding 802.11 definition. There is code that exists to p= arse=20 802.11
IEs elsewhere in the WTP, so we get code reuse too. :-)

= For=20 #2, my vote would be for the WTP to switch channels on detecting radarand=20 notify the AC of the radar detect and the resulting channel change
eve= nts.=20 This keeps it simple and WTPs have the ability to detect=20 radar
already.

Thanks
partha

On Tue, 18 Apr 2006, Dor= othy=20 Stanley wrote:

> Hi Puneet,
>
> This is assigned t= o a=20 new issue, 104.
>
> All- comments, discussion=20 please.
>
> Thanks,
>
> Dorothy=20 Stanley
>
>
> On 4/14/06, Puneet < pb.ietf@gmail.com>=20 wrote:
>
>       1. Section 11.= 9.3=20 'IEEE 802.11 Multi-domain Capability': The length of this element is fixe= d at=20 8 bytes, but if there are multiple, disjoint bands that are supported in = the=20 regulatory domain does the AC use multiple such elements? It might be cle= aner=20 to make the length of this element variable, and allow multiple triplets= =20 <first_channel,num_channel,max_power) to be added one after the other.= =20 (like the Country-Information element in=20 802.11d)
>
>       2. How does= =20 CAPWAP plan to support 802.11h? Does the WTP handle everything on its own= or=20 is the channel switching etc controlled by the AC? In either case there m= ight=20 be a need for message elements with which the WTP to report the detection= of=20 radar to the AC.
>
>      =20 Thanks,
>      =20 Puneet.
>
>
>      =20 _________________________________________________________________
>=       =20 To unsubscribe or modify your subscription options, please visit:=20
>       http://lists.frascone.com/mailman/listinf= o/capwap=20 <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.co= m/pipermail/capwap


------=_Part_43973_13029011.1145612596942-- --===============0406296359== 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 --===============0406296359==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 21 10:11:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWwLo-0001nO-FL for capwap-archive@lists.ietf.org; Fri, 21 Apr 2006 10:11: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 1FWvQY-0006I3-NV for capwap-archive@lists.ietf.org; Fri, 21 Apr 2006 09:12:02 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FWv7p-0007lB-QK for capwap-archive@lists.ietf.org; Fri, 21 Apr 2006 08:52:47 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8D2EA430102 for ; Fri, 21 Apr 2006 05:52:40 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 59EF0430059 for ; Fri, 21 Apr 2006 05:52:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3984443137C for ; Fri, 21 Apr 2006 05:52:16 -0700 (PDT) Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [204.127.192.84]) by hermes.tigertech.net (Postfix) with ESMTP id 684F84313A8 for ; Fri, 21 Apr 2006 05:52:14 -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 <20060421125213m1400837rje>; Fri, 21 Apr 2006 12:52:13 +0000 Message-ID: <4448D57C.8080904@hyperthought.com> Date: Fri, 21 Apr 2006 05:52:12 -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 Subject: Re: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages References: <5F09D220B62F79418461A978CA0921BDD51FAD@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BDD51FAD@pslexc01.psl.local> 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: -2.6 (--) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 21 13:55:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWzqY-0003w3-SN for capwap-archive@lists.ietf.org; Fri, 21 Apr 2006 13:55:10 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWzqU-0006Uj-T4 for capwap-archive@lists.ietf.org; Fri, 21 Apr 2006 13:55:10 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D68934300F4 for ; Fri, 21 Apr 2006 10:55:01 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1090243005F for ; Fri, 21 Apr 2006 10:54:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id F2EB2398039 for ; Fri, 21 Apr 2006 10:54:20 -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 8EFC339803B for ; Fri, 21 Apr 2006 10:54:18 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 21 Apr 2006 10:54:19 -0700 X-IronPort-AV: i="4.04,146,1144047600"; d="scan'208,217"; a="424839016:sNHT97472900" 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 k3LHsGh2022666 for ; Fri, 21 Apr 2006 10:54:18 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Apr 2006 10:54:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] 802.11d / 802.11h support Date: Fri, 21 Apr 2006 10:54:16 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC016C7541@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] 802.11d / 802.11h support Thread-Index: AcZlKAdvmuR213m1Qh27mYS8/rNpVgARFtXw From: "Bob O'Hara (boohara)" To: X-OriginalArrivalTime: 21 Apr 2006 17:54:16.0138 (UTC) FILETIME=[9B33E2A0:01C6656C] 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: 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="===============0407258979==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 6e8a3b85ef670172081194f0b0f68e6f This is a multi-part message in MIME format. --===============0407258979== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6656C.9AF08260" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6656C.9AF08260 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Puneet, =20 As you point out, the regulatory requirements change with the band of operation and with time. Whatever we build into the protocol, the WTP and its vendor will always be responsible to behave properly, according to the regulations currently in force. -Bob =20 =20 ________________________________ From: Puneet [mailto:pb.ietf@gmail.com]=20 Sent: Friday, April 21, 2006 2:43 AM To: Bob O'Hara (boohara) Cc: capwap@frascone.com Subject: Re: [Capwap] 802.11d / 802.11h support For the channel move the WTP can probably handle things on its own (detect radar, hop to a new channel and inform the AC before and after it changes channels), but 802.11h also requires "testing channel for radar before using it". Given a channel and power level from an AC, how does the WTP decide if it needs to carry out a test or not? >From what I understand the DFS/TPC requirements (& consequently the need to test channels before use) change both per-band as well as with time in different regulatory domains. Would the WTP have to track all those regulatory requirements on its own? If so, how is this information updated? I would think it would be updated by the AC, either by downloading a new image to the WTP, or as part of configuration, again bringing the AC into this... thanks, Puneet On 4/20/06, Bob O'Hara (boohara) wrote:=20 On the issue of radar detection, the proposal to have the WTP inform the AC, then have the AC make the decision about channel change will probably run into either regulatory problems or cost of certification problems, or both. Because radar detection is a regulatory issue, it must be tested to certify a device to operate in a band requiring radar avoidance. If the WTP defers to the AC for some part of the radar avoidance operation, certification will require that both the WTP and AC be certified as a system. =20 Given that the goal of CAPWAP is to promote multi-vendor interoperability between WTP and AC, system certification to meet radar avoidance regulatory requirements will result in one or more of the following outcomes: 1. WTPs will have to maintain a list of ACs for which they are certified to operate and meet radar avoidance requirements. 2. WTPs will have to be certified with every AC. 3. WTP certification will be extraordinarily costly. 4. Multi-vendor interoperability will be impaired. =20 I would recommend that the WTP, alone make the decision, then inform the AC when it has changed channels. -Bob =20 =20 ________________________________ From: Puneet [mailto:pb.ietf@gmail.com]=20 Sent: Thursday, April 20, 2006 10:17 AM To: Partha Narasimhan Cc: capwap@frascone.com Subject: Re: [Capwap] 802.11d / 802.11h support =09 =09 =09 Partha, =09 for #1 I agree with you, we should just use the 802.11 IE (802.11d). That IE is what will finally go out in the beacons/probe-responses. No need for the WTP to have to translate and construct that IE. =09 for #2 it might be simpler if the WTP reports radar to the AC, and the AC makes the decision about what channel to jump to. As David also mentions, the channel to move to might be determined by policy or by some channel-selection logic on the AC which takes into account neighbouring channels etc. A 'future' channel can either be provided to the WTP at configuration time (if the timing constraints seem so tight), or as soon as it reports radar.=20 =09 Thanks, Puneet =09 =09 On 4/18/06, Partha Narasimhan wrote:=20 For #1, why dont we use the IEs as defined by IEEE 802.11? Why do we need to re-define something that is already defined in 802.11? This is probably true for the 11d, RSN, WPA, WMM, 11e IEs, and anything else that has a=20 corresponding 802.11 definition. There is code that exists to parse 802.11 IEs elsewhere in the WTP, so we get code reuse too. :-) =09 For #2, my vote would be for the WTP to switch channels on detecting radar and notify the AC of the radar detect and the resulting channel change events. This keeps it simple and WTPs have the ability to detect radar already. =09 Thanks partha =09 On Tue, 18 Apr 2006, Dorothy Stanley wrote:=20 =09 > Hi Puneet, > > This is assigned to a new issue, 104. > > All- comments, discussion please. > > Thanks, > > Dorothy Stanley > > > On 4/14/06, Puneet < pb.ietf@gmail.com> wrote: > > 1. Section 11.9.3 'IEEE 802.11 Multi-domain Capability': The length of this element is fixed at 8 bytes, but if there are multiple, disjoint bands that are supported in the regulatory domain does the AC use multiple such elements? It might be cleaner to make the length of this element variable, and allow multiple triplets > 2. How does CAPWAP plan to support 802.11h? Does the WTP handle everything on its own or is the channel switching etc controlled by the AC? In either case there might be a need for message elements with which the WTP to report the detection of radar to the AC.=20 > > Thanks, > Puneet. > > > _________________________________________________________________ > 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 > > > > =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 ------_=_NextPart_001_01C6656C.9AF08260 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Puneet,
 
As you=20 point out, the regulatory requirements change with the band of operation = and=20 with time.  Whatever we build into the protocol, the WTP and its = vendor=20 will always be responsible to behave properly, according to the = regulations=20 currently in force.

 -Bob
 

 

From: Puneet = [mailto:pb.ietf@gmail.com]=20
Sent: Friday, April 21, 2006 2:43 AM
To: Bob O'Hara = (boohara)
Cc: capwap@frascone.com
Subject: Re: = [Capwap]=20 802.11d / 802.11h support

For the channel move the WTP can probably handle things on = its own=20 (detect radar, hop to a new channel and inform the AC before and after = it=20 changes channels), but 802.11h also requires "testing channel for radar = before=20 using it". Given a channel and power level from an AC, how does the WTP = decide=20 if it needs to carry out a test or not?

From what I understand = the=20 DFS/TPC requirements (& consequently the need to test channels = before use)=20 change both per-band as well as with time in different regulatory = domains. Would=20 the WTP have to track all those regulatory requirements on its own? If = so, how=20 is this information updated? I would think it would be updated by the = AC, either=20 by downloading a new image to the WTP, or as part of configuration, = again=20 bringing the AC into this...

thanks,
Puneet

On 4/20/06, Bob O'Hara=20 (boohara) <boohara@cisco.com>=20 wrote:
On the=20 issue of radar detection, the proposal to have the WTP inform the AC, = then=20 have the AC make the decision about channel change will probably run = into=20 either regulatory problems or cost of certification problems, or = both. =20 Because radar detection is a regulatory issue, it must be tested to = certify a=20 device to operate in a band requiring radar avoidance.  If the = WTP defers=20 to the AC for some part of the radar avoidance operation, = certification will=20 require that both the WTP and AC be certified as a = system.
 
Given that=20 the goal of CAPWAP is to promote multi-vendor interoperability between = WTP and=20 AC, system certification to meet radar avoidance regulatory = requirements will=20 result in one or more of the following outcomes:
1. WTPs=20 will have to maintain a list of ACs for which they are certified to = operate=20 and meet radar avoidance requirements.
2. WTPs=20 will have to be certified with every AC.
3. WTP=20 certification will be extraordinarily costly.
4.=20 Multi-vendor interoperability will be impaired.
 
I would = recommend that the=20 WTP, alone make the decision, then inform the AC when it has changed=20 channels.

 -Bob
 

 

From: Puneet [mailto:pb.ietf@gmail.com]=20
Sent: Thursday, April 20, 2006 10:17 AM
To: = Partha=20 Narasimhan
Cc: capwap@frascone.com
Subject: Re: = [Capwap] 802.11d=20 / 802.11h support

Partha,

for #1 I agree with you, we should just use = the=20 802.11 IE (802.11d). That IE is what will finally go out in the=20 beacons/probe-responses. No need for the WTP to have to translate and=20 construct that IE.

for #2 it might be simpler if the WTP = reports radar=20 to the AC, and the AC makes the decision about what channel to jump = to. As=20 David also mentions, the channel to move to might be determined by = policy or=20 by some channel-selection logic on the AC which takes into account=20 neighbouring channels etc. A 'future' channel can either be provided = to the=20 WTP at configuration time (if the timing constraints seem so tight), = or as=20 soon as it reports radar.

Thanks,
Puneet

On 4/18/06, Partha=20 Narasimhan <partha@arubanetworks.com> wrote:=20
For=20 #1, why dont we use the IEs as defined by IEEE 802.11? Why do we = need
to=20 re-define something that is already defined in 802.11? This is=20 probably
true for the 11d, RSN, WPA, WMM, 11e IEs, and anything = else that=20 has a
corresponding 802.11 definition. There is code that exists = to=20 parse 802.11
IEs elsewhere in the WTP, so we get code reuse too.=20 :-)

For #2, my vote would be for the WTP to switch channels = on=20 detecting radar
and notify the AC of the radar detect and the = resulting=20 channel change
events. This keeps it simple and WTPs have the = ability to=20 detect radar
already.

Thanks
partha

On Tue, 18 = Apr 2006,=20 Dorothy Stanley wrote:

> Hi Puneet,
>
> This = is=20 assigned to a new issue, 104.
>
> All- comments, = discussion=20 please.
>
> Thanks,
>
> Dorothy=20 Stanley
>
>
> On 4/14/06, Puneet < pb.ietf@gmail.com>=20 wrote:
>
>       1. = Section 11.9.3=20 'IEEE 802.11 Multi-domain Capability': The length of this element is = fixed=20 at 8 bytes, but if there are multiple, disjoint bands that are = supported in=20 the regulatory domain does the AC use multiple such elements? It = might be=20 cleaner to make the length of this element variable, and allow = multiple=20 triplets <first_channel,num_channel,max_power) to be added one = after the=20 other. (like the Country-Information element in=20 802.11d)
>
>       2. How = does=20 CAPWAP plan to support 802.11h? Does the WTP handle everything on = its own or=20 is the channel switching etc controlled by the AC? In either case = there=20 might be a need for message elements with which the WTP to report = the=20 detection of radar to the AC.=20
>
>      =20 Thanks,
>      =20 Puneet.
>
>
>      =20 = _________________________________________________________________
>=       =20 To unsubscribe or modify your subscription options, please visit:=20
>       http://lists.frascone.com/mailman/listinfo/capwap = <http://lists.frascone.com/mailman/listinfo/capwap=20 >
>
>       = Archives: http://lists.frascone.com/pipermail/capwap
>=20 =
>
>
>
>

<= BR>_________________________________________________________________
T= o=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20


------_=_NextPart_001_01C6656C.9AF08260-- --===============0407258979== 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 --===============0407258979==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 21 17:32:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX3Ek-0006eP-LS for capwap-archive@lists.ietf.org; Fri, 21 Apr 2006 17:32:22 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX3Ei-0000I4-2T for capwap-archive@lists.ietf.org; Fri, 21 Apr 2006 17:32:22 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 20985430094 for ; Fri, 21 Apr 2006 14:32:17 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 33DAE43005F for ; Fri, 21 Apr 2006 14:31:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2649C39804B for ; Fri, 21 Apr 2006 14:31:57 -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 A7EDD39803B for ; Fri, 21 Apr 2006 14:31:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=eFScLjMZ7keBktaox148sYtDQ52zyudDyEGI/pfFF14JyByA4BqLwIEM4FvgwZKD; 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.32] (helo=elwamui-cypress.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FX3ED-0004Ou-Uh for capwap@frascone.com; Fri, 21 Apr 2006 17:31:49 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Fri, 21 Apr 2006 17:31:49 -0400 Message-ID: <5796555.1145655109891.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Date: Fri, 21 Apr 2006 17:31:49 -0400 (EDT) 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: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff71075e739b6850365f1cc8ae0bff89c8111350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.32 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [Capwap] WTP statistics reports 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: ff03b0075c3fc728d7d60a15b4ee1ad2 We've been discussing what statistics the WTP should provide to the AC, and I promised to follow up after talking with folks I work with. Sorry it took me longer than expected - here's what we've come up with so far. There are 802.11 (binding-specific) stats, and these should probably be segregated from general stats which apply regardless of radio type. However, I do think it's appropriate to assume that there will always be radios, regardless of the binding type. With that in mind, here's a list of stats the AC might want to collect, with suggested values in some cases: WTP Stats: --------- - # reboots (total) - # AC initiated reboots - # reboots due to link failure - # reboots due to SW failure - # reboots due to HW failure - # reboots due to other reasons - # reboots due to unknown reasons - last reboot cause (suggested values below) *0 - not supported *1 - AC initiated *2 - link failure *3 - SW failure *4 - HW failure *5 - Other *all 0xfffs - unknown (note: "not supported" could collapse into "unknown ") - uptime (how long has WTP been running) -------------- Radio stats: -------------- - # resets - # resets caused by SW failure - # resets caused by HW failure - # resets caused by other reasons - # resets caused by unknown reasons - last reset cause (suggested values below) *0 - not supported *1 - SW failure *2 - HW failure *3 - Other *all 0xffs - Unknown (note: "not supported" could collapse into "unknown ") (these next 6 may be 802.11-specific) - # channel changes - # band changes - # radar detects - # radar channel changes - current noise floor - current 11g protection status (this one seems to generally apply to radios) - # config updates --------------------------------------------------------- WLAN stats (is wlan an 802.11-specific concept?) --------------------------------------------------------- TX stats: -------- - current max tx power - available tx buffers - # frames received for transmission over this WLAN - # data frames received - # mgmt frames received - # multicast received - # frames successfully transmitted - # data frames transmitted - # mgmt frames transmitted - # rts sent - # cts sent - # beacons transmitted - # probe responses transmitted - # multicast transmitted - # frames dropped - # frames dropped due to excessive retries - # frames dropped due to buffer unavailability - # frames dropped due to listern interval timeouts - # multicast frames dropped - # data frames dropped - # mgmt frames dropped - # retries - # multiple retries - # fragments RX stats: -------- - rssi of the most recent frame - # frames received - # good frames received - # multicast received - # data frames received - # mgmt frames received - # probe requests received - # rts received - # cts received - # ps-poll received - # bad frames received - # CRC errors - # PHY errors - # decryption errors - # unknown errors - # duplicate frames - # fragments ----------------------------------------------------------------------- In addition to reporting these, there must be an ability to reset counters, and it might be desirable to set different reporting intervals for different types of stats. For example, there's not much point in reporting reboot statistics every 5 minutes (if the WTP is worth anything). Once those've been reported once, it may not make sense to report them again unless there's a reboot. We probably also need some concept of a 'last-reset' time or reference time to denote when stats collection started (sort of like stats-uptime). Anyway, this is a start.... Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Apr 23 13:58:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXir3-0007bV-OZ for capwap-archive@lists.ietf.org; Sun, 23 Apr 2006 13:58:41 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXir2-00011J-9v for capwap-archive@lists.ietf.org; Sun, 23 Apr 2006 13:58:41 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 235274300DB for ; Sun, 23 Apr 2006 10:58:39 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 679AD4300B2 for ; Sun, 23 Apr 2006 10:58:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 37077431548 for ; Sun, 23 Apr 2006 10:58:12 -0700 (PDT) X-Greylist-Status: Sender first seen 00:10:37 ago Received: from co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by hermes.tigertech.net (Postfix) with ESMTP id 7FCAD431542 for ; Sun, 23 Apr 2006 10:58:09 -0700 (PDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3NHj7Ju003012 for ; Sun, 23 Apr 2006 13:45:08 -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 Subject: RE: [Capwap] WTP statistics reports Date: Sun, 23 Apr 2006 20:47:29 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] WTP statistics reports Thread-Index: AcZlixB4mECK+UA9T9K93bCYL61oIABcsEWA From: "Romascanu, Dan (Dan)" To: "Scott G. Kelly" , "capwap" X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: 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: 225414c974e0d6437992164e91287a51 How many of these statistics are capwap specific?=20 Dan =20 =20 > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com]=20 > Sent: Saturday, April 22, 2006 12:32 AM > To: capwap > Subject: [Capwap] WTP statistics reports >=20 > We've been discussing what statistics the WTP should provide=20 > to the AC, and I promised to follow up after talking with=20 > folks I work with. Sorry it took me longer than expected -=20 > here's what we've come up with so far. >=20 > There are 802.11 (binding-specific) stats, and these should=20 > probably be segregated from general stats which apply=20 > regardless of radio type. However, I do think it's=20 > appropriate to assume that there will always be radios,=20 > regardless of the binding type. With that in mind, here's a=20 > list of stats the AC might want to collect, with suggested=20 > values in some cases: >=20 > WTP Stats: > --------- > - # reboots (total) > - # AC initiated reboots > - # reboots due to link failure > - # reboots due to SW failure > - # reboots due to HW failure > - # reboots due to other reasons > - # reboots due to unknown reasons >=20 > - last reboot cause (suggested values below) > *0 - not supported > *1 - AC initiated > *2 - link failure > *3 - SW failure > *4 - HW failure > *5 - Other > *all 0xfffs - unknown >=20 > (note: "not supported" could collapse into "unknown ") >=20 > - uptime (how long has WTP been running) >=20 > -------------- > Radio stats: > -------------- >=20 > - # resets > - # resets caused by SW failure > - # resets caused by HW failure > - # resets caused by other reasons > - # resets caused by unknown reasons >=20 > - last reset cause (suggested values below) > *0 - not supported > *1 - SW failure > *2 - HW failure > *3 - Other > *all 0xffs - Unknown >=20 > (note: "not supported" could collapse into "unknown ") >=20 > (these next 6 may be 802.11-specific) > - # channel changes > - # band changes > - # radar detects > - # radar channel changes > - current noise floor > - current 11g protection status >=20 > (this one seems to generally apply to radios) > - # config updates >=20 > --------------------------------------------------------- > WLAN stats (is wlan an 802.11-specific concept?) > --------------------------------------------------------- >=20 > TX stats: > -------- > - current max tx power > - available tx buffers > - # frames received for transmission over this WLAN > - # data frames received > - # mgmt frames received > - # multicast received > - # frames successfully transmitted > - # data frames transmitted > - # mgmt frames transmitted > - # rts sent > - # cts sent > - # beacons transmitted > - # probe responses transmitted > - # multicast transmitted > - # frames dropped > - # frames dropped due to excessive retries > - # frames dropped due to buffer unavailability > - # frames dropped due to listern interval timeouts > - # multicast frames dropped > - # data frames dropped > - # mgmt frames dropped > - # retries > - # multiple retries > - # fragments >=20 > RX stats: > -------- > - rssi of the most recent frame > - # frames received > - # good frames received > - # multicast received > - # data frames received > - # mgmt frames received > - # probe requests received > - # rts received > - # cts received > - # ps-poll received > - # bad frames received > - # CRC errors > - # PHY errors > - # decryption errors > - # unknown errors > - # duplicate frames > - # fragments >=20 > -------------------------------------------------------------- > --------- >=20 > In addition to reporting these, there must be an ability to=20 > reset counters, and it might be desirable to set different=20 > reporting intervals for different types of stats. For=20 > example, there's not much point in reporting reboot=20 > statistics every 5 minutes (if the WTP is worth anything).=20 > Once those've been reported once, it may not make sense to=20 > report them again unless there's a reboot. >=20 > We probably also need some concept of a 'last-reset' time or=20 > reference time to denote when stats collection started (sort=20 > of like stats-uptime). >=20 > Anyway, this is a start.... >=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 Sun Apr 23 14:00:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXit6-0007dC-0b for capwap-archive@lists.ietf.org; Sun, 23 Apr 2006 14:00:48 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXit5-00015v-GG for capwap-archive@lists.ietf.org; Sun, 23 Apr 2006 14:00:47 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 266534300CF for ; Sun, 23 Apr 2006 11:00:47 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id CDCE74300B2 for ; Sun, 23 Apr 2006 11:00:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BCAA6431542 for ; Sun, 23 Apr 2006 11:00:16 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.192.81]) by hermes.tigertech.net (Postfix) with ESMTP id 0137543154F for ; Sun, 23 Apr 2006 11:00:14 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (rwcrmhc11) with ESMTP id <20060423180014m11005doh7e>; Sun, 23 Apr 2006 18:00:14 +0000 Message-ID: <444BC0AD.4020208@hyperthought.com> Date: Sun, 23 Apr 2006 11:00:13 -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: "Romascanu, Dan (Dan)" Subject: Re: [Capwap] WTP statistics reports References: In-Reply-To: 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: 995b2e24d23b953c94bac5288c432399 Hi Dan, Romascanu, Dan (Dan) wrote: > How many of these statistics are capwap specific? > > Dan I'm not sure I understand the question, so before attempting an answer, I'll ask for some clarification. Do you mean how many of these are not 802.11-specific (binding-specific)? In general, I think any that are not 802.11-specific fall generally under capwap, but I agree that we need to clearly delineate. I think of any stats that would be present regardless of radio type to be capwap-specific. I think we can sort that out easily enough, but I want to make sure that's what you mean before attempting anything further. Scott >>-----Original Message----- >>From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >>Sent: Saturday, April 22, 2006 12:32 AM >>To: capwap >>Subject: [Capwap] WTP statistics reports >> >>We've been discussing what statistics the WTP should provide >>to the AC, and I promised to follow up after talking with >>folks I work with. Sorry it took me longer than expected - >>here's what we've come up with so far. >> >>There are 802.11 (binding-specific) stats, and these should >>probably be segregated from general stats which apply >>regardless of radio type. However, I do think it's >>appropriate to assume that there will always be radios, >>regardless of the binding type. With that in mind, here's a >>list of stats the AC might want to collect, with suggested >>values in some cases: >> >>WTP Stats: >>--------- >>- # reboots (total) >> - # AC initiated reboots >> - # reboots due to link failure >> - # reboots due to SW failure >> - # reboots due to HW failure >> - # reboots due to other reasons >> - # reboots due to unknown reasons >> >>- last reboot cause (suggested values below) >> *0 - not supported >> *1 - AC initiated >> *2 - link failure >> *3 - SW failure >> *4 - HW failure >> *5 - Other >> *all 0xfffs - unknown >> >>(note: "not supported" could collapse into "unknown ") >> >>- uptime (how long has WTP been running) >> >>-------------- >>Radio stats: >>-------------- >> >>- # resets >> - # resets caused by SW failure >> - # resets caused by HW failure >> - # resets caused by other reasons >> - # resets caused by unknown reasons >> >>- last reset cause (suggested values below) >> *0 - not supported >> *1 - SW failure >> *2 - HW failure >> *3 - Other >> *all 0xffs - Unknown >> >>(note: "not supported" could collapse into "unknown ") >> >>(these next 6 may be 802.11-specific) >>- # channel changes >>- # band changes >>- # radar detects >>- # radar channel changes >>- current noise floor >>- current 11g protection status >> >>(this one seems to generally apply to radios) >>- # config updates >> >>--------------------------------------------------------- >>WLAN stats (is wlan an 802.11-specific concept?) >>--------------------------------------------------------- >> >>TX stats: >>-------- >>- current max tx power >>- available tx buffers >>- # frames received for transmission over this WLAN >>- # data frames received >>- # mgmt frames received >>- # multicast received >>- # frames successfully transmitted >> - # data frames transmitted >> - # mgmt frames transmitted >>- # rts sent >>- # cts sent >>- # beacons transmitted >>- # probe responses transmitted >>- # multicast transmitted >>- # frames dropped >> - # frames dropped due to excessive retries >> - # frames dropped due to buffer unavailability >> - # frames dropped due to listern interval timeouts >> - # multicast frames dropped >> - # data frames dropped >> - # mgmt frames dropped >>- # retries >>- # multiple retries >>- # fragments >> >>RX stats: >>-------- >>- rssi of the most recent frame >>- # frames received >>- # good frames received >>- # multicast received >>- # data frames received >>- # mgmt frames received >>- # probe requests received >>- # rts received >>- # cts received >>- # ps-poll received >>- # bad frames received >>- # CRC errors >>- # PHY errors >>- # decryption errors >>- # unknown errors >>- # duplicate frames >>- # fragments >> >>-------------------------------------------------------------- >>--------- >> >>In addition to reporting these, there must be an ability to >>reset counters, and it might be desirable to set different >>reporting intervals for different types of stats. For >>example, there's not much point in reporting reboot >>statistics every 5 minutes (if the WTP is worth anything). >>Once those've been reported once, it may not make sense to >>report them again unless there's a reboot. >> >>We probably also need some concept of a 'last-reset' time or >>reference time to denote when stats collection started (sort >>of like stats-uptime). >> >>Anyway, this is a start.... >> >>Scott >> >>_________________________________________________________________ >>To unsubscribe or modify your subscription options, please visit: >>http://lists.frascone.com/mailman/listinfo/capwap >> >>Archives: http://lists.frascone.com/pipermail/capwap >> > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Apr 23 14:22:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXjEE-0008Eh-4s for capwap-archive@lists.ietf.org; Sun, 23 Apr 2006 14:22:38 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXjEC-0001oK-OY for capwap-archive@lists.ietf.org; Sun, 23 Apr 2006 14:22:38 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 68B864300FB for ; Sun, 23 Apr 2006 11:22:36 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id E2502430054 for ; Sun, 23 Apr 2006 11:22:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B328943157E for ; Sun, 23 Apr 2006 11:22:14 -0700 (PDT) X-Greylist-Status: Sender first seen 00:11:26 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 F3E5043158C for ; Sun, 23 Apr 2006 11:22:12 -0700 (PDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3NI7ZSu006479 for ; Sun, 23 Apr 2006 14:07:35 -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 Subject: RE: [Capwap] WTP statistics reports Date: Sun, 23 Apr 2006 21:10:44 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] WTP statistics reports Thread-Index: AcZm/8cVCIXQSSxpT0mdsLu9IUZF6AAAQpSw From: "Romascanu, Dan (Dan)" To: "Scott G Kelly" X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap 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 =20 =20 > -----Original Message----- > From: Scott G Kelly [mailto:scott@hyperthought.com]=20 > Sent: Sunday, April 23, 2006 9:00 PM > To: Romascanu, Dan (Dan) > Cc: capwap > Subject: Re: [Capwap] WTP statistics reports >=20 > Hi Dan, >=20 > Romascanu, Dan (Dan) wrote: > > How many of these statistics are capwap specific?=20 > >=20 > > Dan >=20 > I'm not sure I understand the question, so before attempting=20 > an answer, I'll ask for some clarification. Do you mean how=20 > many of these are not 802.11-specific (binding-specific)? >=20 > In general, I think any that are not 802.11-specific fall=20 > generally under capwap, but I agree that we need to clearly=20 > delineate. I think of any stats that would be present=20 > regardless of radio type to be capwap-specific. I think we=20 > can sort that out easily enough, but I want to make sure=20 > that's what you mean before attempting anything further. >=20 > Scott >=20 I believe that you actually understood quite well the intention of the question, it is important to determine imo how many of these stats belong to the capwap layer, and what re-use could be made of existing management objects already defined at other layers.=20 Dan _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Apr 25 16:23:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYU49-0006tS-Ft for capwap-archive@lists.ietf.org; Tue, 25 Apr 2006 16:23:21 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYU46-0005u6-Ll for capwap-archive@lists.ietf.org; Tue, 25 Apr 2006 16:23:21 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D90274300CF for ; Tue, 25 Apr 2006 13:23:17 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 306FA430064 for ; Tue, 25 Apr 2006 13:22:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1E4321448025 for ; Tue, 25 Apr 2006 13:22:45 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.203]) by hermes.tigertech.net (Postfix) with ESMTP id 1E3FE1448024 for ; Tue, 25 Apr 2006 13:22:42 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so838475wxd for ; Tue, 25 Apr 2006 13:22:42 -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=qL4CG4Ov2TlzVApoctxdxV0OTl2GIzdU/zCxfTJht1g9mTaP0sOc8cWlVNwpw51XINBk6vOpxo7rlA3Vcpeao7c+Z4AW6vNz9UaIbJVFnAgkOfXWhWM3N1Cv3qn8tIfNKDSeT1zaUG2PGm1x7Y9Jv+PuL+fNqpSL9RF4Fo+4q2s= Received: by 10.70.15.2 with SMTP id 2mr6153562wxo; Tue, 25 Apr 2006 13:22:42 -0700 (PDT) Received: by 10.70.6.16 with HTTP; Tue, 25 Apr 2006 13:22:42 -0700 (PDT) Message-ID: <5bfe7a820604251322i654a69cs57e87c9a2bc5dc55@mail.gmail.com> Date: Tue, 25 Apr 2006 13:22:42 -0700 From: "Dorothy Stanley" To: "David T. Perkins" Subject: Re: [Capwap] Proposed Resolution for Issue 58 - Need to rename Config Request and Config Update Request In-Reply-To: MIME-Version: 1.0 References: <5bfe7a820604101051s3c1b3060rd7761b985044f93f@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="===============1632585376==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad --===============1632585376== Content-Type: multipart/alternative; boundary="----=_Part_33978_31140188.1145996562175" ------=_Part_33978_31140188.1145996562175 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline David, Iissue, # 108 "Configuration Failure Processing" has been opened to track the issues that you have raised. There have been no objections to the proposed configuration message name changes, so I'll plan to incorporate those into -01. Thanks, Dorothy On 4/11/06, David T. Perkins wrote: > > HI, > > I believe that the current config model is broken due to the > following: > 1) Config changes can fail (even when they are "not suppose to"). > This may be due to > a) resource deletion > b) semantic constraints > c) hardware failures > d) software failures > e) lack of authorization > In the "configure request/response" (sections 7.2/7.3) , the > "response" message specifies configuration settings. As > described, there is no mechanism for the WTP to communicate > to the AC that some (or part) of the config sent by the AC > to WTP failed. Thus, I suggest that the response contain > no configuration. > 2) I'm not sure that all of the configuration info can fit > into one CAPWAP control message. However, a WTP needs to > be able to indicate to a AC the "classes" of config info > that it supports. SNMP uses the GETNEXT operation to > iterate through both all classes and instances of > management info (which includes config info). I suggest > for CAPWAP that a WTP specify in the "configure > request" the classes of configuration info and then > allow an AC to use one or more "Update config request" > messages to change the WTP config. > 3) When an AC changes the WTP config with an "Update config > request", the request can fail. The response message needs > to indicate which config message element(s) had an error > and what was the error. Currently, this is not the case. > (The error code in the result, as currently defined > makes no sense to me!) Also, I didn't see if a config > request was "all or nothing". That is, do the OK > config values get applied and the error one not, > or none get applied on any failure. > 4) There are a lot of stange (too me) and not well defined > config elements. I believe that all need to be reviewed, > but this is really a separate issue. > 5) A get config operation is needed that specifies at > least a class of configuration info, and possibly > additionally the instance of config info. (Again, > this is because not all config info will be able to > fit in a single CAPWAP message.) > 6) I've ignored what should be done when an WTP has > config info that is not supported by an AC, or > when an AC tries to modify config info (class or > specific values) that is not supported by the WTP. > (CAPWAP is suppose to support WTPs and ACs from > different vendors, and, thus, there can be no > "tight version synchonization" as found in current > products. > > On Mon, 10 Apr 2006, Dorothy Stanley wrote: > > All, > > > > Issue 58 currently has the following discussion in the issues list: > > > > > > > > Page 104, Section 11.8.1. The description for Config-Request > > > describes a message sent from the AC to the WTP. In Section > > > 7.2, the config request is sent from the AP to the WTP. I > > > would prefer the mechanism described in 11.8.1. > > > 40. > > > > There are two types of configuration messages, one that comes from > > the WTP to the AC, and is used for the WTP to update the AC with its > > config at boot time. The second allows the AC to push down a new > > config to the WTP, and this can occur at run time. The former is > > called the Configure Request, while the latter is called the > Configuration > > update Request. That said, I think we should come up with a different > > set of names to differentiate them better. > > > > > > In the Configure State, we currently have: > > Configure Request - WTP sends AC its boot-time config > > Configure Response - AC overrides the current WTP boot-time config > > > > In the Run state, we currently have > > Configure Update Request - AC sends WTP new config parameters > > Configure Update Response - WTP acknowledges the Configure Update > Request, > > includes result code > > IEEE 802.11 WLAN Config Request > > > > Recommended resolution: Accept, make the following changes: > > > > In the Configure State, rename to > > Configuration Status - WTP sends AC its boot-time config > > Configuration Status Response - AC overrides the current WTP boot-time > > config > > > > In the Run state, - keep > > Configure Update Request - AC sends WTP new config parameters > > Configure Update Response - WTP acknowledges the Configure Update > Request, > > includes result code, and in > > IEEE 802.11 WLAN Config Request, update the text in 11.8.1 to referenc= e > > usage after Configure Update Request > > > > Comments please. > > > > Thanks, > > > > Dorothy > > > Regards, > /david t. perkins > > > > ------=_Part_33978_31140188.1145996562175 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline David,

Iissue, # 108 "Configuration Failure Processing" has been opened = to track the
issues that you have raised.

There have been no objections to the proposed configuration message name ch= anges, so
I'll plan to incorporate those into -01.

Thanks,

Dorothy

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

I believe that the current config model is broken due to the
= following:
  1) Config changes can fail (even when they are &q= uot;not suppose to").
     This may be due to       a) resource deletion
       b) semantic constraints
 &= nbsp;     c) hardware failures
   &nb= sp;   d) software failures
      = ; e) lack of authorization
     In the "configu= re request/response" (sections 7.2/7.3) , the
   &nb= sp; "response" message specifies configuration settings. As
     described, there is no mechanism for the WTP t= o communicate
     to the AC that some (or part) of = the config sent by the AC
     to WTP failed. Thus, = I suggest that the response contain
     no configur= ation.
  2) I'm not sure that all of the configuration info can fit<= br>     into one CAPWAP control message. However, a WTP= needs to
     be able to indicate to a AC the "= ;classes" of config info
     that it supports.= SNMP uses the GETNEXT operation to
     iterate through both all classes and instances= of
     management info (which includes config info= ). I suggest
     for CAPWAP that a WTP specify in t= he "configure
     request" the classes of= configuration info and then
     allow an AC to use one or more "Update co= nfig request"
     messages to change the WTP c= onfig.
  3) When an AC changes the WTP config with an "Up= date config
     request", the request can fail= . The response message needs
     to indicate which config message element(s) ha= d an error
     and what was the error. Currently, t= his is not the case.
     (The error code in the res= ult, as currently defined
     makes no sense to me!= ) Also, I didn't see if a config
     request was "all or nothing". That i= s, do the OK
     config values get applied and the = error one not,
     or none get applied on any failu= re.
  4) There are a lot of stange (too me) and not well defin= ed
     config elements. I believe that all need to be= reviewed,
     but this is really a separate issue.=
  5) A get config operation is needed that specifies at
&n= bsp;    least a class of configuration info, and possibly
     additionally the instance of config info. (Aga= in,
     this is because not all config info will be= able to
     fit in a single CAPWAP message.)
&n= bsp; 6) I've ignored what should be done when an WTP has
 &nbs= p;   config info that is not supported by an AC, or
     when an AC tries to modify config info (class = or
     specific values) that is not supported by th= e WTP.
     (CAPWAP is suppose to support WTPs and A= Cs from
     different vendors, and, thus, there can= be no
     "tight version synchonization" as fo= und in current
     products.

On Mon, 10 Apr = 2006, Dorothy Stanley wrote:
> All,
>
> Issue 58 currentl= y has the following discussion in the issues list:
>
> >
> > Page 104, Section 11.8.1. The descriptio= n for Config-Request
> > describes a message sent from the AC to t= he WTP. In Section
> > 7.2, the config request is sent from the AP= to the WTP. I
> > would prefer the mechanism described in 11.8.1.
> > = 40.
>
> There are two types of configuration messages, one that= comes from
> the WTP to the AC, and is used for the WTP to update th= e AC with its
> config at boot time. The second allows the AC to push down a new> config to the WTP, and this can occur at run time. The former is
= > called the Configure Request, while the latter is called the Configura= tion
> update Request. That said, I think we should come up with a differ= ent
> set of names to differentiate them better.
>
>
&= gt; In the Configure State, we currently have:
> Configure Request - = WTP sends AC its boot-time config
> Configure Response - AC overrides the current WTP boot-time config=
>
> In the Run state, we currently have
> Configure Upda= te Request - AC sends WTP new config parameters
> Configure Update Re= sponse - WTP acknowledges the Configure Update Request,
> includes result code
> IEEE 802.11 WLAN Config Request
&g= t;
> Recommended resolution: Accept, make the following changes:
&= gt;
> In the Configure State, rename to
> Configuration Status = - WTP sends AC its boot-time config
> Configuration Status Response - AC overrides the current WTP boot-= time
> config
>
> In the Run state,  - keep
= > Configure Update Request - AC sends WTP new config parameters
> = Configure Update Response - WTP acknowledges the Configure Update Request,
> includes result code, and in
> IEEE 802.11 WLAN Config Reque= st, update the text in 11.8.1  to reference
> usage after C= onfigure Update Request
>
> Comments please.
>
> Th= anks,
>
> Dorothy
>
Regards,
/david t. perkins



------=_Part_33978_31140188.1145996562175-- --===============1632585376== 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 --===============1632585376==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Apr 25 16:43:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYUNU-0004pb-9E for capwap-archive@lists.ietf.org; Tue, 25 Apr 2006 16:43:20 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYUNS-00070z-Sj for capwap-archive@lists.ietf.org; Tue, 25 Apr 2006 16:43:20 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4C76E4300D7 for ; Tue, 25 Apr 2006 13:43:18 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3273E43005A for ; Tue, 25 Apr 2006 13:42:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 19AC61448026 for ; Tue, 25 Apr 2006 13:42:51 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.197]) by hermes.tigertech.net (Postfix) with ESMTP id 0DABE1448022 for ; Tue, 25 Apr 2006 13:42:48 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so841542wxd for ; Tue, 25 Apr 2006 13:42:48 -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=QdAuzuhU3yQhz6tXxk6VPRMK8JwsjwQtbvagFLMElEaFHyF1NDsk7yazCoqHMBZL06ifny47RCyN7SzCBUOFnCKVdDIPV9UMZP8KV2jQRj4J5x4cdrm31gpCSCxqhghyICJ/Us+FXMpZt8PScWy9+XU4wUz6Fl87ezhRSJGiwVo= Received: by 10.70.26.4 with SMTP id 4mr1981482wxz; Tue, 25 Apr 2006 13:42:48 -0700 (PDT) Received: by 10.70.6.16 with HTTP; Tue, 25 Apr 2006 13:42:48 -0700 (PDT) Message-ID: <5bfe7a820604251342j73a382cch9c827d2bfa200758@mail.gmail.com> Date: Tue, 25 Apr 2006 13:42:48 -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 X-Spam-Level: Subject: [Capwap] Duplicate Messages - WTP Event and 802.11 WTP Event? 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="===============0189214583==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.8 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe --===============0189214583== Content-Type: multipart/alternative; boundary="----=_Part_34210_28908150.1145997768276" ------=_Part_34210_28908150.1145997768276 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 radio 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_34210_28908150.1145997768276 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 radio = 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_34210_28908150.1145997768276-- --===============0189214583== 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 --===============0189214583==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Apr 26 19:48:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYtjv-0000nz-KQ for capwap-archive@lists.ietf.org; Wed, 26 Apr 2006 19:48:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYtju-0007yz-84 for capwap-archive@lists.ietf.org; Wed, 26 Apr 2006 19:48:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9883F4300F8 for ; Wed, 26 Apr 2006 16:48:01 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A54134300AF for ; Wed, 26 Apr 2006 16:47:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9857B398031 for ; Wed, 26 Apr 2006 16:47:43 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A6362398008 for ; Wed, 26 Apr 2006 16:47:41 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k3QNlf5U030618 for ; Wed, 26 Apr 2006 16:47:41 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k3QNleQs030610 for ; Wed, 26 Apr 2006 16:47:40 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 26 Apr 2006 16:47:40 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.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: Subject: [Capwap] Getting started with Interoperability tests 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 HI, I'd like to get started with an interoperability test of going through discovery and creating a DTLS session between an AC and WTP. I PLEAD that the design team publish immediately a snapshot of their current work so that I and others can proceed to this point. This is a critical issue to be resolved, since it is new design. I don't need a complete update of the -00 I-D with other issues. Just send the details on whether or not there is a MUX header, whether or not there is a join, etc. Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Apr 26 20:04:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYtzH-0004t3-1P for capwap-archive@lists.ietf.org; Wed, 26 Apr 2006 20:04:03 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYtzE-00007s-KJ for capwap-archive@lists.ietf.org; Wed, 26 Apr 2006 20:04:03 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4736E430116 for ; Wed, 26 Apr 2006 17:04:00 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 08AFC4300AF for ; Wed, 26 Apr 2006 17:03:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A33A539803D for ; Wed, 26 Apr 2006 17:03:38 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.192.83]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2CFD2398031 for ; Wed, 26 Apr 2006 17:03:29 -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 <20060427000329m13000l9o9e>; Thu, 27 Apr 2006 00:03:29 +0000 Message-ID: <44500A50.3020904@hyperthought.com> Date: Wed, 26 Apr 2006 17:03:28 -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 T. Perkins" Subject: Re: [Capwap] Getting started with Interoperability tests References: In-Reply-To: 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@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: e1e48a527f609d1be2bc8d8a70eb76cb Hi David, I told you a little earlier today that we're in the middle of writing it up. Interoperability testing makes no sense before we have rough consensus on some major outstanding issues. I think we are very close. Please be patient just a little longer. Scott David T. Perkins wrote: > HI, > > I'd like to get started with an interoperability test > of going through discovery and creating a DTLS session > between an AC and WTP. > > I PLEAD that the design team publish immediately > a snapshot of their current work so that I and others > can proceed to this point. This is a critical > issue to be resolved, since it is new design. > > I don't need a complete update of the -00 I-D > with other issues. Just send the details on > whether or not there is a MUX header, whether > or not there is a join, etc. > > Regards, > /david t. perkins > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Apr 27 09:53:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ6wP-0003MU-Rg for capwap-archive@lists.ietf.org; Thu, 27 Apr 2006 09:53:57 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ6wO-00067C-9m for capwap-archive@lists.ietf.org; Thu, 27 Apr 2006 09:53:57 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3DECD43015E for ; Thu, 27 Apr 2006 06:53:49 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 777E943006C for ; Thu, 27 Apr 2006 06:53:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5C6E5431304 for ; Thu, 27 Apr 2006 06:53:19 -0700 (PDT) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.195]) by hermes.tigertech.net (Postfix) with ESMTP id 5A1B643130A for ; Thu, 27 Apr 2006 06:53:17 -0700 (PDT) Received: by xproxy.gmail.com with SMTP id h29so1140462wxd for ; Thu, 27 Apr 2006 06:53:16 -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=sOQ2LmSL/1zRiVWmaYNYFW2nX4hPBulkjV2FV/9q59jv9sPLm/ye4gAUtbMlWIxA2ZfIrDJNQMrAcoglSm8o1Fc4EBiIVYquK66f33kP/RLuFPeeTiykcuB+oax50396YQTzKvnEuizWnZ1I4nRG4bQMQwkBSPs3qHngwovTaxk= Received: by 10.70.49.20 with SMTP id w20mr883143wxw; Thu, 27 Apr 2006 06:53:16 -0700 (PDT) Received: by 10.70.68.11 with HTTP; Thu, 27 Apr 2006 06:53:16 -0700 (PDT) Message-ID: <5bfe7a820604270653p1709172fi4b45a48f709b259d@mail.gmail.com> Date: Thu, 27 Apr 2006 06:53:16 -0700 From: "Dorothy Stanley" To: "Michael Montemurro" Subject: Re: [Capwap] duplicate message element values In-Reply-To: <1652EBA28502ED4393B9BC9B8A4B601377903C@mism121a.toronto.chantrynetworks.com> MIME-Version: 1.0 References: <1652EBA28502ED4393B9BC9B8A4B601377903C@mism121a.toronto.chantrynetworks.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="===============1294073237==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c --===============1294073237== Content-Type: multipart/alternative; boundary="----=_Part_6058_16649198.1146145996337" ------=_Part_6058_16649198.1146145996337 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Proposed resolution: Re-number all the message element values as follows: CAPWAP message elements - begin with #1 IEEE 802.11 message elements - beginning with #1024 This eliminates duplicates, provides values for several existing TBDs, and enables straightforward Identification of the CAPWAP/IEEE specific nature of the elements. Currently there are 40 CAPWAP message elements, and 24 IEEE specific message elements defined. Comments? Thanks, Dorothy On 3/31/06, Michael Montemurro wrote: > > I've created item 91 to track this issue. > > Cheers, > > Mike > > > -----Original Message----- > > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > > Sent: March 30, 2006 6:07 PM > > To: capwap; Pat Calhoun > > Subject: [Capwap] duplicate message element values > > > > Hi Pat, > > > > The following capwap message elements are currently defined > > with duplicate values: > > > > - AC Address and Result Code (2) > > > > - 802.11 supported rates and 802.11 rate set (16) > > > > - Duplicate IPv4 address and Duplicate IPv6 address (77) > > > > Are these typos, or do new unique values need to be assigned? > > > > 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_6058_16649198.1146145996337 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Proposed resolution:

Re-number all the message element values as follows:

CAPWAP message elements - begin with #1
IEEE 802.11 message elements - beginning with #1024

This eliminates duplicates, provides values for several existing TBDs, and = enables
straightforward Identification of the CAPWAP/IEEE specific nature of the el= ements.

Currently there are 40 CAPWAP message elements,   and
24 IEEE specific message elements defined.

Comments?

Thanks,

Dorothy

On 3/31/06, Michael Montemurro <michael.montemurro@siemens.com> wrote: I've created item 91 to track this issue.

Cheers,

  = ;      Mike

> -----Original Message= -----
> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com]
> Sent: March 30, 2006 6:07 PM
> To: capwap; Pat Calhoun
> S= ubject: [Capwap] duplicate message element values
>
> Hi Pat,>
> The following capwap message elements are currently defined
> with duplicate values:
>
> - AC Address and Result Cod= e (2)
>
> - 802.11 supported rates and 802.11 rate set (16)
= >
> - Duplicate IPv4 address and Duplicate IPv6 address (77)
>
> Are these typos, or do new unique values need to be assigned?<= br>>
> Scott
>
> _____________________________________= ____________________________
> To unsubscribe or modify your subscrip= tion 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_6058_16649198.1146145996337-- --===============1294073237== 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 --===============1294073237==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Apr 27 11:46:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8hG-0007TI-3S for capwap-archive@lists.ietf.org; Thu, 27 Apr 2006 11:46:26 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ8hD-0006Gy-FR for capwap-archive@lists.ietf.org; Thu, 27 Apr 2006 11:46:26 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 707D0430108 for ; Thu, 27 Apr 2006 08:46:22 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 94E8043006C for ; Thu, 27 Apr 2006 08:45:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 71AF7431502 for ; Thu, 27 Apr 2006 08:45:06 -0700 (PDT) Received: from huawei-3com.com (smtp.huawei-3com.com [210.21.230.51]) by hermes.tigertech.net (Postfix) with ESMTP id ED5A34314FC for ; Thu, 27 Apr 2006 08:45:01 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYE00BL018ZFF@h3cml01-in.huawei-3com.com> for capwap@frascone.com; Thu, 27 Apr 2006 23:48:36 +0800 (CST) Received: from RichardYoung ([10.18.7.90]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IYE004JQ18XXO@h3cml01-in.huawei-3com.com> for capwap@frascone.com; Thu, 27 Apr 2006 23:48:35 +0800 (CST) Date: Thu, 27 Apr 2006 21:14:47 +0530 From: young In-reply-to: <20060420171823.F060543010A@leela.tigertech.net> To: dstanley1389@gmail.com Message-id: <000001c66a11$841932b0$5a07120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE X-Spam-Level: Cc: capwap@frascone.com Subject: [Capwap] RE: some suggestion for 802.11 binding TLV (Dorothy Stanley) 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="===============2069431323==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 5aec5327a02d1dfe64fbd5ba060d1311 This is a multi-part message in MIME format. --===============2069431323== Content-type: multipart/alternative; boundary="Boundary_(ID_Fswg5Syp+/MDIDYXheU7wA)" This is a multi-part message in MIME format. --Boundary_(ID_Fswg5Syp+/MDIDYXheU7wA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear All: I give more detailed suggestion about the following requirement: 1) New TLV "reset IEEE 802.11 Statistics" a) Why we need it? Now, the draft defines "IEEE 802.11 Statistics" to report Multicast Tx Count, Multiple Retry Count and so on. As AP keep updating the statistic value, after some time, the statistic value will become very great, and it could not reflect the real state of network. So administrator need a method to reset IEEE 802.11 Statistics" b) The TLV could be carried in the "Configure Update request" c) The TLV format is as follow: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Radio ID | +-+-+-+-+-+-+-+-+ When AP side get radio id from TLV, it will reset the radio as per radio ID. d) Other suggestion: Whether it needs a "Reset interval" element? By this way, user could configure after how many time (seconds) AP will reset Statistics for a specific radio. 2) New TLV "Preamble-length" a) Why we need it? "Preamble-length" is basic configuration for most vendor's AP product. As CAPWAP will provide 802.11 binding element, it should support the common 802.11 configuration that most vendor support. b) The TLV could be carried in the "Configure Update request, configure request, configure response" c) The TLV format The CAPWAP already has TLV IEEE 802.11 MAC operation, and we could add one more element named "Preamble-length". The value for it could be: 1 - short (default) 2 - long 3) Issues 107 Now, in the draft, IEEE 802.11 Broadcast Probe Mode is configured for AP, while "Supress SSID (section 11.8.1)" is for specific radio. I suggest we could delete "IEEE 802.11 Broadcast Probe Mode" TLV, and move this TLV element to "IEEE 802.11 Add WLAN" TLV. Regards Richard -----Original Message----- Message: 2 Date: Thu, 20 Apr 2006 09:03:27 -0700 From: "Dorothy Stanley" Subject: Re: [Capwap] some suggestion for 802.11 binding TLV To: young Cc: capwap@frascone.com Message-ID: <5bfe7a820604200903qcb7ba6aj7b2a55ef96f71388@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Richard, Status and comments inline 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? 2) Because CAPWAP provide the definition of 802.11 binding, the common > configuration for AP came from different vendors should defined by draft. I > felt something like "Preamble-length" configuration need to be added into > draft. > Issue 106 has been opened for item (2) Where would you add "pre-amble length"? In the WTP Radio information? Is this info provided by the WTP to the AC on what is supported? 3) Now, in the draft, IEEE 802.11 Broadcast Probe Mode is configured for AP, > while Supress SSID (section 11.8.1) is for specific radio. > > I suggest both Broadcast Probe Mode and Supress SSID could be configured > for a specific radio. > Issue 107 has been opened for item (3). Regards > > > > Richard > > _________________________________________________________________ > 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/20060420/2259b68b/at tachment.htm > _________________________________________________________________ > 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/20060420/841ac68d/at tachment.htm ------------------------------ Message: 4 Date: Thu, 20 Apr 2006 10:17:25 -0700 From: Puneet Subject: Re: [Capwap] 802.11d / 802.11h support To: "Partha Narasimhan" Cc: capwap@frascone.com Message-ID: <1013407b0604201017n54b69a54o85b3111d1cf42ccd@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Partha, for #1 I agree with you, we should just use the 802.11 IE (802.11d). That IE is what will finally go out in the beacons/probe-responses. No need for the WTP to have to translate and construct that IE. for #2 it might be simpler if the WTP reports radar to the AC, and the AC makes the decision about what channel to jump to. As David also mentions, the channel to move to might be determined by policy or by some channel-selection logic on the AC which takes into account neighbouring channels etc. A 'future' channel can either be provided to the WTP at configuration time (if the timing constraints seem so tight), or as soon as it reports radar. Thanks, Puneet On 4/18/06, Partha Narasimhan wrote: > > For #1, why dont we use the IEs as defined by IEEE 802.11? Why do we need > to re-define something that is already defined in 802.11? This is probably > true for the 11d, RSN, WPA, WMM, 11e IEs, and anything else that has a > corresponding 802.11 definition. There is code that exists to parse 802.11 > IEs elsewhere in the WTP, so we get code reuse too. :-) > > For #2, my vote would be for the WTP to switch channels on detecting radar > and notify the AC of the radar detect and the resulting channel change > events. This keeps it simple and WTPs have the ability to detect radar > already. > > Thanks > partha > > On Tue, 18 Apr 2006, Dorothy Stanley wrote: > > > Hi Puneet, > > > > This is assigned to a new issue, 104. > > > > All- comments, discussion please. > > > > Thanks, > > > > Dorothy Stanley > > > > > > On 4/14/06, Puneet wrote: > > > > 1. Section 11.9.3 'IEEE 802.11 Multi-domain Capability': The > length of this element is fixed at 8 bytes, but if there are multiple, > disjoint bands that are supported in the regulatory domain does the AC use > multiple such elements? It might be cleaner to make the length of this > element variable, and allow multiple triplets > the Country-Information element in 802.11d) > > > > 2. How does CAPWAP plan to support 802.11h? Does the WTP handle > everything on its own or is the channel switching etc controlled by the AC? > In either case there might be a need for message elements with which the WTP > to report the detection of radar to the AC. > > > > Thanks, > > Puneet. > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap < > http://lists.frascone.com/mailman/listinfo/capwap> > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.tigertech.net/pipermail/capwap/attachments/20060420/63cc621b/at tachment.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 6, Issue 47 ************************************* --Boundary_(ID_Fswg5Syp+/MDIDYXheU7wA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dear All:

 

I give more detailed suggestion about the following requirement:

 

1) New TLV "reset IEEE 802.11 Statistics"

a) Why we need it?

Now, the draft defines "IEEE 802.11 Statistics" to report Multicast Tx Count, Multiple Retry Count and so on. As AP keep updating the statistic value, after some time, the statistic value will become very great, and it could not reflect the real state of network. So administrator need a method to reset IEEE 802.11 Statistics”

b) The TLV could be carried in the “Configure Update request”

c) The TLV format is as follow:

      0 1 2 3 4 5 6 7

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

     |   Radio ID   |

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

   When AP side get radio id from TLV, it will reset the radio as per radio ID.

d) Other suggestion:

Whether it needs a “Reset interval” element? By this way, user could configure after how many time (seconds) AP will reset Statistics for a specific radio.

 

2) New TLV "Preamble-length"

a) Why we need it?

"Preamble-length" is basic configuration for most vendor’s AP product. As CAPWAP will provide 802.11 binding element, it should support the common 802.11 configuration that most vendor support.

b) The TLV could be carried in the “Configure Update request, configure request, configure response”

c) The TLV format

The CAPWAP already has TLV IEEE 802.11 MAC operation, and we could add one more element named "Preamble-length". The value for it could be:

      1 – short (default)

      2 - long

 

3) Issues 107

Now, in the draft, IEEE 802.11 Broadcast Probe Mode is configured for AP, while “Supress SSID (section 11.8.1)” is for specific radio.

I suggest we could delete “IEEE 802.11 Broadcast Probe Mode” TLV, and move this TLV element to “IEEE 802.11 Add WLAN” TLV.

 

Regards

 

Richard

 

 

-----Original Message-----

Message: 2

Date: Thu, 20 Apr 2006 09:03:27 -0700

From: "Dorothy Stanley" <dstanley1389@gmail.com>

Subject: Re: [Capwap] some suggestion for 802.11 binding TLV

To: young <young@huawei-3com.com>

Cc: capwap@frascone.com

Message-ID:

     <5bfe7a820604200903qcb7ba6aj7b2a55ef96f71388@mail.gmail.com>

Content-Type: text/plain; charset="iso-8859-1"

 

Richard,

 

Status and comments inline below.

 

Thanks,

 

Dorothy

 

On 4/19/06, young <young@huawei-3com.com> wrote:

>

>  Dear all:

>

>

>

> I have some suggestion about CAPWAP draft, please kindly discuss it.

>

> 1) For IEEE 802.11 Statistics

>

> I suggest we should add new TLV for "reset IEEE 802.11 Statistics"

>

 

Issue 105 has been opened for item (1).

 

Can you provide suggested text for a description of the proposed TLV?  This

will enable a more informed discussion, and

give insight into the problem that is being solved.

Is this a boolean, which when set causes the WTP to reset all of its

statistics collection counters?

Is it included in the statistics message element? A new message element?  In

which message elements and messages would it be included?

 

 

 

2) Because CAPWAP provide the definition of 802.11 binding, the common

> configuration for AP came from different vendors should defined by draft. I

> felt something like "Preamble-length" configuration need to be added into

> draft.

>

 

Issue 106 has been opened for item (2)

 

Where would you add "pre-amble length"? In the WTP Radio information?

Is this info provided by the WTP to the AC on what is supported?

 

3) Now, in the draft, IEEE 802.11 Broadcast Probe Mode is configured for AP,

> while Supress SSID (section 11.8.1) is for specific radio.

>

> I suggest both Broadcast Probe Mode and Supress SSID could be configured

> for a specific radio.

>

 

Issue 107 has been opened for item (3).

 

Regards

>

>

>

> Richard

>

> _________________________________________________________________

> 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/20060420/2259b68b/attachment.htm

 

> _________________________________________________________________

> 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/20060420/841ac68d/attachment.htm

 

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

 

Message: 4

Date: Thu, 20 Apr 2006 10:17:25 -0700

From: Puneet <pb.ietf@gmail.com>

Subject: Re: [Capwap] 802.11d / 802.11h support

To: "Partha Narasimhan" <partha@arubanetworks.com>

Cc: capwap@frascone.com

Message-ID:

     <1013407b0604201017n54b69a54o85b3111d1cf42ccd@mail.gmail.com>

Content-Type: text/plain; charset="iso-8859-1"

 

Partha,

 

for #1 I agree with you, we should just use the 802.11 IE (802.11d). That IE

is what will finally go out in the beacons/probe-responses. No need for the

WTP to have to translate and construct that IE.

 

for #2 it might be simpler if the WTP reports radar to the AC, and the AC

makes the decision about what channel to jump to. As David also mentions,

the channel to move to might be determined by policy or by some

channel-selection logic on the AC which takes into account neighbouring

channels etc. A 'future' channel can either be provided to the WTP at

configuration time (if the timing constraints seem so tight), or as soon as

it reports radar.

 

Thanks,

Puneet

 

On 4/18/06, Partha Narasimhan <partha@arubanetworks.com> wrote:

>

> For #1, why dont we use the IEs as defined by IEEE 802.11? Why do we need

> to re-define something that is already defined in 802.11? This is probably

> true for the 11d, RSN, WPA, WMM, 11e IEs, and anything else that has a

> corresponding 802.11 definition. There is code that exists to parse 802.11

> IEs elsewhere in the WTP, so we get code reuse too. :-)

>

> For #2, my vote would be for the WTP to switch channels on detecting radar

> and notify the AC of the radar detect and the resulting channel change

> events. This keeps it simple and WTPs have the ability to detect radar

> already.

>

> Thanks

> partha

>

> On Tue, 18 Apr 2006, Dorothy Stanley wrote:

>

> > Hi Puneet,

> >

> > This is assigned to a new issue, 104.

> >

> > All- comments, discussion please.

> >

> > Thanks,

> >

> > Dorothy Stanley

> >

> >

> > On 4/14/06, Puneet <pb.ietf@gmail.com> wrote:

> >

> >       1. Section 11.9.3 'IEEE 802.11 Multi-domain Capability': The

> length of this element is fixed at 8 bytes, but if there are multiple,

> disjoint bands that are supported in the regulatory domain does the AC use

> multiple such elements? It might be cleaner to make the length of this

> element variable, and allow multiple triplets

> <first_channel,num_channel,max_power) to be added one after the other. (like

> the Country-Information element in 802.11d)

> >

> >       2. How does CAPWAP plan to support 802.11h? Does the WTP handle

> everything on its own or is the channel switching etc controlled by the AC?

> In either case there might be a need for message elements with which the WTP

> to report the detection of radar to the AC.

> >

> >       Thanks,

> >       Puneet.

> >

> >

> >       _________________________________________________________________

> >       To unsubscribe or modify your subscription options, please visit:

> >       http://lists.frascone.com/mailman/listinfo/capwap <

> http://lists.frascone.com/mailman/listinfo/capwap>

> >

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

> >

> >

> >

> >

> >

>

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.tigertech.net/pipermail/capwap/attachments/20060420/63cc621b/attachment.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 6, Issue 47

*************************************

--Boundary_(ID_Fswg5Syp+/MDIDYXheU7wA)-- --===============2069431323== 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 --===============2069431323==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Apr 27 11:50:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ8lV-0008GC-5b for capwap-archive@lists.ietf.org; Thu, 27 Apr 2006 11:50:49 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ8lU-0006dM-Em for capwap-archive@lists.ietf.org; Thu, 27 Apr 2006 11:50:49 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 183B9430148 for ; Thu, 27 Apr 2006 08:50:48 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D475F43006C for ; Thu, 27 Apr 2006 08:50:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 70B5A431514 for ; Thu, 27 Apr 2006 08:50:04 -0700 (PDT) Received: from huawei-3com.com (smtp.huawei-3com.com [210.21.230.51]) by hermes.tigertech.net (Postfix) with ESMTP id A045B43150D for ; Thu, 27 Apr 2006 08:49:57 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYE00BX21HHFF@h3cml01-in.huawei-3com.com> for capwap@frascone.com; Thu, 27 Apr 2006 23:53:41 +0800 (CST) Received: from RichardYoung ([10.18.7.90]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IYE0040D1HGXO@h3cml01-in.huawei-3com.com> for capwap@frascone.com; Thu, 27 Apr 2006 23:53:41 +0800 (CST) Date: Thu, 27 Apr 2006 21:19:54 +0530 From: young Subject: Re: [Capwap] CAPWAP need new TLV to configure Radio Type To: dstanley1389@gmail.com Message-id: <000501c66a12$3a9a8ac0$5a07120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE 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="===============1399720243==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e9d8c60d9288f2c774f26bab15869505 This is a multi-part message in MIME format. --===============1399720243== Content-type: multipart/alternative; boundary="Boundary_(ID_2QjRszAn25fZA7WpAJerkg)" This is a multi-part message in MIME format. --Boundary_(ID_2QjRszAn25fZA7WpAJerkg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear Dorothy Stanley: Felt sorry to answer too late. I think it is a nice solution for radio type configuration issue. Regards RIchard -----Original Message----- Message: 3 Date: Thu, 20 Apr 2006 09:38:32 -0700 From: "Dorothy Stanley" Subject: Re: [Capwap] CAPWAP need new TLV to configure Radio Type To: young Cc: capwap@frascone.com Message-ID: <5bfe7a820604200938h1c64df46lb3496eee546728d@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Richard, I suggest including discussion of this as part of issue 102, WTP WLAN Radio Configuration Changes. Section 11.9.1, "IEEE 802.11 WTP Radio Configuration" is the message element used to configure the radio. This message element is currently included in the Configuration request, Configuration response and Configuration update messages. So, is the proposed change that a new field be added: Radio Type - with definitions as per those in 5.1.3? Thanks, Dorothy On 4/19/06, young wrote: > > Dear all: > > > > At present, only one TLV of " WTP Radio Information" is related to radio > type, and only carried during the discovery phase. > > But there is no TLV to configure radio type. > > So I suggest CAPWAP could add new TLV for radio type configuration. > > > > Regards > > Richard > --Boundary_(ID_2QjRszAn25fZA7WpAJerkg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dear Dorothy Stanley:

 

Felt sorry to answer too late.

 

I think it is a nice solution for radio type configuration issue.

 

Regards

 

RIchard

 

-----Original Message-----

 

Message: 3

Date: Thu, 20 Apr 2006 09:38:32 -0700

From: "Dorothy Stanley" <dstanley1389@gmail.com>

Subject: Re: [Capwap] CAPWAP need new TLV to configure Radio Type

To: young <young@huawei-3com.com>

Cc: capwap@frascone.com

Message-ID:

     <5bfe7a820604200938h1c64df46lb3496eee546728d@mail.gmail.com>

Content-Type: text/plain; charset="iso-8859-1"

 

Richard,

 

I suggest including discussion of  this as part of issue 102, WTP WLAN Radio

Configuration Changes.

Section 11.9.1, "IEEE 802.11 WTP Radio Configuration" is the message element

used to

configure the radio. This message element is currently included in the

Configuration request,

Configuration response and Configuration update messages.

 

So, is the proposed change that a new field be added:

 

Radio Type - with definitions as per those in 5.1.3?

 

Thanks,

 

Dorothy

 

On 4/19/06, young <young@huawei-3com.com> wrote:

>

>  Dear all:

>

>

>

> At present, only one TLV of  " WTP Radio Information" is related to radio

> type, and only carried during the discovery phase.

>

> But there is no TLV to configure radio type.

>

> So I suggest CAPWAP could add new TLV for radio type configuration.

>

>

>

> Regards

>

> Richard

>

 

--Boundary_(ID_2QjRszAn25fZA7WpAJerkg)-- --===============1399720243== 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 --===============1399720243==-- From page@page.com Fri Apr 28 00:49:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZKv7-0003FC-EA for capwap-archive@ietf.org; Fri, 28 Apr 2006 00:49:33 -0400 Received: from [59.191.86.211] (helo=page.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZKqy-0004Km-AM for capwap-archive@ietf.org; Fri, 28 Apr 2006 00:45:20 -0400 From: "page" Subject: =?GB2312?B?sNGwrtDEt+7P17j4uqLX08PHo6E=?= To: capwap-archive@ietf.org Content-Type: text/html;charset="GB2312" Content-Transfer-Encoding: 8bit Reply-To: page@page.com Date: Fri, 28 Apr 2006 12:45:09 +0800 X-Priority: 2 X-Mailer: FoxMail 4.0 beta 2 [cn] X-Spam-Score: 3.7 (+++) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Untitled Document
¡ï¡ï¡ï°Ñ°®ÐÄ·îÏ׸øº¢×ÓÃÇ¡ï¡ï¡ï
¡¡¡¡

¡¡¡¡ÔÚÈ«Çò²»Í¬ÈËÖÖ¡¢²»Í¬·ôÉ«¡¢²»Í¬¹ú¶ÈµÄÈËȺÖУ¬ÓÐÕâÑùÒ»¸öȺÌ壬ËûÃǵijɳ¤¡¢ËûÃǵÄϲÀÖ¼¢º®¡¢ËûÃǵÄÒ»ò­Ò»Ð¦×îÄܲ¦¶¯ÎÒÃǵÄÐÄÏÒ¡£ËûÃǾÍÊÇ¡ª¡ª¶ùͯ¡£

¡¡¡¡¶ùͯ£¬ÊÇÒ»¸ö¹ú¼ÒµÄδÀ´£¬ÊÇÒ»¸öÃñ×åµÄÏ£Íû¡£ËûÃǵݲȫ½¡¿µ³É³¤£¬²»½öʹØǧ¼ÒÍò»§£¬»¹¹Øϵµ½¹úÔËÐËË¥¡£ÔÚÈ«Çò£¬ÎÞÂÛºÚƤ·ô»¹ÊÇ°×Ƥ·ô¡¢ÎÞÂÛÑÇÖÞ»¹ÊÇ·ÇÖÞ£¬ÎÞÂÛ¸»¹ó»¹ÊÇƶÇÈËÃǶԺ¢×ÓÃÇÇãÐĽßÁ¦µÄ°®¶¼Êǹ²Í¨µÄ¡£

¡¡¡¡ÖйúÓÐÈýÒÚÁùǧÍò¶ùͯ£¬Õ¼ÊÀ½ç¶ùͯ×ÜÊýµÄÁù·ÖÖ®Ò»¡£ÓÉÓÚ×ÔÈ»ÀúÊ·¡¢ÎÄ»¯Ï°Ëס¢µØÓò·¢Õ¹²»Æ½ºâµÈÖî¶àÒòËØ£¬ÎÒ¹ú»¹ÓÐÏ൱һ²¿·Ö¶ùͯÉÙÄ껹´¦ÓÚÈõÊƵĴ¦¾³£¬»òÊǼ²²¡¡¢»òÊÇʧѧ¡¢»òÊÇÔâÊÜÉ˺¦µÈµÈ¡£ËûÃǵĽ¡¿µ³É³¤Ç£¶¯×ÅÎÒÃÇÿһ¸öÑ×»Æ×ÓËïµÄÐÄ¡£×÷ΪÁúµÄ´«ÈË£¬¶ÔÎÒÃǵÄ×ÓËïºó´ú¶àһЩ¹Ø×¢£¬¶àÒ»·Ý°®ÐÄ£¬¶àÒ»µã°ïÖú£¬Èú¢×ÓÃǸü¼Ó½¡¿µ¿ìÀֵijɳ¤£¬ÎÒÃÇÔðÎÞÅÔ´û£¡

¡¡¡¡ÊÀÉϵÄÒ»Çж¼ÊÇ˲ϢÍò±ä£¬Î¨Óа®ÊÇÊÀÈËÒ÷³ª¡¢ÓÀºã²»±äµÄÖ÷Ìâ¡£ÎÒÃÇÕæ³ÏµÄºôÓõºÍÆÚ´ýÄúµÄÈÈÇé²ÎÓëºÍ°®ÐÄÖ§³Ö£º

¡¡¡¡¾è¿î1000Ôª,¿ÉÒÔ¾è¿îÕßÃû³ÆÃüÃûÒ»¸ö¡°°²¿µÌåÓýÓÃÆ·¹ñ¡±£»¡Ì

¡¡¡¡¾è¿î2000Ôª,¿ÉÒÔ¾è¿îÕßÃû³ÆÃüÃûÒ»¸ö¡°°²¿µÒ½ÁÆÎÀÉúÏ䡱£»¡Ì

¡¡¡¡¾è¿î3000Ôª,¿ÉÒÔ¾è¿îÕßÃû³ÆÃüÃûÒ»¸ö¡°°²¿µ¿ÆÆÕÊé¼Ü¡±£»¡Ì

¡¡¡¡¾è¿î4000Ôª,¿ÉÒÔ¾è¿îÕßÃû³ÆÃüÃûÒ»¸ö¡°°²¿µµçÊǪ́¡±£»¡Ì

¡¡¡¡¾è¿î10000Ôª,¿ÉÒÔ¾è¿îÕßÃû³ÆÃüÃûÒ»ËùѧУ(º¬Ð¡Ñ§¡¢ÖÐѧ¡¢¸ßÖÐ)Ò»ÄêµÄ¡°°²¿µÔ¶³Ì½ÌÊÒ¡±£»¡Ì

¡¡¡¡¾è¿î30000Ôª,¿ÉÒÔ¾è¿îÕßÃû³ÆÃüÃûÒ»ËùѧУ(º¬Ð¡Ñ§¡¢ÖÐѧ¡¢¸ßÖÐ)ÈýÄêµÄ¡°°²¿µÔ¶³Ì½ÌÊÒ¡±£»¡Ì

¡¡¡¡¾è¿î20000Ôª,¿ÉÒÔ¾è¿îÕßÃû³ÆÃüÃûÒ»¸ö¡°°²¿µÒæ¼ÒÐû´«À¸¡±£»¡Ì

¡¡¡¡¾è¿î30000Ôª,¿ÉÒÔ¾è¿îÕßÃû³ÆÃüÃûÒ»¸ö¡°°²¿µÒæ¼Ò¡±£»¡Ì

¡¡¡¡¾è¿î50000Ôª,¿ÉÒÔΪƶÀ§µØÇø×°ÅäÒ»¸ö¡°°²¿µÎÀÉúÔº¡±£»¡Ì

¡¡¡¡¾è¿î200000Ôª,¿ÉÒÔΪƶÀ§µØÇø×°ÅäÒ»Á¾¡°°²¿µÁ÷¶¯Ò½ÁƳµ¡±(º¬»ù±¾Ò½ÁÆÉ豸).¡Ì

¡¡¡¡¾è¿î5000Ôª£¬¿ÉÒÔ¾ÈÖúÒ»ÃûƶÀ§ÈõÊÓ¶ùͯÖؼû¹âÃ÷£»¡Ì

¡¡¡¡¾è¿î1500Ôª£¬¿ÉÒÔ°ïÖúÒ»ÃûƶÀ§¡°´ºÀÙСѧÉú¡±Íê³ÉÈýÄêµÄѧҵ£»¡Ì

¡¡¡¡¾è¿î1800Ôª£¬¿ÉÒÔ°ïÖúÒ»ÃûƶÀ§¡°´ºÀÙ³õÖÐÉú¡±Íê³ÉÈýÄêµÄѧҵ£»¡Ì

¡¡¡¡¾è¿î2400Ôª£¬¿ÉÒÔ°ïÖúÒ»ÃûƶÀ§¡°´ºÀÙ¸ßÖÐÉú¡±Íê³ÉÈýÄêµÄѧҵ£»¡Ì

¡¡¡¡¾è¿î500Ôª£¬¿ÉÒÔ×ÊÖúÒ»ÃûƶÀ§Å®Í¯½ÓÊÜÒ»ÄêµÄʵÓü¼ÊõÅàѵ¡£¡Ì
¡¡¡¡
¡¡¡¡Èç¹ûÄúÊÇÊг¤¡¢ÆóÒµ¼Ò¡¢³É¹¦ÈËÊ¿£¬ÎªÁ˺¢×ÓÃÇ£¬Äú¿ÉÒÔ¶¯Ô±ÄúµÄ³ÇÊС¢ÄúµÄÆóÒµ¡¢ÄúµÄ×éÖ¯¡¢ÄúµÄÍŶӽÚÊ¡Ò»ÈÕµÄÕдý·Ñ¡¢»òÊÇ·îÏ×Ò»ÈÕµÄÀûÈó£»Èç¹ûÄúÊÇÊÐÃñ¡¢Ö°Ô±¡¢¹¤Ð½½×²ã£¬ÎªÁ˺¢×ÓÃÇÄú¿ÉÒÔͨ¹ý¹Ì¶¨µç»°»òСÁéͨ²¦´ò12361ļ¾èרÏß,¿ÉÒÔÍùļ¾èÏäÀïͶÈëһöӲ±Ò£¬¿ÉÒÔÒåÂòÒ»¸öÊé°ü...°®ÐÄÎÞÂÛ´óС¡¢²»·Ö½çÏÞ£¬¼´Ê¹ÄÒÖеãËÚ£¬±­Ë®³µÐ½£¬Ò²×ãÒÔÖ¤Ã÷ÄúÄÇÒóÒóó¶¿Ö®Ç飬ȭȭ°®Ó×Ö®ÐÄ¡£ÎÒÃǶ¼½«´ú±íº¢×ÓÃÇÃú¸ÐÎåÖÔ£¡

¡¡¡¡ÈÃÈ«ÊÀ½çËùÓÐÁ÷ÌÊ×ÅÖлªÃñ×åѪҺµÄÈËÊ¿¶¼»ý¼«Ðж¯ÆðÀ´£¬·¢ÑïÖлªÃñ×å¡°Ó×ÎáÓ×£¬ÒÔ¼°ÈËÖ®Óס±µÄ´«Í³ÃÀµÂ¡£ÍŽáÒ»ÇÐÁ¦Á¿£¬µ÷¶¯Ò»ÇÐÓÐÀû×ÊÔ´£¬½ß¾¡ËùÄÜ£¬¾èÏ×Ò»·ÝÉƿ·îÏ×һƬ°®ÐÄ£¬Èú¢×ÓÃǸü¼Ó½¡¿µ¿ìÀֵijɳ¤£¡ÈùÅÀ϶«·½ÁúµÄÃñ×å¸ü¼Ó¸»Ç¿ÐËÍú£¡°Ñ°®ÐÄ·îÏ׸øº¢×ÓÃÇ£¡

¡¡¡¡×¨Ïî¾è¿îÕÊ»§: ¹ã¶«·¢Õ¹ÒøÐб±¾©·ÖÐÐÓªÒµ²¿¡¡»§Ãû£ºÖйú¶ùͯÉÙÄê»ù½ð»á¡¡ÕʺÅ:12361

Öйú¶ùͯÉÙÄê»ù½ð»á
From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 28 14:49:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZY2B-0000BV-1M for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 14:49:43 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZY29-0003tV-Dp for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 14:49:43 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6489D4300CC for ; Fri, 28 Apr 2006 11:49:40 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 5EB6F43004F for ; Fri, 28 Apr 2006 11:49:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 52AFA398032 for ; Fri, 28 Apr 2006 11:49:13 -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 83C31398013 for ; Fri, 28 Apr 2006 11:49:10 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-2.cisco.com with ESMTP; 28 Apr 2006 11:49:10 -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 k3SIn9RT003224; Fri, 28 Apr 2006 11:49:10 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Apr 2006 11:49:09 -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, 28 Apr 2006 11:49:08 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201CBA52B@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: AcZflTnNboSzSz1tThmGxcChR/8J6ALWY01A From: "Pat Calhoun (pacalhou)" To: "Puneet" , X-OriginalArrivalTime: 28 Apr 2006 18:49:09.0848 (UTC) FILETIME=[6F4C6580:01C66AF4] 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: Subject: [Capwap] 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: f49c97ce49302a02285a2d36a99eef8c 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. =09 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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 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.=20 Thanks, that has been fixed =09 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. =09 5. maybe rename WME to WMM?=20 No longer relevant =09 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems=09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Apr 28 15:21:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZYWU-0008IK-Os for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 15:21:02 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZYWR-0006EK-H6 for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 15:21:02 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D1BC6430097 for ; Fri, 28 Apr 2006 12:20:54 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 569B443005F for ; Fri, 28 Apr 2006 12:20:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4499A398013 for ; Fri, 28 Apr 2006 12:20:05 -0700 (PDT) X-Greylist-Status: Sender first seen 00:01:01 ago Received: from postal2.belairnetworks.com (unknown [142.46.200.242]) by zoidberg.tigertech.net (Postfix) with ESMTP id 60AB8398028 for ; Fri, 28 Apr 2006 12:20:02 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] BSSID-WLAN mappings Date: Fri, 28 Apr 2006 15:18:59 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] BSSID-WLAN mappings Thread-Index: AcZiRe5rwuKfEiOmRj+0tGKDGix2rAIr0ODAAACD/VA= From: "Jeff Joslin" To: X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.078 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO, HTML_60_70, HTML_MESSAGE 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: , Content-Type: multipart/mixed; boundary="===============0712958553==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 966811b049c4d80323826ee01e1b1ce9 This is a multi-part message in MIME format. --===============0712958553== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66AF8.9A144090" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66AF8.9A144090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. =20 The above scheme works, after a fashion, but creates some client compatibility issues. Multiple BSSID is preferable. =20 One SSID =3D=3D 1 WLAN. In general we cannot assume that 1 BSSID =3D=3D = 1 WLAN. =20 Perhaps 1 VLAN =3D=3D 1 WLAN is more helpful? It is standard practice to = map each SSID to a separate VLAN. =20 Jeff Joslin Senior Network Architect BelAir Networks =20 _____ =20 From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: 28 April 2006 2:57 PM To: Puneet; Bob O'Hara (boohara) Cc: capwap@frascone.com Subject: RE: [Capwap] BSSID-WLAN mappings =20 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. =20 I contend 1 BSSID =3D=3D 1 WLAN. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 _____ =20 From: Puneet [mailto:pb.ietf@gmail.com]=20 Sent: Monday, April 17, 2006 10:39 AM To: Bob O'Hara (boohara) Cc: capwap@frascone.com Subject: Re: [Capwap] BSSID-WLAN mappings Bob, =09 > We should not be implementing, or requiring an CAPWAP implementation to implement a method=20 > that lowers the security of the WLAN. =09 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) =09 Thanks, Puneet 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 We should not be implementing, or requiring an CAPWAP implementation to implement a method that lowers the security of the WLAN. -Bob =20 =20 =20 =09 _____ =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, =09 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. =09 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. =09 Thanks, Puneet =09 =09 On 4/15/06, Saravanan Govindan wrote:=20 Hi Puneet, =09 My concern regarding the BSSID - WLAN mapping is based on the mandatory Objective "Logical Groups" (Section 5.1.1 of CAPWAP Objectives). =09 The Objective requires that WTP traffic be kept logically distinct among=20 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=20 over the AC-WTP environment (e.g. WLANs). =09 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,=20 CAPWAP frames of different logical groups (WLANs) can be distinctly exchanged. =09 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 =09 Cheers, =09 Saravanan =09 =09 =09 =09 > ------------------------------ > *From:* Puneet [mailto:pb.ietf@gmail.com] > *Sent:* Friday, April 14, 2006 12:29 AM=20 > *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=20 > 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=20 WLAN > information back to the AC, why do we need to mandate this 1:1 BSSID-WLAN > mapping? > > Thanks, > Puneet > > _________________________________________________________________=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 _________________________________________________________________=20 Get an advanced look at the new version of MSN Messenger.=20 http://messenger.msn.com.sg/Beta/Default.aspx=20 =09 =09 =09 =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =20 ------_=_NextPart_001_01C66AF8.9A144090 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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) [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 =3D=3D 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) <boohara@cisco.com> 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 <saravanang@hotmail.com> 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

 

------_=_NextPart_001_01C66AF8.9A144090-- --===============0712958553== 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 --===============0712958553==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 28 15:35:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZYka-0004d1-J5 for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 15:35:36 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZYkX-0006x0-B8 for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 15:35:36 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E60704300B7 for ; Fri, 28 Apr 2006 12:35:32 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 6A22E43005F for ; Fri, 28 Apr 2006 12:34:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 51C54398038 for ; Fri, 28 Apr 2006 12:34:43 -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 5AA8F398025 for ; Fri, 28 Apr 2006 12:34:41 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 28 Apr 2006 12:34:41 -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 k3SJYfh0014303 for ; Fri, 28 Apr 2006 12:34:41 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Apr 2006 12:34:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] BSSID-WLAN mappings Date: Fri, 28 Apr 2006 12:34:40 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC0175B4C8@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] BSSID-WLAN mappings Thread-Index: AcZiRe5rwuKfEiOmRj+0tGKDGix2rAIr0ODAAACD/VAAAMd8kA== From: "Bob O'Hara (boohara)" To: X-OriginalArrivalTime: 28 Apr 2006 19:34:40.0835 (UTC) FILETIME=[CB17F130:01C66AFA] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.402 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE 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: , Content-Type: multipart/mixed; boundary="===============0851486076==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0807e85f6792b2e267100df15b13cd9b This is a multi-part message in MIME format. --===============0851486076== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66AFA.CB0A7CA6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66AFA.CB0A7CA6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 =20 =20 ________________________________ From: Jeff Joslin [mailto:jjoslin@belairnetworks.com]=20 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. =20 The above scheme works, after a fashion, but creates some client compatibility issues. Multiple BSSID is preferable. =20 One SSID =3D=3D 1 WLAN. In general we cannot assume that 1 BSSID =3D=3D = 1 WLAN. =20 Perhaps 1 VLAN =3D=3D 1 WLAN is more helpful? It is standard practice to = map each SSID to a separate VLAN. =20 Jeff Joslin Senior Network Architect BelAir Networks =20 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: 28 April 2006 2:57 PM To: Puneet; Bob O'Hara (boohara) Cc: capwap@frascone.com Subject: RE: [Capwap] BSSID-WLAN mappings =20 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. =20 I contend 1 BSSID =3D=3D 1 WLAN. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Puneet [mailto:pb.ietf@gmail.com]=20 Sent: Monday, April 17, 2006 10:39 AM To: Bob O'Hara (boohara) Cc: capwap@frascone.com Subject: Re: [Capwap] BSSID-WLAN mappings Bob, =09 > We should not be implementing, or requiring an CAPWAP implementation to implement a method=20 > that lowers the security of the WLAN. =09 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) =09 Thanks, Puneet 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 We should not be implementing, or requiring an CAPWAP implementation to implement a method that lowers the security of the WLAN. -Bob =20 =20 =20 =09 ________________________________ 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, =09 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. =09 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. =09 Thanks, Puneet =09 =09 On 4/15/06, Saravanan Govindan wrote:=20 Hi Puneet, =09 My concern regarding the BSSID - WLAN mapping is based on the mandatory Objective "Logical Groups" (Section 5.1.1 of CAPWAP Objectives). =09 The Objective requires that WTP traffic be kept logically distinct among=20 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=20 over the AC-WTP environment (e.g. WLANs). =09 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,=20 CAPWAP frames of different logical groups (WLANs) can be distinctly exchanged. =09 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 =09 Cheers, =09 Saravanan =09 =09 =09 =09 > ------------------------------ > *From:* Puneet [mailto:pb.ietf@gmail.com] > *Sent:* Friday, April 14, 2006 12:29 AM=20 > *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=20 > 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=20 WLAN > information back to the AC, why do we need to mandate this 1:1 BSSID-WLAN > mapping? > > Thanks, > Puneet > > _________________________________________________________________=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 _________________________________________________________________=20 Get an advanced look at the new version of MSN Messenger.=20 http://messenger.msn.com.sg/Beta/Default.aspx=20 =09 =09 =09 =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =20 ------_=_NextPart_001_01C66AFA.CB0A7CA6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The mechanism below is, of course, not = compliant with=20 the 802.11 standard.  It is a proprietary extension.  It is = not clear=20 to me why CAPWAP should support this mechanism, or any other proprietary = mechanism.  As Jeff points out below, this is not compatible with = all=20 clients (most likely because the mechanism is not mentioned in the = standard) and=20 also violates the security assumptions of = 802.11.

 -Bob
 

 

From: Jeff Joslin=20 [mailto:jjoslin@belairnetworks.com]
Sent: Friday, April 28, = 2006=20 12:19 PM
To: capwap@frascone.com
Subject: RE: = [Capwap]=20 BSSID-WLAN mappings

You can = implement=20 multiple SSID with single BSSID by having only one SSID in the beacon; = the=20 others SSIDs are hidden. If a client broadcasts a probe for one of those = hidden=20 SSIDs the AP will respond and the client can then do a normal = association. The=20 AP maintains one broadcast/multicast key for each encryption type (WEP, = TKIP,=20 AES) and uses the appropriate one according to the encryption type of = the=20 frame’s SSID. This allows a certain amount of information leakage = between SSIDs,=20 but in most applications this is = acceptable.

 

The above = scheme works,=20 after a fashion, but creates some client compatibility issues. Multiple = BSSID is=20 preferable.

 

One SSID = =3D=3D 1 WLAN. In=20 general we cannot assume that 1 BSSID =3D=3D 1 = WLAN.

 

Perhaps 1 = VLAN =3D=3D 1=20 WLAN is more helpful? It is standard practice to map each SSID to a = separate=20 VLAN.

 

Jeff=20 Joslin

Senior = Network=20 Architect

BelAir=20 Networks

 

From: Pat=20 Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: 28 April 2006 2:57 = PM
To: Puneet; Bob O'Hara=20 (boohara)
Cc:=20 capwap@frascone.com
Subject:=20 RE: [Capwap] BSSID-WLAN mappings

 

Well, first, = there is=20 no way that I am aware of where you can have multiple SSIDs for a single = BSSID.=20 Furthermore, if one were to do this, how would you handle broadcast = packet=20 encryption, where a station would see packets from a BSSID, but would = not be=20 able to decrypt it - presumably because the AC would have multiple GTKs, = not=20 indexed on a BSSID, but some other non-defined=20 mechanism.

 

I contend 1 = BSSID =3D=3D 1=20 WLAN.

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

 

 

From: Puneet=20 [mailto:pb.ietf@gmail.com]
Sent: Monday, April 17, 2006 = 10:39=20 AM
To: Bob O'Hara=20 (boohara)
Cc:=20 capwap@frascone.com
Subject:=20 Re: [Capwap] BSSID-WLAN mappings

Bob,

> We = should=20 not be implementing, or requiring an CAPWAP implementation to = implement a=20 method
> that lowers the security of the = WLAN.

I=20 am not sure I understand the argument here: supporting open or WEP = also does=20 the same thing, but CAPWAP supports those encryption protocols. CAPWAP = does=20 not force everyone to support WEP, but it *allows* it to be setup on a = WLAN.=20 Along the same lines we should allow this mapping too. Maybe make a = note that=20 it does not allow WLAN traffic separation into logical groups over the = air=20 (Saravanans point)

Thanks,
Puneet

On 4/17/06, Bob O'Hara (boohara) <boohara@cisco.com>=20 wrote:

There are = also=20 security issues when there is not a 1:1 mapping of WLAN to = BSSID. =20 Without this restriction, a station will not have any assurance that = traffic=20 it believes is encrypted and protected according to the policy of the = WLAN to=20 which it is associated is not being decrypted by an oracle (the AP) = and=20 rebroadcast to other stations without the same requirements for = abiding with=20 the same security policies.

 

We should = not be=20 implementing, or requiring an CAPWAP implementation to implement a = method that=20 lowers the security of the WLAN.

 -Bob
  =

 

 

From: Puneet [mailto: = pb.ietf@gmail.com]=20

Sent: Sunday,=20 April 16, 2006 4:47 PM
To:=20 Saravanan Govindan
Cc: capwap@frascone.com
Subject: Re: [Capwap] = BSSID-WLAN=20 mappings

Hi=20 Saravanan,

I see your = point, but=20 this seems to address a very specific deployment scenario (service = providers=20 sharing WLAN equipment). If nothing else in the CAPWAP messages is = dependent=20 on this, then this should be a recommendation instead of a mandate. = That way=20 the protocol remains inclusive, and also meets its=20 objective.

I think it is very important = that=20 existing implementations are not excluded just because they dont seem = to meet=20 one specific need in a specific deployment = scenario.

Thanks,
Puneet

On 4/15/06, Saravanan Govindan <saravanang@hotmail.com> = wrote:=20

Hi Puneet,

My concern = regarding=20 the BSSID - WLAN mapping is based on the mandatory
Objective = "Logical=20 Groups" (Section 5.1.1 of CAPWAP Objectives).

The Objective = requires=20 that WTP traffic be kept logically distinct among
logical groups. = This=20 arises from the commercial need of service providers
sharing WLAN=20 infrastructure equipment. Service providers want their traffic
to = be=20 distinguished both over the wireless environment (e.g. BSSIDS) and =
over=20 the AC-WTP environment (e.g. WLANs).

The BSSID-WLAN mapping = issue is=20 the technical requirement coming from this
commercial need. It = allows an AC=20 - or WTP - to decide how logical groups are
separated over the = wireless and=20 AC-WTP segments. So by making this mapping,
CAPWAP frames of = different=20 logical groups (WLANs) can be distinctly
exchanged.

I agree = with=20 others that this mapping should not exclude any implementation
- my = concern=20 is that the mapping be including in the first place.=20 =

Cheers,

Saravanan




>  -----= -------------------------
>=20 *From:* Puneet [mailto:pb.ietf@gmail.com]
> *Sent:* Friday, April = 14, 2006=20 12:29 AM
> *To:* capwap@frascone.com
> *Subject:* [Capwap] = BSSID-WLAN=20 mappings
>
> the BSSID description in Section 11.9.1 'WTP = Radio=20 Configuration' notes
> that a WTP that supports 16 WLANS MUST = have 16=20 MAC addresses reserved for
> it. Why? ie. what part of the = protocol=20 does not work if we have multiple
> SSIDs on a single BSSID? = (whether=20 thats good design or bad is a different
> matter). Since the = WLAN ID=20 could be used in all such places to convey
WLAN
> = information back=20 to the AC, why do we need to mandate this 1:1 BSSID-WLAN
>=20 mapping?
>
> Thanks,
> Puneet
>
>=20 _________________________________________________________________ =
> To=20 unsubscribe or modify your subscription options, please visit:
> = http://lists.frascone.com/mailman/listinfo/capwap=20
>
> Archives: http://lists.frascone.com/pipermail/capwap
>
_________________________________________________________________=20
Get an advanced look at the new version of MSN Messenger.
http://messenger.msn.com.sg/Beta/Default.aspx=20




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

 

------_=_NextPart_001_01C66AFA.CB0A7CA6-- --===============0851486076== 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 --===============0851486076==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 28 15:47:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZYw6-0003TR-Sy for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 15:47:30 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZYw4-0007ZA-Lw for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 15:47:30 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 26D2A430092 for ; Fri, 28 Apr 2006 12:47:28 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B0B9843005F for ; Fri, 28 Apr 2006 12:46:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9EA09398037 for ; Fri, 28 Apr 2006 12:46:38 -0700 (PDT) X-Greylist-Status: Sender first seen 00:27:35 ago Received: from postal2.belairnetworks.com (unknown [142.46.200.242]) by zoidberg.tigertech.net (Postfix) with ESMTP id 51153398025 for ; Fri, 28 Apr 2006 12:46:36 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] BSSID-WLAN mappings Date: Fri, 28 Apr 2006 15:46:35 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] BSSID-WLAN mappings Thread-Index: AcZiRe5rwuKfEiOmRj+0tGKDGix2rAIr0ODAAACD/VAAAMd8kAAAINMw From: "Jeff Joslin" To: "Bob O'Hara (boohara)" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.078 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO, HTML_60_70, 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="===============0922970197==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9a0a5b57b7540919633bb8f7cd3cb4bd This is a multi-part message in MIME format. --===============0922970197== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66AFC.75301AAC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66AFC.75301AAC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. =20 Jeff =20 _____ =20 From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: 28 April 2006 3:35 PM To: capwap@frascone.com Subject: RE: [Capwap] BSSID-WLAN mappings =20 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 =20 =20 =20 _____ =20 From: Jeff Joslin [mailto:jjoslin@belairnetworks.com]=20 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. =20 The above scheme works, after a fashion, but creates some client compatibility issues. Multiple BSSID is preferable. =20 One SSID =3D=3D 1 WLAN. In general we cannot assume that 1 BSSID =3D=3D = 1 WLAN. =20 Perhaps 1 VLAN =3D=3D 1 WLAN is more helpful? It is standard practice to = map each SSID to a separate VLAN. =20 Jeff Joslin Senior Network Architect BelAir Networks =20 _____ =20 From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: 28 April 2006 2:57 PM To: Puneet; Bob O'Hara (boohara) Cc: capwap@frascone.com Subject: RE: [Capwap] BSSID-WLAN mappings =20 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. =20 I contend 1 BSSID =3D=3D 1 WLAN. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 _____ =20 From: Puneet [mailto:pb.ietf@gmail.com]=20 Sent: Monday, April 17, 2006 10:39 AM To: Bob O'Hara (boohara) Cc: capwap@frascone.com Subject: Re: [Capwap] BSSID-WLAN mappings Bob, =09 > We should not be implementing, or requiring an CAPWAP implementation to implement a method=20 > that lowers the security of the WLAN. =09 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) =09 Thanks, Puneet 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 We should not be implementing, or requiring an CAPWAP implementation to implement a method that lowers the security of the WLAN. -Bob =20 =20 =20 =09 _____ =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, =09 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. =09 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. =09 Thanks, Puneet On 4/15/06, Saravanan Govindan wrote:=20 Hi Puneet, =09 My concern regarding the BSSID - WLAN mapping is based on the mandatory Objective "Logical Groups" (Section 5.1.1 of CAPWAP Objectives). =09 The Objective requires that WTP traffic be kept logically distinct among=20 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=20 over the AC-WTP environment (e.g. WLANs). =09 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,=20 CAPWAP frames of different logical groups (WLANs) can be distinctly exchanged. =09 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 =09 Cheers, =09 Saravanan =09 =09 =09 =09 > ------------------------------ > *From:* Puneet [mailto:pb.ietf@gmail.com] > *Sent:* Friday, April 14, 2006 12:29 AM=20 > *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=20 > 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=20 WLAN > information back to the AC, why do we need to mandate this 1:1 BSSID-WLAN > mapping? > > Thanks, > Puneet > > _________________________________________________________________=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 _________________________________________________________________=20 Get an advanced look at the new version of MSN Messenger.=20 http://messenger.msn.com.sg/Beta/Default.aspx=20 =20 =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =20 ------_=_NextPart_001_01C66AFC.75301AAC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 =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) [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 =3D=3D 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) <boohara@cisco.com> 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 <saravanang@hotmail.com> 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

 

------_=_NextPart_001_01C66AFC.75301AAC-- --===============0922970197== 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 --===============0922970197==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 28 16:27:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZZYY-0003L6-Sh for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 16:27:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZYNz-0005NZ-DR for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 15:12:15 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FZY9h-0004XU-4f for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 14:57:33 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E23F24300D4 for ; Fri, 28 Apr 2006 11:57:27 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 0CC7843004F for ; Fri, 28 Apr 2006 11:56:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id ECB87398032 for ; Fri, 28 Apr 2006 11:56:45 -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 CDA32398025 for ; Fri, 28 Apr 2006 11:56:41 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-3.cisco.com with ESMTP; 28 Apr 2006 11:56:41 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3SIufh0018362; Fri, 28 Apr 2006 11:56: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); Fri, 28 Apr 2006 11:56:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] BSSID-WLAN mappings Date: Fri, 28 Apr 2006 11:56:37 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201CBA532@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] BSSID-WLAN mappings Thread-Index: AcZiRe5rwuKfEiOmRj+0tGKDGix2rAIr0ODA From: "Pat Calhoun (pacalhou)" To: "Puneet" , "Bob O'Hara (boohara)" X-OriginalArrivalTime: 28 Apr 2006 18:56:41.0313 (UTC) FILETIME=[7C647D10:01C66AF5] 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@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="===============1604638730==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 544c2133b952fa264803d857bb70855b This is a multi-part message in MIME format. --===============1604638730== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66AF5.7C25FF3E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66AF5.7C25FF3E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. =20 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]=20 Sent: Monday, April 17, 2006 10:39 AM To: Bob O'Hara (boohara) Cc: capwap@frascone.com Subject: Re: [Capwap] BSSID-WLAN mappings =09 =09 Bob, =09 > We should not be implementing, or requiring an CAPWAP implementation to implement a method=20 > that lowers the security of the WLAN. =09 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) =09 Thanks, Puneet =09 =09 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 We should not be implementing, or requiring an CAPWAP implementation to implement a method that lowers the security of the WLAN. -Bob =20 =20 ________________________________ =09 From: Puneet [mailto: pb.ietf@gmail.com ]=20 =09 =09 Sent: Sunday, April 16, 2006 4:47 PM To: Saravanan Govindan Cc: capwap@frascone.com Subject: Re: [Capwap] BSSID-WLAN mappings =09 =09 =09 Hi Saravanan, =09 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. =09 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. =09 Thanks, Puneet =09 =09 =09 On 4/15/06, Saravanan Govindan wrote:=20 Hi Puneet, =09 My concern regarding the BSSID - WLAN mapping is based on the mandatory Objective "Logical Groups" (Section 5.1.1 of CAPWAP Objectives). =09 The Objective requires that WTP traffic be kept logically distinct among=20 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=20 over the AC-WTP environment (e.g. WLANs). =09 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,=20 CAPWAP frames of different logical groups (WLANs) can be distinctly exchanged. =09 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 =09 Cheers, =09 Saravanan =09 =09 =09 =09 > ------------------------------ > *From:* Puneet [mailto:pb.ietf@gmail.com] > *Sent:* Friday, April 14, 2006 12:29 AM=20 > *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=20 > 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=20 WLAN > information back to the AC, why do we need to mandate this 1:1 BSSID-WLAN > mapping? > > Thanks, > Puneet > > _________________________________________________________________=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 _________________________________________________________________=20 Get an advanced look at the new version of MSN Messenger.=20 http://messenger.msn.com.sg/Beta/Default.aspx=20 =09 =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 ------_=_NextPart_001_01C66AF5.7C25FF3E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Well,=20 first, there is no way that I am aware of where you can have multiple = SSIDs for=20 a single BSSID. Furthermore, if one were to do this, how would you = handle=20 broadcast packet encryption, where a station would see packets from a = BSSID, but=20 would not be able to decrypt it - presumably because the AC would have = multiple=20 GTKs, not indexed on a BSSID, but some other non-defined=20 mechanism.
 
I=20 contend 1 BSSID =3D=3D 1 WLAN.

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

 

From: Puneet = [mailto:pb.ietf@gmail.com]=20
Sent: Monday, April 17, 2006 10:39 AM
To: Bob = O'Hara=20 (boohara)
Cc: capwap@frascone.com
Subject: Re: = [Capwap]=20 BSSID-WLAN mappings

Bob,

> We=20 should not be implementing, or requiring an CAPWAP implementation to = implement=20 a method
> that lowers the security of the = WLAN.

I=20 am not sure I understand the argument here: supporting open or WEP = also does=20 the same thing, but CAPWAP supports those encryption protocols. CAPWAP = does=20 not force everyone to support WEP, but it *allows* it to be setup on a = WLAN.=20 Along the same lines we should allow this mapping too. Maybe make a = note that=20 it does not allow WLAN traffic separation into logical groups over the = air=20 (Saravanans point)

Thanks,
Puneet

On 4/17/06, Bob O'Hara=20 (boohara) <boohara@cisco.com>=20 wrote:
There=20 are also security issues when there is not a 1:1 mapping of WLAN to=20 BSSID.  Without this restriction, a station will not have any = assurance=20 that traffic it believes is encrypted and protected according to the = policy=20 of the WLAN to which it is associated is not being decrypted by an = oracle=20 (the AP) and rebroadcast to other stations without the same = requirements for=20 abiding with the same security policies.
 
We=20 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]=20
Sent: Sunday,=20 April 16, 2006 4:47 PM
To: Saravanan = Govindan
Cc: capwap@frascone.com
Subject: Re: = [Capwap]=20 BSSID-WLAN mappings

Hi Saravanan,

I see your point, but this seems to = address=20 a very specific deployment scenario (service providers sharing WLAN=20 equipment). If nothing else in the CAPWAP messages is dependent on = this,=20 then this should be a recommendation instead of a mandate. That way = the=20 protocol remains inclusive, and also meets its objective.

I = think it=20 is very important that existing implementations are not excluded = just=20 because they dont seem to meet one specific need in a specific = deployment=20 scenario.

Thanks,
Puneet


On 4/15/06, Saravanan=20 Govindan <saravanang@hotmail.com> wrote:=20
Hi=20 Puneet,

My concern regarding the BSSID - WLAN mapping is = based on=20 the mandatory
Objective "Logical Groups" (Section 5.1.1 of = CAPWAP=20 Objectives).

The Objective requires that WTP traffic be = kept=20 logically distinct among
logical groups. This arises from the=20 commercial need of service providers
sharing WLAN = infrastructure=20 equipment. Service providers want their traffic
to be = distinguished=20 both over the wireless environment (e.g. BSSIDS) and
over the = AC-WTP=20 environment (e.g. WLANs).

The BSSID-WLAN mapping issue is = the=20 technical requirement coming from this
commercial need. It = allows an AC=20 - or WTP - to decide how logical groups are
separated over the = wireless=20 and AC-WTP segments. So by making this mapping,
CAPWAP frames = of=20 different logical groups (WLANs) can be = distinctly
exchanged.

I=20 agree with others that this mapping should not exclude any=20 implementation
- my concern is that the mapping be including in = the=20 first place.=20 =

Cheers,

Saravanan




>  -----= -------------------------
>=20 *From:* Puneet [mailto:pb.ietf@gmail.com]
> *Sent:* Friday, = April 14,=20 2006 12:29 AM
> *To:* capwap@frascone.com
> *Subject:* = [Capwap]=20 BSSID-WLAN mappings
>
> the BSSID description in = Section=20 11.9.1 'WTP Radio Configuration' notes
> that a WTP that = supports 16=20 WLANS MUST have 16 MAC addresses reserved for
> it. Why? = ie. what=20 part of the protocol does not work if we have multiple
> = SSIDs on a=20 single BSSID? (whether thats good design or bad is a = different
>=20 matter). Since the WLAN ID could be used in all such places to = convey=20
WLAN
> information back to the AC, why do we need to = mandate=20 this 1:1 BSSID-WLAN
> mapping?
>
> = Thanks,
>=20 Puneet
>
>=20 _________________________________________________________________ =
>=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
Get an advanced look at the new version of MSN Messenger. =
http://messenger.msn.com.sg/Beta/Default.aspx=20 =



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


------_=_NextPart_001_01C66AF5.7C25FF3E-- --===============1604638730== 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 --===============1604638730==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 28 16:39:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZZkK-0001W3-LG for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 16:39:24 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZZkH-0002dT-PM for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 16:39:24 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1C32B4300B7 for ; Fri, 28 Apr 2006 13:39:21 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 57D5843004F for ; Fri, 28 Apr 2006 13:38:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4646B398026 for ; Fri, 28 Apr 2006 13:38:28 -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 1ED8A398028 for ; Fri, 28 Apr 2006 13:38:24 -0700 (PDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 28 Apr 2006 13:38:25 -0700 X-IronPort-AV: i="4.04,164,1144047600"; d="scan'208,217"; a="1799747765:sNHT77479056" 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 k3SKcOVI011717; Fri, 28 Apr 2006 13:38:24 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Apr 2006 13:38:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] BSSID-WLAN mappings Date: Fri, 28 Apr 2006 13:38:23 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC0175B515@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] BSSID-WLAN mappings Thread-Index: AcZiRe5rwuKfEiOmRj+0tGKDGix2rAIr0ODAAACD/VAAAMd8kAAAINMwAAIMdMA= From: "Bob O'Hara (boohara)" To: "Jeff Joslin" , X-OriginalArrivalTime: 28 Apr 2006 20:38:24.0306 (UTC) FILETIME=[B20F5120:01C66B03] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.402 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, 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="===============1880382825==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 86df8ce7a29490312557c74a439f90f8 This is a multi-part message in MIME format. --===============1880382825== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66B03.B1C84C42" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66B03.B1C84C42 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. =20 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. =20 -Bob =20 =20 ________________________________ From: Jeff Joslin [mailto:jjoslin@belairnetworks.com]=20 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. =20 Jeff =20 ________________________________ From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: 28 April 2006 3:35 PM To: capwap@frascone.com Subject: RE: [Capwap] BSSID-WLAN mappings =20 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 =20 =20 =20 ________________________________ From: Jeff Joslin [mailto:jjoslin@belairnetworks.com]=20 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. =20 The above scheme works, after a fashion, but creates some client compatibility issues. Multiple BSSID is preferable. =20 One SSID =3D=3D 1 WLAN. In general we cannot assume that 1 BSSID =3D=3D = 1 WLAN. =20 Perhaps 1 VLAN =3D=3D 1 WLAN is more helpful? It is standard practice to = map each SSID to a separate VLAN. =20 Jeff Joslin Senior Network Architect BelAir Networks =20 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: 28 April 2006 2:57 PM To: Puneet; Bob O'Hara (boohara) Cc: capwap@frascone.com Subject: RE: [Capwap] BSSID-WLAN mappings =20 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. =20 I contend 1 BSSID =3D=3D 1 WLAN. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Puneet [mailto:pb.ietf@gmail.com]=20 Sent: Monday, April 17, 2006 10:39 AM To: Bob O'Hara (boohara) Cc: capwap@frascone.com Subject: Re: [Capwap] BSSID-WLAN mappings Bob, =09 > We should not be implementing, or requiring an CAPWAP implementation to implement a method=20 > that lowers the security of the WLAN. =09 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) =09 Thanks, Puneet 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 We should not be implementing, or requiring an CAPWAP implementation to implement a method that lowers the security of the WLAN. -Bob =20 =20 =20 =09 ________________________________ 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, =09 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. =09 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. =09 Thanks, Puneet On 4/15/06, Saravanan Govindan wrote:=20 Hi Puneet, =09 My concern regarding the BSSID - WLAN mapping is based on the mandatory Objective "Logical Groups" (Section 5.1.1 of CAPWAP Objectives). =09 The Objective requires that WTP traffic be kept logically distinct among=20 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=20 over the AC-WTP environment (e.g. WLANs). =09 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,=20 CAPWAP frames of different logical groups (WLANs) can be distinctly exchanged. =09 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 =09 Cheers, =09 Saravanan =09 =09 =09 =09 > ------------------------------ > *From:* Puneet [mailto:pb.ietf@gmail.com] > *Sent:* Friday, April 14, 2006 12:29 AM=20 > *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=20 > 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=20 WLAN > information back to the AC, why do we need to mandate this 1:1 BSSID-WLAN > mapping? > > Thanks, > Puneet > > _________________________________________________________________=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 _________________________________________________________________=20 Get an advanced look at the new version of MSN Messenger.=20 http://messenger.msn.com.sg/Beta/Default.aspx=20 =20 =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =20 ------_=_NextPart_001_01C66B03.B1C84C42 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
As I said, this is a proprietary extension, = even if it=20 might have been provided on some Cisco products.  I hold that = CAPWAP is=20 chartered to implement a protocol to support 802.11, not the myriad = proprietary=20 extension that have been hammered onto its side over the=20 years.
 
But, the more damning problem for this is the = lowering of=20 security and the violation of the security assumptions on which 802.11i = is=20 based.  Crossing the boundary of a security domain, even if "only" = for=20 multicast, dramatically increases the opportunity for compromise of data = that communicants believe is secure.
 

 -Bob
 

 

From: Jeff Joslin=20 [mailto:jjoslin@belairnetworks.com]
Sent: Friday, April 28, = 2006=20 12:47 PM
To: Bob O'Hara (boohara);=20 capwap@frascone.com
Subject: RE: [Capwap] BSSID-WLAN=20 mappings

Indeed, the = M-SSID=20 mechanism I described is not in the standard but has been implemented by = a=20 number of different vendors, including, as I recall, Cisco Aironet. Now = that=20 802.11 chip sets and drivers have better support for M-BSSID, there is = little=20 reason to use the more problematic M-SSID. Its only advantage over = M-BSSID is=20 that M-SSID uses up fewer MAC addresses.

 

Jeff

 

From: Bob=20 O'Hara (boohara) [mailto:boohara@cisco.com]
Sent: 28 April 2006 3:35 = PM
To: = capwap@frascone.com
Subject: RE: [Capwap] BSSID-WLAN=20 mappings

 

The mechanism = below is,=20 of course, not compliant with the 802.11 standard.  It is a = proprietary=20 extension.  It is not clear to me why CAPWAP should support this = mechanism,=20 or any other proprietary mechanism.  As Jeff points out below, this = is not=20 compatible with all clients (most likely because the mechanism is not = mentioned=20 in the standard) and also violates the security assumptions of=20 802.11.

 -Bob
 =20

 

 

From: Jeff=20 Joslin [mailto:jjoslin@belairnetworks.com]
Sent: Friday, April 28, 2006 = 12:19=20 PM
To:=20 capwap@frascone.com
Subject:=20 RE: [Capwap] BSSID-WLAN mappings

You can = implement=20 multiple SSID with single BSSID by having only one SSID in the beacon; = the=20 others SSIDs are hidden. If a client broadcasts a probe for one of those = hidden=20 SSIDs the AP will respond and the client can then do a normal = association. The=20 AP maintains one broadcast/multicast key for each encryption type (WEP, = TKIP,=20 AES) and uses the appropriate one according to the encryption type of = the=20 frame’s SSID. This allows a certain amount of information leakage = between SSIDs,=20 but in most applications this is = acceptable.

 

The above = scheme works,=20 after a fashion, but creates some client compatibility issues. Multiple = BSSID is=20 preferable.

 

One SSID = =3D=3D 1 WLAN. In=20 general we cannot assume that 1 BSSID =3D=3D 1 = WLAN.

 

Perhaps 1 = VLAN =3D=3D 1=20 WLAN is more helpful? It is standard practice to map each SSID to a = separate=20 VLAN.

 

Jeff=20 Joslin

Senior = Network=20 Architect

BelAir=20 Networks

 

From: Pat=20 Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: 28 April 2006 2:57 = PM
To: Puneet; Bob O'Hara=20 (boohara)
Cc:=20 capwap@frascone.com
Subject:=20 RE: [Capwap] BSSID-WLAN mappings

 

Well, first, = there is=20 no way that I am aware of where you can have multiple SSIDs for a single = BSSID.=20 Furthermore, if one were to do this, how would you handle broadcast = packet=20 encryption, where a station would see packets from a BSSID, but would = not be=20 able to decrypt it - presumably because the AC would have multiple GTKs, = not=20 indexed on a BSSID, but some other non-defined=20 mechanism.

 

I contend 1 = BSSID =3D=3D 1=20 WLAN.

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

 

 

From: Puneet=20 [mailto:pb.ietf@gmail.com]
Sent: Monday, April 17, 2006 = 10:39=20 AM
To: Bob O'Hara=20 (boohara)
Cc:=20 capwap@frascone.com
Subject:=20 Re: [Capwap] BSSID-WLAN mappings

Bob,

> We = should=20 not be implementing, or requiring an CAPWAP implementation to = implement a=20 method
> that lowers the security of the = WLAN.

I=20 am not sure I understand the argument here: supporting open or WEP = also does=20 the same thing, but CAPWAP supports those encryption protocols. CAPWAP = does=20 not force everyone to support WEP, but it *allows* it to be setup on a = WLAN.=20 Along the same lines we should allow this mapping too. Maybe make a = note that=20 it does not allow WLAN traffic separation into logical groups over the = air=20 (Saravanans point)

Thanks,
Puneet

On 4/17/06, Bob O'Hara (boohara) <boohara@cisco.com>=20 wrote:

There are = also=20 security issues when there is not a 1:1 mapping of WLAN to = BSSID. =20 Without this restriction, a station will not have any assurance that = traffic=20 it believes is encrypted and protected according to the policy of the = WLAN to=20 which it is associated is not being decrypted by an oracle (the AP) = and=20 rebroadcast to other stations without the same requirements for = abiding with=20 the same security policies.

 

We should = not be=20 implementing, or requiring an CAPWAP implementation to implement a = method that=20 lowers the security of the WLAN.

 -Bob
  =

 

 

From: Puneet [mailto: = pb.ietf@gmail.com]=20

Sent: Sunday,=20 April 16, 2006 4:47 PM
To:=20 Saravanan Govindan
Cc: capwap@frascone.com
Subject: Re: [Capwap] = BSSID-WLAN=20 mappings

Hi=20 Saravanan,

I see your = point, but=20 this seems to address a very specific deployment scenario (service = providers=20 sharing WLAN equipment). If nothing else in the CAPWAP messages is = dependent=20 on this, then this should be a recommendation instead of a mandate. = That way=20 the protocol remains inclusive, and also meets its=20 objective.

I think it is very important = that=20 existing implementations are not excluded just because they dont seem = to meet=20 one specific need in a specific deployment = scenario.

Thanks,
Puneet

On 4/15/06, Saravanan Govindan <saravanang@hotmail.com> = wrote:=20

Hi Puneet,

My concern = regarding=20 the BSSID - WLAN mapping is based on the mandatory
Objective = "Logical=20 Groups" (Section 5.1.1 of CAPWAP Objectives).

The Objective = requires=20 that WTP traffic be kept logically distinct among
logical groups. = This=20 arises from the commercial need of service providers
sharing WLAN=20 infrastructure equipment. Service providers want their traffic
to = be=20 distinguished both over the wireless environment (e.g. BSSIDS) and =
over=20 the AC-WTP environment (e.g. WLANs).

The BSSID-WLAN mapping = issue is=20 the technical requirement coming from this
commercial need. It = allows an AC=20 - or WTP - to decide how logical groups are
separated over the = wireless and=20 AC-WTP segments. So by making this mapping,
CAPWAP frames of = different=20 logical groups (WLANs) can be distinctly
exchanged.

I agree = with=20 others that this mapping should not exclude any implementation
- my = concern=20 is that the mapping be including in the first place.=20 =

Cheers,

Saravanan




>  -----= -------------------------
>=20 *From:* Puneet [mailto:pb.ietf@gmail.com]
> *Sent:* Friday, April = 14, 2006=20 12:29 AM
> *To:* capwap@frascone.com
> *Subject:* [Capwap] = BSSID-WLAN=20 mappings
>
> the BSSID description in Section 11.9.1 'WTP = Radio=20 Configuration' notes
> that a WTP that supports 16 WLANS MUST = have 16=20 MAC addresses reserved for
> it. Why? ie. what part of the = protocol=20 does not work if we have multiple
> SSIDs on a single BSSID? = (whether=20 thats good design or bad is a different
> matter). Since the = WLAN ID=20 could be used in all such places to convey
WLAN
> = information back=20 to the AC, why do we need to mandate this 1:1 BSSID-WLAN
>=20 mapping?
>
> Thanks,
> Puneet
>
>=20 _________________________________________________________________ =
> To=20 unsubscribe or modify your subscription options, please visit:
> = http://lists.frascone.com/mailman/listinfo/capwap=20
>
> Archives: http://lists.frascone.com/pipermail/capwap
>
_________________________________________________________________=20
Get an advanced look at the new version of MSN Messenger.
http://messenger.msn.com.sg/Beta/Default.aspx=20

 


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

 

------_=_NextPart_001_01C66B03.B1C84C42-- --===============1880382825== 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 --===============1880382825==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 28 16:53:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZZyC-0006an-Je for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 16:53:44 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZZy9-0003Tt-BH for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 16:53:44 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E76334300AD for ; Fri, 28 Apr 2006 13:53:40 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 05CD443004F for ; Fri, 28 Apr 2006 13:52:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id ED2C2398037 for ; Fri, 28 Apr 2006 13:52:48 -0700 (PDT) Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0DF01398027 for ; Fri, 28 Apr 2006 13:52:45 -0700 (PDT) Received: from Matt-Holdrege2.verizon.net ([86.213.172.137]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0IYG0036Z9ZKBRD1@vms044.mailsrvcs.net> for capwap@frascone.com; Fri, 28 Apr 2006 15:52:35 -0500 (CDT) Date: Fri, 28 Apr 2006 22:52:35 +0200 From: Matt Holdrege Subject: RE: [Capwap] BSSID-WLAN mappings In-reply-to: X-Sender: res06gzk@incoming.verizon.net To: capwap@frascone.com Message-id: <6.0.3.0.2.20060428225025.03723640@incoming.verizon.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 References: X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.857 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, FORGED_RCVD_HELO, HTML_30_40, HTML_MESSAGE 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: , Content-Type: multipart/mixed; boundary="===============1003370167==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d188b91ff79eaa1be2a0e9635461d9a --===============1003370167== Content-type: multipart/alternative; boundary="Boundary_(ID_OlRAQ1vCNh8mb69n/sOnYQ)" --Boundary_(ID_OlRAQ1vCNh8mb69n/sOnYQ) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT We implemented the multi-SSID with a single BSSID at first. Then we discovered that a certain OS that dominates the laptop market didn't like it. So we stopped doing that and went to a separate BSSID per SSID. As for SSID = VLAN, that may not be a good idea. There is no reason not to have multiple VLAN's per SSID. -Matt At 09:18 PM 4/28/2006, Jeff Joslin wrote: >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) ><boohara@cisco.com> 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 ><saravanang@hotmail.com> 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 --Boundary_(ID_OlRAQ1vCNh8mb69n/sOnYQ) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable We implemented the multi-SSID with a single BSSID at first. Then we discovered that a certain OS that dominates the laptop market didn't like it. So we stopped doing that and went to a separate BSSID per SSID. As for SSID =3D VLAN, that may not be a good idea. There is no reason not to have multiple VLAN's per SSID.

-Matt

At 09:18 PM 4/28/2006, Jeff Joslin wrote:

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=92s 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) [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 = =3D=3D 1 WLAN.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
 
 
From: Puneet [mailto:pb.ietf@g= mail.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) <boohara@cisco.com> wrote:
There are also securi= ty 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 deploymen= t scenario (service providers sharing WLAN equipment). If nothing else in= the CAPWAP messages is dependent on this, then this should be a recommen= dation 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 ex= cluded just because they dont seem to meet one specific need in a specifi= c deployment scenario.

Thanks,
Puneet

On 4/15/06, Saravanan Govindan<= /b> <saravanang@hotmail.com<= /a>> wrote:
Hi Puneet,

My concern regarding the BSSID - WLAN mapping is based on the mandato= ry
Objective "Logical Groups" (Section 5.1.1 of CAPWAP Objecti= ves).

The Objective requires that WTP traffic be kept logically distinct am= ong
logical groups. This arises from the commercial need of service provi= ders
sharing WLAN infrastructure equipment. Service providers want their t= raffic
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 gro= ups are
separated over the wireless and AC-WTP segments. So by making this ma= pping,
CAPWAP frames of different logical groups (WLANs) can be distinctly
exchanged.

I agree with others that this mapping should not exclude any implemen= tation
- 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 res= erved 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 B= SSID-WLAN
> mapping?
>
> Thanks,
> Puneet
>
> ________________________________________________________________= _
> To unsubscribe or modify your subscription options, please visit= :
> ht= tp://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://mess= enger.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
--Boundary_(ID_OlRAQ1vCNh8mb69n/sOnYQ)-- --===============1003370167== 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 --===============1003370167==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 28 16:55:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZZze-0006hG-DA for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 16:55:14 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZZzb-0003VP-26 for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 16:55:14 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8F6064300A2 for ; Fri, 28 Apr 2006 13:55:10 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C645643008F for ; Fri, 28 Apr 2006 13:52:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 897A0144800E for ; Fri, 28 Apr 2006 13:52:52 -0700 (PDT) X-Greylist-Status: Sender first seen 01:33:48 ago Received: from postal2.belairnetworks.com (unknown [142.46.200.242]) by hermes.tigertech.net (Postfix) with ESMTP id C83661448004 for ; Fri, 28 Apr 2006 13:52:49 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] BSSID-WLAN mappings Date: Fri, 28 Apr 2006 16:52:48 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] BSSID-WLAN mappings Thread-Index: AcZiRe5rwuKfEiOmRj+0tGKDGix2rAIr0ODAAACD/VAAAMd8kAAAINMwAAIMdMAAAJl3AA== From: "Jeff Joslin" 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.1 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO, HTML_60_70, HTML_MESSAGE 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: , Content-Type: multipart/mixed; boundary="===============0992681225==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: caf889d1cc399d1b0eefae882d326da1 This is a multi-part message in MIME format. --===============0992681225== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66B05.B564BA66" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66B05.B564BA66 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree that CAPWAP need not support M-SSID, particularly given the security implications. =20 Jeff =20 =20 _____ =20 From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: 28 April 2006 4:38 PM To: Jeff Joslin; capwap@frascone.com Subject: RE: [Capwap] BSSID-WLAN mappings =20 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. =20 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. =20 -Bob =20 =20 =20 _____ =20 From: Jeff Joslin [mailto:jjoslin@belairnetworks.com]=20 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. =20 Jeff =20 _____ =20 From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: 28 April 2006 3:35 PM To: capwap@frascone.com Subject: RE: [Capwap] BSSID-WLAN mappings =20 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 =20 =20 =20 _____ =20 From: Jeff Joslin [mailto:jjoslin@belairnetworks.com]=20 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. =20 The above scheme works, after a fashion, but creates some client compatibility issues. Multiple BSSID is preferable. =20 One SSID =3D=3D 1 WLAN. In general we cannot assume that 1 BSSID =3D=3D = 1 WLAN. =20 Perhaps 1 VLAN =3D=3D 1 WLAN is more helpful? It is standard practice to = map each SSID to a separate VLAN. =20 Jeff Joslin Senior Network Architect BelAir Networks =20 _____ =20 From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: 28 April 2006 2:57 PM To: Puneet; Bob O'Hara (boohara) Cc: capwap@frascone.com Subject: RE: [Capwap] BSSID-WLAN mappings =20 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. =20 I contend 1 BSSID =3D=3D 1 WLAN. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 _____ =20 From: Puneet [mailto:pb.ietf@gmail.com]=20 Sent: Monday, April 17, 2006 10:39 AM To: Bob O'Hara (boohara) Cc: capwap@frascone.com Subject: Re: [Capwap] BSSID-WLAN mappings Bob, =09 > We should not be implementing, or requiring an CAPWAP implementation to implement a method=20 > that lowers the security of the WLAN. =09 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) =09 Thanks, Puneet 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 We should not be implementing, or requiring an CAPWAP implementation to implement a method that lowers the security of the WLAN. -Bob =20 =20 =20 =09 _____ =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, =09 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. =09 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. =09 Thanks, Puneet On 4/15/06, Saravanan Govindan wrote:=20 Hi Puneet, =09 My concern regarding the BSSID - WLAN mapping is based on the mandatory Objective "Logical Groups" (Section 5.1.1 of CAPWAP Objectives). =09 The Objective requires that WTP traffic be kept logically distinct among=20 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=20 over the AC-WTP environment (e.g. WLANs). =09 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,=20 CAPWAP frames of different logical groups (WLANs) can be distinctly exchanged. =09 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 =09 Cheers, =09 Saravanan =09 =09 =09 =09 > ------------------------------ > *From:* Puneet [mailto:pb.ietf@gmail.com] > *Sent:* Friday, April 14, 2006 12:29 AM=20 > *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=20 > 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=20 WLAN > information back to the AC, why do we need to mandate this 1:1 BSSID-WLAN > mapping? > > Thanks, > Puneet > > _________________________________________________________________=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 _________________________________________________________________=20 Get an advanced look at the new version of MSN Messenger.=20 http://messenger.msn.com.sg/Beta/Default.aspx=20 =20 =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =20 ------_=_NextPart_001_01C66B05.B564BA66 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree that CAPWAP need not = support M-SSID, particularly given the security = implications.

 

Jeff

 

 

From: Bob = O'Hara (boohara) [mailto:boohara@cisco.com]
Sent: 28 April 2006 4:38 = PM
To: Jeff Joslin; capwap@frascone.com
Subject: RE: [Capwap] = BSSID-WLAN mappings

 

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 =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) [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 =3D=3D 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) <boohara@cisco.com> 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 <saravanang@hotmail.com> 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

 

------_=_NextPart_001_01C66B05.B564BA66-- --===============0992681225== 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 --===============0992681225==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 28 17:23:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZaQe-000055-M2 for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 17:23:08 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZaQZ-0007Fx-PE for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 17:23:08 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1ED354300FD for ; Fri, 28 Apr 2006 14:23:03 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 8CB0E43005F for ; Fri, 28 Apr 2006 14:22:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 811A9398039 for ; Fri, 28 Apr 2006 14:22:38 -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 7FABF398028 for ; Fri, 28 Apr 2006 14:22:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=Yxt0w4xtzHWb8V1wq9iuGUmxSgwo2kp8OsoWSaPFYUxbTFhUIaZAxjxsGeL3GH/6; 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.36] (helo=elwamui-hybrid.atl.sa.earthlink.net) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1FZaQ4-00050I-Em; Fri, 28 Apr 2006 17:22:33 -0400 Received: from 216.31.249.246 by webmail.pas.earthlink.net with HTTP; Fri, 28 Apr 2006 17:22:32 -0400 Message-ID: <11752830.1146259352376.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Date: Fri, 28 Apr 2006 17:22:32 -0400 (EDT) From: "Scott G. Kelly" To: "Bob O'Hara (boohara)" , Jeff Joslin , capwap@frascone.com Subject: RE: [Capwap] BSSID-WLAN mappings 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: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710a0fc0e34270c046a753427044ec80114350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.36 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: dd887a8966a4c4c217a52303814d0b5f I agree with Bob - this is unacceptable from a security perspective. -----Original Message----- >From: "Bob O'Hara (boohara)" >Sent: Apr 28, 2006 4:38 PM >To: Jeff Joslin , capwap@frascone.com >Subject: RE: [Capwap] BSSID-WLAN mappings > >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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 28 19:20:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZcGL-0004x5-8o for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 19:20:37 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZcGJ-0004fR-Hx for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 19:20:37 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 36E414300C1 for ; Fri, 28 Apr 2006 16:20:34 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D5FC643005F for ; Fri, 28 Apr 2006 16:20:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 82B721448027 for ; Fri, 28 Apr 2006 16:20:05 -0700 (PDT) Received: from test-iport-1.cisco.com (test-iport-1.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id 3D3B8144800E for ; Fri, 28 Apr 2006 16:20:01 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 28 Apr 2006 16:20:01 -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 k3SNK0h0020288; Fri, 28 Apr 2006 16:20:01 -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, 28 Apr 2006 16:20:00 -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, 28 Apr 2006 16:19:59 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201CBA6BA@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: AcZlQnxrOUGpBkxiTMaWbF+BETuV+gF15U6w From: "Pat Calhoun (pacalhou)" To: "Scott G Kelly" , "Saravanan Govindan" X-OriginalArrivalTime: 28 Apr 2006 23:20:00.0865 (UTC) FILETIME=[45A8CD10:01C66B1A] X-Virus-Scanned: by amavisd-new-20030616-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 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 =20 > -----Original Message----- > From: Scott G Kelly [mailto:scott@hyperthought.com]=20 > Sent: Friday, April 21, 2006 5:52 AM > To: Saravanan Govindan > Cc: capwap > Subject: Re: [Capwap] Proposed Resolution to Issue 45=20 > -Issueoncombiningmessages >=20 > Hi Saravanan, >=20 > Saravanan Govindan wrote: > > Hi Scott, > >=20 > > I think David's note does address the issue on hand.=20 > >=20 > > 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=20 > alone for=20 > > this purpose, reason being that statistics are periodically=20 > exchanged. > >=20 > > My concern is that by using "any" control message to indicate=20 > > keepalive (Echo), the AC processing will be complicated. This is=20 > > because the AC will need to process each control message=20 > for both its own value (e.g. > > Configure Request) and also keepalive value.=20 >=20 > Of course, complexity is a function of many factors, but=20 > there is a straightforward way to implement an echo trigger=20 > with a flag and timer:=20 > when you receive a control message, unconditionally raise the flag.=20 > 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=20 > this works just fine. >=20 > 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=20 > whatever it is your AC does if a WTP doesn't report in a=20 > given echo interval (which may be nothing). Pretty basic stuff. >=20 > On the WTP, implementation is similar, except that if the=20 > flag is down, you send the keepalive. Again, very simple and basic. >=20 > > So I suggest keeping it simple - arrival of statistics message from=20 > > WTP means WTP is alive. >=20 > Certainly, a statistics message qualifies as a control=20 > message, so I have no issues with this statement when taken=20 > alone. I'm concerned with the earlier suggestion that the=20 > echo req/reply message be discarded and replaced by the=20 > statistics message. >=20 > In some cases, the keepalive interval must be *very* brief in=20 > order to facilitate rapid link loss detection and recovery. I=20 > know of one vendor who routinely uses a one second interval,=20 > and it's conceivable that in some scenarios one might choose=20 > to use even less. >=20 > 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 to find another AC), whereas the AC simply needs=20 > to somehow report the event.=20 > While in some cases reporting might be considered urgent,=20 > 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 it's=20 > 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=20 > remain wholly in the AC fastpath. >=20 > But say we eliminate the echo: what happens when, say, 500=20 > WTPs send stats potentially every second or less? >=20 > I think we still need the echo req/rsp. >=20 > Scott >=20 > >=20 > > Saravanan > >=20 > >=20 > >=20 > >=20 > >=20 > > -----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 > >=20 > > Just trying to close the loop: I think David's point (i.e.=20 > that echoes=20 > > should only be sent in the absence of other control=20 > traffic) is dead=20 > > on, and that this effectively closes the question as to=20 > whether echoes=20 > > 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: > > 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 >=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 Apr 28 20:14:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZd6j-0001ix-C5 for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 20:14:45 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZd6h-0007Qx-Vy for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 20:14:45 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5DCDB430104 for ; Fri, 28 Apr 2006 17:14:43 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 2A7BE43005F for ; Fri, 28 Apr 2006 17:14:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 137D139801B for ; Fri, 28 Apr 2006 17:14:25 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9A34A398013 for ; Fri, 28 Apr 2006 17:14:22 -0700 (PDT) Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k3T0EMfk025763; Fri, 28 Apr 2006 17:14:22 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k3T0ELbK025759; Fri, 28 Apr 2006 17:14:21 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 28 Apr 2006 17:14:21 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Pat Calhoun (pacalhou)" Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201CBA6BA@xmb-sjc-235.amer.cisco.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: 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: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 HI I'm having some problems understanding the "MAY only", which seems much more restrictive than needs be. Are you saying that an AC or WTP can only seen an ECHO request when it hasn't seen any control traffic after X amount of time? For example, if an AC sends, say, a config update request, then it cannot send an echo request before X ammount of time has elapsed? On Fri, 28 Apr 2006, 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 Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Apr 28 21:22:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZeA0-0005rw-4G for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 21:22:12 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZe9y-0001oU-R9 for capwap-archive@lists.ietf.org; Fri, 28 Apr 2006 21:22:12 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DC5AF4300F5 for ; Fri, 28 Apr 2006 18:22:07 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3B04543005F for ; Fri, 28 Apr 2006 18:21:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 17541398027 for ; Fri, 28 Apr 2006 18:21:47 -0700 (PDT) Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9F84B398026 for ; Fri, 28 Apr 2006 18:21:44 -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 k3T1LiYa008744 for ; Fri, 28 Apr 2006 18:21:44 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k3T1LiJn008740 for ; Fri, 28 Apr 2006 18:21:44 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 28 Apr 2006 18:21:44 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: capwap@frascone.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: Subject: [Capwap] RFCs for TLS 1.1 and DTLS published 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: de4f315c9369b71d7dd5909b42224370 HI, Good news for CAPWAP! RFC 4346 - The Transport Layer Security (TLS) Protocol Version 1.1 RFC 4347 - Datagram Transport Layer Security Just came out! 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 Sat Apr 29 00:18:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZgv1-0002QM-R1 for capwap-archive@lists.ietf.org; Sat, 29 Apr 2006 00:18:55 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZgv0-0004RK-Ck for capwap-archive@lists.ietf.org; Sat, 29 Apr 2006 00:18:55 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3FD784300AF for ; Fri, 28 Apr 2006 21:18:53 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4345543008F for ; Fri, 28 Apr 2006 21:18:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2C0721448008 for ; Fri, 28 Apr 2006 21:18:30 -0700 (PDT) Received: from test-iport-1.cisco.com (test-iport-1.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id 967E8144800A for ; Fri, 28 Apr 2006 21:18:27 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 28 Apr 2006 21:18:27 -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 k3T4IQh0001936; Fri, 28 Apr 2006 21:18:26 -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, 28 Apr 2006 21:18:26 -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, 28 Apr 2006 21:18:24 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201CBA746@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: AcZrId58IpqsZk0VRIWfScUraKEQWgAIchSg From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" X-OriginalArrivalTime: 29 Apr 2006 04:18:26.0578 (UTC) FILETIME=[F64BC720:01C66B43] X-Virus-Scanned: by amavisd-new-20030616-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: 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: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 I'm saying you restart the echo timer everytime you send a control packet. However, some implementation, for whatever reason, may opt to simply send the echo request after the expiration of the timer, and never reset it. One cannot penalize an implementation for doing so, since it is not technically breaking anything. My point was that the receiver must abide by the idle timer, and accept unexpected echos, and consider the link dead as per the rules. Be conservative in what you send, liberal in what you receive. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com]=20 > Sent: Friday, April 28, 2006 5:14 PM > To: Pat Calhoun (pacalhou) > Cc: Scott G Kelly; Saravanan Govindan; capwap > Subject: RE: [Capwap] Proposed Resolution to Issue 45=20 > -Issueoncombiningmessages >=20 > HI >=20 > I'm having some problems understanding the "MAY only", which=20 > seems much more restrictive than needs be. >=20 > Are you saying that an AC or WTP can only seen an ECHO=20 > request when it hasn't seen any control traffic after X=20 > amount of time? >=20 > For example, if an AC sends, say, a config update request,=20 > then it cannot send an echo request before X ammount of time=20 > has elapsed? >=20 > On Fri, 28 Apr 2006, Pat Calhoun (pacalhou) 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=20 > > 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=20 > > 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 > Regards, > /david t. perkins >=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 Sat Apr 29 10:29:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZqRl-0002K0-JQ for capwap-archive@lists.ietf.org; Sat, 29 Apr 2006 10:29:21 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZqRj-000133-VT for capwap-archive@lists.ietf.org; Sat, 29 Apr 2006 10:29:22 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 28B3043008C for ; Sat, 29 Apr 2006 07:29:18 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id AAA4F43006C for ; Sat, 29 Apr 2006 07:28:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 935F1144800D for ; Sat, 29 Apr 2006 07:28:58 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 08DFB144800A for ; Sat, 29 Apr 2006 07:28: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 k3TESt15012632; Sat, 29 Apr 2006 07:28:55 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k3TESsl6012627; Sat, 29 Apr 2006 07:28:54 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Sat, 29 Apr 2006 07:28:54 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Pat Calhoun (pacalhou)" Subject: RE: [Capwap] Proposed Resolution to Issue 45 -Issueoncombiningmessages In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201CBA746@xmb-sjc-235.amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new-20030616-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 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: 0bc60ec82efc80c84b8d02f4b0e4de22 HI, Thanks for the clarification. I also believe what you describe is the most appropriate behavior. On Fri, 28 Apr 2006, Pat Calhoun (pacalhou) wrote: > I'm saying you restart the echo timer everytime you send a control > packet. However, some implementation, for whatever reason, may opt to > simply send the echo request after the expiration of the timer, and > never reset it. One cannot penalize an implementation for doing so, > since it is not technically breaking anything. My point was that the > receiver must abide by the idle timer, and accept unexpected echos, and > consider the link dead as per the rules. > > Be conservative in what you send, liberal in what you receive. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems Regards, /david t. perkins _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Apr 29 16:13:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZvpF-0002x9-QA for capwap-archive@lists.ietf.org; Sat, 29 Apr 2006 16:13:57 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZvpE-0000mS-Bu for capwap-archive@lists.ietf.org; Sat, 29 Apr 2006 16:13:57 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7C4484300F7 for ; Sat, 29 Apr 2006 13:13:55 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7E6C4430059 for ; Sat, 29 Apr 2006 13:13:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7174A39801B for ; Sat, 29 Apr 2006 13:13:31 -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 DC35739800E for ; Sat, 29 Apr 2006 13:13:28 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 29 Apr 2006 13:13:28 -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 k3TKDRRT013324; Sat, 29 Apr 2006 13:13:28 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 29 Apr 2006 13:13: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] Use of "Status/WLANs" field in ctrl msgs Date: Sat, 29 Apr 2006 13:13:26 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201CBA7AA@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Use of "Status/WLANs" field in ctrl msgs Thread-Index: AcZacE6RkSMqFH7MSxOl2t1B8J+2ewRWJaeQ From: "Pat Calhoun (pacalhou)" To: "David T. Perkins" , "capwap" X-OriginalArrivalTime: 29 Apr 2006 20:13:27.0878 (UTC) FILETIME=[60884660:01C66BC9] 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: e1e48a527f609d1be2bc8d8a70eb76cb I think this is a good proposal. I am in the process of changing this section as per discussions on the list - and the request to add the Data Rate to the frame. I've created issue 111 to track this request. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com]=20 > Sent: Friday, April 07, 2006 11:22 AM > To: capwap > Subject: [Capwap] Use of "Status/WLANs" field in ctrl msgs >=20 > HI, >=20 > Presently, the "Status/WLANs" field in the CAPWAP header is=20 > not used (always has a value of zero) in CAPWAP control=20 > messages. I suggest that this contain a timestamp sent in a=20 > request and echoed back in a response to help determine=20 > retransmission timeout (RTO). The details for how to use this=20 > and the motivations are described in "UNIX Network=20 > Programming, vol 1, 3rd Ed" by Stevens, section 22.5 (starts=20 > on page 597). >=20 > Regards, > /david t. perkins >=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 Sat Apr 29 16:46:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZwKR-0005HY-5B for capwap-archive@lists.ietf.org; Sat, 29 Apr 2006 16:46:11 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZwKN-00026r-Dp for capwap-archive@lists.ietf.org; Sat, 29 Apr 2006 16:46:11 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CFAC34300A7 for ; Sat, 29 Apr 2006 13:46:02 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A2BC243006C for ; Sat, 29 Apr 2006 13:45:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8BA2839800E for ; Sat, 29 Apr 2006 13:45:33 -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 F285339800D for ; Sat, 29 Apr 2006 13:45:30 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-2.cisco.com with ESMTP; 29 Apr 2006 13:45: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 k3TKjUw1021856 for ; Sat, 29 Apr 2006 13:45: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); Sat, 29 Apr 2006 13:45:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 29 Apr 2006 13:45:30 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201CBA7AF@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 41: Default mode for logical groups Thread-Index: AcZrzdpCcftuSKsITLaoxnK7gKcW6A== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 29 Apr 2006 20:45:30.0372 (UTC) FILETIME=[DA6D9440:01C66BCD] 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: Subject: [Capwap] Issue 41: Default mode for logical groups 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="===============1431509560==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be This is a multi-part message in MIME format. --===============1431509560== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66BCD.DA50054A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66BCD.DA50054A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The original request is to add a field to the Add WLAN and descriptive text to section 11.4 (BSSID to WLAN ID mapping). However, the current specification already allows for this feature, and it can be found in section 9.1.1 (Add Mobile). The reason why it was put in here is that it allows the AC to assign a separate VLAN for each user. Please note that this is ONLY relevant for Local MAC mode, since in this mode the WTP tags all packets and does local bridging. In Split MAC mode, the AC is the one that would prepend the VLAN tag, and therefore the WTP does not need to have access to this info. Consequently, this field was made optional. =20 I would propose we mark this issue as resolved. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C66BCD.DA50054A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The = original request=20 is to add a field to the Add WLAN and descriptive text to section 11.4 = (BSSID to=20 WLAN ID mapping). However, the current specification already allows for = this=20 feature, and it can be found in section 9.1.1 (Add Mobile). The reason = why it=20 was put in here is that it allows the AC to assign a separate VLAN for = each=20 user. Please note that this is ONLY relevant for Local MAC mode, since = in this=20 mode the WTP tags all packets and does local bridging. In Split MAC = mode, the AC=20 is the one that would prepend the VLAN tag, and therefore the WTP does = not need=20 to have access to this info. Consequently, this field was made=20 optional.
 
I = would propose we=20 mark this issue as resolved.
 

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

 
------_=_NextPart_001_01C66BCD.DA50054A-- --===============1431509560== 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 --===============1431509560==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Apr 29 17:05:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZwcs-0004Ei-4c for capwap-archive@lists.ietf.org; Sat, 29 Apr 2006 17:05:14 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZwcq-0002uO-Lc for capwap-archive@lists.ietf.org; Sat, 29 Apr 2006 17:05:14 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 509AB4300AF for ; Sat, 29 Apr 2006 14:05:12 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1000F43006C for ; Sat, 29 Apr 2006 14:04:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E6785144802A for ; Sat, 29 Apr 2006 14:04:51 -0700 (PDT) Received: from test-iport-1.cisco.com (test-iport-1.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id 48054144800A for ; Sat, 29 Apr 2006 14:04:49 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 29 Apr 2006 14:04:48 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3TL4mh0006449 for ; Sat, 29 Apr 2006 14:04:48 -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); Sat, 29 Apr 2006 14:04:48 -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: Sat, 29 Apr 2006 14:04:48 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201CBA7B1@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 70: Section 5.2.2 Minor Editioral Comment Thread-Index: AcZr0Iy//dI8JWDBTPipFp+iNVVZQQ== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 29 Apr 2006 21:04:48.0724 (UTC) FILETIME=[8CDC1140:01C66BD0] X-Virus-Scanned: by amavisd-new-20030616-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 70: Section 5.2.2 Minor Editioral Comment 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: e8a67952aa972b528dd04570d58ad8fe 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 =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 Sat Apr 29 17:15:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZwmc-0007aC-MR for capwap-archive@lists.ietf.org; Sat, 29 Apr 2006 17:15:18 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZwmb-0003GE-8T for capwap-archive@lists.ietf.org; Sat, 29 Apr 2006 17:15:18 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 979584300E4 for ; Sat, 29 Apr 2006 14:15:13 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D31BC43006C for ; Sat, 29 Apr 2006 14:14:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id BE3D939800E for ; Sat, 29 Apr 2006 14:14:49 -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 4A88039800D for ; Sat, 29 Apr 2006 14:14:46 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-3.cisco.com with ESMTP; 29 Apr 2006 14:14:46 -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 k3TLEjh0009993 for ; Sat, 29 Apr 2006 14:14:45 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 29 Apr 2006 14:14:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 29 Apr 2006 14:14:46 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201CBA7B4@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 44: Increase length of control message type Thread-Index: AcZr0fDfgkJnr/R4T127GSliTwol6g== From: "Pat Calhoun (pacalhou)" To: "capwap" X-OriginalArrivalTime: 29 Apr 2006 21:14:45.0837 (UTC) FILETIME=[F0C447D0:01C66BD1] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.402 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE X-Spam-Level: Subject: [Capwap] Issue 44: Increase length of control message type 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="===============0273366263==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 This is a multi-part message in MIME format. --===============0273366263== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66BD1.F0B7FBCC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66BD1.F0B7FBCC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is a request to increase the size of the control message type from 8 to 16 bytes, which seems reasonable. Any oppositions to make this change in the -01 draft? =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C66BD1.F0B7FBCC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There = is a=20 request to increase the size of the control message type from 8 to 16 = bytes,=20 which seems reasonable. Any oppositions to make this change in the -01=20 draft?
 

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

 
------_=_NextPart_001_01C66BD1.F0B7FBCC-- --===============0273366263== 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 --===============0273366263==-- From barkmanu@tiscali.cz Sat Apr 29 17:45:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZxFv-0000wU-B7 for capwap-archive@ietf.org; Sat, 29 Apr 2006 17:45:35 -0400 Received: from apoitiers-154-1-106-150.w86-221.abo.wanadoo.fr ([86.221.57.150] helo=tiscali.cz) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FZxFq-0004Cj-33 for capwap-archive@ietf.org; Sat, 29 Apr 2006 17:45:35 -0400 Message-ID: <000001c66bd6$0132fd10$4202a8c0@vze19> Reply-To: "Mat Barkman" From: "Mat Barkman" To: capwap-archive@ietf.org Subject: Re: CstALlS new Date: Sat, 29 Apr 2006 14:43:51 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C66B9B.54D69610" 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.2 (++) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C66B9B.54D69610 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 X p A o N a A y X i=20 C r I h A x L l I q S y=20 V n A o L u I u U a M c=20 V i I s A j G m R j A x=20 =20 http://www.sproutemlokvad.com observabl laconica juniorit indistinc famil furies, have almost disappeared. The solitary walks in the woods when=20 hed come back with hands bruised from attacking tree trunks; the quiet,=20 stifled tears in his study late at night when he couldnt remember what=20 he was or what hed done, thinking the worst of himself-they were gone,=20 Johnny! There was real sunlight, do you know what I mean?=20 Yes, I do, said the brother solemnly.=20 ------=_NextPart_000_0001_01C66B9B.54D69610 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
X p = A o N a A y X i
C r I h A x L l I = q S y
V n A o L u I u U = a M c
V i I s A j G m R = j A x
 
observabl
laconica
juniorit
indistinc
famil
furies, have almost disappeared. The = solitary walks in the woods when
hed come back with hands bruised = from attacking tree trunks; the quiet,
stifled tears in his study = late at night when he couldnt remember what
he was or what hed done, = thinking the worst of himself-they were gone,
Johnny! There was real = sunlight, do you know what I mean?
Yes, I do, said the brother = solemnly.
------=_NextPart_000_0001_01C66B9B.54D69610-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Apr 29 22:30:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fa1hC-0003Ft-Hu for capwap-archive@lists.ietf.org; Sat, 29 Apr 2006 22:30:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fa1hC-00073F-GM for capwap-archive@lists.ietf.org; Sat, 29 Apr 2006 22:30:02 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fa1PW-00043D-Bz for capwap-archive@lists.ietf.org; Sat, 29 Apr 2006 22:11:50 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 102194300D2 for ; Sat, 29 Apr 2006 19:11:39 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 04A7443008C for ; Sat, 29 Apr 2006 19:10:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id DC5D9398031 for ; Sat, 29 Apr 2006 19:10:57 -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 46653398036 for ; Sat, 29 Apr 2006 19:10:55 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 29 Apr 2006 19:10:55 -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 k3U2AsRT015987 for ; Sat, 29 Apr 2006 19:10:54 -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); Sat, 29 Apr 2006 19:10:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] Issue 44: Increase length of control message type Date: Sat, 29 Apr 2006 19:08:09 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201CBA7D7@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 44: Increase length of control message type Thread-Index: AcZr0fDfgkJnr/R4T127GSliTwol6gAKPZBA From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , "capwap" X-OriginalArrivalTime: 30 Apr 2006 02:10:54.0649 (UTC) FILETIME=[4FCDD290:01C66BFB] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.402 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, 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="===============2137146634==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 This is a multi-part message in MIME format. --===============2137146634== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66BFB.4DBD058C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66BFB.4DBD058C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alternatively, we could make it 16 bits. =20 My apologies =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Pat Calhoun (pacalhou)=20 Sent: Saturday, April 29, 2006 2:15 PM To: capwap Subject: [Capwap] Issue 44: Increase length of control message type =09 =09 There is a request to increase the size of the control message type from 8 to 16 bytes, which seems reasonable. Any oppositions to make this change in the -01 draft? =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C66BFB.4DBD058C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Alternatively, we could make it 16 bits.
 
My=20 apologies
 

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

 

From: Pat Calhoun (pacalhou) =
Sent:=20 Saturday, April 29, 2006 2:15 PM
To: = capwap
Subject:=20 [Capwap] Issue 44: Increase length of control message=20 type

There is a=20 request to increase the size of the control message type from 8 to 16 = bytes,=20 which seems reasonable. Any oppositions to make this change in the -01 = draft?
 

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

 
------_=_NextPart_001_01C66BFB.4DBD058C-- --===============2137146634== 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 --===============2137146634==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Apr 30 11:52:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaEDo-0003Yk-Sl for capwap-archive@lists.ietf.org; Sun, 30 Apr 2006 11:52:32 -0400 Received: from leela-mail.tigertech.net ([64.62.209.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaEDn-0000lR-Ej for capwap-archive@lists.ietf.org; Sun, 30 Apr 2006 11:52:32 -0400 Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6E8174300E5 for ; Sun, 30 Apr 2006 08:52:30 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4427543005F for ; Sun, 30 Apr 2006 08:52:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 28E6F1448002 for ; Sun, 30 Apr 2006 08:52:10 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by hermes.tigertech.net (Postfix) with ESMTP id 92E5F430A00 for ; Sun, 30 Apr 2006 08:52:07 -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 k3UFq7P6003471; Sun, 30 Apr 2006 08:52:07 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k3UFq6Re003468; Sun, 30 Apr 2006 08:52:06 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Sun, 30 Apr 2006 08:52:06 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net 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> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new-20030616-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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 HI, I don't remember if I sent in comments specifically about this and the the similar one for WTPs. In general, the value for hardware and software versions doesn't match typical practices, and also does not follow the values found in the Entity MIB module. Secondly, originally this info was provided in Discovery responses and used by WTPs in choosing which AC to connect to. This provides for either active or passive elements the opportunity to gather "static" and dynamic info about ACs and help them choose attack targets. Thirdly, as specified in the LWAPP-03 (and I believe in the CAPWAP-00) docs, the versions are used for matching during WTP image selection. For WTPs and ACs with different versioning schemes, a version match is not the appropriate image selection rule. Fourthly, a only a limited discussion was taken place about what fields must be included in the X.509 certs and how should certs be validated. There are a few interesting cases, such as when a WTP has no calendar clock, or when it does have a clock and the value is way off, and thus validating the AC's cert may fail. I hope to soon send out a proposal to help clarify the discovery, control channel set up, and WTP image selection and transfer. On Sat, 29 Apr 2006, 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 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