From xml-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Aug 1 05:50:18 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFDC928C4C4 for ; Fri, 1 Aug 2008 05:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnC0VPY4g+8q for ; Fri, 1 Aug 2008 05:50:18 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 2F6D33A6964 for ; Fri, 1 Aug 2008 05:46:53 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CBAF8432A7B for ; Fri, 1 Aug 2008 05:30:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: frascone.com mailing list memberships reminder From: xml-owner@frascone.com X-No-Archive: yes Message-ID: Date: Fri, 01 Aug 2008 05:30:20 -0700 Precedence: bulk X-BeenThere: xml@frascone.com X-Mailman-Version: 2.1.9 List-Id: Diameter XML Dictionary Design Team List -- CLOSED -- ARCHIVES ONLY X-List-Administrivia: yes To: capwap-archive@lists.ietf.org Errors-To: xml-bounces+capwap-archive=lists.ietf.org@frascone.com 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, xml-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 Fri Aug 1 06:22:46 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 808C93A6B3B for ; Fri, 1 Aug 2008 06:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b85HvnA5xSqm for ; Fri, 1 Aug 2008 06:22:45 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 23D8B3A6D8C for ; Fri, 1 Aug 2008 06:20:47 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6E23C433CD2 for ; Fri, 1 Aug 2008 06:20:24 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 3262444011E for ; Fri, 1 Aug 2008 02:38:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0C8C134AC055 for ; Fri, 1 Aug 2008 02:38:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D069B34AC076 for ; Fri, 1 Aug 2008 02:38:34 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from bacon.cs.umd.edu (server-nat-4.cs.umd.edu [128.8.127.147]) by mx1.tigertech.net (Postfix) with ESMTP for ; Fri, 1 Aug 2008 02:38:31 -0700 (PDT) Received: from [130.129.18.59] ([130.129.18.59]) (authenticated bits=0) by bacon.cs.umd.edu (8.13.1/8.14.1) with ESMTP id m719bqXU027072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Aug 2008 05:37:54 -0400 Message-ID: <4892D971.1010303@ltsnet.net> Date: Fri, 01 Aug 2008 05:37:53 -0400 From: Charles Clancy User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <4FF84B0BC277FF45AA27FE969DD956A20632FD71@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20632FD71@xmb-sjc-235.amer.cisco.com> X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-50, required 5, autolearn=not spam, ALL_TRUSTED -50.00) X-CSD-MailScanner-From: clancy@ltsnet.net X-Mailman-Approved-At: Fri, 01 Aug 2008 06:20:14 -0700 Cc: capwap@frascone.com, Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Suggested text changes to address the comments: Replace this 2.4.1 text: DTLS, as specified, provides its own retransmit timers with an exponential back-off. However, DTLS will never terminate the handshake due to non-responsiveness; instead, DTLS will continue to increase its back-off timer period. Hence, timing out incomplete DTLS handshakes is entirely the responsibility of the CAPWAP module. with this text: DTLS, as specified, provides its own retransmit timers with an exponential back-off. [RFC4347] does not specify how long retransmissions should continue. Consequently, timing out incomplete DTLS handshakes is entirely the responsibility of the CAPWAP module. I'm not sure what needs to be addressed in 2.4.3. Pasi -- can you be more specific? -- Dr. Charles Clancy www.ltsnet.net/~clancy Senior Researcher, Laboratory for Telecommunications Sciences Pat Calhoun (pacalhou) wrote: > Pasi's comment was: > > Section 2.4.1: "DTLS will never terminate the handshake due to > non-responsiveness; instead, DTLS will continue to > increase its back-off timer period" While RFC 4347 doesn't specify > how > long you should continue retransmitting, the > intent certainly was not to continue indefinitely. > > Section 2.4.3 text about DTLS retransmissions is slightly inaccurate; > DTLS handshake isn't strictly request/response, > and both parties (not just the DTLS client) retransmit based on > timers > (in some situations). > > It is unclear to me as to whether these are simply observations, or > request for change. That said, I would like either Charles or Scott to > reply. > > PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 1 09:54:02 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B2143A67A1 for ; Fri, 1 Aug 2008 09:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDLpGLMd45ro for ; Fri, 1 Aug 2008 09:53:59 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 947C63A688E for ; Fri, 1 Aug 2008 09:53:59 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8D2471C41011 for ; Fri, 1 Aug 2008 09:53:45 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 8109944013C for ; Fri, 1 Aug 2008 09:53:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0220F34AC07E for ; Fri, 1 Aug 2008 09:53:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2830D34AC079 for ; Fri, 1 Aug 2008 09:53:26 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Fri, 1 Aug 2008 09:53:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,294,1215388800"; d="scan'208";a="71427763" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 01 Aug 2008 16:53:21 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m71GrLTM021703; Fri, 1 Aug 2008 09:53:21 -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.13.8/8.13.8) with ESMTP id m71GrL6P019382; Fri, 1 Aug 2008 16:53:21 GMT 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.1830); Fri, 1 Aug 2008 09:53:21 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Aug 2008 09:53:19 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2063304F7@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Recap of current pending issues Thread-Index: Acjz9xoEqCcXlGoTT6y9r7yIArdLFw== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 01 Aug 2008 16:53:21.0516 (UTC) FILETIME=[1AFA92C0:01C8F3F7] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Recap of current pending issues X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com All, With the IETF Last Call ending next Tuesday, I thought it would be useful to do a recap of where we are at with regards to the issues that have been raised already. For those I mark as closed, I will wait until the end of the IETF Last Call before I take the actual action in tracker. ISSUES WAITING FOR FEEDBACK. Issue 150 (Allocation of WBIDs). There is no clear agreement on this issue. The current spec requires a Standards Action to allocate a WBID, but it doesn't look like EPCGlobal plans on submitting their protocol to the IETF. So we either agree to keep the document as it (although we did agree to remove 802.16), or change the IANA action from "Standards Action" to something else, such as perhaps "Designated Expert". We need clear resolution on this. Issue 151 (MTU discovery doesn't look right). Pasi stated that the MTU Discovery text was not sufficient, since we pointed to RFCs that described MTU Discovery behavior, but no protocol specifics. So I had to re-instate some old CAPWAP text (and new) to add protocol discovery. I am waiting for feedback for this issue. Issue 154 (Should we use IPv4 Multicast Address?). A request for a known multicast address to be registered. I proposed we reject this issue, and am waiting to make sure that we have consensus on this proposal. Issue 155 (WTP/AC ACL Synchronization Issue). So this is another interesting issue, and talking to the LWAPP developers it was introduced to support a mode of operation that the CAPWAP standard does not currently support. In the thread, I proposed we remove these message elements, otherwise we will need to do much more specmanship in order to support this new deployment requirement. Issue 161 (NAT Inconsistencies). This is another issue that uncovered some real problems in the CAPWAP protocol. Fixing it required some changes that will create backward compatibility issues - but there was no choice. The old text had two different possible ways of doing the same thing, with little/no guidance that would clearly create issues. Issue 165 (Image Download inconsistencies). This issue uncovered some problems in the CAPWAP protocol's mechanism of downloading firmware to a WTP. It required some changes to the protocol and I am waiting for feedback from folks before I consider this closed. Note this new text does possibly break backward compatibility, depending on how folks had interpreted the original text. Issue 169 (What to do with QoS tags exceeding maximum). Another one where we have a potential interoperability issue, and we need to agree on what behavior the WTP will take if it receives a packet whose QoS marking violates the configured policy. Alternatives have been proposed - waiting for feedback. Issue 172 (How is the WTP Descriptor's Encryption Capabilities defined?). This is a particularly thorny issue that can cause us to break backward interoperability, or worse, severely limit the scope of the protocol. We need a good resolution, and I have proposed a few already. Waiting for feedback. ISSUES WAITING FOR PASI's REVIEW Issue 156 (Need more details on use of DNS for discovery). This was a rather small change, but I got it wrong the first time. I am waiting for confirmation that this time around we are good to go. Issue 159 (Question on CAPWAP control protocol). This was a question, which I have responded to. There was no need for change, unless Pasi raises a specific issue. At this point, I consider this issue closed. Issue 166 (Various IANA Issues). This issue has been addressed, but I am waiting for Pasi's feedback. Issue 171 (Pasi nits on binding spec). I believe this is done - I am just waiting to see if Pasi has issues with any of the proposed resolutions CLOSED ISSUES Issue 152 (Need crypto protocol agility). This issue has been addressed. I will close it. Issue 170 (Inconsistent WLAN ID length). This issue has been addressed. I will close it. Issue 160 (Use of Replay Protection). This issue has been addressed. I will close it. Issue 153( Linking of control and data channels). This issue has been addressed. I will close it. Issue 167 (Need to mention PSK Identity Hint). This issue has been addressed. I will close it. Issue 163 (R-MAC Info Field needs to be clarified and cleaned up). This issue has been addressed. I will close it. Issue 164 (Some bitfields need to be clarified). This issue has been addressed. I will close it. Issue 168 (DTLS and Retransmissions). I am waiting for either Scott or Charles to opine on this issue. Issue 157 (Issue with handling of cookies). This issue has been addressed. I will close it. Issue 149 (Incompatibility with message element numbering between drafts 10 and 11). This issue has been addressed. I will close it. Issue 150 (binding doc. 802.11 wlan config req/resp msg type valueissue). This issue has been addressed. I will close it. Issue 144 (Invalid reference to message element field). This issue has been addressed. I will close it. Issue 162 (Nits from Pasi's Review). Various NITs. This issue has been addressed. I will close it. PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 1 10:13:02 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 452963A6A21 for ; Fri, 1 Aug 2008 10:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.703 X-Spam-Level: X-Spam-Status: No, score=-2.703 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, FUZZY_CPILL=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1mQyMUwubIz for ; Fri, 1 Aug 2008 10:13:01 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 482D33A6A16 for ; Fri, 1 Aug 2008 10:13:01 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id F3481175024D for ; Fri, 1 Aug 2008 10:12:39 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 550E8440131 for ; Fri, 1 Aug 2008 10:12:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 080D334AC08B for ; Fri, 1 Aug 2008 10:12:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id A65BC34AC079 for ; Fri, 1 Aug 2008 10:12:26 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Fri, 1 Aug 2008 10:12:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,294,1215388800"; d="scan'208";a="71434209" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 01 Aug 2008 17:12:26 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m71HCQah028839; Fri, 1 Aug 2008 10:12:26 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m71HCQTv011036; Fri, 1 Aug 2008 17:12:26 GMT 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.1830); Fri, 1 Aug 2008 10:12:26 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Aug 2008 10:12:24 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206330514@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4892D971.1010303@ltsnet.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 168: DTLS and Retransmissions Thread-Index: Acjz2WCdWj/4NEiBRna0IkK5PBovgQAIF04A References: <4FF84B0BC277FF45AA27FE969DD956A20632FD71@xmb-sjc-235.amer.cisco.com> <4892D971.1010303@ltsnet.net> From: "Pat Calhoun (pacalhou)" To: "Charles Clancy" X-OriginalArrivalTime: 01 Aug 2008 17:12:26.0298 (UTC) FILETIME=[C55271A0:01C8F3F9] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: capwap@frascone.com, Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Got it - waiting for Pasi on 2.4.3. PatC -----Original Message----- From: Charles Clancy [mailto:clancy@ltsnet.net] Sent: Friday, August 01, 2008 2:38 AM To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com; Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions Suggested text changes to address the comments: Replace this 2.4.1 text: DTLS, as specified, provides its own retransmit timers with an exponential back-off. However, DTLS will never terminate the handshake due to non-responsiveness; instead, DTLS will continue to increase its back-off timer period. Hence, timing out incomplete DTLS handshakes is entirely the responsibility of the CAPWAP module. with this text: DTLS, as specified, provides its own retransmit timers with an exponential back-off. [RFC4347] does not specify how long retransmissions should continue. Consequently, timing out incomplete DTLS handshakes is entirely the responsibility of the CAPWAP module. I'm not sure what needs to be addressed in 2.4.3. Pasi -- can you be more specific? -- Dr. Charles Clancy www.ltsnet.net/~clancy Senior Researcher, Laboratory for Telecommunications Sciences Pat Calhoun (pacalhou) wrote: > Pasi's comment was: > > Section 2.4.1: "DTLS will never terminate the handshake due to > non-responsiveness; instead, DTLS will continue to > increase its back-off timer period" While RFC 4347 doesn't specify > how > long you should continue retransmitting, the > intent certainly was not to continue indefinitely. > > Section 2.4.3 text about DTLS retransmissions is slightly inaccurate; > DTLS handshake isn't strictly request/response, > and both parties (not just the DTLS client) retransmit based on > timers > (in some situations). > > It is unclear to me as to whether these are simply observations, or > request for change. That said, I would like either Charles or Scott to > reply. > > PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 Aug 4 11:36:06 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9BE73A6D14 for ; Mon, 4 Aug 2008 11:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKlnHOnmcBJe for ; Mon, 4 Aug 2008 11:36:06 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id EF5E83A6824 for ; Mon, 4 Aug 2008 11:36:05 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 033EE1C40F9B for ; Mon, 4 Aug 2008 11:36:35 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 2238E4401BA for ; Mon, 4 Aug 2008 11:36:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id F33AD34AC083 for ; Mon, 4 Aug 2008 11:36:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2179B34AC097 for ; Mon, 4 Aug 2008 11:36:16 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 4 Aug 2008 11:36:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,306,1215388800"; d="scan'208";a="61294088" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 04 Aug 2008 18:36:11 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m74IaB2t001421 for ; Mon, 4 Aug 2008 11:36:11 -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.13.8/8.13.8) with ESMTP id m74IaB4s014583 for ; Mon, 4 Aug 2008 18:36:11 GMT 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.1830); Mon, 4 Aug 2008 11:36:10 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Aug 2008 11:36:09 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206393498@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 173: Inconsistency in enabling DTLSWait timer Thread-Index: Acj2YPba2o0d9MHTQladEGR1hc0LPg== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 04 Aug 2008 18:36:10.0682 (UTC) FILETIME=[F753D9A0:01C8F660] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Capwap] Issue 173: Inconsistency in enabling DTLSWait timer X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com There is an issue with the DTLSWait timer description in section 2.4.2. The actual description in the state machine shows the DTLSWait timer starting before the DTLSStart command is executed (state transition 3), yet the text in 2.4.2 says that the timer is started when PeerAuthorize event is received (state transition 5). The correct one is state transition 3. PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 4 14:31:21 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68E5C28C241 for ; Mon, 4 Aug 2008 14:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.211 X-Spam-Level: X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhGt3jYLM2MC for ; Mon, 4 Aug 2008 14:31:20 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 716AF3A6A35 for ; Mon, 4 Aug 2008 14:31:19 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C363D1C40FE6 for ; Mon, 4 Aug 2008 14:31:48 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 4C5064401A5 for ; Mon, 4 Aug 2008 14:31:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0BB3434AC006 for ; Mon, 4 Aug 2008 14:31:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id BDCCE34AC02B for ; Mon, 4 Aug 2008 14:31:30 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 4 Aug 2008 14:31:30 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 04 Aug 2008 21:23:24 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m74LNOYC023464; Mon, 4 Aug 2008 14:23:24 -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.13.8/8.13.8) with ESMTP id m74LNO4p021617; Mon, 4 Aug 2008 21:23:24 GMT 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.1830); Mon, 4 Aug 2008 14:23:24 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Aug 2008 14:23:22 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2063935F4@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 106: WaitJoin may be unnecessary Thread-Index: Acj2eFMECaN6JJNaTFuaj5Q7qVhCJg== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 04 Aug 2008 21:23:24.0332 (UTC) FILETIME=[53D956C0:01C8F678] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: yozhang@gmail.com Subject: [Capwap] Issue 106: WaitJoin may be unnecessary X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com All, I need to re-open this issue, as I have just found out while fixing issue 173 that we continue to have a problem. The original intent of the WaitJoin was to make sure that once the DTLS session was established, the AC had a chance to teardown the session if the WTP were inactive. Unfortunately, the fix was not correct. Specifically, the following state transition is the issue, as you will note that this transition can occur if the WaitDTLS timer expires: Join to DTLS Teardown (e): This transition occurs when the join process failed. WTP: This state transition occurs when the WTP receives a Join Response message with a Result Code message element containing an error, if the Image Identifier provided by the AC in the Join Response message differs from the WTP's currently running firmware version and the WTP has the requested image in its non-volatile memory, or if the WaitDTLS timer expires. This causes the WTP to initiate the DTLSShutdown command (see Section 2.3.2.1). This transition also occurs if the WTP receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect. The WTP starts the DTLSSessionDelete timer (see Section 4.7.6). AC: This state transition occurs either if the WaitDTLS timer expires or if the AC transmits a Join Response message with a Result Code message element containing an error. This causes the AC to initiate the DTLSShutdown command (see Section 2.3.2.1). This transition also occurs if the AC receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect. The AC starts the DTLSSessionDelete timer (see Section 4.7.6). However, as you can read in the following text, the WaitDTLS timer is stopped when the Join state is entered: DTLS Connect to Join (d): This transition occurs when the DTLS Session is successfully established. WTP: This state transition occurs when the WTP receives the DTLSEstablished notification (see Section 2.3.2.2), indicating that the DTLS session was successfully established. When this notification is received, the FailedDTLSSessionCount counter is set to zero. The WTP enters the Join state by transmiting the Join Request to the AC. The WTP stops the WaitDTLS timer. AC: This state transition occurs when the AC receives the DTLSEstablished notification (see Section 2.3.2.2), indicating that the DTLS session was successfully established. When this notification is received, the FailedDTLSSessionCount counter is set to zero. The AC stops the WaitDTLS timer. So, to be clear, only the AC needs this because if the WTP retransmits the Join Request, the session will timeout anyhow through the "Join to DTLSTeardown" state transition. So to help understand the fix, I will provide narratives throughout the new text. First, when the DTLS Session is established, and the AC disables the WaitDTLS timer, it also starts the WaitJoin timer: DTLS Connect to Join (d): This transition occurs when the DTLS Session is successfully established. [...] AC: This state transition occurs when the AC receives the DTLSEstablished notification (see Section 2.3.2.2), indicating that the DTLS session was successfully established. When this notification is received, the FailedDTLSSessionCount counter is set to zero. The AC stops the WaitDTLS timer, and starts the WaitJoin timer. If the WaitJoin timer expires on the AC, it will transition from Join to DTLSTeardown: Join to DTLS Teardown (e): This transition occurs when the join process failed. [...] AC: This state transition occurs either if the WaitJoin timer expires or if the AC transmits a Join Response message with a Result Code message element containing an error. This causes the AC to initiate the DTLSShutdown command (see Section 2.3.2.1). This transition also occurs if the AC receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect. The AC starts the DTLSSessionDelete timer (see Section 4.7.6). Now, assuming that we transition out of the Join state, which can only be the "Join to Image Data" or "Join to Configure" state transitions, the WaitJoin is disabled on the AC: Join to Image Data (f): This state transition is used by the WTP and the AC to download executable firmware. [...] AC: This state transition occurs when the AC receives the Image Data Request message from the WTP, after having sent its Join Response to the WTP. The AC stops the WaitJoin timer. The AC MUST transmit an Image Data Response message (see Section 9.1.2) to the WTP, which includes a portion of the firmware. The AC MUST start the ImageDataStartTimer timer (see Section 4.7). Join to Configure (g): This state transition is used by the WTP and the AC to exchange configuration information. [...] AC: This state transition occurs when it receives the Configuration Status Request message from the WTP (see Section 8.2), which MAY include specific message elements to override the WTP's configuration. The AC stops the WaitJoin timer. The AC transmits the Configuration Status Response message (see Section 8.3) and starts the ChangeStatePendingTimer timer (see Section 4.7). Finally, the definition of the timer itself: 4.7.16. WaitJoin The maximum time, in seconds, an AC will wait after the DTLS session has been established until it receives the Join Request from the WTP. This timer MUST be greater than 20 seconds. Default: 60 PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 4 14:37:20 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EEE728C2F6 for ; Mon, 4 Aug 2008 14:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.22 X-Spam-Level: X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znn0buL9ELTE for ; Mon, 4 Aug 2008 14:37:19 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 2DBDF28C2D9 for ; Mon, 4 Aug 2008 14:37:18 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8544843A06F for ; Mon, 4 Aug 2008 14:37:47 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 0DAAD440175 for ; Mon, 4 Aug 2008 14:37:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 435C234AC083 for ; Mon, 4 Aug 2008 14:37:34 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3B0A734AC032 for ; Mon, 4 Aug 2008 14:37:21 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 4 Aug 2008 14:37:21 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 04 Aug 2008 21:07:58 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m74L7wgp011277 for ; Mon, 4 Aug 2008 14:07:58 -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.13.8/8.13.8) with ESMTP id m74L7uso017640 for ; Mon, 4 Aug 2008 21:07:58 GMT 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.1830); Mon, 4 Aug 2008 14:07:58 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Aug 2008 14:07:57 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2063935D7@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A206393498@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 173: Inconsistency in enabling DTLSWait timer Thread-Index: Acj2YPba2o0d9MHTQladEGR1hc0LPgAEvx+A References: <4FF84B0BC277FF45AA27FE969DD956A206393498@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 04 Aug 2008 21:07:58.0042 (UTC) FILETIME=[2BBCB3A0:01C8F676] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Capwap] Issue 173: Inconsistency in enabling DTLSWait timer X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com All, I have addressed the problem by changing the text in 2.4.2 to ensure that it is consistent with the state machine: 2.4.2. DTLS Session Establishment The WTP, either through the Discovery process, or through pre- configuration, determines the AC to connect to. The WTP uses the DTLSStart command to request that a secure connection be established to the selected AC. Prior to initiation of the DTLS handshake, the WTP sets the WaitDTLS timer. Upon invoking the DTLSStart or DTLSListen commands, the WTP and AC, respectively, set the WaitDTLS timer. If the DTLSEstablished notification is not received prior to timer expiration, the DTLS session is aborted by issuing the DTLSAbortSession DTLS command. This notification causes the CAPWAP module to transition to the Idle state. Upon receiving a DTLSEstablished notification, the WaitDTLS timer is deactivated. PatC -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Monday, August 04, 2008 11:36 AM To: capwap@frascone.com Subject: [Capwap] Issue 173: Inconsistency in enabling DTLSWait timer There is an issue with the DTLSWait timer description in section 2.4.2. The actual description in the state machine shows the DTLSWait timer starting before the DTLSStart command is executed (state transition 3), yet the text in 2.4.2 says that the timer is started when PeerAuthorize event is received (state transition 5). The correct one is state transition 3. PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 Aug 4 15:25:08 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0B773A6895 for ; Mon, 4 Aug 2008 15:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.27 X-Spam-Level: X-Spam-Status: No, score=-3.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dR-Jznn6aqcE for ; Mon, 4 Aug 2008 15:25:07 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id C95BE3A682A for ; Mon, 4 Aug 2008 15:25:07 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 93C0E1C40F66 for ; Mon, 4 Aug 2008 15:25:36 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id A23E5440022 for ; Mon, 4 Aug 2008 15:25:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 7026534AC061 for ; Mon, 4 Aug 2008 15:25:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 19B0E34AC02F for ; Mon, 4 Aug 2008 15:25:11 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.72 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 4 Aug 2008 15:25:11 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 04 Aug 2008 22:25:06 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m74MP6Fh020757; Mon, 4 Aug 2008 15:25:06 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m74MP6Yc012412; Mon, 4 Aug 2008 22:25:06 GMT 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.1830); Mon, 4 Aug 2008 15:25:06 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Aug 2008 15:25:05 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2063936BF@xmb-sjc-235.amer.cisco.com> In-Reply-To: <48975FF0.7060907@joelhalpern.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Gen-art] IETF LC review: draft-ietf-capwap-protocol-binding-ieee80211-07 Thread-Index: Acj2bQvsYj1mHQ2hQHGKP4caC/uiLgAEKLgg References: <48975FF0.7060907@joelhalpern.com> From: "Pat Calhoun (pacalhou)" To: "Joel M. Halpern" , "Mary Barnes" X-OriginalArrivalTime: 04 Aug 2008 22:25:06.0687 (UTC) FILETIME=[F29FE0F0:01C8F680] Authentication-Results: sj-dkim-4; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: dstanley@arubanetworks.com, gen-art@ietf.org, capwap@frascone.com, mmontemurro@rim.com, IETF discussion list Subject: Re: [Capwap] [Gen-art] IETF LC review: draft-ietf-capwap-protocol-binding-ieee80211-07 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thanks for your review, Joel. Please see my comments below. Question: The document (in section 2.5) calls for specific DSCP values (46 and 34) to be used on management frames. Two questions: Is this the decimal value of the 6 bit DSCP field, or the decimal value of the 8 bit ToS field, or a hex value? More important question: The DSCP RFCs make it very clear that the meanings of DSCP values are locally defined by network operators. As such, shouldn't this be defined in terms of the intend PHB, not the DSCP? I.e. define the desired behavioral treatment, and indicate the common code point used to represent that treatment? If the meanings of these code points in this environment is standardized, then there MUST be a reference so that a reader can figure out what that standard is. Fair comment. I would propose the following text: 2.6. Quality of Service for IEEE 802.11 MAC Management Messages It is recommended that IEEE 802.11 MAC Management frames be sent by both the AC and the WTP with appropriate Quality of Service values, listed below, to ensure that congestion in the network minimizes occurrences of packet loss. 802.1p: The precedence value of 7 (decimal) SHOULD be used for all IEEE 802.11 MAC management frames, except for Probe Requests which SHOULD use 4. DSCP: All IEEE 802.11 MAC management frames SHOULD use the Expedited Forwarding per-hop behavior (see [RFC2598]), while IEEE 802.11 Probe Requests should use the Low Drop Assured Forwarding per-hop behavior (see [RFC2598]). Confusion: In section 6.9 describing the Multi-Domain Capability, the text refers to "the associated domain country string" There is no domain country string in the particular information element being defined. And there appears to be no domain country string defined elsewhere in the document. So what is the "associated domain country string", how is it associated, and how is the implementor supposed to know what is meant? (There are lots of explicit cross-references to the IEEE specs for the fields being sent. But no reference at all for the domain country string.) Thanks for pointing this out. I have modified the text to include a reference to the "IEEE 802.11 WTP Radio Configuration" message element, where the Country String can be found. Minor: If it is necessary to revise the document, it would be a good idea to do some work on the Introduction. This document, which provides the protocol bindings, should actually explain what it means to provide the protocol bindings. The reader should not be left to guess. I suspect the WG felt that the sentence beginning "Use of CAPWAP control message fields ..." covers the issue. It hints at it. A sentence or two (assuming I have properly inferred the goal) stating that binding consists of defining how a the CAPWAP protocol is to be used with a specific technology, would solve this concern. While I suspect that anyone reading this particular document would have read the base, and be familiar with the protocol concepts, it still doesn't hurt to be a tad clearer in the introduction. I would propose some small modifications, which would result in the following: 1. Introduction The CAPWAP protocol [I-D.ietf-capwap-protocol-specification] defines an extensible protocol to allow an Access Controller to manage wireless agnostic Wireless Termination Points. The CAPWAP protocol itself does not include any specific wireless technologies, but instead relies on binding specification to extend the technology to a particular wireless technology. This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network protocol. Use of CAPWAP control message fields, new control messages and message elements are defined. The minimum required definitions for a binding-specific Statistics message element, Station message element, and WTP Radio Information message element are included. Also, it seems that the goals are mostly the general CAPWAP goals. So it might be better if the first sentence of 1.1 read "Th goals of this CAPWAP protocol binding are to make the capabilities of the CAPWAP protocol available for use in conjunction with 802.11 wireless networks. The capabilities to be made available can be summarized as:" Thanks for the proposed text. I have made a small modification, so the text now reads: 1.1. Goals The goals of this CAPWAP protocol binding are to make the capabilities of the CAPWAP protocol available for use in conjunction with IEEE 802.11 wireless networks. The capabilities to be made available can be summarized as: PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 4 23:17:02 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC9993A68DA for ; Mon, 4 Aug 2008 23:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.184 X-Spam-Level: X-Spam-Status: No, score=-3.184 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VkndJwFHytE for ; Mon, 4 Aug 2008 23:17:01 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id A34883A67D7 for ; Mon, 4 Aug 2008 23:17:01 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2C29C1C40F86 for ; Mon, 4 Aug 2008 23:16:58 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 164E54401CF for ; Mon, 4 Aug 2008 18:43:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D65F63610006 for ; Mon, 4 Aug 2008 18:43:12 -0700 (PDT) Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 6EAAE3610003 for ; Mon, 4 Aug 2008 18:43:12 -0700 (PDT) X-TigerTech-Content-Filter: Clean Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 4 Aug 2008 18:43:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 56AE81C40F3D; Mon, 4 Aug 2008 18:43:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-162.clppva.btas.verizon.net [71.161.51.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 72D341C40F02; Mon, 4 Aug 2008 18:43:10 -0700 (PDT) Message-ID: <4897AFE8.4010101@joelhalpern.com> Date: Mon, 04 Aug 2008 21:42:00 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <48975FF0.7060907@joelhalpern.com> <4FF84B0BC277FF45AA27FE969DD956A2063936BF@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2063936BF@xmb-sjc-235.amer.cisco.com> X-Mailman-Approved-At: Mon, 04 Aug 2008 23:16:48 -0700 Cc: dstanley@arubanetworks.com, gen-art@ietf.org, capwap@frascone.com, mmontemurro@rim.com, IETF discussion list Subject: Re: [Capwap] [Gen-art] IETF LC review: draft-ietf-capwap-protocol-binding-ieee80211-07 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thank you. Those changes address my concerns very well. Please work with your document shepherd to determine when a new draft should be produced with those changes. I appreciate your prompt response, Joel Pat Calhoun (pacalhou) wrote: > Thanks for your review, Joel. Please see my comments below. > > > Question: > The document (in section 2.5) calls for specific DSCP values (46 > and > 34) to be used on management frames. Two questions: > Is this the decimal value of the 6 bit DSCP field, or the decimal value > of the 8 bit ToS field, or a hex value? > More important question: The DSCP RFCs make it very clear that the > meanings of DSCP values are locally defined by network operators. As > such, shouldn't this be defined in terms of the intend PHB, not the > DSCP? I.e. define the desired behavioral treatment, and indicate the > common code point used to represent that treatment? If the meanings of > these code points in this environment is standardized, then there MUST > be a reference so that a reader can figure out what that standard is. > > Fair comment. I would propose the following text: > > > 2.6. Quality of Service for IEEE 802.11 MAC Management Messages > > It is recommended that IEEE 802.11 MAC Management frames be sent by > both the AC and the WTP with appropriate Quality of Service values, > listed below, to ensure that congestion in the network minimizes > occurrences of packet loss. > > 802.1p: The precedence value of 7 (decimal) SHOULD be used for all > IEEE 802.11 MAC management frames, except for Probe Requests which > SHOULD use 4. > > DSCP: All IEEE 802.11 MAC management frames SHOULD use the > Expedited Forwarding per-hop behavior (see [RFC2598]), while IEEE > 802.11 Probe Requests should use the Low Drop Assured Forwarding > per-hop behavior (see [RFC2598]). > > > Confusion: > In section 6.9 describing the Multi-Domain Capability, the text > refers > to "the associated domain country string" There is no domain country > string in the particular information element being defined. And there > appears to be no domain country string defined elsewhere in the > document. So what is the "associated domain country string", how is it > associated, and how is the implementor supposed to know what is meant? > (There are lots of explicit cross-references to the IEEE specs for the > fields being sent. But no reference at all for the domain country > string.) > > Thanks for pointing this out. I have modified the text to include > a reference to the "IEEE 802.11 WTP Radio Configuration" message > element, where the Country String can be found. > > Minor: > If it is necessary to revise the document, it would be a good idea to do > > some work on the Introduction. This document, which provides the > protocol bindings, should actually explain what it means to provide the > protocol bindings. The reader should not be left to guess. I suspect > the WG felt that the sentence beginning "Use of CAPWAP control message > fields ..." covers the issue. It hints at it. A sentence or two > (assuming I have properly inferred the goal) stating that binding > consists of defining how a the CAPWAP protocol is to be used with a > specific technology, would solve this concern. > > While I suspect that anyone reading this particular document would > have read the base, and be familiar with the protocol concepts, it still > doesn't hurt to be a tad clearer in the introduction. I would propose > some small modifications, which would result in the following: > > > 1. Introduction > > The CAPWAP protocol [I-D.ietf-capwap-protocol-specification] defines > an extensible protocol to allow an Access Controller to manage > wireless agnostic Wireless Termination Points. The CAPWAP protocol > itself does not include any specific wireless technologies, but > instead relies on binding specification to extend the technology to a > particular wireless technology. > > This specification defines the Control And Provisioning of Wireless > Access Points (CAPWAP) Protocol Binding Specification for use with > the IEEE 802.11 Wireless Local Area Network protocol. Use of CAPWAP > control message fields, new control messages and message elements are > defined. The minimum required definitions for a binding-specific > Statistics message element, Station message element, and WTP Radio > Information message element are included. > > > Also, it seems that the goals are mostly the general CAPWAP goals. So > it might be better if the first sentence of 1.1 read "Th goals of this > CAPWAP protocol binding are to make the capabilities of the CAPWAP > protocol available for use in conjunction with 802.11 wireless networks. > > The capabilities to be made available can be summarized as:" > > Thanks for the proposed text. I have made a small modification, so > the text now reads: > > > 1.1. Goals > > The goals of this CAPWAP protocol binding are to make the > capabilities of the CAPWAP protocol available for use in conjunction > with IEEE 802.11 wireless networks. The capabilities to be made > available can be summarized as: > > > PatC > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 5 09:17:05 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B6EE3A6D18 for ; Tue, 5 Aug 2008 09:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.389 X-Spam-Level: X-Spam-Status: No, score=-3.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dO9Z9qut1238 for ; Tue, 5 Aug 2008 09:17:04 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 00CFC28C26D for ; Tue, 5 Aug 2008 09:16:57 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 021271C40F55 for ; Tue, 5 Aug 2008 09:17:28 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id C78BB4401E0 for ; Tue, 5 Aug 2008 09:17:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 1CF303610049 for ; Tue, 5 Aug 2008 09:17:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8A02C34AC02F for ; Tue, 5 Aug 2008 09:16:44 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.72 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 5 Aug 2008 09:16:44 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 05 Aug 2008 16:16:35 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m75GGZCI012987; Tue, 5 Aug 2008 09:16:35 -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.13.8/8.13.8) with ESMTP id m75GGZqS001912; Tue, 5 Aug 2008 16:16:35 GMT 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.1830); Tue, 5 Aug 2008 09:16:31 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Aug 2008 09:16:30 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206393959@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4897AFE8.4010101@joelhalpern.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] [Gen-art] IETF LC review:draft-ietf-capwap-protocol-binding-ieee80211-07 Thread-Index: Acj2wubyvme7gEwCT9SWIKtwuc4A3QAU6kDg References: <48975FF0.7060907@joelhalpern.com><4FF84B0BC277FF45AA27FE969DD956A2063936BF@xmb-sjc-235.amer.cisco.com> <4897AFE8.4010101@joelhalpern.com> From: "Pat Calhoun (pacalhou)" To: "Joel M. Halpern" X-OriginalArrivalTime: 05 Aug 2008 16:16:31.0495 (UTC) FILETIME=[9F5B2170:01C8F716] Authentication-Results: sj-dkim-4; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: gen-art@ietf.org, capwap@frascone.com, IETF discussion list , dstanley@arubanetworks.com, mmontemurro@rim.com Subject: Re: [Capwap] [Gen-art] IETF LC review:draft-ietf-capwap-protocol-binding-ieee80211-07 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Great. I had forgotten to mention that I had created tracker #174 for this issue. I will mark this one resolved. PatC -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Monday, August 04, 2008 6:42 PM To: Pat Calhoun (pacalhou) Cc: dstanley@arubanetworks.com; gen-art@ietf.org; capwap@frascone.com; mmontemurro@rim.com; IETF discussion list Subject: Re: [Capwap] [Gen-art] IETF LC review:draft-ietf-capwap-protocol-binding-ieee80211-07 Thank you. Those changes address my concerns very well. Please work with your document shepherd to determine when a new draft should be produced with those changes. I appreciate your prompt response, Joel Pat Calhoun (pacalhou) wrote: > Thanks for your review, Joel. Please see my comments below. > > > Question: > The document (in section 2.5) calls for specific DSCP values (46 and > 34) to be used on management frames. Two questions: > Is this the decimal value of the 6 bit DSCP field, or the decimal > value of the 8 bit ToS field, or a hex value? > More important question: The DSCP RFCs make it very clear that the > meanings of DSCP values are locally defined by network operators. As > such, shouldn't this be defined in terms of the intend PHB, not the > DSCP? I.e. define the desired behavioral treatment, and indicate the > common code point used to represent that treatment? If the meanings > of these code points in this environment is standardized, then there > MUST be a reference so that a reader can figure out what that standard is. > > Fair comment. I would propose the following text: > > > 2.6. Quality of Service for IEEE 802.11 MAC Management Messages > > It is recommended that IEEE 802.11 MAC Management frames be sent by > both the AC and the WTP with appropriate Quality of Service values, > listed below, to ensure that congestion in the network minimizes > occurrences of packet loss. > > 802.1p: The precedence value of 7 (decimal) SHOULD be used for all > IEEE 802.11 MAC management frames, except for Probe Requests which > SHOULD use 4. > > DSCP: All IEEE 802.11 MAC management frames SHOULD use the > Expedited Forwarding per-hop behavior (see [RFC2598]), while IEEE > 802.11 Probe Requests should use the Low Drop Assured Forwarding > per-hop behavior (see [RFC2598]). > > > Confusion: > In section 6.9 describing the Multi-Domain Capability, the text > refers to "the associated domain country string" There is no domain > country string in the particular information element being defined. > And there appears to be no domain country string defined elsewhere in > the document. So what is the "associated domain country string", how > is it associated, and how is the implementor supposed to know what is > meant? > (There are lots of explicit cross-references to the IEEE specs for the > fields being sent. But no reference at all for the domain country > string.) > > Thanks for pointing this out. I have modified the text to > include a reference to the "IEEE 802.11 WTP Radio Configuration" > message element, where the Country String can be found. > > Minor: > If it is necessary to revise the document, it would be a good idea to > do > > some work on the Introduction. This document, which provides the > protocol bindings, should actually explain what it means to provide > the protocol bindings. The reader should not be left to guess. I > suspect the WG felt that the sentence beginning "Use of CAPWAP control > message fields ..." covers the issue. It hints at it. A sentence or > two (assuming I have properly inferred the goal) stating that binding > consists of defining how a the CAPWAP protocol is to be used with a > specific technology, would solve this concern. > > While I suspect that anyone reading this particular document > would have read the base, and be familiar with the protocol concepts, > it still doesn't hurt to be a tad clearer in the introduction. I would > propose some small modifications, which would result in the following: > > > 1. Introduction > > The CAPWAP protocol [I-D.ietf-capwap-protocol-specification] defines > an extensible protocol to allow an Access Controller to manage > wireless agnostic Wireless Termination Points. The CAPWAP protocol > itself does not include any specific wireless technologies, but > instead relies on binding specification to extend the technology to a > particular wireless technology. > > This specification defines the Control And Provisioning of Wireless > Access Points (CAPWAP) Protocol Binding Specification for use with > the IEEE 802.11 Wireless Local Area Network protocol. Use of CAPWAP > control message fields, new control messages and message elements are > defined. The minimum required definitions for a binding-specific > Statistics message element, Station message element, and WTP Radio > Information message element are included. > > > Also, it seems that the goals are mostly the general CAPWAP goals. So > it might be better if the first sentence of 1.1 read "Th goals of this > CAPWAP protocol binding are to make the capabilities of the CAPWAP > protocol available for use in conjunction with 802.11 wireless networks. > > The capabilities to be made available can be summarized as:" > > Thanks for the proposed text. I have made a small modification, > so the text now reads: > > > 1.1. Goals > > The goals of this CAPWAP protocol binding are to make the > capabilities of the CAPWAP protocol available for use in conjunction > with IEEE 802.11 wireless networks. The capabilities to be made > available can be summarized as: > > > PatC > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 Aug 5 10:05:23 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 951973A6846 for ; Tue, 5 Aug 2008 10:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.393 X-Spam-Level: X-Spam-Status: No, score=-3.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgS3si4G+vMO for ; Tue, 5 Aug 2008 10:05:22 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 964423A68BF for ; Tue, 5 Aug 2008 10:05:22 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 288391C40F69 for ; Tue, 5 Aug 2008 10:05:54 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 9F2504401B8 for ; Tue, 5 Aug 2008 10:05:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 16DAC3610049 for ; Tue, 5 Aug 2008 10:05:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id EC6DA361006F for ; Tue, 5 Aug 2008 10:04:52 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.72 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 5 Aug 2008 10:04:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,311,1215388800"; d="scan'208";a="92715377" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 05 Aug 2008 17:04:52 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m75H4qpg024916 for ; Tue, 5 Aug 2008 10:04:52 -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.13.8/8.13.8) with ESMTP id m75H4qae008681 for ; Tue, 5 Aug 2008 17:04:52 GMT 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.1830); Tue, 5 Aug 2008 10:04:52 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Aug 2008 10:04:51 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2063939D9@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 175: Retransmission clarification required Thread-Index: Acj3HWAX3EQ5lTiJSze8nvUXiJWBqw== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 05 Aug 2008 17:04:52.0339 (UTC) FILETIME=[6064CC30:01C8F71D] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Capwap] Issue 175: Retransmission clarification required X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com The text from section 4.5.3 is unclear as to what happens when the RetransmitInterval timer reaches half the EchoInterval. Should the CAPWAP implementation no longer attempt to double the value, or stop retransmitting. The text in question is: 4.5.3. Retransmissions [...] After transmitting a Request message, the RetransmitInterval (see Section 4.7) timer and MaxRetransmit (see Section 4.8) variable are used to determine if the original Request message needs to be retransmitted. The RetransmitInterval timer is used the first time the Request is retransmitted. The timer is then doubled every subsequent time the same Request message is retransmitted, up to MaxRetransmit but no more than half the EchoInterval timer (see Section 4.7.7). Response messages are not subject to these timers. I believe the original intent is that the implementation should retransmit until MaxRetransmit has been reached, and not keep the RetransmitInterval intact once it has reached half EchoInterval. Further, section 4.4.1 describes how the CAPWAP Data Channel Keepalive is retransmitted, specifically: 4.4.1. CAPWAP Data Channel Keepalive [...] Upon receiving a CAPWAP Data Channel Keep Alive packet, the WTP cancels the DataChannelDeadInterval timer and resets the DataChannelKeepAlive timer. The CAPWAP Data Channel Keep Alive packet is retransmitted by the WTP in the same manner as the CAPWAP control messages. If the DataChannelDeadInterval timer expires, the WTP tears down the control DTLS session, and the data DTLS session if one existed. I think the second sentence could use a clarification and modified as follows: The CAPWAP Data Channel Keep Alive packet is retransmitted by the WTP in the same manner as the CAPWAP control messages, except the DataChannelKeepAlive timer is used in lieu of the EchoInterval timer. Comments? _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 5 15:24:02 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B85453A69CF for ; Tue, 5 Aug 2008 15:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdFKbvhsz9Mv for ; Tue, 5 Aug 2008 15:24:01 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 8721E3A67C1 for ; Tue, 5 Aug 2008 15:24:01 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A4BC81C40F85 for ; Tue, 5 Aug 2008 15:24:33 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id C35CA4401CF for ; Tue, 5 Aug 2008 15:24:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 9AA218006 for ; Tue, 5 Aug 2008 15:24:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 020608001 for ; Tue, 5 Aug 2008 15:24:21 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 5 Aug 2008 15:24:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,312,1215388800"; d="scan'208";a="61937806" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 05 Aug 2008 22:23:58 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m75MNw7c004815; Tue, 5 Aug 2008 15:23:58 -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.13.8/8.13.8) with ESMTP id m75MNwp2004496; Tue, 5 Aug 2008 22:23:58 GMT 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.1830); Tue, 5 Aug 2008 15:23:58 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Aug 2008 15:23:57 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206393CCC@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2063304F7@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Recap of current pending issues Thread-Index: Acjz9xoEqCcXlGoTT6y9r7yIArdLFwDULppA References: <4FF84B0BC277FF45AA27FE969DD956A2063304F7@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 05 Aug 2008 22:23:58.0228 (UTC) FILETIME=[F43B9D40:01C8F749] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Recap of current pending issues X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com All, With the IETF Last Call ending in a few hours, I wanted to provide an updated list of the issues, and required actions. I have updated Tracker to reflect the current state of all issues. I would like to get review, and confirmation, that the changes I have proposed are satisfactory before I publish another rev of the spec. Assuming I get nothing from the list (which I hope does not happen), my plan would be to publish the specs next Monday. So in order to ensure we have a high quality spec, I would urge you to look at the proposed changes and make sure that we are good to do. The resulting three specs (DHCP, Base and Binding) would then be ready to move to the IESG for publication. ISSUES WAITING FOR PASI's REVIEW Issue 156 (Need more details on use of DNS for discovery). This was a rather small change, but I got it wrong the first time. I am waiting for confirmation that this time around we are good to go. Issue 159 (Question on CAPWAP control protocol). This was a question, which I have responded to. There was no need for change, unless Pasi raises a specific issue. At this point, I consider this issue closed. Issue 166 (Various IANA Issues). This issue has been addressed, but I am waiting for Pasi's feedback. Issue 168 (DTLS and Retransmissions). Charles provided text for section 2.4.1, but we need Pasi to provide clarification on what he needed in section 2.4.3. Issue 171 (Pasi nits on binding spec). I believe this is done - I am just waiting to see if Pasi has issues with any of the proposed resolutions ISSUES WAITING FOR WG FEEDBACK. Issue 106 (WaitJoin may be unnecessary). Yes, this is an old one, but in fixing 173 I realized that we never should have removed the WaitJoin timer, but instead cleaned it up. This fix re-introduces the timer, but it is enabled/disabled differently from the WaitDTLS timer. I am waiting for WG feedback on this proposed change. Issue 150 (Allocation of WBIDs). There is no clear agreement on this issue. The current spec requires a Standards Action to allocate a WBID, but it doesn't look like EPCGlobal plans on submitting their protocol to the IETF. So we either agree to keep the document as it (although we did agree to remove 802.16), or change the IANA action from "Standards Action" to something else, such as perhaps "Designated Expert". We need clear resolution on this. Issue 151 (MTU discovery doesn't look right). Pasi stated that the MTU Discovery text was not sufficient, since we pointed to RFCs that described MTU Discovery behavior, but no protocol specifics. So I had to re-instate some old CAPWAP text (and new) to add protocol discovery. I am waiting for feedback for this issue. Issue 154 (Should we use IPv4 Multicast Address?). A request for a known multicast address to be registered. I proposed we reject this issue, and am waiting to make sure that we have consensus on this proposal. Issue 155 (WTP/AC ACL Synchronization Issue). So this is another interesting issue, and talking to the LWAPP developers it was introduced to support a mode of operation that the CAPWAP standard does not currently support. In the thread, I proposed we remove these message elements, otherwise we will need to do much more specmanship in order to support this new deployment requirement. Issue 161 (NAT Inconsistencies). This is another issue that uncovered some real problems in the CAPWAP protocol. Fixing it required some changes that will create backward compatibility issues - but there was no choice. The old text had two different possible ways of doing the same thing, with little/no guidance that would clearly create issues. Issue 165 (Image Download inconsistencies). This issue uncovered some problems in the CAPWAP protocol's mechanism of downloading firmware to a WTP. It required some changes to the protocol and I am waiting for feedback from folks before I consider this closed. Note this new text does possibly break backward compatibility, depending on how folks had interpreted the original text. Issue 169 (What to do with QoS tags exceeding maximum). Another one where we have a potential interoperability issue, and we need to agree on what behavior the WTP will take if it receives a packet whose QoS marking violates the configured policy. Alternatives have been proposed - waiting for feedback. Issue 172 (How is the WTP Descriptor's Encryption Capabilities defined?). This is a particularly thorny issue that can cause us to break backward interoperability, or worse, severely limit the scope of the protocol. We need a good resolution, and I have proposed a few already. Waiting for WG feedback. Issue 173 (Inconsistency in enabling DTLSWait timer). The text was inconsistent in how it was making use of the WaitDTLS timer. Specifically, there were two state transitions that referenced the timer, when it would have been stopped already before reaching that transition. I have already sent text and am waiting for feedback. Issue 175 (Retransmission clarification required). The text that specifies how control messages are retransmitted needs some clarification, specifically around the text that deals with congestion control. I have proposed a change, and am waiting for WG feedback. PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 5 15:34:57 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C440B3A6B5C for ; Tue, 5 Aug 2008 15:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zr7XF2nDZybu for ; Tue, 5 Aug 2008 15:34:57 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 5047A28C33F for ; Tue, 5 Aug 2008 15:34:45 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7CC181C40FD1 for ; Tue, 5 Aug 2008 15:35:17 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id E74034401C2 for ; Tue, 5 Aug 2008 15:35:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id B3E7B8011 for ; Tue, 5 Aug 2008 15:35:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D651F8007 for ; Tue, 5 Aug 2008 15:35:01 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from exchange.tm.thingmagic.com (exchange.tm.thingmagic.com [204.9.221.21]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 5 Aug 2008 15:35:01 -0700 (PDT) Received: from nwilliams-pc1 (10.0.0.175) by exchange.tm.thingmagic.com (10.0.0.9) with Microsoft SMTP Server id 8.1.291.1; Tue, 5 Aug 2008 18:35:01 -0400 From: "Nathan J. Williams" To: "Pat Calhoun (pacalhou)" References: <4FF84B0BC277FF45AA27FE969DD956A2062CB358@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A206330259@xmb-sjc-235.amer.cisco.com> Date: Tue, 5 Aug 2008 18:35:20 -0400 In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A206330259@xmb-sjc-235.amer.cisco.com> (Pat Calhoun's message of "Thu, 31 Jul 2008 17:43:34 -0400") Message-ID: MIME-Version: 1.0 Cc: "capwap@frascone.com" , "Pasi.Eronen@nokia.com" Subject: Re: [Capwap] Issue 155: WTP/AC ACL Synchronization Issue X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com "Pat Calhoun (pacalhou)" writes: > Second, the way it works is that the AC *always* sends an updated list > to the WTP at reboot. However, some WTPs *could* conceptually operate > without an AC (such as the case where the WAN link between the WTP and > the AC is down). Obviously, such WTPs could only operate this way when > configured for Local mode. Split mode requires an AC. > > So the WTP stores the ACL, and can use it even if it reboots and it is > unable to connect to the AC. However, it always gets an updated list > from the AC when it does connect. > > So... Given that we've never discussed the concept of a WTP operating > without an AC, does it really make sense to leave this functionality in > the spec? I think we should pull out the Add/Delete Static message > elements, and deal with this in a future rev of the spec if the need > arises (because it will likely require more than just some verbage here > and there). > > Thoughts? Deleting the Add/Delete Static message elements sounds good to me. Should we spell out when the WTP's list is reset to zero? At the time of association with an AC seems right, otherwise things like Primary Discovery could re-introduce the problem of losing sync of the ACL. - Nathan _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 6 09:18:47 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 810C13A68AA for ; Wed, 6 Aug 2008 09:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.494 X-Spam-Level: X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDDC8UYAQHQo for ; Wed, 6 Aug 2008 09:18:46 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 290393A67FE for ; Wed, 6 Aug 2008 09:18:46 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 405011C40FC3 for ; Wed, 6 Aug 2008 09:18:53 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id A03D7440194 for ; Wed, 6 Aug 2008 09:18:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 65E4C34AC062 for ; Wed, 6 Aug 2008 09:18:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8587234AC034 for ; Wed, 6 Aug 2008 09:18:40 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.68.10.86 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 6 Aug 2008 09:18:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,315,1215388800"; d="scan'208";a="19457213" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 06 Aug 2008 16:18:31 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m76GIVYk028863; Wed, 6 Aug 2008 09:18:31 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m76GIUkU000179; Wed, 6 Aug 2008 16:18:31 GMT 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.1830); Wed, 6 Aug 2008 09:18:21 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Aug 2008 09:18:20 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206393F8B@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 155: WTP/AC ACL Synchronization Issue Thread-Index: Acj3S5NVVPQiIMZwTFmI80MotTxCqQAk9hQA References: <4FF84B0BC277FF45AA27FE969DD956A2062CB358@xmb-sjc-235.amer.cisco.com><4FF84B0BC277FF45AA27FE969DD956A206330259@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Nathan J. Williams" X-OriginalArrivalTime: 06 Aug 2008 16:18:21.0537 (UTC) FILETIME=[0B5BF510:01C8F7E0] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: capwap@frascone.com, Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 155: WTP/AC ACL Synchronization Issue X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com OK, great. Here is the proposed changes. I am deleting the following text: 4.6. CAPWAP Protocol Message Elements [...] Add Static MAC ACL Entry 9 [...] Delete Static MAC ACL Entry 19 4.6.9. Add Static MAC ACL Entry The Add Static MAC ACL Entry message element is used by an AC to add a permanent ACL entry on a WTP, ensuring that the WTP no longer provides any service to the MAC addresses provided in the message. The MAC Addresses provided in this message element are expected to be saved in non-volatile memory on the WTP. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num of Entries| Length | MAC Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 9 for Add Static MAC ACL Entry Length: >= 8 Num of Entries: The number of instances of the Length/MAC Addresses fields in the array. This value MUST NOT exceed 255. Length: The length of the MAC Address field. The following formats, and lengths, are supported [EUI-48] and [EUI-64]. MAC Address: MAC Addresses to add to the permanent ACL. 4.6.22. Delete Static MAC ACL Entry The Delete Static MAC ACL Entry message element is used by an AC to delete a previously added static MAC ACL entry on a WTP, ensuring that the WTP provides service to the MAC addresses provided in the message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num of Entries| Length | MAC Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 19 for Delete Static MAC ACL Entry Length: >= 8 Num of Entries: The number of instances of the Length/MAC Addresses fields in the array. This field MUST NOT exceed the value of 1024. Length: The length of the MAC Address field. The following formats, and lengths, are supported [EUI-48] and [EUI-64]. MAC Address: An array of MAC Addresses to delete from the static MAC ACL entry. 4.9.7. Static ACL Table The static ACL table saved on the WTP, as configured by the Add Static MAC ACL Entry message element, see Section 4.6.9. 8.4. Configuration Update Request [...] o Add MAC ACL Entry, see Section 4.6.7 [...] o Delete Static MAC ACL Entry, see Section 4.6.22 And have made the following changes, including adding a sentence to the end of 4.6.7: 4.6. CAPWAP Protocol Message Elements [...] Reserved 9 [...] Reserved 19 4.6.7. Add MAC ACL Entry The Add MAC Access Control List (ACL) Entry message element is used by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP no longer provides service to the MAC addresses provided in the message. The MAC Addresses provided in this message element are not expected to be saved in non-volatile memory on the WTP. The MAC ACL table on the WTP is cleared everytime the WTP establishes a new session with an AC. [...] PatC -----Original Message----- From: Nathan J. Williams [mailto:nathan.williams@thingmagic.com] Sent: Tuesday, August 05, 2008 3:35 PM To: Pat Calhoun (pacalhou) Cc: Nathan Williams; capwap@frascone.com; Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 155: WTP/AC ACL Synchronization Issue "Pat Calhoun (pacalhou)" writes: > Second, the way it works is that the AC *always* sends an updated list > to the WTP at reboot. However, some WTPs *could* conceptually operate > without an AC (such as the case where the WAN link between the WTP and > the AC is down). Obviously, such WTPs could only operate this way when > configured for Local mode. Split mode requires an AC. > > So the WTP stores the ACL, and can use it even if it reboots and it is > unable to connect to the AC. However, it always gets an updated list > from the AC when it does connect. > > So... Given that we've never discussed the concept of a WTP operating > without an AC, does it really make sense to leave this functionality > in the spec? I think we should pull out the Add/Delete Static message > elements, and deal with this in a future rev of the spec if the need > arises (because it will likely require more than just some verbage > here and there). > > Thoughts? Deleting the Add/Delete Static message elements sounds good to me. Should we spell out when the WTP's list is reset to zero? At the time of association with an AC seems right, otherwise things like Primary Discovery could re-introduce the problem of losing sync of the ACL. - Nathan _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 7 02:27:29 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40D6628C165 for ; Thu, 7 Aug 2008 02:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.305 X-Spam-Level: X-Spam-Status: No, score=-4.305 tagged_above=-999 required=5 tests=[AWL=-0.706, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQU+i1T-AgHx for ; Thu, 7 Aug 2008 02:27:28 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 22EC928C157 for ; Thu, 7 Aug 2008 02:27:28 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C9810430D2F for ; Thu, 7 Aug 2008 02:28:02 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 2055544015B for ; Thu, 7 Aug 2008 02:27:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id EBB2A34AC05A for ; Thu, 7 Aug 2008 02:27:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4835134AC059 for ; Thu, 7 Aug 2008 02:27:43 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.105.134 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 7 Aug 2008 02:27:43 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m779R0dc006864; Thu, 7 Aug 2008 04:27:37 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2008 12:27:28 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2008 12:27:21 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 12:27:21 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72014C5DE2@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20632FD50@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 156: Need more details on use of DNS for discovery Thread-Index: Acjw7k+CFmHJVrthTkC9sgWe7odDLwBixyKwAAbVHpABdnsPwA== References: <4FF84B0BC277FF45AA27FE969DD956A2062CB002@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72013BB240@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20632FD50@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 07 Aug 2008 09:27:21.0475 (UTC) FILETIME=[CB3ADD30:01C8F86F] X-Nokia-AV: Clean Subject: Re: [Capwap] Issue 156: Need more details on use of DNS for discovery X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Hi Pat, The 'DNS name "CAPWAP-AC-Address" MAY be resolvable' part still isn't quite right; that DNS name won't be resolvable (which is clear after reading the third sentence). Also, some more details would be helpful for the SRV record part. Would something like this match your intent? DNS: The WTP MAY support use of DNS SRV records [RFC2782] to discover the AC address(es). In this case, the WTP first obtains (e.g., from local configuration) the correct domain name suffix (e.g., "example.com") and performs a SRV lookup with Service name "capwap-control" and Proto "udp". Thus, the name resolved in DNS would be, e.g., "_capwap-control._udp.example.com". Note that the SRV record MAY specify a non-default port number for the control channel; the port number for the data channel is the next port number (control channel port + 1). (I'm assuming the use of the IANA-assigned service name, instead of non-registered "CAPWAP-AC-Address"; and with this text about SRV port number handling, you might need small tweaking in Section 3.1, too. Or you might want to handle port number in some other way.) Best regards, Pasi > -----Original Message----- > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: 31 July, 2008 01:38 > To: Eronen Pasi (Nokia-NRC/Helsinki); capwap@frascone.com > Subject: RE: Issue 156: Need more details on use of DNS for discovery > > My apologies, Pasi. I'm not sure what I was thinking when I wrote the > text. > > What I should have sent was: > > > DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one or > more AC addresses. A WTP that wishes to make use of DNS SHOULD > use the format described in [RFC2782]. The recommended > format for > a lookup would be CAPWAP-AC-Address._udp.example.com. > > > Does that make more sense? > > PatC > > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Wednesday, July 30, 2008 12:29 PM > To: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: RE: Issue 156: Need more details on use of DNS for discovery > > Pat Calhoun wrote: > > > > Pasi's comment was: > > > > Section 3.3: there's a single sentence about DNS-based discovery; > > probably slightly more details would be useful. > > > > Well... There's not much else we can say, but I am proposing the > > following text In hopes that it will provide more clarity to the > > implementor. > > > > > > 3.3. AC Discovery > > [...] > > DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one > > or more AC addresses. A WTP that wishes to make use of DNS > > SHOULD use the format described in [RFC2782]. The > recommended > > format for a lookup would be _capwap._udp.example.com. > > > > I have some trouble parsing the 'The DNS name > "CAPWAP-AC-Address" MAY be > resolvable...' part. It seems to be suggesting doing a DNS > query for DNS > name "CAPWAP-AC-Address" -- or in other words, defining a new > Top-Level > Domain. That probably isn't a good idea. > > The two latter sentences are also leaving awfully lot of > details to the > implementor -- RFC2782 has specific requirements about the labels etc. > (E.g. RFC 3861 has much more text about using SRV records for another > purpose.) > > Best regards, > Pasi > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 7 02:29:03 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C353828C16D for ; Thu, 7 Aug 2008 02:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.283 X-Spam-Level: X-Spam-Status: No, score=-4.283 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_00=-2.599, FUZZY_CPILL=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z617ofNJmEA2 for ; Thu, 7 Aug 2008 02:29:02 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id E2D8028C165 for ; Thu, 7 Aug 2008 02:29:02 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EBEDE430BC0 for ; Thu, 7 Aug 2008 02:29:38 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 47A2F44015B for ; Thu, 7 Aug 2008 02:29:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 072F33610014 for ; Thu, 7 Aug 2008 02:29:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 13AD2361000C for ; Thu, 7 Aug 2008 02:29:28 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.105.134 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 7 Aug 2008 02:29:28 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m779TBQt008821; Thu, 7 Aug 2008 04:29:18 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2008 12:29:11 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2008 12:29:09 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 12:29:09 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72014C5DE6@vaebe104.NOE.Nokia.com> In-Reply-To: <4892D971.1010303@ltsnet.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 168: DTLS and Retransmissions Thread-Index: AcjzumyAbATy+JciTxKX5CL/ZnsZmAEtZWqQ References: <4FF84B0BC277FF45AA27FE969DD956A20632FD71@xmb-sjc-235.amer.cisco.com> <4892D971.1010303@ltsnet.net> From: To: , X-OriginalArrivalTime: 07 Aug 2008 09:29:09.0426 (UTC) FILETIME=[0B92E120:01C8F870] X-Nokia-AV: Clean Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Hi Charles, Your suggested change looks good. Best regards, Pasi > -----Original Message----- > From: ext Charles Clancy [mailto:clancy@ltsnet.net] > Sent: 01 August, 2008 12:38 > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com; Eronen Pasi (Nokia-NRC/Helsinki); > skelly@arubanetworks.com > Subject: Re: Issue 168: DTLS and Retransmissions > > Suggested text changes to address the comments: > > Replace this 2.4.1 text: > > DTLS, as specified, provides its own retransmit timers with an > exponential back-off. However, DTLS will never terminate the > handshake due to non-responsiveness; instead, DTLS will > continue to > increase its back-off timer period. Hence, timing out incomplete > DTLS handshakes is entirely the responsibility of the > CAPWAP module. > > with this text: > > DTLS, as specified, provides its own retransmit timers with an > exponential back-off. [RFC4347] does not specify how long > retransmissions should continue. Consequently, timing > out incomplete > DTLS handshakes is entirely the responsibility of the > CAPWAP module. > > I'm not sure what needs to be addressed in 2.4.3. Pasi -- can you be > more specific? > > -- > Dr. Charles Clancy www.ltsnet.net/~clancy > Senior Researcher, Laboratory for Telecommunications Sciences > > > Pat Calhoun (pacalhou) wrote: > > Pasi's comment was: > > > > Section 2.4.1: "DTLS will never terminate the handshake due to > > non-responsiveness; instead, DTLS will continue to > > increase its back-off timer period" While RFC 4347 > doesn't specify > > how > > long you should continue retransmitting, the > > intent certainly was not to continue indefinitely. > > > > Section 2.4.3 text about DTLS retransmissions is > slightly inaccurate; > > DTLS handshake isn't strictly request/response, > > and both parties (not just the DTLS client) retransmit based on > > timers > > (in some situations). > > > > It is unclear to me as to whether these are simply observations, or > > request for change. That said, I would like either Charles > or Scott to > > reply. > > > > PatC > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 7 05:42:22 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64EDB3A6BCF for ; Thu, 7 Aug 2008 05:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.659 X-Spam-Level: X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=0.941, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wg34+82SzAJv for ; Thu, 7 Aug 2008 05:42:21 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 406473A6B65 for ; Thu, 7 Aug 2008 05:42:21 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 317B543286C for ; Thu, 7 Aug 2008 05:42:57 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 3CC9E440168 for ; Thu, 7 Aug 2008 05:42:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 5975B34AC073 for ; Thu, 7 Aug 2008 05:42:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4214E34AC064 for ; Thu, 7 Aug 2008 05:42:40 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from exchange.tm.thingmagic.com (exchange.tm.thingmagic.com [204.9.221.21]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 7 Aug 2008 05:42:39 -0700 (PDT) Received: from [10.36.0.26] (76.24.195.210) by exchange.tm.thingmagic.com (10.0.0.9) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 7 Aug 2008 08:42:38 -0400 In-Reply-To: <1696498986EFEC4D9153717DA325CB72014C5DE2@vaebe104.NOE.Nokia.com> References: <4FF84B0BC277FF45AA27FE969DD956A2062CB002@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72013BB240@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20632FD50@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C5DE2@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 (Apple Message framework v753.1) Message-ID: <8DB21F28-ADCB-4E94-A6CF-4192ABB81985@thingmagic.com> From: Margaret Wasserman Date: Thu, 7 Aug 2008 08:42:36 -0400 To: X-Mailer: Apple Mail (2.753.1) Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 156: Need more details on use of DNS for discovery X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com FWIW, Pasi's wording sounds good to me. I also agree that we should ask for an IANA-assigned service name, which implies a related change to the IANA Considerations. Margaret On Aug 7, 2008, at 5:27 AM, wrote: > Hi Pat, > > The 'DNS name "CAPWAP-AC-Address" MAY be resolvable' part still > isn't quite right; that DNS name won't be resolvable (which > is clear after reading the third sentence). Also, some more details > would be helpful for the SRV record part. Would something like this > match your intent? > > DNS: The WTP MAY support use of DNS SRV records [RFC2782] to > discover the AC address(es). In this case, the WTP first obtains > (e.g., from local configuration) the correct domain name suffix > (e.g., "example.com") and performs a SRV lookup with Service name > "capwap-control" and Proto "udp". Thus, the name resolved in DNS > would be, e.g., "_capwap-control._udp.example.com". Note that the > SRV record MAY specify a non-default port number for the control > channel; the port number for the data channel is the next > port number (control channel port + 1). > > (I'm assuming the use of the IANA-assigned service name, instead of > non-registered "CAPWAP-AC-Address"; and with this text about SRV port > number handling, you might need small tweaking in Section 3.1, too. > Or you might want to handle port number in some other way.) > > Best regards, > Pasi > >> -----Original Message----- >> From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] >> Sent: 31 July, 2008 01:38 >> To: Eronen Pasi (Nokia-NRC/Helsinki); capwap@frascone.com >> Subject: RE: Issue 156: Need more details on use of DNS for discovery >> >> My apologies, Pasi. I'm not sure what I was thinking when I wrote the >> text. >> >> What I should have sent was: >> >> >> DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one or >> more AC addresses. A WTP that wishes to make use of DNS SHOULD >> use the format described in [RFC2782]. The recommended >> format for >> a lookup would be CAPWAP-AC-Address._udp.example.com. >> >> >> Does that make more sense? >> >> PatC >> >> -----Original Message----- >> From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] >> Sent: Wednesday, July 30, 2008 12:29 PM >> To: Pat Calhoun (pacalhou); capwap@frascone.com >> Subject: RE: Issue 156: Need more details on use of DNS for discovery >> >> Pat Calhoun wrote: >>> >>> Pasi's comment was: >>> >>> Section 3.3: there's a single sentence about DNS-based discovery; >>> probably slightly more details would be useful. >>> >>> Well... There's not much else we can say, but I am proposing the >>> following text In hopes that it will provide more clarity to the >>> implementor. >>> >>> >>> 3.3. AC Discovery >>> [...] >>> DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one >>> or more AC addresses. A WTP that wishes to make use of DNS >>> SHOULD use the format described in [RFC2782]. The >> recommended >>> format for a lookup would be _capwap._udp.example.com. >>> >> >> I have some trouble parsing the 'The DNS name >> "CAPWAP-AC-Address" MAY be >> resolvable...' part. It seems to be suggesting doing a DNS >> query for DNS >> name "CAPWAP-AC-Address" -- or in other words, defining a new >> Top-Level >> Domain. That probably isn't a good idea. >> >> The two latter sentences are also leaving awfully lot of >> details to the >> implementor -- RFC2782 has specific requirements about the labels >> etc. >> (E.g. RFC 3861 has much more text about using SRV records for another >> purpose.) >> >> Best regards, >> Pasi >> > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/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 Aug 7 09:27:02 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15B023A6C21 for ; Thu, 7 Aug 2008 09:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kpalCV+cLks for ; Thu, 7 Aug 2008 09:27:00 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id D91253A6BF6 for ; Thu, 7 Aug 2008 09:27:00 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9E64443A053 for ; Thu, 7 Aug 2008 09:27:37 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id EED27440171 for ; Thu, 7 Aug 2008 09:27:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E690834AC02D for ; Thu, 7 Aug 2008 09:27:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 5569E34AC018 for ; Thu, 7 Aug 2008 09:27:21 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.68.10.86 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 7 Aug 2008 09:27:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,321,1215388800"; d="scan'208";a="19511788" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 07 Aug 2008 16:27:16 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m77GRGno006063; Thu, 7 Aug 2008 09:27:16 -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.13.8/8.13.8) with ESMTP id m77GRGSt002802; Thu, 7 Aug 2008 16:27:16 GMT 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.1830); Thu, 7 Aug 2008 09:27:16 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 09:27:15 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2063E653E@xmb-sjc-235.amer.cisco.com> In-Reply-To: <8DB21F28-ADCB-4E94-A6CF-4192ABB81985@thingmagic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 156: Need more details on use of DNS for discovery Thread-Index: Acj4ix0T/AKMpHGvTCScOyi8TECibQAHrtRw References: <4FF84B0BC277FF45AA27FE969DD956A2062CB002@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72013BB240@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20632FD50@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C5DE2@vaebe104.NOE.Nokia.com> <8DB21F28-ADCB-4E94-A6CF-4192ABB81985@thingmagic.com> From: "Pat Calhoun (pacalhou)" To: "Margaret Wasserman" , X-OriginalArrivalTime: 07 Aug 2008 16:27:16.0259 (UTC) FILETIME=[747DCF30:01C8F8AA] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 156: Need more details on use of DNS for discovery X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com The IANA service name has already been taken care of, and is already in the IANA Considerations section in -12 (as requested during WG LC). I do, however, have an issue with the last sentence in Pasi's proposed text, as it states that data channel is control+1. However, in the previous sentence he clearly states that control MAY NOT be the default (assigned) port. So I would prefer to change the last sentence to: "Note that the SRV record MAY specify a non-default port number for the control channel; the default port number for the data channel is the next port number (control channel port + 1). However, in the case where the control channel uses a non-default port number, the WTP MAY perform a SRV lookup with Service name "capwap-data" and Proto "udp". Thus, the name resolved in DNS would be e.g., "_capwap-data._udp.example.com"." Comments? PatC -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com] Sent: Thursday, August 07, 2008 5:43 AM To: Pasi.Eronen@nokia.com Cc: Pat Calhoun (pacalhou); capwap@frascone.com Subject: Re: [Capwap] Issue 156: Need more details on use of DNS for discovery FWIW, Pasi's wording sounds good to me. I also agree that we should ask for an IANA-assigned service name, which implies a related change to the IANA Considerations. Margaret On Aug 7, 2008, at 5:27 AM, wrote: > Hi Pat, > > The 'DNS name "CAPWAP-AC-Address" MAY be resolvable' part still isn't > quite right; that DNS name won't be resolvable (which is clear after > reading the third sentence). Also, some more details would be helpful > for the SRV record part. Would something like this match your intent? > > DNS: The WTP MAY support use of DNS SRV records [RFC2782] to > discover the AC address(es). In this case, the WTP first obtains > (e.g., from local configuration) the correct domain name suffix > (e.g., "example.com") and performs a SRV lookup with Service name > "capwap-control" and Proto "udp". Thus, the name resolved in DNS > would be, e.g., "_capwap-control._udp.example.com". Note that the > SRV record MAY specify a non-default port number for the control > channel; the port number for the data channel is the next > port number (control channel port + 1). > > (I'm assuming the use of the IANA-assigned service name, instead of > non-registered "CAPWAP-AC-Address"; and with this text about SRV port > number handling, you might need small tweaking in Section 3.1, too. > Or you might want to handle port number in some other way.) > > Best regards, > Pasi > >> -----Original Message----- >> From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] >> Sent: 31 July, 2008 01:38 >> To: Eronen Pasi (Nokia-NRC/Helsinki); capwap@frascone.com >> Subject: RE: Issue 156: Need more details on use of DNS for discovery >> >> My apologies, Pasi. I'm not sure what I was thinking when I wrote the >> text. >> >> What I should have sent was: >> >> >> DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one or >> more AC addresses. A WTP that wishes to make use of DNS SHOULD >> use the format described in [RFC2782]. The recommended format >> for >> a lookup would be CAPWAP-AC-Address._udp.example.com. >> >> >> Does that make more sense? >> >> PatC >> >> -----Original Message----- >> From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] >> Sent: Wednesday, July 30, 2008 12:29 PM >> To: Pat Calhoun (pacalhou); capwap@frascone.com >> Subject: RE: Issue 156: Need more details on use of DNS for discovery >> >> Pat Calhoun wrote: >>> >>> Pasi's comment was: >>> >>> Section 3.3: there's a single sentence about DNS-based discovery; >>> probably slightly more details would be useful. >>> >>> Well... There's not much else we can say, but I am proposing the >>> following text In hopes that it will provide more clarity to the >>> implementor. >>> >>> >>> 3.3. AC Discovery >>> [...] >>> DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one >>> or more AC addresses. A WTP that wishes to make use of DNS >>> SHOULD use the format described in [RFC2782]. The >> recommended >>> format for a lookup would be _capwap._udp.example.com. >>> >> >> I have some trouble parsing the 'The DNS name "CAPWAP-AC-Address" MAY >> be resolvable...' part. It seems to be suggesting doing a DNS query >> for DNS name "CAPWAP-AC-Address" -- or in other words, defining a new >> Top-Level Domain. That probably isn't a good idea. >> >> The two latter sentences are also leaving awfully lot of details to >> the implementor -- RFC2782 has specific requirements about the labels >> etc. >> (E.g. RFC 3861 has much more text about using SRV records for another >> purpose.) >> >> Best regards, >> Pasi >> > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/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 Aug 7 09:48:23 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4378B3A6C20 for ; Thu, 7 Aug 2008 09:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.287 X-Spam-Level: X-Spam-Status: No, score=-4.287 tagged_above=-999 required=5 tests=[AWL=-0.688, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkl231il553N for ; Thu, 7 Aug 2008 09:48:22 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 47A603A6C1F for ; Thu, 7 Aug 2008 09:48:22 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1102B1C40FC3 for ; Thu, 7 Aug 2008 09:48:59 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 2338B440173 for ; Thu, 7 Aug 2008 09:48:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id EA09A34AC005 for ; Thu, 7 Aug 2008 09:48:45 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0974F34AC018 for ; Thu, 7 Aug 2008 09:48:44 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.122.230 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 7 Aug 2008 09:48:43 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m77Gm7WB003350; Thu, 7 Aug 2008 19:48:18 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2008 19:47:52 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2008 19:47:41 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 19:47:42 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72014C6257@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2063E653E@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 156: Need more details on use of DNS for discovery Thread-Index: Acj4ix0T/AKMpHGvTCScOyi8TECibQAHrtRwAACqL0A= References: <4FF84B0BC277FF45AA27FE969DD956A2062CB002@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72013BB240@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20632FD50@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C5DE2@vaebe104.NOE.Nokia.com> <8DB21F28-ADCB-4E94-A6CF-4192ABB81985@thingmagic.com> <4FF84B0BC277FF45AA27FE969DD956A2063E653E@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 07 Aug 2008 16:47:41.0393 (UTC) FILETIME=[4EBA6C10:01C8F8AD] X-Nokia-AV: Clean Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 156: Need more details on use of DNS for discovery X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun wrote: > > The IANA service name has already been taken care of, and is already > in the IANA Considerations section in -12 (as requested during WG > LC). I do, however, have an issue with the last sentence in Pasi's > proposed text, as it states that data channel is control+1. However, > in the previous sentence he clearly states that control MAY NOT be > the default (assigned) port. So I would prefer to change the last > sentence to: > > "Note that the SRV record MAY specify a non-default port number for > the control channel; the default port number for the data channel is > the next port number (control channel port + 1). However, in the > case where the control channel uses a non-default port number, the > WTP MAY perform a SRV lookup with Service name "capwap-data" and > Proto "udp". Thus, the name resolved in DNS would be e.g., > "_capwap-data._udp.example.com"." > > Comments? How would the WTP know whether the data channel is control+1, or found by another SRV lookup? Something like "If the control channel port in the SRV record is 5246, data port is 5247; otherwise, the WTP MUST perform another SRV lookup" would work, but IMHO it sounds like unnecessary complexity -- is there any reason why the AC can't just pick two consecutive ports? Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 7 10:05:30 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24C4E3A68F0 for ; Thu, 7 Aug 2008 10:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glJ7domQBcwF for ; Thu, 7 Aug 2008 10:05:29 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 17AB13A6768 for ; Thu, 7 Aug 2008 10:05:29 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EA94A439FD0 for ; Thu, 7 Aug 2008 10:06:05 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 14BBD44015B for ; Thu, 7 Aug 2008 10:05:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3835434AC085 for ; Thu, 7 Aug 2008 10:05:52 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 6434B34AC09B for ; Thu, 7 Aug 2008 10:05:39 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 7 Aug 2008 10:05:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,321,1215388800"; d="scan'208";a="137060651" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 07 Aug 2008 17:05:38 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m77H5cMP014948; Thu, 7 Aug 2008 10:05:38 -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.13.8/8.13.8) with ESMTP id m77H5cM8014010; Thu, 7 Aug 2008 17:05:38 GMT 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.1830); Thu, 7 Aug 2008 10:05:38 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 10:05:37 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2063E6598@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB72014C6257@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 156: Need more details on use of DNS for discovery Thread-Index: Acj4ix0T/AKMpHGvTCScOyi8TECibQAHrtRwAACqL0AAAKokUA== References: <4FF84B0BC277FF45AA27FE969DD956A2062CB002@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72013BB240@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20632FD50@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C5DE2@vaebe104.NOE.Nokia.com> <8DB21F28-ADCB-4E94-A6CF-4192ABB81985@thingmagic.com> <4FF84B0BC277FF45AA27FE969DD956A2063E653E@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C6257@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 07 Aug 2008 17:05:38.0217 (UTC) FILETIME=[D090B990:01C8F8AF] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 156: Need more details on use of DNS for discovery X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com OK, in which case we need to include text in 3.1 that says that if an AC uses the non-default control port, then the data port MUST be control+1. Specifically, I would propose keeing your original text, and adding the following text to section 3.1: 3.1. UDP Transport [...] CAPWAP protocol data packets sent from the WTP to the AC use the CAPWAP data channel, as defined in Section 1.4. The CAPWAP data port at the AC is the well known UDP port 5247. If an AC permits the administrator to change the CAPWAP control port, the CAPWAP data port MUST be the next consecutive port number. The CAPWAP data port at the WTP can be any port selected by the WTP. OK? PatC -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Thursday, August 07, 2008 9:48 AM To: Pat Calhoun (pacalhou); margaret@thingmagic.com Cc: capwap@frascone.com Subject: RE: [Capwap] Issue 156: Need more details on use of DNS for discovery Pat Calhoun wrote: > > The IANA service name has already been taken care of, and is already > in the IANA Considerations section in -12 (as requested during WG LC). > I do, however, have an issue with the last sentence in Pasi's proposed > text, as it states that data channel is control+1. However, in the > previous sentence he clearly states that control MAY NOT be the > default (assigned) port. So I would prefer to change the last sentence > to: > > "Note that the SRV record MAY specify a non-default port number for > the control channel; the default port number for the data channel is > the next port number (control channel port + 1). However, in the case > where the control channel uses a non-default port number, the WTP MAY > perform a SRV lookup with Service name "capwap-data" and Proto "udp". > Thus, the name resolved in DNS would be e.g., > "_capwap-data._udp.example.com"." > > Comments? How would the WTP know whether the data channel is control+1, or found by another SRV lookup? Something like "If the control channel port in the SRV record is 5246, data port is 5247; otherwise, the WTP MUST perform another SRV lookup" would work, but IMHO it sounds like unnecessary complexity -- is there any reason why the AC can't just pick two consecutive ports? Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 7 11:11:35 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1455E3A6914 for ; Thu, 7 Aug 2008 11:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.268 X-Spam-Level: X-Spam-Status: No, score=-4.268 tagged_above=-999 required=5 tests=[AWL=-0.669, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-9YRbRl40Ao for ; Thu, 7 Aug 2008 11:11:33 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id AE30E3A67ED for ; Thu, 7 Aug 2008 11:11:33 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 311281C40FB3 for ; Thu, 7 Aug 2008 11:12:08 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 6B9A444017E for ; Thu, 7 Aug 2008 11:11:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2850034AC009 for ; Thu, 7 Aug 2008 11:11:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D0F9E34AC045 for ; Thu, 7 Aug 2008 11:10:59 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.122.230 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 7 Aug 2008 11:10:57 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m77IAidh015379; Thu, 7 Aug 2008 21:10:52 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2008 21:10:44 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2008 21:10:31 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 21:10:31 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72014C6276@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2063E6598@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 156: Need more details on use of DNS for discovery Thread-Index: Acj4ix0T/AKMpHGvTCScOyi8TECibQAHrtRwAACqL0AAAKokUAACaZcg References: <4FF84B0BC277FF45AA27FE969DD956A2062CB002@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72013BB240@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20632FD50@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C5DE2@vaebe104.NOE.Nokia.com> <8DB21F28-ADCB-4E94-A6CF-4192ABB81985@thingmagic.com> <4FF84B0BC277FF45AA27FE969DD956A2063E653E@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C6257@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2063E6598@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 07 Aug 2008 18:10:31.0985 (UTC) FILETIME=[E16E9210:01C8F8B8] X-Nokia-AV: Clean Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 156: Need more details on use of DNS for discovery X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Works for me. Best regards, Pasi > -----Original Message----- > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: 07 August, 2008 20:06 > To: Eronen Pasi (Nokia-NRC/Helsinki); margaret@thingmagic.com > Cc: capwap@frascone.com > Subject: RE: [Capwap] Issue 156: Need more details on use of > DNS for discovery > > OK, in which case we need to include text in 3.1 that says > that if an AC > uses the non-default control port, then the data port MUST be > control+1. > Specifically, I would propose keeing your original text, and > adding the > following text to section 3.1: > > > 3.1. UDP Transport > [...] > CAPWAP protocol data packets sent from the WTP to the AC use the > CAPWAP data channel, as defined in Section 1.4. The > CAPWAP data port > at the AC is the well known UDP port 5247. If an AC permits the > administrator to change the CAPWAP control port, the > CAPWAP data port > MUST be the next consecutive port number. The CAPWAP data port at > the WTP can be any port selected by the WTP. > > > OK? > > PatC > > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Thursday, August 07, 2008 9:48 AM > To: Pat Calhoun (pacalhou); margaret@thingmagic.com > Cc: capwap@frascone.com > Subject: RE: [Capwap] Issue 156: Need more details on use of DNS for > discovery > > Pat Calhoun wrote: > > > > The IANA service name has already been taken care of, and > is already > > in the IANA Considerations section in -12 (as requested > during WG LC). > > > I do, however, have an issue with the last sentence in > Pasi's proposed > > > text, as it states that data channel is control+1. However, in the > > previous sentence he clearly states that control MAY NOT be the > > default (assigned) port. So I would prefer to change the > last sentence > > > to: > > > > "Note that the SRV record MAY specify a non-default port number for > > the control channel; the default port number for the data > channel is > > the next port number (control channel port + 1). However, > in the case > > where the control channel uses a non-default port number, > the WTP MAY > > perform a SRV lookup with Service name "capwap-data" and > Proto "udp". > > > Thus, the name resolved in DNS would be e.g., > > "_capwap-data._udp.example.com"." > > > > Comments? > > How would the WTP know whether the data channel is control+1, or found > by another SRV lookup? > > Something like "If the control channel port in the SRV record is 5246, > data port is 5247; otherwise, the WTP MUST perform another SRV lookup" > would work, but IMHO it sounds like unnecessary complexity -- is there > any reason why the AC can't just pick two consecutive ports? > > Best regards, > Pasi > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 7 14:09:18 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31C423A6872 for ; Thu, 7 Aug 2008 14:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbksMqRLNfCJ for ; Thu, 7 Aug 2008 14:09:17 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 09E063A6976 for ; Thu, 7 Aug 2008 14:09:14 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EFDB01C40FD7 for ; Thu, 7 Aug 2008 14:09:11 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 110B7440156 for ; Thu, 7 Aug 2008 14:08:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D049C3808018 for ; Thu, 7 Aug 2008 14:08:56 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id DA8623808006 for ; Thu, 7 Aug 2008 14:08:54 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.122.230 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 7 Aug 2008 14:08:54 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m77L7i5o012861; Fri, 8 Aug 2008 00:08:07 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 00:08:05 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 00:07:57 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Aug 2008 00:08:00 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72014C629F@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20633000B@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 171: Pasi nits on binding spec Thread-Index: AcjzL5wHOa8wpdqYQUmSlvTmZmTg1QFnnI4Q References: <4FF84B0BC277FF45AA27FE969DD956A20633000B@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 07 Aug 2008 21:07:57.0173 (UTC) FILETIME=[AA755A50:01C8F8D1] X-Nokia-AV: Clean Subject: Re: [Capwap] Issue 171: Pasi nits on binding spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun wrote: > > Section 6.1 and 6.21: are some of these 802.11 information elements > > optional, or are all of them always included? > Always, since the text states: > > > The inclusion of this message > element MUST also include the IEEE 802.11 Information > Element message > element, containing the following 802.11 IEs: > Does this mean that e.g. all WTPs MUST support WMM? (since the AC MUST always send the WMM information element) And MUST support WPA forever (in addition to RSN)? > > Section 6.1 and 6.21: what do you put in "Key Status" if you're not > > using encryption at all? > > Well... Good question. The way it works is that the absence of a key > means that the key status field is irrelevant, but perhaps it would be > good to define a new "unused" value. However, this *could* create a > backward compatibility problem. Alternatively, we could add text that > simply states that this field is ignored if the key field has a zero > length, and then it really doesn't matter what value was used. > > OK? I'm fine with either approach. > > Section 6.14, 6.20, and 6.22: the 802.1p Tag field should probably > > be shown as 3 bits in the diagram, to make it unambiguous about > > which bits are not used. > Well... That would truncate a packet on a non-byte boundary. Do you > really believe that would help clear things up? No need to truncate the packet on a non-byte boundary; just show where the unused padding bits are. Something like this ("Z" is unused): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address |Z|Z| DSCP Tag |Z|Z|Z|Z|Z|8021p| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or this: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | DSCP Tag |Z|Z|Z|Z|Z|Z|Z|8021p| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or this: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | DSCP Tag |Z|Z|8021p|Z|Z|Z|Z|Z| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ depending on which you meant... > > Sections 6.20 and 6.22: the DSCP Tag field should probably be > > shown as 6 bits in the diagram, to make it unambiguous how it's > > sent in IPv4/IPv6 header (and which bits are unused). > > See above. I think showing fragments of a byte is even harder to > understand. I have never seen RFCs to that. See above. > > Section 6.20 and 6.22: "if packets are to be DSCP tagged" would > benefit of > > clarifying what packets are meant (I guess > > it means CAPWAP Data packets sent from the WTP to the AC?). > > New text: > > 6.20. IEEE 802.11 Update Station QoS > > The IEEE 802.11 Update Station QoS message element is used > to change > the Quality of Service policy on the WTP for a given station. The > QoS tags included in this message element are to be applied to > packets received by the station. By "packets received by the station", do you mean "packets sent by the WTP to the station"? (In this case, including DSCP here is slightly unexpected -- those packets aren't necessarily even IP?) > [...] > 6.22. IEEE 802.11 WTP Quality of Service > > The IEEE 802.11 WTP Quality of Service message element value is > sent by the AC to the WTP to communicate quality of service > configuration information. The QoS tag included in this message > element are to be applied to packets received by the WTP from > station on a particular radio. > By "applied to packets received by the WTP from the station", do you mean the tagging is applied to the headers received by the WTP, or to the headers added by WTP for CAPWAP data tunneling? (If it's the former, the comment above about DSCP applies) > > Section 8.1: WEP is missing from the list? > > Given that WEP was introduced so long ago, it was just assumed that > WTPs support it. However, with TKIP and AES possibly requiring > changes to the ASIC, we wanted to allow WTPs to advertise these > capabilities. Well, some new WTPs might decide *not* to support WEP anymore -- perhaps not yet, but five year from now..? (But if support of WEP is required, the document should say so) Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 7 15:05:51 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23C303A695A for ; Thu, 7 Aug 2008 15:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.116 X-Spam-Level: X-Spam-Status: No, score=-4.116 tagged_above=-999 required=5 tests=[AWL=-1.117, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-q6hwcXUYKP for ; Thu, 7 Aug 2008 15:05:50 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 1A21C3A67AB for ; Thu, 7 Aug 2008 15:05:50 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4E4B61C40FD5 for ; Thu, 7 Aug 2008 15:05:50 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id EDB1644014F for ; Thu, 7 Aug 2008 15:05:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id BDBE93808005 for ; Thu, 7 Aug 2008 15:05:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id C79D63808004 for ; Thu, 7 Aug 2008 15:05:36 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.122.233 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 7 Aug 2008 15:05:36 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m77M5G5W028461; Fri, 8 Aug 2008 01:05:32 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 01:05:20 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 01:05:15 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Aug 2008 01:05:23 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72014C62A7@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20632FDC3@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Last call comments for capwap-protocol-binding-ieee80211-07 Thread-Index: AcjxWvvYp8NTYNntQ6KnjwjYAMoZswBPfGhwAY62tJA= References: <1696498986EFEC4D9153717DA325CB72013BA889@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20632FDC3@xmb-sjc-235.amer.cisco.com> From: To: X-OriginalArrivalTime: 07 Aug 2008 22:05:15.0382 (UTC) FILETIME=[ABCA6960:01C8F8D9] X-Nokia-AV: Clean Cc: capwap@frascone.com Subject: Re: [Capwap] Last call comments for capwap-protocol-binding-ieee80211-07 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun wrote: > > I was under the impression that 802 (or at least 802.11) required > > (or assumed) strict in-order delivery -- but perhaps I remember > > this wrong? (Obvious, tunneling over arbitrary IP hops doesn't > > guarantee in-order delivery, and it seems the data channel doesn't > > have mechanisms to reorder or drop out-of-order packets.) > The MAC layer will provide guaranteed delivery at the AP, but > remember that the air isn't exactly a reliable medium. The AP is > then responsible for tunneling the packets. For open or when crypto > is provided at the WTP, there are no issues with re-ordering. When > crypto is provided at the AC, both TKIP and AES have no ordering > requirements, so that is also not an issue. IEEE 802.11 spec talks about the possibility that the higher layer protocol (run on top of 802?) would require in-order delivery (IP doesn't, of course), and seems to be able to provide strict in-order delivery. It might be at least good to discuss this topic in the spec (describing that CAPWAP might not be able to provide fully faithful 802.11 implementation in Split MAC mode, but that this doesn't matter for most practical purposes when you're running TCP/IP). > > 802.11 header has 4 different addresses, all of which can be > > different. When doing split MAC with 802.3 frames, the 802.3 > > frame contains only two of the addresses; the "Radio MAC Address" > > field in CAPWAP header contains the third -- but what about the > > fourth one? > The CAPWAP WG only supports 802.11-2007, and does not support ad-hoc > mode (client-client). The very fact that we are providing an > alternative way to deploy 802.11 infrastructure means that do not > need to support ad hoc mode ;-) I wasn't thinking about ad-hoc mode, but rather a STA sending a packet to an AP where the 802.3 source address would be different from the transmitting STA address. Is this possible? (Perhaps a "wireless Ethernet bridge", which connects to PC via wired Ethernet, but looks like STA to the AP? Although I'm not quite sure how the address fields really look in this situation...) > > The document should have some more text about how the WTP > > processes IEEE 802.11 IEs it receives from the AC. Section 6.6 > > talks about copying them to Beacon/Probe Response messages, but it > > seems that in some cases, the WTP also does some local > > processing. (I was sort of expecting a list of all IEs, and > > description of expected WTP processing (possibly none) for them.) > There are two mode of operation: > 1. Split MAC. In this case, the WTP needs to make sure that > the beacons have the proper information. Other than that,the AC > handles all of the IEs in the manner described in the 802.11-2007 > standard. This is contradicted by text in e.g. Section 6.15, which requires the WTP to process (beyond copying to beacons) the IE received from AC even in Split MAC mode. Also, it seems that some of the IEs sent are not even included in beacons; e.g. Section 6.1 says the AC MUST send the Power Capability IE to the WTP -- but reading 802.11, I can't seem to find any place the AP would actually send this IE (it's sent by the STA). So what does the WTP do with it? > 2. Local MAC. In this case, the 802.11 management packets are > processed in the WTP, as described 2.2.2. In this case, the WTP > handles the IEs in the manner described in the 802.11-2007 standard. Right, 802.11-2007 specifies how the WTP processes IEs received from the STA. But it doesn't specify how to process IEs received from AC (obviously, since the concept of AC doesn't exist). > > Section 6.15: Is this really the PTK (which also includes KCK and > > KEK, which aren't needed by the WTP since the AC is handling the > > EAPOL-Key messages -- so probably shouldn't be sent to PTK), or > > only the TK used for encrypting traffic? > > We send the whole PTK. The WTP simply extracts what it needs and uses > it. In that case, the "key the WTP is to use when encrypting traffic to/from the station" is a bit confusing -- that would only the TK. > > Is the binding specified here sufficient for 802.11r as well, or > > would something more be needed? (I don't know the answer -- but > > probably the document should tell what it is) > Given we only support 802.11-2007, we do not worry about 802.11r at > this point (or 802.11n), so the answer is yes, more is needed. The document certainly gives the impression of supporting 802.11n, since it's e.g. listed in WTP Radio Information message element. If that's not the case, it'd be useful to say explicitly that more is needed for 11r and 11n. Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 7 15:33:43 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEBAF3A67EF for ; Thu, 7 Aug 2008 15:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.256 X-Spam-Level: X-Spam-Status: No, score=-4.256 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RC+gKXzLT+n for ; Thu, 7 Aug 2008 15:33:42 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 0DA3B3A6BC3 for ; Thu, 7 Aug 2008 15:33:02 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8B0BA1C40F81 for ; Thu, 7 Aug 2008 15:32:54 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id CB12144017A for ; Thu, 7 Aug 2008 15:32:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 9DA28380800B for ; Thu, 7 Aug 2008 15:32:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id B98993808001 for ; Thu, 7 Aug 2008 15:32:40 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.122.230 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 7 Aug 2008 15:32:40 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m77MWT2T023894; Fri, 8 Aug 2008 01:32:36 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 01:32:13 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 01:32:11 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Aug 2008 01:32:23 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72014C62A8@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20632FC22@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 166: Various IANA Issues Thread-Index: AcjyfwiGWFFYbM34RwGLIXgw/+Uu9wGXDdqQ References: <4FF84B0BC277FF45AA27FE969DD956A20632FC22@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 07 Aug 2008 22:32:11.0543 (UTC) FILETIME=[6F190270:01C8F8DD] X-Nokia-AV: Clean Subject: Re: [Capwap] Issue 166: Various IANA Issues X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun wrote: > 15.6. CAPWAP Control Message Type > > The Type field in the CAPWAP Control Message header (see Section > 4.6) is used to identify the data being transported. Section 4.6 doesn't seem to have CAPWAP Control Message header; and IANA considerations for the CAPWAP Message Type field was already covered in Section 15.3. This probably should be "CAPWAP Message Element Type"? > The namespace is 32 bits (0-4294967295), where the value of zero > (0) is reserved and must not be assigned. If this is the message element type field, it's only 16 bits. > The values one (1) through 52 are allocated in this specification, > and can be found in Section 4.5.1.1. This namespace is managed by > IANA and assignments require a Standards Action. If the intent is to allow bindings documented outside standards track RFCs (e.g. EPCGlobal), Standards Action probably isn't the right policy here. > 15.7. Wireless Binding Identifiers > > The Wireless Binding Identifier (WBID) field in the CAPWAP header > (see Section 4.3) is used to identify the wireless technology > associated with the packet. Due to the limited address space > available, a new WBID request requires Standards Action. Again, Standards Action requires all wireless bindings to be standards track RFCs, which isn't compatible with EPCGlobal. > 15.10. AC Information Type > > The Information Type field in the AC Descriptor message element > (see Section 4.6.1) is used to represent information about the AC. > The namespace is 16 bits (0-65535), where the value of zero (0) is > reserved and must not be assigned. The values four (4) and five (5) > are allocated in this specification, and can be found in Section > 4.6.1. This namespace is managed by IANA and assignments require a > Standards Action. IANA will create the AC Information Type > registry, whose format is: > > AC Information Type Type Value Reference Is the intent to have something similar as for CAPWAP Message Types (IANA manages registry for Enterprise Number 0; other Enterprise Numbers are not controlled via IANA?) Or is the AC Information Type independent of the AC Information Vendor Identifier? (in that case, I'd expect vendors would want to include vendor-specific information, and Standards Action perhaps isn't the optimal policy.) Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 7 15:37:06 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FE8B3A6993 for ; Thu, 7 Aug 2008 15:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyMfz1YWwWfx for ; Thu, 7 Aug 2008 15:37:05 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 9287B3A69E9 for ; Thu, 7 Aug 2008 15:37:05 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B24B71C40FD8 for ; Thu, 7 Aug 2008 15:37:05 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 13B1244017A for ; Thu, 7 Aug 2008 15:36:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id DD0D23808004 for ; Thu, 7 Aug 2008 15:36:56 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 03BC1380801A for ; Thu, 7 Aug 2008 15:36:54 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.184]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 7 Aug 2008 15:36:51 -0700 (PDT) Received: by mu-out-0910.google.com with SMTP id w9so733156mue.0 for ; Thu, 07 Aug 2008 15:36:50 -0700 (PDT) Received: by 10.125.153.16 with SMTP id f16mr17470mko.178.1218148610453; Thu, 07 Aug 2008 15:36:50 -0700 (PDT) Received: by 10.125.115.18 with HTTP; Thu, 7 Aug 2008 15:36:50 -0700 (PDT) Message-ID: Date: Thu, 7 Aug 2008 15:36:50 -0700 From: "Clint Chaplin" To: "Pasi.Eronen@nokia.com" In-Reply-To: <1696498986EFEC4D9153717DA325CB72014C62A7@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB72013BA889@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20632FDC3@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C62A7@vaebe104.NOE.Nokia.com> Cc: capwap@frascone.com Subject: Re: [Capwap] Last call comments for capwap-protocol-binding-ieee80211-07 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com On 8/7/08, Pasi.Eronen@nokia.com wrote: > Pat Calhoun wrote: > > > > I was under the impression that 802 (or at least 802.11) required > > > (or assumed) strict in-order delivery -- but perhaps I remember > > > this wrong? (Obvious, tunneling over arbitrary IP hops doesn't > > > guarantee in-order delivery, and it seems the data channel doesn't > > > have mechanisms to reorder or drop out-of-order packets.) > > > The MAC layer will provide guaranteed delivery at the AP, but > > remember that the air isn't exactly a reliable medium. The AP is > > then responsible for tunneling the packets. For open or when crypto > > is provided at the WTP, there are no issues with re-ordering. When > > crypto is provided at the AC, both TKIP and AES have no ordering > > requirements, so that is also not an issue. > > > IEEE 802.11 spec talks about the possibility that the higher layer > protocol (run on top of 802?) would require in-order delivery (IP > doesn't, of course), and seems to be able to provide strict in-order > delivery. > > It might be at least good to discuss this topic in the spec > (describing that CAPWAP might not be able to provide fully faithful > 802.11 implementation in Split MAC mode, but that this doesn't matter > for most practical purposes when you're running TCP/IP). > > Just because you are running TCP/IP as your main protocol doesn't guarantee that it's the only protocol. DNS, DHCP, UDP/IP and others may be necessary to support running TCP/IP. Now, do all those other support protocols not care about out-of-order delivery? I don't know the answer to that question. -- Clint (JOATMON) Chaplin Principal Engineer Corporate Standardization (US) SISA _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 7 15:42:01 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAB0F3A6B1C for ; Thu, 7 Aug 2008 15:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.174 X-Spam-Level: X-Spam-Status: No, score=-4.174 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_00=-2.599, FUZZY_CPILL=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huvFbLrfgnEL for ; Thu, 7 Aug 2008 15:42:00 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id A5DD23A6B2B for ; Thu, 7 Aug 2008 15:42:00 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CEA731C4100F for ; Thu, 7 Aug 2008 15:42:00 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 5DC25440177 for ; Thu, 7 Aug 2008 15:41:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3C86E3808002 for ; Thu, 7 Aug 2008 15:41:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8B1763808001 for ; Thu, 7 Aug 2008 15:41:48 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.105.134 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 7 Aug 2008 15:41:48 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m77MewlN022871; Thu, 7 Aug 2008 17:41:45 -0500 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 01:41:28 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 01:41:28 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Aug 2008 01:41:41 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72014C62AA@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A206330514@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 168: DTLS and Retransmissions Thread-Index: Acjz2WCdWj/4NEiBRna0IkK5PBovgQAIF04AATj3hCA= References: <4FF84B0BC277FF45AA27FE969DD956A20632FD71@xmb-sjc-235.amer.cisco.com> <4892D971.1010303@ltsnet.net> <4FF84B0BC277FF45AA27FE969DD956A206330514@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 07 Aug 2008 22:41:28.0048 (UTC) FILETIME=[BACCEF00:01C8F8DE] X-Nokia-AV: Clean Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Section 2.4.3 assumes that only the WTP retransmits DTLS messages if it doesn't get a reply (and AC retransmits a reply only when it gets a retransmitted request from the WTP). That's not the case: both parties retransmit if the handshake isn't done yet. For example, the AC will also keep retransmitting ServerHello (and Certificate/ServerKeyExchange/ServerHelloDone) if it doesn't receive a reply (Certificate/ClientKeyExchange/etc.) from the WTP. Best regards, Pasi > -----Original Message----- > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: 01 August, 2008 20:12 > To: Charles Clancy > Cc: capwap@frascone.com; Eronen Pasi (Nokia-NRC/Helsinki) > Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions > > Got it - waiting for Pasi on 2.4.3. > > PatC > > -----Original Message----- > From: Charles Clancy [mailto:clancy@ltsnet.net] > Sent: Friday, August 01, 2008 2:38 AM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com; Pasi.Eronen@nokia.com > Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions > > Suggested text changes to address the comments: > > Replace this 2.4.1 text: > > DTLS, as specified, provides its own retransmit timers with an > exponential back-off. However, DTLS will never terminate the > handshake due to non-responsiveness; instead, DTLS will > continue to > increase its back-off timer period. Hence, timing out incomplete > DTLS handshakes is entirely the responsibility of the > CAPWAP module. > > with this text: > > DTLS, as specified, provides its own retransmit timers with an > exponential back-off. [RFC4347] does not specify how long > retransmissions should continue. Consequently, timing out > incomplete > DTLS handshakes is entirely the responsibility of the > CAPWAP module. > > I'm not sure what needs to be addressed in 2.4.3. Pasi -- can you be > more specific? > > -- > Dr. Charles Clancy www.ltsnet.net/~clancy > Senior Researcher, Laboratory for Telecommunications Sciences > > > Pat Calhoun (pacalhou) wrote: > > Pasi's comment was: > > > > Section 2.4.1: "DTLS will never terminate the handshake due to > > non-responsiveness; instead, DTLS will continue to > > increase its back-off timer period" While RFC 4347 > doesn't specify > > how > > long you should continue retransmitting, the > > intent certainly was not to continue indefinitely. > > > > Section 2.4.3 text about DTLS retransmissions is slightly > inaccurate; > > DTLS handshake isn't strictly request/response, > > and both parties (not just the DTLS client) retransmit based on > > timers > > (in some situations). > > > > It is unclear to me as to whether these are simply observations, or > > request for change. That said, I would like either Charles > or Scott to > > > reply. > > > > PatC > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/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 Aug 7 15:44:54 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA3983A6B61 for ; Thu, 7 Aug 2008 15:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfAUtLeqkQIM for ; Thu, 7 Aug 2008 15:44:53 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id DE3A93A6AFD for ; Thu, 7 Aug 2008 15:44:53 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 12FA443A06F for ; Thu, 7 Aug 2008 15:44:53 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 39988440177 for ; Thu, 7 Aug 2008 15:43:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E354E380800A for ; Thu, 7 Aug 2008 15:43:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 23F323808004 for ; Thu, 7 Aug 2008 15:43:57 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.122.230 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 7 Aug 2008 15:43:56 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m77MhX4D001877; Fri, 8 Aug 2008 01:43:53 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 01:43:46 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 01:43:39 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Aug 2008 01:43:52 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72014C62AB@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A206393CCC@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Recap of current pending issues Thread-Index: Acjz9xoEqCcXlGoTT6y9r7yIArdLFwDULppAAGVprtA= References: <4FF84B0BC277FF45AA27FE969DD956A2063304F7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A206393CCC@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 07 Aug 2008 22:43:39.0104 (UTC) FILETIME=[08EA7E00:01C8F8DF] X-Nokia-AV: Clean Subject: Re: [Capwap] Recap of current pending issues X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun wrote: > All, > > With the IETF Last Call ending in a few hours, I wanted to provide > an updated list of the issues, and required actions. I have updated > Tracker to reflect the current state of all issues. I would like to > get review, and confirmation, that the changes I have proposed are > satisfactory before I publish another rev of the spec. Assuming I > get nothing from the list (which I hope does not happen), my plan > would be to publish the specs next Monday. So in order to ensure we > have a high quality spec, I would urge you to look at the proposed > changes and make sure that we are good to do. The resulting three > specs (DHCP, Base and Binding) would then be ready to move to the > IESG for publication. > > > ISSUES WAITING FOR PASI's REVIEW > > Issue 156 (Need more details on use of DNS for discovery). This was > a rather small change, but I got it wrong the first time. I am > waiting for confirmation that this time around we are good to go. This was probably nailed down in emails earlier today. > Issue 159 (Question on CAPWAP control protocol). This was a > question, which I have responded to. There was no need for change, > unless Pasi raises a specific issue. At this point, I consider this > issue closed. The answer (you can't have multiple outstanding requests) really needs to be in the spec. Also, the spec needs some more text about how the receiver processes them -- e.g. does the receiver maintain "last seen sequence number" counter, and silently drop (without replying) requests older than this? > Issue 166 (Various IANA Issues). This issue has been addressed, but > I am waiting for Pasi's feedback. I replied about this earlier today -- couple of bugs, and Standards Action might not be the best policy for all registries. > Issue 168 (DTLS and Retransmissions). Charles provided text > for section 2.4.1, but we need Pasi to provide clarification on > what he needed in section 2.4.3. Also replied earlier today. > Issue 171 (Pasi nits on binding spec). I believe this is done - I am > just waiting to see if Pasi has issues with any of the proposed > resolutions Also replied earlier today. Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 7 16:23:56 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60DC03A6A3E for ; Thu, 7 Aug 2008 16:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaRBiSCEJlnp for ; Thu, 7 Aug 2008 16:23:55 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id F1C873A6993 for ; Thu, 7 Aug 2008 16:23:54 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AE784439FBB for ; Thu, 7 Aug 2008 16:23:54 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id A0587440182 for ; Thu, 7 Aug 2008 16:23:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 7B0783808016 for ; Thu, 7 Aug 2008 16:23:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 48878380800B for ; Thu, 7 Aug 2008 16:23:41 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 7 Aug 2008 16:23:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,323,1215388800"; d="scan'208";a="137219091" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 07 Aug 2008 23:23:36 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m77NNaAX026201; Thu, 7 Aug 2008 16:23:36 -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.13.8/8.13.8) with ESMTP id m77NNa8m007077; Thu, 7 Aug 2008 23:23:36 GMT 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.1830); Thu, 7 Aug 2008 16:23:36 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 16:23:35 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2063E6823@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB72014C629F@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 171: Pasi nits on binding spec Thread-Index: AcjzL5wHOa8wpdqYQUmSlvTmZmTg1QFnnI4QAAUEOaA= References: <4FF84B0BC277FF45AA27FE969DD956A20633000B@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C629F@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 07 Aug 2008 23:23:36.0199 (UTC) FILETIME=[9DB22970:01C8F8E4] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Capwap] Issue 171: Pasi nits on binding spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Thursday, August 07, 2008 2:08 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: Issue 171: Pasi nits on binding spec Pat Calhoun wrote: > > > Section 6.1 and 6.21: are some of these 802.11 information elements > > > optional, or are all of them always included? > > Always, since the text states: > > > > > > The inclusion of this message > > element MUST also include the IEEE 802.11 Information > > Element message > > element, containing the following 802.11 IEs: > > > > Does this mean that e.g. all WTPs MUST support WMM? (since the AC MUST always send the WMM information element) And > MUST support WPA forever (in addition to RSN)? > Well... We are 2007, and I'm not sure how much we need to care about hardware out there that is unable to support IEEE 802.11-2007. If there is ever a new IEEE standard for securing, then the list of IEs would have to change, but that would be post IEEE 802.11-2007 anyhow. The CAPWAP specification could publish an updated set of rules of what IEs need to be present. > > > Section 6.1 and 6.21: what do you put in "Key Status" if you're not > > > using encryption at all? > > > > Well... Good question. The way it works is that the absence of a key > > means that the key status field is irrelevant, but perhaps it would be > > good to define a new "unused" value. However, this *could* create a > > backward compatibility problem. Alternatively, we could add text that > > simply states that this field is ignored if the key field has a zero > > length, and then it really doesn't matter what value was used. > > > > OK? > > I'm fine with either approach. > I've chosen the latter, so the text now reads: Key Status: A 1 byte value that specifies the state and usage of the key that has been included. Note this field is ignored if the Key Length field is set to zero (0). The following values describe the key usage and its status: > > > Section 6.14, 6.20, and 6.22: the 802.1p Tag field should probably > > > be shown as 3 bits in the diagram, to make it unambiguous about > > > which bits are not used. > > > > Well... That would truncate a packet on a non-byte boundary. Do you > > really believe that would help clear things up? > > No need to truncate the packet on a non-byte boundary; just show where the unused padding bits are. Something like this ("Z" is unused): > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MAC Address |Z|Z| DSCP Tag |Z|Z|Z|Z|Z|8021p| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > or this: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MAC Address | DSCP Tag |Z|Z|Z|Z|Z|Z|Z|8021p| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > or this: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MAC Address | DSCP Tag |Z|Z|8021p|Z|Z|Z|Z|Z| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > depending on which you meant... Oh, I see. Well, that makes sense. Here is the new text: 6.20. IEEE 802.11 Update Station QoS [...] 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | DSCP Tag | Reserved|8021p| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [...] Reserved: All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. 8021p: The three bit 802.1p priority value to use if packets are to be IEEE 802.1p tagged. > > > Sections 6.20 and 6.22: the DSCP Tag field should probably be shown > > > as 6 bits in the diagram, to make it unambiguous how it's sent in > > > IPv4/IPv6 header (and which bits are unused). > > > > See above. I think showing fragments of a byte is even harder to > > understand. I have never seen RFCs to that. > > See above. Ditto > > > Section 6.20 and 6.22: "if packets are to be DSCP tagged" would > > benefit of > > > clarifying what packets are meant (I guess it means CAPWAP Data > > > packets sent from the WTP to the AC?). > > > > New text: > > > > 6.20. IEEE 802.11 Update Station QoS > > > > The IEEE 802.11 Update Station QoS message element is used > > to change > > the Quality of Service policy on the WTP for a given station. The > > QoS tags included in this message element are to be applied to > > packets received by the station. > > By "packets received by the station", do you mean "packets sent by the WTP to the station"? (In this case, including DSCP here is slightly unexpected -- those packets aren't necessarily even IP?) Hmmm... Should have read: "applied to packets received at the WTP from the station." > > [...] > > 6.22. IEEE 802.11 WTP Quality of Service > > > > The IEEE 802.11 WTP Quality of Service message element value is > > sent by the AC to the WTP to communicate quality of service > > configuration information. The QoS tag included in this message > > element are to be applied to packets received by the WTP from > > station on a particular radio. > > > > By "applied to packets received by the WTP from the station", do you mean the tagging is applied to the headers received by the WTP, or to the headers added by WTP for CAPWAP data tunneling? > (If it's the former, the comment above about DSCP applies) > I am proposing adding the following sentence to both sections 6.20 and 6.22: Any tagging performed by the WTP MUST be directly applied to the packets receive from the station, as well as the CAPWAP tunnel, if the packets are tunneled to the AC. > > > Section 8.1: WEP is missing from the list? > > > > Given that WEP was introduced so long ago, it was just assumed that > > WTPs support it. However, with TKIP and AES possibly requiring changes > > to the ASIC, we wanted to allow WTPs to advertise these capabilities. > > Well, some new WTPs might decide *not* to support WEP anymore -- perhaps not yet, but five year from now..? (But if support of WEP is required, the document should say so) Understood, but IEEE 802.11-2007 still requires the AP support it. PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 8 04:18:46 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BA1B3A6D3C for ; Fri, 8 Aug 2008 04:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.153 X-Spam-Level: X-Spam-Status: No, score=-4.153 tagged_above=-999 required=5 tests=[AWL=-0.554, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gfr+4wwcW6D0 for ; Fri, 8 Aug 2008 04:18:45 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 850CD3A6B3A for ; Fri, 8 Aug 2008 04:18:45 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E9E071C40FEE for ; Fri, 8 Aug 2008 04:18:45 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 9356C440159 for ; Fri, 8 Aug 2008 04:18:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 68BDD34AC035 for ; Fri, 8 Aug 2008 04:18:34 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 7279C34AC025 for ; Fri, 8 Aug 2008 04:18:32 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.122.233 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by mx1.tigertech.net (Postfix) with ESMTP for ; Fri, 8 Aug 2008 04:18:32 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m78BHYOZ032314; Fri, 8 Aug 2008 14:18:01 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 14:17:35 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 14:17:26 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Aug 2008 14:17:26 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720150BDF9@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2063E6823@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 171: Pasi nits on binding spec Thread-Index: AcjzL5wHOa8wpdqYQUmSlvTmZmTg1QFnnI4QAAUEOaAAGNrSwA== References: <4FF84B0BC277FF45AA27FE969DD956A20633000B@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C629F@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2063E6823@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 08 Aug 2008 11:17:26.0034 (UTC) FILETIME=[56445720:01C8F948] X-Nokia-AV: Clean Subject: Re: [Capwap] Issue 171: Pasi nits on binding spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun wrote: > > Does this mean that e.g. all WTPs MUST support WMM? (since the AC > > MUST always send the WMM information element) And MUST support WPA > > forever (in addition to RSN)? > > Well... We are 2007, and I'm not sure how much we need to care about > hardware out there that is unable to support IEEE 802.11-2007. If > there is ever a new IEEE standard for securing, then the list of IEs > would have to change, but that would be post IEEE 802.11-2007 > anyhow. The CAPWAP specification could publish an updated set of > rules of what IEs need to be present. I can't find any mention of "WMM Information Element" in IEEE 802.11-2007 -- I assumed it's some extension that not everyone implements? BTW, how are you planning to update these rules without breaking backwards compatibility? > Oh, I see. Well, that makes sense. Here is the new text: > > > 6.20. IEEE 802.11 Update Station QoS > [...] > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 > 8 9 0 1 2 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Radio ID | MAC Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MAC Address | DSCP Tag | Reserved|8021p| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > [...] > Reserved: All implementations complying with this > protocol MUST set > to zero any bits that are reserved in the version of > the protocol > supported by that implementation. Receivers MUST > ignore all bits > not defined for the version of the protocol they support. > > 8021p: The three bit 802.1p priority value to use if > packets are to > be IEEE 802.1p tagged. > Here DSCP Tag should be 6 bits, not 8. > > > > Section 6.20 and 6.22: "if packets are to be DSCP tagged" would > > > > benefit of > > > > clarifying what packets are meant (I guess it means CAPWAP Data > > > > packets sent from the WTP to the AC?). > > > > > > New text: > > > > > > 6.20. IEEE 802.11 Update Station QoS > > > > > > The IEEE 802.11 Update Station QoS message element is used > > > to change > > > the Quality of Service policy on the WTP for a given station. > > > The > > > QoS tags included in this message element are to be applied to > > > packets received by the station. > > > > By "packets received by the station", do you mean "packets > > sent by the > > WTP to the station"? (In this case, including DSCP here is slightly > > unexpected -- those packets aren't necessarily even IP?) > > Hmmm... Should have read: "applied to packets received at the WTP from > the station." In this case, it seems both "Update Station QoS" and "WTP Quality of Service" message elements apply to same packets -- how do they interact? How does the tagging work (or not work) if the 'C' bit in IEEE 802.11 Station Session Key message element is set? I'm also slightly surprised to see the WTP modifying the contents of IP packets here -- I thought it was acting as Layer 2 device for user plane traffic (not making any assumptions about the Layer 3 protocol carried in 802.3 frames). At the very least, the text should probably say the DSCP Tag applies only to packets with certain values in the 802.3 Type field. > > > [...] > > > 6.22. IEEE 802.11 WTP Quality of Service > > > > > > The IEEE 802.11 WTP Quality of Service message element value is > > > sent by the AC to the WTP to communicate quality of service > > > configuration information. The QoS tag included in > this message > > > element are to be applied to packets received by the WTP from > > > station on a particular radio. > > > > > > > By "applied to packets received by the WTP from the station", do you > > mean the tagging is applied to the headers received by the WTP, or to > > the headers added by WTP for CAPWAP data tunneling? > > (If it's the former, the comment above about DSCP applies) > > > I am proposing adding the following sentence to both sections 6.20 and > 6.22: > > > Any tagging performed > by the WTP MUST be directly applied to the packets receive from the > station, as well as the CAPWAP tunnel, if the packets are > tunneled to the AC. > The comment above about 'C' bit and DSCP Tag applies here as well... > > Well, some new WTPs might decide *not* to support WEP anymore -- > perhaps not yet, but five year from now..? (But if support of WEP is > required, the document should say so) > > Understood, but IEEE 802.11-2007 still requires the AP support it. If I'm reading IEEE 802.11-2007, Section A.4.4.1 correctly, it seems supporting WEP is optional...? Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 8 12:30:20 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1C5D3A6D8F for ; Fri, 8 Aug 2008 12:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.8 X-Spam-Level: X-Spam-Status: No, score=-102.8 tagged_above=-999 required=5 tests=[AWL=0.799, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJrVWkrde9BA for ; Fri, 8 Aug 2008 12:30:20 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 0A99E3A6D7F for ; Fri, 8 Aug 2008 12:30:20 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9C36B1C40FC0 for ; Fri, 8 Aug 2008 12:30:20 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 445FE44018F for ; Fri, 8 Aug 2008 12:30:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 06BCD34AC021 for ; Fri, 8 Aug 2008 12:30:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 69C8734AC045 for ; Fri, 8 Aug 2008 12:30:02 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (64.170.98.32 whitelisted by list.dnswl.org 9.2) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx1.tigertech.net (Postfix) with ESMTP for ; Fri, 8 Aug 2008 12:30:02 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 0) id 4F3633A69A8; Fri, 8 Aug 2008 12:30:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080808193001.4F3633A69A8@core3.amsl.com> Date: Fri, 8 Aug 2008 12:30:01 -0700 (PDT) Cc: capwap@frascone.com Subject: [Capwap] I-D ACTION:draft-ietf-capwap-threat-analysis-02.txt X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Control And Provisioning of Wireless Access Points Working Group of the IETF. Title : CAPWAP Threat Analysis for IEEE 802.11 Deployments Author(s) : S. Kelly, C. Clancy Filename : draft-ietf-capwap-threat-analysis-02.txt Pages : 33 Date : 2008-8-8 Early Wireless Local Area Network (WLAN) deployments feature a "fat" Access Point (AP) which serves as a standalone interface between the wired and wireless network segments. However, this model raises scaling, mobility, and manageability issues, and the Control and Provisioning for Wireless Access Points (CAPWAP) protocol is meant to address these issues. CAPWAP effectively splits the fat AP functionality into two network elements, and the communication channel between these components may traverse potentially hostile hops. This document analyzes the security exposure resulting from the introduction of CAPWAP, and summarizes the associated security considerations for IEEE 802.11-based CAPWAP implementations and deployments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-capwap-threat-analysis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-capwap-threat-analysis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-8-8122313.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --NextPart-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Aug 8 13:32:15 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78EDE3A63C9 for ; Fri, 8 Aug 2008 13:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eHCsZC4Avyy for ; Fri, 8 Aug 2008 13:32:14 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 7725F3A6A9E for ; Fri, 8 Aug 2008 13:32:14 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4C93A1C40FB8 for ; Fri, 8 Aug 2008 13:32:15 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 40CA7440154 for ; Fri, 8 Aug 2008 13:32:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 1BD5A34AC032 for ; Fri, 8 Aug 2008 13:32:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E32E534AC072 for ; Fri, 8 Aug 2008 13:32:03 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Sender first seen 22 days 07:11:38 ago / dynamic or unknown reverse DNS) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by mx1.tigertech.net (Postfix) with ESMTP for ; Fri, 8 Aug 2008 13:32:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,329,1215403200"; d="scan'208";a="117670438" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 08 Aug 2008 16:31:58 -0400 X-IronPort-AV: E=Sophos;i="4.31,329,1215403200"; d="scan'208";a="254014937" Received: from unknown (HELO 306181ANEX2.global.avaya.com) ([135.9.6.103]) by co300216-co-erhwest-out.avaya.com with ESMTP; 08 Aug 2008 16:31:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Aug 2008 14:31:52 -0600 Message-ID: In-Reply-To: <20080808193001.4F3633A69A8@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] I-D ACTION:draft-ietf-capwap-threat-analysis-02.txt Thread-Index: Acj5jTobNBD2X0PlTg+hBE7Syt4BZQAAJFVA References: <20080808193001.4F3633A69A8@core3.amsl.com> From: "Mani, Mahalingam (Mani)" To: Subject: Re: [Capwap] I-D ACTION:draft-ietf-capwap-threat-analysis-02.txt X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Dear WG, Please note: This version addresses AD(DanR)-review comments (and gen-art too, I believe). This revision was sent to IETF before... Follow-up observations, comments and suggestions from sec-area AD (Pasi) were received: these are due to be addressed in a followup draft revision - viz., -03. Regards, -mani -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, August 08, 2008 12:30 PM To: i-d-announce@ietf.org Cc: capwap@frascone.com Subject: [Capwap] I-D ACTION:draft-ietf-capwap-threat-analysis-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Control And Provisioning of Wireless Access Points Working Group of the IETF. Title : CAPWAP Threat Analysis for IEEE 802.11 Deployments Author(s) : S. Kelly, C. Clancy Filename : draft-ietf-capwap-threat-analysis-02.txt Pages : 33 Date : 2008-8-8 Early Wireless Local Area Network (WLAN) deployments feature a "fat" Access Point (AP) which serves as a standalone interface between the wired and wireless network segments. However, this model raises scaling, mobility, and manageability issues, and the Control and Provisioning for Wireless Access Points (CAPWAP) protocol is meant to address these issues. CAPWAP effectively splits the fat AP functionality into two network elements, and the communication channel between these components may traverse potentially hostile hops. This document analyzes the security exposure resulting from the introduction of CAPWAP, and summarizes the associated security considerations for IEEE 802.11-based CAPWAP implementations and deployments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-capwap-threat-analysis-02 .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 13 07:09:41 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B58033A69B3 for ; Wed, 13 Aug 2008 07:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voyyCNEVol07 for ; Wed, 13 Aug 2008 07:09:40 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 8E5BE3A68C7 for ; Wed, 13 Aug 2008 07:09:40 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 73FC4433DC6 for ; Wed, 13 Aug 2008 07:09:11 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 7673644019B for ; Wed, 13 Aug 2008 06:22:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id A46153688007 for ; Wed, 13 Aug 2008 06:22:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 322EB3628007 for ; Wed, 13 Aug 2008 06:22:12 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Sender first seen 00:43:00 ago / dynamic or unknown reverse DNS) Received: from sirocco.sandstorm.net (ip-69-33-111-75.bos.megapath.net [69.33.111.75]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 13 Aug 2008 06:22:07 -0700 (PDT) Received: from [10.36.0.45] (c-76-24-195-210.hsd1.ma.comcast.net [76.24.195.210]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id m7DCcweO069232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 13 Aug 2008 08:38:58 -0400 (EDT) (envelope-from mrw@sandstorm.net) Mime-Version: 1.0 (Apple Message framework v752.3) References: <200808131221.18409.julien.laganier.IETF@googlemail.com> Message-Id: From: Margaret Wasserman Date: Wed, 13 Aug 2008 08:38:56 -0400 To: capwap X-Mailer: Apple Mail (2.752.3) X-Mailman-Approved-At: Wed, 13 Aug 2008 07:09:02 -0700 Subject: [Capwap] Fwd: [MEXT] FW: Third Nomcom 2008-9 Call for Volunteers! X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Please consider volunteering for the nomcom. See the attached message for details. Margaret > From: NomCom Chair > To: IETF Announcement list > Subject: Third Nomcom 2008-9 Call for Volunteers! > > Once again, the IETF nominating process has begun, and the community > (and I) need your help. The IETF Nominating Committee appoints > folks to > fill the open slots on the IAOC, the IAB, and the IESG. The people > who > do that are 10 folks selected randomly from the pool of volunteers. > To make this work well for the community, we need people to volunteer. > Lots of people. Please! > > Volunteers must have attended 3 of the past 5 IETF meetings. As > defined > by RFC 3777, that is 3 of the past 5 meetings as of the time this > announcement goes out to start the solicitation. If you qualify, > and are > willing to forgo appointment to any of the positions for which the > nominating committee is responsible, please volunteer. Details on the > nominating process can be found in RFC 3777. > > Below is the list of people and posts whose terms end with the March > 2009 IETF meeting, and whose positions therefore the nominating > committee is responsible for: > > IAOC: > Jonne Soininen > > IAB: > Loa Andersson > Barry Leiba > Kurtis Lindqvist > Danny McPherson > Dave Thaler > Lixia Zhang > > IESG: > IETF and IESG Chair: Russ Housley > Applications Area (app): Chris Newman > Internet Area (int): Mark Townsley > Operations and Management Area (ops): Ronald Bonica > Real-time Applications and Infrastructure Area (rai): > Jon Peterson > Routing Area (rtg): David Ward > Security Area (sec): Tim Polk > Transport Area (tsv): Lars Eggert > > Before volunteering, please think about whether you want to be > considered for one of the above positions instead. If you are willing > to volunteer, please send email before 5:00 pm EDT (2100 UTC/GMT) > August > 18, 2008 (otherwise, please read on) > > Please send email to me using the following skeleton: > > To: jmh@joelhalpern.com > Subject: Nomcom 2008-9 Volunteer > Body: > > // As you enter in the IETF Registration Form, > // First/Given name followed by Last/Family Name > > // typically what goes in the Company field > // in the IETF Registration Form > [] > // > // For confirmation if selected > > Please expect an email response from me within 1-2 days stating > whether you are qualified or not. If you don't receive anything, > please > re-send your email with the tag (duplicate) in the subject line. > During the IETF meeting in Dublin, responses will be somewhat slower, > due to both my activities at the meeting and the secretariat's many > activities in support of the meeting. I will try to send out at > least > a prompt confirmation that your email volunteering has been received. > > > Not convinced yet? Please consider that nomcom members play an > important role in shaping the leadership of the IETF. If you are a > people person, you will enjoy meeting many of the active > contributors to > the IETF. If you prefer instead to read a lot of email, well, we have > that too. Being a nomcom member is also an important > responsibility: it > requires adherence to confidentiality rules and some time commitment > from the members. The term of this nomcom will begin in early > September > this year. We will be talking with folks at the Minneapolis IETF (if > you are there. It is not mandatory that all nomcom members come to > the > meeting.) I hope to wrap up our primary selection work by mid- > December, > and we must complete our selection work by mid-January. > > We will be collecting requirements from the community, as well as > talking to candidates and to community members about candidates. > There will be weekly conference calls to ensure progress. > > > Nomcom members are selected following a publicly verifiable random > selection method specified in RFC 3797. > > For the nomcom to work as it should, the pool from which the > volunteers > are chosen should be as large as possible. The more people who > volunteer, the better chance we have of choosing a random yet > representative cross section of the IETF population. > > Ensuring the leadership of the IETF is fair and balanced and comprised > of those who can lead the IETF in the right direction is an important > responsibility that rests on the IETF participants at large. > Volunteering for the nomcom is a good way of contributing in that > direction. So please volunteer! > > > I will be publishing a more thorough and precise target timetable, as > well as details of the randomness seeds to be used for the RFC 3797 > selection process within the next few days. > > > Thank you, and I hope to hear from you, > Joel M. Halpern > jmh@joelhalpern.com > nomcom-chair@ietf.org _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 13 12:08:42 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE33F3A6A1E for ; Wed, 13 Aug 2008 12:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVOHIYdWCyLN for ; Wed, 13 Aug 2008 12:08:41 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 3FD773A6990 for ; Wed, 13 Aug 2008 12:08:41 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 729031C40FC8 for ; Wed, 13 Aug 2008 12:08:43 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id DB2FF4401A4 for ; Wed, 13 Aug 2008 12:08:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id C260A34AC03C for ; Wed, 13 Aug 2008 12:08:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 7016934AC01C for ; Wed, 13 Aug 2008 12:08:31 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 13 Aug 2008 12:08:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,202,1217808000"; d="scan'208";a="74933991" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 13 Aug 2008 19:08:22 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7DJ8Mt5024216; Wed, 13 Aug 2008 12:08:22 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m7DJ8MNb007586; Wed, 13 Aug 2008 19:08:22 GMT 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.1830); Wed, 13 Aug 2008 12:08:22 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Aug 2008 12:08:21 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20645989D@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB720150BDF9@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 171: Pasi nits on binding spec Thread-Index: AcjzL5wHOa8wpdqYQUmSlvTmZmTg1QFnnI4QAAUEOaAAGNrSwAEJI2JQ References: <4FF84B0BC277FF45AA27FE969DD956A20633000B@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C629F@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2063E6823@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720150BDF9@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 13 Aug 2008 19:08:22.0672 (UTC) FILETIME=[F499E100:01C8FD77] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Capwap] Issue 171: Pasi nits on binding spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com > > > Does this mean that e.g. all WTPs MUST support WMM? (since the AC > > > MUST always send the WMM information element) And MUST support WPA > > > forever (in addition to RSN)? > > > > Well... We are 2007, and I'm not sure how much we need to care about > > hardware out there that is unable to support IEEE 802.11-2007. If > > there is ever a new IEEE standard for securing, then the list of IEs > > would have to change, but that would be post IEEE 802.11-2007 anyhow. > > The CAPWAP specification could publish an updated set of rules of what > > IEs need to be present. > > I can't find any mention of "WMM Information Element" in IEEE > 802.11-2007 -- I assumed it's some extension that not everyone implements? Yup - my bad. Now include a reference to the WMM web page on www.wi-fi.org. > > BTW, how are you planning to update these rules without breaking backwards compatibility? There are a couple of ways, but the most obvious one would be to have the next binding use a new Wireless Binding Identifier (WBID). > > > Oh, I see. Well, that makes sense. Here is the new text: > > > > > > 6.20. IEEE 802.11 Update Station QoS > > [...] > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 > > 8 9 0 1 2 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Radio ID | MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | MAC Address | DSCP Tag | Reserved|8021p| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > [...] > > Reserved: All implementations complying with this > > protocol MUST set > > to zero any bits that are reserved in the version of the > > protocol > > supported by that implementation. Receivers MUST ignore all > > bits > > not defined for the version of the protocol they support. > > > > 8021p: The three bit 802.1p priority value to use if > > packets are to > > be IEEE 802.1p tagged. > > > > Here DSCP Tag should be 6 bits, not 8. OK, here is the packet format: > > > > > > Section 6.20 and 6.22: "if packets are to be DSCP tagged" would > > > > > benefit of clarifying what packets are meant (I guess it means > > > > > CAPWAP Data packets sent from the WTP to the AC?). > > > > > > > > New text: > > > > > > > > 6.20. IEEE 802.11 Update Station QoS > > > > > > > > The IEEE 802.11 Update Station QoS message element is used > > > > to change > > > > the Quality of Service policy on the WTP for a given station. > > > > The > > > > QoS tags included in this message element are to be applied to > > > > packets received by the station. > > > > > > By "packets received by the station", do you mean "packets sent by > > > the WTP to the station"? (In this case, including DSCP here is > > > slightly unexpected -- those packets aren't necessarily even IP?) > > > > Hmmm... Should have read: "applied to packets received at the WTP from > > the station." > > In this case, it seems both "Update Station QoS" and "WTP Quality of Service" message elements apply to same packets -- how do they interact? I have added addition verbage to make this clearer: 6.20. IEEE 802.11 Update Station QoS The IEEE 802.11 Update Station QoS message element is used to change the Quality of Service policy on the WTP for a given station. The QoS tags included in this message element are to be applied to packets received at the WTP from the station indicated through the MAC Address field. This message element overrides the default values provided through the IEEE 802.11 WTP Quality of Service message element (see Section 6.22. Any tagging performed by the WTP MUST be directly applied to the packets receive from the station, as well as the CAPWAP tunnel, if the packets are tunneled to the AC. [...] 6.22. IEEE 802.11 WTP Quality of Service The IEEE 802.11 WTP Quality of Service message element value is sent by the AC to the WTP to communicate quality of service configuration information. The QoS tag included in this message element are the default QoS values to be applied to packets received by the WTP from stations on a particular radio. Any tagging performed by the WTP MUST be directly applied to the packets receive from the station, as well as the CAPWAP tunnel, if the packets are tunneled to the AC. > > How does the tagging work (or not work) if the 'C' bit in IEEE 802.11 Station Session Key message element is set? Well.. If that's the case, the packets inside the tunnel cannot be modified - that would be the responsibility of the AC. I can add: C: The one bit field is set by the AC to inform the WTP that encryption services will be provided by the AC. When set, the WTP SHOULD police frames received from stations to ensure that are properly encrypted as specified in the RSN Information Element, but does not need to take specific cryptographic action on the frame. Similarly, for transmitted frames, the WTP only needs to forward already encrypted frames. Since packets received by the WTP will be encrypted, the WTP cannot modify the contents of the packets, including modifying the DSCP markings of the encapsulated packet. In this case, this function would be the responsibility of the AC. > > I'm also slightly surprised to see the WTP modifying the contents of IP packets here -- I thought it was acting as Layer 2 device for user plane traffic (not making any assumptions about the Layer 3 protocol carried in 802.3 frames). At the very least, the text should probably say the DSCP Tag applies only to packets with certain values in the > 802.3 Type field. OK, I can modify the text to specifically read: DSCP Tag: The 6 bit DSCP label to use if packets are eligible to be DSCP tagged (see [RFC2474]). > > > > [...] > > > > 6.22. IEEE 802.11 WTP Quality of Service > > > > > > > > The IEEE 802.11 WTP Quality of Service message element value is > > > > sent by the AC to the WTP to communicate quality of service > > > > configuration information. The QoS tag included in > > this message > > > > element are to be applied to packets received by the WTP from > > > > station on a particular radio. > > > > > > > > > > By "applied to packets received by the WTP from the station", do you > > > mean the tagging is applied to the headers received by the WTP, or > > > to the headers added by WTP for CAPWAP data tunneling? > > > (If it's the former, the comment above about DSCP applies) > > > > > I am proposing adding the following sentence to both sections 6.20 and > > 6.22: > > > > > > Any tagging performed > > by the WTP MUST be directly applied to the packets receive from the > > station, as well as the CAPWAP tunnel, if the packets are > > tunneled to the AC. > > > > The comment above about 'C' bit and DSCP Tag applies here as well... I think this comment is now handled above. > > > > > Well, some new WTPs might decide *not* to support WEP anymore -- > > perhaps not yet, but five year from now..? (But if support of WEP is > > required, the document should say so) > > > > Understood, but IEEE 802.11-2007 still requires the AP support it. > > If I'm reading IEEE 802.11-2007, Section A.4.4.1 correctly, it seems supporting WEP is optional...? Yes, I see PC2 as optional, but all of the sub-elements are being mandatory. I suppose I should read this as those sub-elements are required only if WEP was implemented. We could fix this problem by allocated another bit in section 8.1, alongside TKIP and AES. Note that this would reduce the total number of bits available for the whole protocol, unless we do something to address issue 172. PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 13 12:18:19 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EE0C3A697F for ; Wed, 13 Aug 2008 12:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLP2oXLTg8cX for ; Wed, 13 Aug 2008 12:18:17 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id E6FB53A68DE for ; Wed, 13 Aug 2008 12:18:17 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 099E1439FA9 for ; Wed, 13 Aug 2008 12:18:22 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 62F584401A4 for ; Wed, 13 Aug 2008 12:18:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 297DC34AC04D for ; Wed, 13 Aug 2008 12:18:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 578E234AC018 for ; Wed, 13 Aug 2008 12:18:13 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.68.10.86 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 13 Aug 2008 12:18:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,202,1217808000"; d="scan'208";a="19900617" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 13 Aug 2008 19:18:08 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m7DJI8eO005234; Wed, 13 Aug 2008 12:18:08 -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.13.8/8.13.8) with ESMTP id m7DJI8Vd015824; Wed, 13 Aug 2008 19:18:08 GMT 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.1830); Wed, 13 Aug 2008 12:18:08 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Aug 2008 12:18:08 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2064598B4@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB72014C62A7@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Last call comments for capwap-protocol-binding-ieee80211-07 Thread-Index: AcjxWvvYp8NTYNntQ6KnjwjYAMoZswBPfGhwAY62tJAABD6gUA== References: <1696498986EFEC4D9153717DA325CB72013BA889@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20632FDC3@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C62A7@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 13 Aug 2008 19:18:08.0831 (UTC) FILETIME=[51FAA4F0:01C8FD79] Authentication-Results: sj-dkim-4; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] Last call comments for capwap-protocol-binding-ieee80211-07 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com > > > I was under the impression that 802 (or at least 802.11) required > > > (or assumed) strict in-order delivery -- but perhaps I remember this > > > wrong? (Obvious, tunneling over arbitrary IP hops doesn't guarantee > > > in-order delivery, and it seems the data channel doesn't have > > > mechanisms to reorder or drop out-of-order packets.) > > > The MAC layer will provide guaranteed delivery at the AP, but remember > > that the air isn't exactly a reliable medium. The AP is then > > responsible for tunneling the packets. For open or when crypto is > > provided at the WTP, there are no issues with re-ordering. When crypto > > is provided at the AC, both TKIP and AES have no ordering > > requirements, so that is also not an issue. > > IEEE 802.11 spec talks about the possibility that the higher layer protocol (run on top of 802?) would require in-order delivery (IP doesn't, of course), and seems to be able to provide strict in-order delivery. > > It might be at least good to discuss this topic in the spec (describing that CAPWAP might not be able to provide fully faithful > 802.11 implementation in Split MAC mode, but that this doesn't matter for most practical purposes when you're running TCP/IP). Fair enough, I am proposing adding the following paragraph to section 2.2.1: Note that when the WTP tunnels data packets to the AC (and vice versa), the CAPWAP protocol does not guarantee in-order delivery. When the protocol being transported over IEEE 802.11 is IP, out of order delivery is not an issue as IP has no such requirements. However, implementors need to be aware of this protocol characteristic before deciding to use CAPWAP. > > > 802.11 header has 4 different addresses, all of which can be > > > different. When doing split MAC with 802.3 frames, the 802.3 frame > > > contains only two of the addresses; the "Radio MAC Address" > > > field in CAPWAP header contains the third -- but what about the > > > fourth one? > > > The CAPWAP WG only supports 802.11-2007, and does not support ad-hoc > > mode (client-client). The very fact that we are providing an > > alternative way to deploy 802.11 infrastructure means that do not need > > to support ad hoc mode ;-) > > I wasn't thinking about ad-hoc mode, but rather a STA sending a packet to an AP where the 802.3 source address would be different from the transmitting STA address. Is this possible? (Perhaps a "wireless Ethernet bridge", which connects to PC via wired Ethernet, but looks like STA to the AP? Although I'm not quite sure how the address fields really look in this situation...) Yes, you are correct that bridges work this way, but this is not a use case we are trying to address in this working group. An access point uses the IEEE 802.11 primitives for populating its learning table (e.g., association request), while a bridge needs to use other means (e.g., spanning tree). Trying to add wireless bridges to this specification would not only expand the scope of the WG and protocol, but would require lots more work. > > > The document should have some more text about how the WTP processes > > > IEEE 802.11 IEs it receives from the AC. Section 6.6 talks about > > > copying them to Beacon/Probe Response messages, but it seems that in > > > some cases, the WTP also does some local processing. (I was sort of > > > expecting a list of all IEs, and description of expected WTP > > > processing (possibly none) for them.) > > > There are two mode of operation: > > 1. Split MAC. In this case, the WTP needs to make sure that the > > beacons have the proper information. Other than that,the AC handles > > all of the IEs in the manner described in the 802.11-2007 standard. > > This is contradicted by text in e.g. Section 6.15, which requires the WTP to process (beyond copying to beacons) the IE received from AC even in Split MAC mode. OK, fair enough. That is one exception, but that one is described in the spec. The spec even includes: 2.2.1. Split MAC [...] o The WTP generates the IEEE 802.11 Beacon frames, using information provided to it through the IEEE 802.11 Add WLAN (see Section 6.1) message element, including the RSNIE, which indicates support of 802.1X and AES-CCMP. > > Also, it seems that some of the IEs sent are not even included in beacons; e.g. Section 6.1 says the AC MUST send the Power Capability IE to the WTP -- but reading 802.11, I can't seem to find any place the AP would actually send this IE (it's sent by the STA). So what does the WTP do with it? OK, that should have been Power Constraint, not Power Capability. Thanks for finding that one. > > > 2. Local MAC. In this case, the 802.11 management packets are > > processed in the WTP, as described 2.2.2. In this case, the WTP > > handles the IEs in the manner described in the 802.11-2007 standard. > > Right, 802.11-2007 specifies how the WTP processes IEs received from the STA. But it doesn't specify how to process IEs received from AC (obviously, since the concept of AC doesn't exist). Actually, re-reading the spec, I don't see where it dictates that the WTP needs to process IEs. It does mention that the WTP needs to look at the Result-Code in the (re-)Association Response. It also does mention that the AC MAY send a Disassocation Request to the station, through the WTP, and that the WTP should take the Disassocation Request as an indication that service for the station is to be terminated. Otherwise, there are no IE processing requirements. > > > Section 6.15: Is this really the PTK (which also includes KCK and > > > KEK, which aren't needed by the WTP since the AC is handling the > > > EAPOL-Key messages -- so probably shouldn't be sent to PTK), or only > > > the TK used for encrypting traffic? > > > > We send the whole PTK. The WTP simply extracts what it needs and uses > > it. > > In that case, the "key the WTP is to use when encrypting traffic to/from the station" is a bit confusing -- that would only the TK. Well, you are ignoring the next sentence here. However, I can add a little clarification to the next sentence. The thing is, when WEP is used, then the contents are the actual WEP key, so we can't get into PTK discussions in that sentence. So I am proposing the following: Key: The key the WTP is to use when encrypting traffic to/from the station. For dynamically created keys, such as those used with WPA and RSN, this is commonly known as a Pairwise Transient Key (PTK). For static keys, such as those used in WEP, the Key field contains the actual encryption key. > > > Is the binding specified here sufficient for 802.11r as well, or > > > would something more be needed? (I don't know the answer -- but > > > probably the document should tell what it is) > > > Given we only support 802.11-2007, we do not worry about 802.11r at > > this point (or 802.11n), so the answer is yes, more is needed. > > The document certainly gives the impression of supporting 802.11n, since it's e.g. listed in WTP Radio Information message element. > If that's not the case, it'd be useful to say explicitly that more is needed for 11r and 11n. Fair point, so I will add the following paragraph to the end of the introduction section: Note that this binding only supports the IEEE 802.11-2007 specification. New protocol specifications published outside of this document (e.g., IEEE 802.11n, IEEE 802.11r) are therefore not supported through this binding, and must be addressed either through a separate CAPWAP binding, or an update to this binding. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 13 12:28:07 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FAE83A6B8A for ; Wed, 13 Aug 2008 12:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZrq5Y91JqyT for ; Wed, 13 Aug 2008 12:28:06 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 15F543A6995 for ; Wed, 13 Aug 2008 12:28:06 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 41A9F1C40F8E for ; Wed, 13 Aug 2008 12:28:09 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 8D02E44019B for ; Wed, 13 Aug 2008 12:28:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8F91534AC05F for ; Wed, 13 Aug 2008 12:28:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 986B234AC052 for ; Wed, 13 Aug 2008 12:27:56 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 13 Aug 2008 12:27:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,202,1217808000"; d="scan'208";a="74941184" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 13 Aug 2008 19:27:56 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m7DJRuOS015320; Wed, 13 Aug 2008 12:27:56 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m7DJRu3a004319; Wed, 13 Aug 2008 19:27:56 GMT 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.1830); Wed, 13 Aug 2008 12:27:56 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Aug 2008 12:27:55 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2064598C7@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB72014C62A8@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 166: Various IANA Issues Thread-Index: AcjyfwiGWFFYbM34RwGLIXgw/+Uu9wGXDdqQASeRViA= References: <4FF84B0BC277FF45AA27FE969DD956A20632FC22@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C62A8@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 13 Aug 2008 19:27:56.0071 (UTC) FILETIME=[B0005B70:01C8FD7A] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Capwap] Issue 166: Various IANA Issues X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com > Pat Calhoun wrote: > > > 15.6. CAPWAP Control Message Type > > > > The Type field in the CAPWAP Control Message header (see Section > > 4.6) is used to identify the data being transported. > > Section 4.6 doesn't seem to have CAPWAP Control Message header; and IANA considerations for the CAPWAP Message Type field was already covered in Section 15.3. > > This probably should be "CAPWAP Message Element Type"? Correct. > > > The namespace is 32 bits (0-4294967295), where the value of zero > > (0) is reserved and must not be assigned. > > If this is the message element type field, it's only 16 bits. Oh right. > > > The values one (1) through 52 are allocated in this specification, and > > can be found in Section 4.5.1.1. This namespace is managed by IANA > > and assignments require a Standards Action. > > If the intent is to allow bindings documented outside standards track RFCs (e.g. EPCGlobal), Standards Action probably isn't the right policy here. I'm hoping we can get this discussion going on the thread for issue 158. So I consider this part of another issue being tracked. > > > 15.7. Wireless Binding Identifiers > > > > The Wireless Binding Identifier (WBID) field in the CAPWAP header > > (see Section 4.3) is used to identify the wireless technology > > associated with the packet. Due to the limited address space > > available, a new WBID request requires Standards Action. > > Again, Standards Action requires all wireless bindings to be standards track RFCs, which isn't compatible with EPCGlobal. > Ditto. > > > 15.10. AC Information Type > > > > The Information Type field in the AC Descriptor message element > > (see Section 4.6.1) is used to represent information about the AC. > > The namespace is 16 bits (0-65535), where the value of zero (0) is > > reserved and must not be assigned. The values four (4) and five (5) > > are allocated in this specification, and can be found in Section > > 4.6.1. This namespace is managed by IANA and assignments require a > > Standards Action. IANA will create the AC Information Type registry, > > whose format is: > > > > AC Information Type Type Value Reference > > Is the intent to have something similar as for CAPWAP Message Types (IANA manages registry for Enterprise Number 0; other Enterprise Numbers are not controlled via IANA?) > > Or is the AC Information Type independent of the AC Information Vendor Identifier? (in that case, I'd expect vendors would want to include vendor-specific information, and Standards Action perhaps isn't the optimal policy.) > Currently, any vendor (or SDO) can define their own message elements through the vendor specific message element. This message element allows the vendor (or SDO) to include their Enterprise Code, and they can manage their own message element namespace. PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 13 12:39:49 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57B903A6ACF for ; Wed, 13 Aug 2008 12:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FUZZY_CPILL=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfF1xyy1YA3m for ; Wed, 13 Aug 2008 12:39:48 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 0C8CD3A6452 for ; Wed, 13 Aug 2008 12:39:48 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4AAA1439FAC for ; Wed, 13 Aug 2008 12:39:43 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 541804401B4 for ; Wed, 13 Aug 2008 12:39:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2C13934AC02A for ; Wed, 13 Aug 2008 12:39:34 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 87DA934AC01D for ; Wed, 13 Aug 2008 12:39:32 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.68.10.87 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 13 Aug 2008 12:39:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,202,1217808000"; d="scan'208";a="41387969" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 13 Aug 2008 19:39:31 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m7DJdVii014570; Wed, 13 Aug 2008 12:39:31 -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.13.8/8.13.8) with ESMTP id m7DJdV1C008963; Wed, 13 Aug 2008 19:39:31 GMT 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.1830); Wed, 13 Aug 2008 12:39:31 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Aug 2008 12:39:30 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2064598E3@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB72014C62AA@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 168: DTLS and Retransmissions Thread-Index: Acjz2WCdWj/4NEiBRna0IkK5PBovgQAIF04AATj3hCABJ5M2wA== References: <4FF84B0BC277FF45AA27FE969DD956A20632FD71@xmb-sjc-235.amer.cisco.com> <4892D971.1010303@ltsnet.net> <4FF84B0BC277FF45AA27FE969DD956A206330514@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C62AA@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , , "Scott Kelly" X-OriginalArrivalTime: 13 Aug 2008 19:39:31.0683 (UTC) FILETIME=[4E9E5330:01C8FD7C] Authentication-Results: sj-dkim-4; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Ok, well I'm still looking to Charles and Scott to weigh in, but how about we replace the following text: 2.4.3. DTLS Error Handling If the AC does not respond to any DTLS messages sent by the WTP, the DTLS specification calls for the WTP to retransmit these messages. If the WaitDTLS timer expires, CAPWAP will issue the DTLSAbortSession command, causing DTLS to terminate the handshake and remove any allocated session context. Note that DTLS MAY send a single TLS Alert message to the AC to indicate session termination. If the WTP does not respond to any DTLS messages sent by the AC, the CAPWAP protocol allows for three possibilities, listed below. Note that DTLS MAY send a single TLS Alert message to the AC to indicate session termination. o The message was lost in transit; in this case, the WTP will re- transmit its last outstanding message, since it did not receive a reply. o The WTP sent a DTLS Alert, which was lost in transit; in this case, the AC's WaitDTLS timer will expire, and the session will be terminated. o Communication with the WTP has completely failed; in this case, the AC's WaitDTLS timer will expire, and the session will be terminated. With: 2.4.3. DTLS Error Handling If the AC or WTP does not respond to any DTLS messages sent by its peer, the DTLS specification calls for the message to be retransmited. If the WaitDTLS timer expires, CAPWAP will issue the DTLSAbortSession command, causing DTLS to terminate the handshake and remove any allocated session context. Note that DTLS MAY send a single DTLS Alert message to the AC to indicate session termination. PatC -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Thursday, August 07, 2008 3:42 PM To: Pat Calhoun (pacalhou); clancy@ltsnet.net Cc: capwap@frascone.com Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions Section 2.4.3 assumes that only the WTP retransmits DTLS messages if it doesn't get a reply (and AC retransmits a reply only when it gets a retransmitted request from the WTP). That's not the case: both parties retransmit if the handshake isn't done yet. For example, the AC will also keep retransmitting ServerHello (and Certificate/ServerKeyExchange/ServerHelloDone) if it doesn't receive a reply (Certificate/ClientKeyExchange/etc.) from the WTP. Best regards, Pasi > -----Original Message----- > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: 01 August, 2008 20:12 > To: Charles Clancy > Cc: capwap@frascone.com; Eronen Pasi (Nokia-NRC/Helsinki) > Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions > > Got it - waiting for Pasi on 2.4.3. > > PatC > > -----Original Message----- > From: Charles Clancy [mailto:clancy@ltsnet.net] > Sent: Friday, August 01, 2008 2:38 AM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com; Pasi.Eronen@nokia.com > Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions > > Suggested text changes to address the comments: > > Replace this 2.4.1 text: > > DTLS, as specified, provides its own retransmit timers with an > exponential back-off. However, DTLS will never terminate the > handshake due to non-responsiveness; instead, DTLS will continue > to > increase its back-off timer period. Hence, timing out incomplete > DTLS handshakes is entirely the responsibility of the CAPWAP > module. > > with this text: > > DTLS, as specified, provides its own retransmit timers with an > exponential back-off. [RFC4347] does not specify how long > retransmissions should continue. Consequently, timing out > incomplete > DTLS handshakes is entirely the responsibility of the CAPWAP > module. > > I'm not sure what needs to be addressed in 2.4.3. Pasi -- can you be > more specific? > > -- > Dr. Charles Clancy www.ltsnet.net/~clancy > Senior Researcher, Laboratory for Telecommunications Sciences > > > Pat Calhoun (pacalhou) wrote: > > Pasi's comment was: > > > > Section 2.4.1: "DTLS will never terminate the handshake due to > > non-responsiveness; instead, DTLS will continue to > > increase its back-off timer period" While RFC 4347 > doesn't specify > > how > > long you should continue retransmitting, the > > intent certainly was not to continue indefinitely. > > > > Section 2.4.3 text about DTLS retransmissions is slightly > inaccurate; > > DTLS handshake isn't strictly request/response, > > and both parties (not just the DTLS client) retransmit based on > > timers > > (in some situations). > > > > It is unclear to me as to whether these are simply observations, or > > request for change. That said, I would like either Charles > or Scott to > > > reply. > > > > PatC > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/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 Aug 13 12:49:34 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB58128C1AE for ; Wed, 13 Aug 2008 12:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMqhmaCjt+sJ for ; Wed, 13 Aug 2008 12:49:29 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 1CE393A6452 for ; Wed, 13 Aug 2008 12:49:29 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 47AD31C40FC7 for ; Wed, 13 Aug 2008 12:49:33 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id BAE37D0404C for ; Wed, 13 Aug 2008 12:49:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8ADA134AC014 for ; Wed, 13 Aug 2008 12:49:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 265C334AC02B for ; Wed, 13 Aug 2008 12:49:25 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.68.10.86 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 13 Aug 2008 12:49:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,203,1217808000"; d="scan'208";a="19904715" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 13 Aug 2008 19:49:25 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m7DJnO9j031839; Wed, 13 Aug 2008 12:49:24 -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.13.8/8.13.8) with ESMTP id m7DJnOPB011491; Wed, 13 Aug 2008 19:49:24 GMT 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.1830); Wed, 13 Aug 2008 12:49:24 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Aug 2008 12:49:24 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2064598F1@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB72014C62AB@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Recap of current pending issues Thread-Index: Acjz9xoEqCcXlGoTT6y9r7yIArdLFwDULppAAGVprtABKASH0A== References: <4FF84B0BC277FF45AA27FE969DD956A2063304F7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A206393CCC@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C62AB@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 13 Aug 2008 19:49:24.0746 (UTC) FILETIME=[B01C8EA0:01C8FD7D] Authentication-Results: sj-dkim-4; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Capwap] Recap of current pending issues X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com > Issue 159 (Question on CAPWAP control protocol). This was a question, > which I have responded to. There was no need for change, unless Pasi > raises a specific issue. At this point, I consider this issue closed. The answer (you can't have multiple outstanding requests) really needs to be in the spec. Also, the spec needs some more text about how the receiver processes them -- e.g. does the receiver maintain "last seen sequence number" counter, and silently drop (without replying) requests older than this? I believe some of this was already covered, but I have added a new sentence to the end of the first paragraph. I am including some additional language that does address some of your concern that was already in the spec: 4.5.3. Retransmissions The CAPWAP control protocol operates as a reliable transport. For each Request message, a Response message is defined, which is used to acknowledge receipt of the Request message. In addition, the control header Sequence Number field is used to pair the Request and Response messages (see Section 4.5.1). This Request/Response pair, combined with the Sequence Number, implies that both the WTP and the AC can only have a single request outstanding at any given time. Response messages are not explicitly acknowledged, therefore if a Response message is not received, the original Request message is retransmitted. Implementations MAY cache Response messages to respond to a retransmitted Request messages with minimal local processing. Retransmitted Request messages MUST NOT be altered by the sender. The sender MUST assume that the original Request message was processed, but that the Response message was lost. Any alterations to the original Request message MUST have a new Sequence Number, and be treated as a new Request message by the receiver. PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 13 14:01:03 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BE6C3A67D8 for ; Wed, 13 Aug 2008 14:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FUZZY_CPILL=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gkx1tjYgRJE for ; Wed, 13 Aug 2008 14:01:01 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id D5D113A67A8 for ; Wed, 13 Aug 2008 14:01:01 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8CDA01C40FC1 for ; Wed, 13 Aug 2008 14:00:57 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 87D0B44018A for ; Wed, 13 Aug 2008 14:00:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 79AF634AC02C for ; Wed, 13 Aug 2008 14:00:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id B202534AC01D for ; Wed, 13 Aug 2008 14:00:48 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from mail.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by mx1.tigertech.net (Postfix) with SMTP for ; Wed, 13 Aug 2008 14:00:48 -0700 (PDT) Received: from aruba-mx2.arubanetworks.com ([10.1.1.83]) by mail.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Aug 2008 14:00:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Aug 2008 14:00:26 -0700 Message-ID: <6F22142CC0DEBE478C659612F9CFCA5001C9325D@aruba-mx2.arubanetworks.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2064598E3@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 168: DTLS and Retransmissions Thread-Index: Acjz2WCdWj/4NEiBRna0IkK5PBovgQAIF04AATj3hCABJ5M2wAACo49w References: <4FF84B0BC277FF45AA27FE969DD956A20632FD71@xmb-sjc-235.amer.cisco.com> <4892D971.1010303@ltsnet.net> <4FF84B0BC277FF45AA27FE969DD956A206330514@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C62AA@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064598E3@xmb-sjc-235.amer.cisco.com> From: "Scott Kelly" To: "Pat Calhoun (pacalhou)" , , X-OriginalArrivalTime: 13 Aug 2008 21:00:30.0903 (UTC) FILETIME=[9EF07470:01C8FD87] Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sorry, I've been out of circulation for a while and am just catching up. Pasi's point is that handshake messages are an exception to the current text, as DTLS will re-transmit these on its own. Rather than stripping out the existing text (which is informative and helpful for implementers and people troubleshooting issues), I think it might be better to update it to reflect Pasi's point. How about this: 2.4.3. DTLS Error Handling If the AC does not respond to any DTLS handshake messages sent by the WTP, the DTLS specification calls for the WTP to retransmit these messages according to the current value of the exponential back-off timer. If the WaitDTLS timer expires, CAPWAP will issue the DTLSAbortSession command, causing DTLS to terminate the handshake and remove any allocated session context. Note that DTLS MAY send a single TLS Alert message to the AC to indicate session termination. If the WTP does not respond to any DTLS handshake messages sent by the AC, the CAPWAP protocol allows for three possibilities, listed below. Note that DTLS MAY send a single TLS Alert message to the AC to indicate session termination. o The message was lost in transit; in this case, the DTLS implementation on the WTP will retransmit its last outstanding handshake message, since it did not receive a reply. --Scott > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Wednesday, August 13, 2008 12:40 PM > To: Pasi.Eronen@nokia.com; clancy@ltsnet.net; Scott Kelly > Cc: capwap@frascone.com > Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions > > Ok, well I'm still looking to Charles and Scott to weigh in, but how > about we replace the following text: > > > 2.4.3. DTLS Error Handling > > If the AC does not respond to any DTLS messages sent by > the WTP, the > DTLS specification calls for the WTP to retransmit these messages. > If the WaitDTLS timer expires, CAPWAP will issue the > DTLSAbortSession > command, causing DTLS to terminate the handshake and remove any > allocated session context. Note that DTLS MAY send a single TLS > Alert message to the AC to indicate session termination. > > If the WTP does not respond to any DTLS messages sent by > the AC, the > CAPWAP protocol allows for three possibilities, listed below. Note > that DTLS MAY send a single TLS Alert message to the AC to indicate > session termination. > > o The message was lost in transit; in this case, the WTP will re- > transmit its last outstanding message, since it did not > receive a > reply. > > o The WTP sent a DTLS Alert, which was lost in transit; in this > case, the AC's WaitDTLS timer will expire, and the > session will be > terminated. > > o Communication with the WTP has completely failed; in this case, > the AC's WaitDTLS timer will expire, and the session will be > terminated. > > > With: > > > 2.4.3. DTLS Error Handling > > If the AC or WTP does not respond to any DTLS messages sent by its > peer, the DTLS specification calls for the message to be > retransmited. If the WaitDTLS timer expires, CAPWAP will issue the > DTLSAbortSession command, causing DTLS to terminate the > handshake and > remove any allocated session context. Note that DTLS MAY send a > single DTLS Alert message to the AC to indicate session > termination. > > > PatC > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Thursday, August 07, 2008 3:42 PM > To: Pat Calhoun (pacalhou); clancy@ltsnet.net > Cc: capwap@frascone.com > Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions > > Section 2.4.3 assumes that only the WTP retransmits DTLS > messages if it > doesn't get a reply (and AC retransmits a reply only when it gets a > retransmitted request from the WTP). > > That's not the case: both parties retransmit if the handshake > isn't done > yet. For example, the AC will also keep retransmitting > ServerHello (and > Certificate/ServerKeyExchange/ServerHelloDone) > if it doesn't receive a reply (Certificate/ClientKeyExchange/etc.) > from the WTP. > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: 01 August, 2008 20:12 > > To: Charles Clancy > > Cc: capwap@frascone.com; Eronen Pasi (Nokia-NRC/Helsinki) > > Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions > > > > Got it - waiting for Pasi on 2.4.3. > > > > PatC > > > > -----Original Message----- > > From: Charles Clancy [mailto:clancy@ltsnet.net] > > Sent: Friday, August 01, 2008 2:38 AM > > To: Pat Calhoun (pacalhou) > > Cc: capwap@frascone.com; Pasi.Eronen@nokia.com > > Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions > > > > Suggested text changes to address the comments: > > > > Replace this 2.4.1 text: > > > > DTLS, as specified, provides its own retransmit timers with an > > exponential back-off. However, DTLS will never terminate the > > handshake due to non-responsiveness; instead, DTLS will > continue > > to > > increase its back-off timer period. Hence, timing out > incomplete > > DTLS handshakes is entirely the responsibility of the CAPWAP > > module. > > > > with this text: > > > > DTLS, as specified, provides its own retransmit timers with an > > exponential back-off. [RFC4347] does not specify how long > > retransmissions should continue. Consequently, timing out > > incomplete > > DTLS handshakes is entirely the responsibility of the CAPWAP > > module. > > > > I'm not sure what needs to be addressed in 2.4.3. Pasi -- > can you be > > more specific? > > > > -- > > Dr. Charles Clancy www.ltsnet.net/~clancy > > Senior Researcher, Laboratory for Telecommunications Sciences > > > > > > Pat Calhoun (pacalhou) wrote: > > > Pasi's comment was: > > > > > > Section 2.4.1: "DTLS will never terminate the handshake due to > > > non-responsiveness; instead, DTLS will continue to > > > increase its back-off timer period" While RFC 4347 > > doesn't specify > > > how > > > long you should continue retransmitting, the > > > intent certainly was not to continue indefinitely. > > > > > > Section 2.4.3 text about DTLS retransmissions is slightly > > inaccurate; > > > DTLS handshake isn't strictly request/response, > > > and both parties (not just the DTLS client) retransmit > based on > > > timers > > > (in some situations). > > > > > > It is unclear to me as to whether these are simply > observations, or > > > request for change. That said, I would like either Charles > > or Scott to > > > > > reply. > > > > > > PatC > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/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 Aug 13 14:32:59 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D84CC3A693F for ; Wed, 13 Aug 2008 14:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FUZZY_CPILL=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBvOU7lUSwHW for ; Wed, 13 Aug 2008 14:32:58 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 79ED628C1AB for ; Wed, 13 Aug 2008 14:32:58 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EDE161C40FB4 for ; Wed, 13 Aug 2008 14:32:58 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 06FDCD0404D for ; Wed, 13 Aug 2008 14:32:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 300ED34AC048 for ; Wed, 13 Aug 2008 14:32:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 011B634AC005 for ; Wed, 13 Aug 2008 14:32:05 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 13 Aug 2008 14:32:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,203,1217808000"; d="scan'208";a="65198642" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 13 Aug 2008 21:31:56 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m7DLVujV013167; Wed, 13 Aug 2008 14:31:56 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7DLVujb019730; Wed, 13 Aug 2008 21:31:56 GMT 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.1830); Wed, 13 Aug 2008 14:31:55 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Aug 2008 14:31:54 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206459972@xmb-sjc-235.amer.cisco.com> In-Reply-To: <6F22142CC0DEBE478C659612F9CFCA5001C9325D@aruba-mx2.arubanetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 168: DTLS and Retransmissions Thread-Index: Acjz2WCdWj/4NEiBRna0IkK5PBovgQAIF04AATj3hCABJ5M2wAACo49wAAFg9oA= References: <4FF84B0BC277FF45AA27FE969DD956A20632FD71@xmb-sjc-235.amer.cisco.com> <4892D971.1010303@ltsnet.net> <4FF84B0BC277FF45AA27FE969DD956A206330514@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C62AA@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064598E3@xmb-sjc-235.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001C9325D@aruba-mx2.arubanetworks.com> From: "Pat Calhoun (pacalhou)" To: "Scott Kelly" , , X-OriginalArrivalTime: 13 Aug 2008 21:31:55.0981 (UTC) FILETIME=[028887D0:01C8FD8C] Authentication-Results: sj-dkim-4; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sounds good to me. PatC -----Original Message----- From: Scott Kelly [mailto:skelly@arubanetworks.com] Sent: Wednesday, August 13, 2008 2:00 PM To: Pat Calhoun (pacalhou); Pasi.Eronen@nokia.com; clancy@ltsnet.net Cc: capwap@frascone.com Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions Sorry, I've been out of circulation for a while and am just catching up. Pasi's point is that handshake messages are an exception to the current text, as DTLS will re-transmit these on its own. Rather than stripping out the existing text (which is informative and helpful for implementers and people troubleshooting issues), I think it might be better to update it to reflect Pasi's point. How about this: 2.4.3. DTLS Error Handling If the AC does not respond to any DTLS handshake messages sent by the WTP, the DTLS specification calls for the WTP to retransmit these messages according to the current value of the exponential back-off timer. If the WaitDTLS timer expires, CAPWAP will issue the DTLSAbortSession command, causing DTLS to terminate the handshake and remove any allocated session context. Note that DTLS MAY send a single TLS Alert message to the AC to indicate session termination. If the WTP does not respond to any DTLS handshake messages sent by the AC, the CAPWAP protocol allows for three possibilities, listed below. Note that DTLS MAY send a single TLS Alert message to the AC to indicate session termination. o The message was lost in transit; in this case, the DTLS implementation on the WTP will retransmit its last outstanding handshake message, since it did not receive a reply. --Scott > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Wednesday, August 13, 2008 12:40 PM > To: Pasi.Eronen@nokia.com; clancy@ltsnet.net; Scott Kelly > Cc: capwap@frascone.com > Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions > > Ok, well I'm still looking to Charles and Scott to weigh in, but how > about we replace the following text: > > > 2.4.3. DTLS Error Handling > > If the AC does not respond to any DTLS messages sent by the WTP, > the > DTLS specification calls for the WTP to retransmit these messages. > If the WaitDTLS timer expires, CAPWAP will issue the > DTLSAbortSession > command, causing DTLS to terminate the handshake and remove any > allocated session context. Note that DTLS MAY send a single TLS > Alert message to the AC to indicate session termination. > > If the WTP does not respond to any DTLS messages sent by the AC, > the > CAPWAP protocol allows for three possibilities, listed below. Note > that DTLS MAY send a single TLS Alert message to the AC to indicate > session termination. > > o The message was lost in transit; in this case, the WTP will re- > transmit its last outstanding message, since it did not receive > a > reply. > > o The WTP sent a DTLS Alert, which was lost in transit; in this > case, the AC's WaitDTLS timer will expire, and the session will > be > terminated. > > o Communication with the WTP has completely failed; in this case, > the AC's WaitDTLS timer will expire, and the session will be > terminated. > > > With: > > > 2.4.3. DTLS Error Handling > > If the AC or WTP does not respond to any DTLS messages sent by its > peer, the DTLS specification calls for the message to be > retransmited. If the WaitDTLS timer expires, CAPWAP will issue the > DTLSAbortSession command, causing DTLS to terminate the handshake > and > remove any allocated session context. Note that DTLS MAY send a > single DTLS Alert message to the AC to indicate session > termination. > > > PatC > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Thursday, August 07, 2008 3:42 PM > To: Pat Calhoun (pacalhou); clancy@ltsnet.net > Cc: capwap@frascone.com > Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions > > Section 2.4.3 assumes that only the WTP retransmits DTLS messages if > it doesn't get a reply (and AC retransmits a reply only when it gets a > retransmitted request from the WTP). > > That's not the case: both parties retransmit if the handshake isn't > done yet. For example, the AC will also keep retransmitting > ServerHello (and > Certificate/ServerKeyExchange/ServerHelloDone) > if it doesn't receive a reply (Certificate/ClientKeyExchange/etc.) > from the WTP. > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: 01 August, 2008 20:12 > > To: Charles Clancy > > Cc: capwap@frascone.com; Eronen Pasi (Nokia-NRC/Helsinki) > > Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions > > > > Got it - waiting for Pasi on 2.4.3. > > > > PatC > > > > -----Original Message----- > > From: Charles Clancy [mailto:clancy@ltsnet.net] > > Sent: Friday, August 01, 2008 2:38 AM > > To: Pat Calhoun (pacalhou) > > Cc: capwap@frascone.com; Pasi.Eronen@nokia.com > > Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions > > > > Suggested text changes to address the comments: > > > > Replace this 2.4.1 text: > > > > DTLS, as specified, provides its own retransmit timers with an > > exponential back-off. However, DTLS will never terminate the > > handshake due to non-responsiveness; instead, DTLS will > continue > > to > > increase its back-off timer period. Hence, timing out > incomplete > > DTLS handshakes is entirely the responsibility of the CAPWAP > > module. > > > > with this text: > > > > DTLS, as specified, provides its own retransmit timers with an > > exponential back-off. [RFC4347] does not specify how long > > retransmissions should continue. Consequently, timing out > > incomplete > > DTLS handshakes is entirely the responsibility of the CAPWAP > > module. > > > > I'm not sure what needs to be addressed in 2.4.3. Pasi -- > can you be > > more specific? > > > > -- > > Dr. Charles Clancy www.ltsnet.net/~clancy > > Senior Researcher, Laboratory for Telecommunications Sciences > > > > > > Pat Calhoun (pacalhou) wrote: > > > Pasi's comment was: > > > > > > Section 2.4.1: "DTLS will never terminate the handshake due to > > > non-responsiveness; instead, DTLS will continue to > > > increase its back-off timer period" While RFC 4347 > > doesn't specify > > > how > > > long you should continue retransmitting, the > > > intent certainly was not to continue indefinitely. > > > > > > Section 2.4.3 text about DTLS retransmissions is slightly > > inaccurate; > > > DTLS handshake isn't strictly request/response, > > > and both parties (not just the DTLS client) retransmit > based on > > > timers > > > (in some situations). > > > > > > It is unclear to me as to whether these are simply > observations, or > > > request for change. That said, I would like either Charles > > or Scott to > > > > > reply. > > > > > > PatC > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/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 Aug 13 14:43:26 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DFFA3A6AFC for ; Wed, 13 Aug 2008 14:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJZ2-xiGBrUs for ; Wed, 13 Aug 2008 14:43:25 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 628E03A69AE for ; Wed, 13 Aug 2008 14:43:25 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 954B31C40F8E for ; Wed, 13 Aug 2008 14:43:07 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 4FBA2D0404C for ; Wed, 13 Aug 2008 14:43:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3FC2534AC019 for ; Wed, 13 Aug 2008 14:43:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id AB50334AC005 for ; Wed, 13 Aug 2008 14:42:57 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 13 Aug 2008 14:42:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,203,1217808000"; d="scan'208";a="65202422" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 13 Aug 2008 21:42:57 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7DLgvnc001544; Wed, 13 Aug 2008 14:42:57 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m7DLgv3R027511; Wed, 13 Aug 2008 21:42:57 GMT 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.1830); Wed, 13 Aug 2008 14:42:57 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Aug 2008 14:42:56 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206459987@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20632FD58@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 158: Allocation of WBIDs Thread-Index: AcjxWPPBckiC/dIYR2+hBkqFhpAT4wACFMvQAEz5BoACvg95oA== References: <4FF84B0BC277FF45AA27FE969DD956A2062CB02E@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB72013BA8AA@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20632FD58@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , , X-OriginalArrivalTime: 13 Aug 2008 21:42:57.0063 (UTC) FILETIME=[8C91A370:01C8FD8D] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 158: Allocation of WBIDs X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Folks, in order to move this one along, I would recommend that we change the current IANA considerations from Standards Action to Expert Review. This would alleviate many of the issues brought up for both the WBID, the message element and the EPCGlobal WBID allocation. Objections? PatC -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Wednesday, July 30, 2008 3:42 PM To: Pasi.Eronen@nokia.com; margaret@thingmagic.com Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 158: Allocation of WBIDs Correct, Pasi. The current IANA classification requires a Standards track RFC for assignment of WBIDs (and every other namespace in the document). I suspect that if EPCGlobal is using their own Enterprise Number for control message types, then it is less of an issue. However, the message element types are still global, and therefore unless you are using the vendor specific message element, you would need an RFC. So what I'm hearing is remove 802.16, and keep 802.11 and EPCGlobal. We just need to work out the details of the IANA classification. PatC -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Tuesday, July 29, 2008 2:59 AM To: margaret@thingmagic.com; Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 158: Allocation of WBIDs Ok -- but if the intent is to allow CAPWAP bindings (and possibly other types of CAPWAP specifications) to be developed outside IETF Standards Track, then the IANA instructions need to be something else than "Standards Action". Best regards, Pasi > -----Original Message----- > From: ext Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: 29 July, 2008 11:55 > To: Pat Calhoun > Cc: capwap@frascone.com; Eronen Pasi (Nokia-NRC/Helsinki) > Subject: Re: [Capwap] Issue 158: Allocation of WBIDs > > > > > Frankly, I don't care much whether we adopt this proposed > change. The > > IEEE 802.11 binding specification does not include the WBID value, > > so a change would be required for that specification. The bigger > change, I > > suspect, is on the EPCGlobal spec. Of particular note, the > CAPWAP spec > > currently requires a Standards Action to allocate one of these > > numbers, and since the RFID CAPWAP specification is being published > > by EPCGlobal, and not the IETF, I'm not sure how they could get a > > number assigned. > > Margaret, you are closer to this than I am, so do you have any > > recommendations? > > (Wearing my EPCglobal hat) > > The EPCglobal Discovery Configuration and Initialization (DCI) > specification defines a CAPWAP binding for RFID readers. It is very > nearly complete after ~1-1/2 years of work. EPCglobal requires > interoperability testing before they will ratify a standard, and that > testing was completed last week. Final ratification of the EPCglobal > standard is now blocked on getting an RFC number for CAPWAP. > EPCglobal doesn't have any plans to publish DCI as an IETF standards > track document. > > The work in EPCglobal was done based on the CAPWAP WG's agreement to > assign an binding ID for that purpose in the CAPWAP spec. While I > agree that further binding IDs need to be defined in their bindings, I > think it would be pretty late to change the agreement with EPCglobal > now. > > > Finally, removing the IEEE 802.16 from the list is not a problem, > > and I agree that if there is ever a specification that defines the > > use of CAPWAP for 802.16, then the number would be assigned at that > > time. > > That would be fine with me, as the 802.16 binding doesn't exist, > AFAIK. > > Margaret > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Aug 13 14:54:42 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87383A68D5 for ; Wed, 13 Aug 2008 14:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuooswgPn3Z2 for ; Wed, 13 Aug 2008 14:54:41 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id D7F923A67D6 for ; Wed, 13 Aug 2008 14:54:41 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0D4AF1C40FAC for ; Wed, 13 Aug 2008 14:54:02 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id E5879D0404B for ; Wed, 13 Aug 2008 14:53:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id CED3734AC048 for ; Wed, 13 Aug 2008 14:53:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4F90F34AC041 for ; Wed, 13 Aug 2008 14:53:53 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 13 Aug 2008 14:53:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,203,1217808000"; d="scan'208";a="139700554" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 13 Aug 2008 21:53:53 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7DLrqG4018181; Wed, 13 Aug 2008 14:53:52 -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.13.8/8.13.8) with ESMTP id m7DLrqq7008776; Wed, 13 Aug 2008 21:53:52 GMT 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.1830); Wed, 13 Aug 2008 14:53:51 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Aug 2008 14:53:51 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206459993@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20632FDC4@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 169: What to do with QoS tags exceeding maximum Thread-Index: AcjynGndl9dXBah+RG+rRLzs+z7g/AK8Vjtg References: <4FF84B0BC277FF45AA27FE969DD956A20632FDC4@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 13 Aug 2008 21:53:51.0991 (UTC) FILETIME=[12EFB870:01C8FD8F] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 169: What to do with QoS tags exceeding maximum X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com I will make a recommendation that we simply down-tag. I think dropping the packet will cause nothing but a communication outage, which can lead to a very difficult troubleshooting session. So the new text is: 6.14. IEEE 802.11 Station QoS Profile The IEEE 802.11 Station QoS Profile message element contains the maximum IEEE 802.11e priority tag that may be used by the station. Any packet received that exceeds the value encoded in this message element MUST be tagged using the maximum value permitted by to the user. The priority tag MUST be between zero (0) and seven (7). This message element MUST NOT be present without the IEEE 802.11 Station (see Section 6.13) message element PatC -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Wednesday, July 30, 2008 4:32 PM To: capwap@frascone.com Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 169: What to do with QoS tags exceeding maximum Pasi's comment was > Section 6.14 says that packets exceeding this priority are either dropped or "down-tagged" -- but it seems which of > these is done depends on WTP (and the AC can't even know what the WTP does). > Isn't this problematic for interoperability? Well... That's a good question. I suppose we could either make a decision in this group, or change the format of the frame in order to allow the AC to communicate to the WTP what behavior it should take. Any preference? If we opt to not change the frame formats, then I would opt for down-tagging. PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 Aug 13 15:13:27 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF78C28C13E for ; Wed, 13 Aug 2008 15:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIe91Up41yqG for ; Wed, 13 Aug 2008 15:13:26 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id A04633A6AEF for ; Wed, 13 Aug 2008 15:13:26 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E26941C40FB7 for ; Wed, 13 Aug 2008 15:13:30 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 36FE2440177 for ; Wed, 13 Aug 2008 15:13:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2947A34AC028 for ; Wed, 13 Aug 2008 15:13:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 6D38D34AC01F for ; Wed, 13 Aug 2008 15:13:24 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 13 Aug 2008 15:13:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,203,1217808000"; d="scan'208";a="65212359" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 13 Aug 2008 22:13:24 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7DMDOwp015213; Wed, 13 Aug 2008 15:13:24 -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.13.8/8.13.8) with ESMTP id m7DMDO7Z020820; Wed, 13 Aug 2008 22:13:24 GMT 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.1830); Wed, 13 Aug 2008 15:13:24 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Aug 2008 15:13:23 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2064599C1@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20633001F@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 172: How is the WTP Descriptor's EncryptionCapabilities defined? Thread-Index: AcjzMJkgfuojjpP+SgySgRFa6gVRZAKYCcGw References: <4FF84B0BC277FF45AA27FE969DD956A20633001F@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 13 Aug 2008 22:13:24.0059 (UTC) FILETIME=[CD8B1AB0:01C8FD91] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 172: How is the WTP Descriptor's EncryptionCapabilities defined? X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com All, In order to make progress on this issue, I will be proposing a change that breaks backward compatibility. Unfortunately, there is no easy fix, other than severely limiting protocol extensibility. The fix is to allow multiple encryption capability fields in the WTP Descriptor, hence breaking interoperability with -10. 4.6.40. WTP Descriptor The WTP Descriptor message element is used by a WTP to communicate its current hardware and software (firmware) configuration. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max Radios | Radios in use | Encryption Sub-Element | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Descriptor Sub-Element... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [...] Encryption Sub-Element: The WTP Descriptor message element MUST contain at least one Encryption sub-element. One sub-element is present for each binding supported by the WTP. The Encryption sub-element has the following format: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Resvd| WBID | Encryption Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Resvd: The 3-bit field is reserved for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. WBID: A 5 bit field which is the wireless binding identifier. The identifier will indicate the type of wireless packet associated with the radio. The WBIDs defined in this specification can be found in Section 4.3 Encryption Capabilities: This 16-bit field is used by the WTP to communicate its capabilities to the AC. A WTP that does not have any encryption capabilities sets this field to zero (0). Refer to the specific wireless binding for further specification of the Encryption Capabilities field. PatC -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Thursday, July 31, 2008 10:12 AM To: capwap@frascone.com Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 172: How is the WTP Descriptor's EncryptionCapabilities defined? Pasi's comment was: > Section 8.1: there probably should be IANA considerations text about how the > remaining bits are allocated. The actual issue here is given the number of bits this field has (8), are we expecting that a given WTP will advertise the encryption capabilities based on the binding being advertised? This means that every binding spec would be able to define all 8 bits. Of course, this would then create a potentially significant problem if a WTP advertises two separate bindings. Currently, the new text in the binding specification is: 8.1. WTP Descriptor Message Element, Encryption Capabilities Field: This specification defines two new bits for the WTP Descriptor's Encryption Capabilities field, as defined in [I-D.ietf-capwap-protocol-specification]. Note that only the bits defined in this specification are described below. The format of the Encryption Capabilities Field is: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | |A|T| | +-+-+-+-+-+-+-+-+ A: WTP supports AES-CCMP, as defined in [IEEE.802-11.2007]. T: WTP supports TKIP and Michael, as defined in [IEEE.802-11.2007] and [WPA], respectively. Again, as currently specified, this means that bits 4 and 5 cannot be redefined by another binding document. So we have to make a decision of whether: 1. We allow the bits to be defined entirely by the binding specification. Prevents a WTP from supporting two different bindings. 2. We allow the bits to be globally allocated. This allows a WTP to advertise multiple bindings, but it restricts the encryption methods to 8 - for all bindings. 3. Create an interoperability issue by removing the encryption capabilities field in the base document (or leave the field but mark it reserved), and require all bindings to define their own encryption capabilities message element. Thoughts? PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 Aug 14 10:32:50 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 994F53A6CAF for ; Thu, 14 Aug 2008 10:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+G1FMnE7LUU for ; Thu, 14 Aug 2008 10:32:49 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 8907B3A692D for ; Thu, 14 Aug 2008 10:32:49 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D950D1C40FC7 for ; Thu, 14 Aug 2008 10:32:46 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 334114401DD for ; Thu, 14 Aug 2008 10:32:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 229BC3610010 for ; Thu, 14 Aug 2008 10:32:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id CC4CE3610005 for ; Thu, 14 Aug 2008 10:32:37 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.72 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 14 Aug 2008 10:32:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,210,1217808000"; d="scan'208";a="95104145" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 14 Aug 2008 17:32:32 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7EHWW3A031153; Thu, 14 Aug 2008 10:32:32 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m7EHWWqX022922; Thu, 14 Aug 2008 17:32:32 GMT 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.1830); Thu, 14 Aug 2008 10:32:32 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Aug 2008 10:32:31 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206459CCE@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2062CB33A@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 161: NAT Inconsistencies Thread-Index: AcjxkhxK+PJwXexpQpS7KRytn/xWJAMoZwXQ References: <4FF84B0BC277FF45AA27FE969DD956A2062CB33A@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 14 Aug 2008 17:32:32.0277 (UTC) FILETIME=[BB82FC50:01C8FE33] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 161: NAT Inconsistencies X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Given the lack of comments, or objections, to the proposed text since July 29th, I will consider this issue closed. PatC -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Tuesday, July 29, 2008 8:45 AM To: capwap@frascone.com Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 161: NAT Inconsistencies Pasi's Comment was: There's some inconsistency about NAT detection: Sections 4.6.12, 4.6.13, and 4.6.15 say it's done using "CAPWAP Local IPv4/6 address" message elements; Sections 4.6.44, 4.6.45, and 6.1 say it's using "WTP IPv4/6 address" message elements. Pasi's comment is spot on. The document was unfortunately very inconsistent. There were two pairs of message elements that was doing basically the same thing, and to make things worse, there was no clear text that explained which pair to use. So I have removed the "WTP IPv4/v6 Address" message elements, since we need a way for both the WTP and the AC to communicate their address. Most of the text below contains changes only, except a new paragraph in the NAT Considerations section. 4.6.12. CAPWAP Local IPv4 Address The CAPWAP Local IPv4 Address message element is sent by either the WTP, in the Join Request, or by the AC, in the Join Response. The CAPWAP Local IPv4 Address message element is used to communicate the IP Address of the transmitter. The receiver uses this to determine whether a middlebox exists between the two peers, by comparing the source IP address of the packet against the value of the message element. [...] 4.6.13. CAPWAP Local IPv6 Address The CAPWAP Local IPv6 Address message element is sent by either the WTP, in the Join Request, or by the AC, in the Join Response. The CAPWAP Local IPv6 Address message element is used to communicate the IP Address of the transmitter. The receiver uses this to determine whether a middlebox exists between the two peers, by comparing the source IP address of the packet against the value of the message element. [...] 4.6.15. CAPWAP Transport Protocol When CAPWAP is run over IPv6, the UDP-Lite or UDP transports MAY be used (see Section 3). The CAPWAP IPv6 Transport Protocol message element is used by either the WTP or the AC to signal which transport protocol is to be used for the CAPWAP data channel. Upon receiving the Join Request, the AC MAY set the CAPWAP Transport Protocol to UDP-Lite in the Join Response message if the CAPWAP message was received over IPv6, and the CAPWAP Local IPv6 Address message element (see Section 4.6.13) is present and no middlebox was detected (see Section 11). Upon receiving the Join Response, the WTP MAY set the CAPWAP Transport Protocol to UDP-Lite in the Configuration Status Request or Image Data Request message if the AC advertised support for UDP-Lite, the message was received over IPv6, the CAPWAP Local IPv6 Address message element (see Section 4.6.13) and no middlebox was detected (see Section 11). Upon receiving either the Configuration Status Request or the Image Data Request, the AC MUST observe the preference indicated by the WTP in the CAPWAP Transport Protocol, as long as it is consistent with what the AC advertised in the Join Response. [...] 6.1. Join Request [...] At least one of the following message element MUST be included in the Join Request message. o CAPWAP Local IPv4 Address, see Section 4.6.12 o CAPWAP Local IPv6 Address, see Section 4.6.13 6.2. Join Response [...] One of the following message elements MUST be included in the Join Response Message: o CAPWAP Local IPv4 Address, see Section 4.6.12 o CAPWAP Local IPv6 Address, see Section 4.6.13 11. NAT Considerations [...] In order for a CAPWAP WTP or AC to detect whether a middlebox is present, both the Join Request (see Section 6.1) and the Join Response (see Section 6.2) include either the CAPWAP Local IPv4 Address (see Section 4.6.12), or the CAPWAP Local IPv6 Address (see Section 4.6.13) message element. Upon receiving one of these messages, if the packet's source IP address differs from the address found in either one of these message elements, it indicates that a middlebox is present. PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 Aug 14 10:33:21 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BF5F3A6957 for ; Thu, 14 Aug 2008 10:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5AomHPq6PsU for ; Thu, 14 Aug 2008 10:33:20 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 04B7E3A692D for ; Thu, 14 Aug 2008 10:33:20 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5CDCF1C40FBB for ; Thu, 14 Aug 2008 10:33:20 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 47D7C4401DD for ; Thu, 14 Aug 2008 10:32:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 216CF3610003 for ; Thu, 14 Aug 2008 10:32:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 071D23610010 for ; Thu, 14 Aug 2008 10:32:41 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 14 Aug 2008 10:32:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,210,1217808000"; d="scan'208";a="65603678" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 14 Aug 2008 17:30:21 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m7EHULnF028856; Thu, 14 Aug 2008 10:30:21 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m7EHULJx018043; Thu, 14 Aug 2008 17:30:21 GMT 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.1830); Thu, 14 Aug 2008 10:30:20 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Aug 2008 10:30:19 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206459CC9@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2062CAFE4@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 154: Should we use IPv4 Multicast Address? Thread-Index: Acjw69m1Vw1OQWnKSgO8nGWyzCUNHwNR4ZGQ References: <4FF84B0BC277FF45AA27FE969DD956A2062CAFE4@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 14 Aug 2008 17:30:20.0157 (UTC) FILETIME=[6CC312D0:01C8FE33] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 154: Should we use IPv4 Multicast Address? X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Given the lack of interest or objections to my proposal to reject this issue, I will consider it closed. PatC -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Monday, July 28, 2008 12:55 PM To: capwap@frascone.com Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 154: Should we use IPv4 Multicast Address? Pasi's comment was: Section 3.3: Should IPv4 use a well-known multicast address (instead of broadcast), too? Why not? I'm not very familiar with the registration of a well-known multicast address. From what I can find at http://www.iana.org/assignments/multicast-addresses, the procedure must be very much the same as any other address space. That said, this has never come up by any AC/WTP vendor before, so I question whether the change is necessary. My response to Pasi on his "Why not?" is that our product has never, nor never will, do this. I can't speak for others, and will let them chime in. Thoughts? PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 Aug 14 10:34:07 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B7923A692D for ; Thu, 14 Aug 2008 10:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMJ27m26eq2i for ; Thu, 14 Aug 2008 10:34:06 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 0A5783A6358 for ; Thu, 14 Aug 2008 10:34:06 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DAC491C40FC3 for ; Thu, 14 Aug 2008 10:34:10 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 54D3A4401DF for ; Thu, 14 Aug 2008 10:34:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3BC803610011 for ; Thu, 14 Aug 2008 10:34:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0121E3610019 for ; Thu, 14 Aug 2008 10:34:02 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 14 Aug 2008 10:34:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,210,1217808000"; d="scan'208";a="65605764" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 14 Aug 2008 17:31:45 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m7EHVjHr016401; Thu, 14 Aug 2008 10:31:45 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m7EHVj38022484; Thu, 14 Aug 2008 17:31:45 GMT 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.1830); Thu, 14 Aug 2008 10:31:45 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Aug 2008 10:31:44 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206459CCC@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2062CB5FE@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 165: Image Download inconsistencies Thread-Index: AcjxuSHHbMnlOv04Qjmm+6GXGVnY3AMemvSw References: <4FF84B0BC277FF45AA27FE969DD956A2062CB5FE@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 14 Aug 2008 17:31:45.0045 (UTC) FILETIME=[9F5BF450:01C8FE33] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 165: Image Download inconsistencies X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Given the lack of comments, or objections, to the proposed text since July 29th, I will consider this issue closed. PatC -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Tuesday, July 29, 2008 1:25 PM To: capwap@frascone.com Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 165: Image Download inconsistencies Pasi's comment was: Section 4.6.30 (Initiate Download): there's no message element named "Image Download" and Section 4.6.28 (Image Identifier) says this message element is sent by the AC to the WTP; but according to Section 9.1, it can also be sent by the WTP? and Section 9.1.2: should say that "Image Information" and "Initiate Download" elements are included only when this message is sent by the AC. This is another area that Pasi fortunately caught that is has some bugs. I just went through the text, and there were some inconsistencies, not to mention exchanges that made no sense. For instance, the AC would send the Initiate Download, but it is really the WTP's decision to initiate the download so that needed to be fixed. Further, as Pasi found out, there was a reference to a message element that did not exist (Image Download), inconsistencies on whom should send what, etc. In fact, even in the four scenarios that are described in section 9.1, use case four was inconsistent with use case three. So I have cleaned up the text, and we have, what I now believe is good text. Of course, I would appreciate a review. Unfortunately, a diff only of section 9.1 would be too hard to follow, so I will include the whole section with the use cases. 4.6.28. Image Identifier The Image Identifier message element is sent by the AC to the WTP to indicate the expected active software version that is to be run on the WTP. The WTP sends the Image Identifier message element in order to request a specific software version from the AC. The actual download process is defined in Section 9.1. The value is a variable length UTF-8 encoded string [RFC3629], which is NOT zero terminated. [...] 4.6.29. Image Information The Image Information message element is present in the Image Data Response message sent by the AC to the WTP and contains the following fields. [...] 4.6.30. Initiate Download The Initiate Download message element is used by the WTP to inform the AC that the AC SHOULD initiate a firmware upgrade. The AC subsequently transmits an Image Data Request message which includes the Image Data message element. This message element does not contain any data. [...] 6.2. Join Response [...] The AC includes the Image Identifier message element to indicate the software version it expects the WTP to run. This information is used to determine whether the WTP MUST either change its currently running firmware image, or download a new version (see Section 9.1.1). 8.4. Configuration Update Request [...] The AC includes the Image Identifier message element (see Section 4.6.28) to force the WTP to update its firmware while in the Run state. The WTP MAY proceed to download the requested firmware if it determines the version specified in the Image Identifier message element is not in its non-volatile storage by transmitting an Image Data Request (see Section 9.1.1) that includes the Initiate Download message element (see Section 4.6.30). 9.1. Firmware Management This section describes the firmware download procedures used by the CAPWAP protocol. Firmware download can occur during the Image Data or Run state. Figure 6 provides an example of a WTP that performs a firmware upgrade while in the Image Data state. In this example, the WTP does not already have the requested firmware (Image Identifier = x), and downloads the image from the AC. WTP AC Join Request --------------------------------------------------------> Join Response (Image Identifier = x) <------------------------------------------------------ Image Data Request (Image Identifier = x, Initiate Download) --------------------------------------------------------> Image Data Response (Result Code = Success, Image Information = {size,hash}) <------------------------------------------------------ Image Data Request (Image Data = Data) <------------------------------------------------------ Image Data Response (Result Code = Success) --------------------------------------------------------> ..... Image Data Request (Image Data = EOF) <------------------------------------------------------ Image Data Response (Result Code = Success) --------------------------------------------------------> (WTP enters the Reset State) Figure 6: WTP Firmware Download Case 1 Figure 7 provides an example in which the WTP has the image specified by the AC in its non-volative storage, but is not its current running image. In this case, the WTP opts to NOT download the firmware and immediately reset to the requested image. WTP AC Join Request --------------------------------------------------------> Join Response (Image Identifier = x) <------------------------------------------------------ (WTP enters the Reset State) Figure 7: WTP Firmware Download Case 2 Figure 8 provides an example of a WTP that performs a firmware upgrade while in the Run state. This mode of firmware upgrade allows the WTP to download its image while continuing to provide service. The WTP will not automatically reset until it is notified by the AC, with a Reset Request message. WTP AC Configuration Update Request (Image Identifier = x) <------------------------------------------------------ Configuration Update Response (Result Code = Success) --------------------------------------------------------> Image Data Request (Image Identifier = x, Initiate Download) --------------------------------------------------------> Image Data Response (Result Code = Success, Image Information = {size,hash}) <------------------------------------------------------ Image Data Request (Image Data = Data) <------------------------------------------------------ Image Data Response (Result Code = Success) --------------------------------------------------------> ..... Image Data Request (Image Data = EOF) <------------------------------------------------------ Image Data Response (Result Code = Success) --------------------------------------------------------> ..... (administratively requested reboot request) Reset Request (Image Identifier = x) <------------------------------------------------------ Reset Response (Result Code = Success) --------------------------------------------------------> Figure 8: WTP Firmware Download Case 3 Figure 9 provides another example of the firmware download while in the Run state. In this example, the WTP already has the image specified by the AC in its non-volative storage. The WTP opts to NOT download the firmware. The WTP resets upon receipt of a Reset Request message from the AC. WTP AC Configuration Update Request (Image Identifier = x) <------------------------------------------------------ Configuration Update Response (Result Code = Already Have Image) --------------------------------------------------------> ..... (administratively requested reboot request) Reset Request (Image Identifier = x) <------------------------------------------------------ Reset Response (Result Code = Success) --------------------------------------------------------> Figure 9: WTP Firmware Download Case 4 9.1.1. Image Data Request [...] The decision that new firmware is to be downloaded to the WTP can occur in one of two ways: When the WTP joins the AC, the Join Response message includes the Image Identifier message element, which informs the WTP of the firmware it is expected to run. if the WTP does not currently have the requested firmware version, it transmits an Image Data Request message, with the appropriate Image Identifier message element. If the WTP already has the requested firmware in its non-volatile flash, but is not its currently running image, it simply resets to run the proper firmware. Once the WTP is in the Run state, it is possible for the AC to cause the WTP to initiate a firmware download by sending an Configuration Update Request message with the Image Identifier message elements. This will cause the WTP to transmit an Image Data Request with the Image Identifier and the Initiate Download message elements. Note that when the firmware is downloaded in this way, the WTP does not automatically reset after the download is complete. The WTP will only reset when it receives a Reset Request message from the AC. If the WTP already had the requested firmware version in its non-volatile storage, the WTP does not transmit the Image Data Request message and responds with a Configuration Update Response message with the Result Code set to Image Already Present. Regardless of how the download was initiated, once the AC receives an Image Data Request message with the Image Identifier message element, it begins the transfer process by transmitting an Image Data Request message that includes the Image Data message element. This continues until the firmware image has been transferred. [...] The following message elements MAY be included in the Image Data Request message when sent by the WTP. o Image Identifier, see Section 4.6.28 o Initiate Download, see Section 4.6.30 9.1.2. Image Data Response [...] The following message elements MAY be included in the Image Data Response message when sent by the AC. o Image Information, see Section 4.6.29 9.2. Reset Request [...] A Reset Request message is sent by an AC to cause a WTP to reinitialize its operation. If the AC includes the Image Identifier message element (see Section 4.6.28), it indicates to the WTP that it SHOULD use that version of software upon reboot. PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 Aug 14 10:37:55 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3E0E3A6899 for ; Thu, 14 Aug 2008 10:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoQYUtz74xIo for ; Thu, 14 Aug 2008 10:37:54 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id A1DEF3A6868 for ; Thu, 14 Aug 2008 10:37:54 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 810221C40FCB for ; Thu, 14 Aug 2008 10:37:47 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 58B474401DD for ; Thu, 14 Aug 2008 10:37:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 481203610010 for ; Thu, 14 Aug 2008 10:37:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 42C0E361000B for ; Thu, 14 Aug 2008 10:37:37 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 14 Aug 2008 10:37:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,210,1217808000"; d="scan'208";a="75325021" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 14 Aug 2008 17:33:58 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m7EHXw14003881; Thu, 14 Aug 2008 10:33:58 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m7EHXwDN025147; Thu, 14 Aug 2008 17:33:58 GMT 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.1830); Thu, 14 Aug 2008 10:33:57 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Aug 2008 10:33:57 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206459CD1@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2062CAFCD@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 151: MTU discovery doesn't look right Thread-Index: Acjw6iHIcnbSlA5zSyuGML+2FIg5kwNScM/w References: <4FF84B0BC277FF45AA27FE969DD956A2062CAFCD@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 14 Aug 2008 17:33:57.0915 (UTC) FILETIME=[EE8E4EB0:01C8FE33] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 151: MTU discovery doesn't look right X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Given the lack of comments, or objections, to the proposed text since July 28th, I will consider this issue closed. Fixed in draft-ietf-capwap-protocol-specification-12.txt PatC -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Monday, July 28, 2008 12:43 PM To: capwap@frascone.com Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 151: MTU discovery doesn't look right Pasi's comment was: 3.5 seems to assume that after the WTP has discovered the AC it wishes to communicate with, RFC 1191/1981/4821 would provide it with the MTU, and then the WTP would establish the CAPWAP session. But those RFCs don't specify e.g. what packets would be used for probing for the MTU. I have taken a look at the RFCs, and he is correct. It looks like we had removed from functionality from the CAPWAP protocol prematurely some time ago. So I re-instated the MTU Discovery Padding message element (glad we had only commented out the text :). Here is the new text: 3.5. MTU Discovery Once a WTP has discovered the AC it wishes to establish a CAPWAP session with, it SHOULD perform a Path MTU (PMTU) discovery. One recommendation for performing PMTU discovery is to have the WTP transmit Discovery Request (see Section 5.1) messages, and include the MTU Discovery Padding message element (see Section 4.6.33). The actual procedures used for PMTU discovery are described in [RFC1191], for IPv4, or for IPv6 [RFC1981] SHOULD be used. Alternatively, implementers MAY use the procedures defined in [RFC4821]. The WTP SHOULD also periodically re-evaluate the PMTU using the guidelines provided in these two RFCs, using the Primary Discovery Request (see Section 5.3) along with the MTU Discovery Padding message element (see Section 4.6.33). When the MTU is initially known, or updated in the case where an existing session already exists, the discovered PMTU is used to configure the DTLS component (see Section 2.3.2.1), while non-DTLS frames need to be fragmented to fit the MTU, defined in Section 3.4. 4.6. CAPWAP Protocol Message Elements [...] MTU Discovery Padding 52 4.6.33. MTU Discovery Padding The MTU Discovery Padding message element is used as padding to perform MTU discovery, and MUST contain octets of value 0xFF, of any length. 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Padding... +-+-+-+-+-+-+-+- Type: 52 for MTU Discovery Padding Length: variable Pad: A variable length pad, filled with the value 0xFF. 5.1. Discovery Request Message [...] The following message elements MAY be included in the Discovery Request message: o MTU Discovery Padding, see Section 4.6.33 5.3. Primary Discovery Request Message The Primary Discovery Request message is sent by the WTP to determine whether its preferred (or primary) AC is available or to performa a Path MTU Discovery (see section Section 3.5. [...] The following message elements MAY be included in the Primary Discovery Request message: o MTU Discovery Padding, see Section 4.6.33 PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 Aug 14 10:40:52 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C66F83A68D0 for ; Thu, 14 Aug 2008 10:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0MHE1aS-tUl for ; Thu, 14 Aug 2008 10:40:51 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 76A703A6902 for ; Thu, 14 Aug 2008 10:40:51 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 330E81C40FC5 for ; Thu, 14 Aug 2008 10:40:47 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id F16684401DD for ; Thu, 14 Aug 2008 10:40:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D49E1361000F for ; Thu, 14 Aug 2008 10:40:40 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 686223610003 for ; Thu, 14 Aug 2008 10:40:38 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 14 Aug 2008 10:40:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,210,1217808000"; d="scan'208";a="75327440" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 14 Aug 2008 17:38:32 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7EHcVV3010214; Thu, 14 Aug 2008 10:38:31 -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.13.8/8.13.8) with ESMTP id m7EHcV7a028441; Thu, 14 Aug 2008 17:38:31 GMT 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.1830); Thu, 14 Aug 2008 10:38:31 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Aug 2008 10:38:31 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206459CDF@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20645989D@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 171: Pasi nits on binding spec Thread-Index: AcjzL5wHOa8wpdqYQUmSlvTmZmTg1QFnnI4QAAUEOaAAGNrSwAEJI2JQADKYLFA= References: <4FF84B0BC277FF45AA27FE969DD956A20633000B@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB72014C629F@vaebe104.NOE.Nokia.com><4FF84B0BC277FF45AA27FE969DD956A2063E6823@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB720150BDF9@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20645989D@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 14 Aug 2008 17:38:31.0828 (UTC) FILETIME=[91D21D40:01C8FE34] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Capwap] Issue 171: Pasi nits on binding spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Just realized I forgot to include the text for the DSCP issue being 6, not 8 bits: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address |RSV| DSCP Tag | Reserved|8021p| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [...] RSV: All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. DSCP Tag: The 6 bit DSCP label to use if packets are eligible to be DSCP tagged (see [RFC2474]). -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Wednesday, August 13, 2008 12:08 PM To: Pasi.Eronen@nokia.com; capwap@frascone.com Subject: Re: [Capwap] Issue 171: Pasi nits on binding spec > > > Does this mean that e.g. all WTPs MUST support WMM? (since the AC > > > MUST always send the WMM information element) And MUST support WPA > > > forever (in addition to RSN)? > > > > Well... We are 2007, and I'm not sure how much we need to care about > > hardware out there that is unable to support IEEE 802.11-2007. If > > there is ever a new IEEE standard for securing, then the list of IEs > > would have to change, but that would be post IEEE 802.11-2007 anyhow. > > The CAPWAP specification could publish an updated set of rules of what > > IEs need to be present. > > I can't find any mention of "WMM Information Element" in IEEE > 802.11-2007 -- I assumed it's some extension that not everyone implements? Yup - my bad. Now include a reference to the WMM web page on www.wi-fi.org. > > BTW, how are you planning to update these rules without breaking backwards compatibility? There are a couple of ways, but the most obvious one would be to have the next binding use a new Wireless Binding Identifier (WBID). > > > Oh, I see. Well, that makes sense. Here is the new text: > > > > > > 6.20. IEEE 802.11 Update Station QoS [...] > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 > > 8 9 0 1 2 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Radio ID | MAC Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | MAC Address | DSCP Tag | Reserved|8021p| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > [...] > > Reserved: All implementations complying with this > > protocol MUST set > > to zero any bits that are reserved in the version of the > > protocol > > supported by that implementation. Receivers MUST ignore all > > bits > > not defined for the version of the protocol they support. > > > > 8021p: The three bit 802.1p priority value to use if > > packets are to > > be IEEE 802.1p tagged. > > > > Here DSCP Tag should be 6 bits, not 8. OK, here is the packet format: > > > > > > Section 6.20 and 6.22: "if packets are to be DSCP tagged" would > > > > > benefit of clarifying what packets are meant (I guess it means > > > > > CAPWAP Data packets sent from the WTP to the AC?). > > > > > > > > New text: > > > > > > > > 6.20. IEEE 802.11 Update Station QoS > > > > > > > > The IEEE 802.11 Update Station QoS message element is used > > > > to change > > > > the Quality of Service policy on the WTP for a given station. > > > > The > > > > QoS tags included in this message element are to be applied to > > > > packets received by the station. > > > > > > By "packets received by the station", do you mean "packets sent by > > > the WTP to the station"? (In this case, including DSCP here is > > > slightly unexpected -- those packets aren't necessarily even IP?) > > > > Hmmm... Should have read: "applied to packets received at the WTP from > > the station." > > In this case, it seems both "Update Station QoS" and "WTP Quality of Service" message elements apply to same packets -- how do they interact? I have added addition verbage to make this clearer: 6.20. IEEE 802.11 Update Station QoS The IEEE 802.11 Update Station QoS message element is used to change the Quality of Service policy on the WTP for a given station. The QoS tags included in this message element are to be applied to packets received at the WTP from the station indicated through the MAC Address field. This message element overrides the default values provided through the IEEE 802.11 WTP Quality of Service message element (see Section 6.22. Any tagging performed by the WTP MUST be directly applied to the packets receive from the station, as well as the CAPWAP tunnel, if the packets are tunneled to the AC. [...] 6.22. IEEE 802.11 WTP Quality of Service The IEEE 802.11 WTP Quality of Service message element value is sent by the AC to the WTP to communicate quality of service configuration information. The QoS tag included in this message element are the default QoS values to be applied to packets received by the WTP from stations on a particular radio. Any tagging performed by the WTP MUST be directly applied to the packets receive from the station, as well as the CAPWAP tunnel, if the packets are tunneled to the AC. > > How does the tagging work (or not work) if the 'C' bit in IEEE 802.11 Station Session Key message element is set? Well.. If that's the case, the packets inside the tunnel cannot be modified - that would be the responsibility of the AC. I can add: C: The one bit field is set by the AC to inform the WTP that encryption services will be provided by the AC. When set, the WTP SHOULD police frames received from stations to ensure that are properly encrypted as specified in the RSN Information Element, but does not need to take specific cryptographic action on the frame. Similarly, for transmitted frames, the WTP only needs to forward already encrypted frames. Since packets received by the WTP will be encrypted, the WTP cannot modify the contents of the packets, including modifying the DSCP markings of the encapsulated packet. In this case, this function would be the responsibility of the AC. > > I'm also slightly surprised to see the WTP modifying the contents of IP packets here -- I thought it was acting as Layer 2 device for user plane traffic (not making any assumptions about the Layer 3 protocol carried in 802.3 frames). At the very least, the text should probably say the DSCP Tag applies only to packets with certain values in the > 802.3 Type field. OK, I can modify the text to specifically read: DSCP Tag: The 6 bit DSCP label to use if packets are eligible to be DSCP tagged (see [RFC2474]). > > > > [...] > > > > 6.22. IEEE 802.11 WTP Quality of Service > > > > > > > > The IEEE 802.11 WTP Quality of Service message element value is > > > > sent by the AC to the WTP to communicate quality of service > > > > configuration information. The QoS tag included in > > this message > > > > element are to be applied to packets received by the WTP from > > > > station on a particular radio. > > > > > > > > > > By "applied to packets received by the WTP from the station", do you > > > mean the tagging is applied to the headers received by the WTP, or > > > to the headers added by WTP for CAPWAP data tunneling? > > > (If it's the former, the comment above about DSCP applies) > > > > > I am proposing adding the following sentence to both sections 6.20 and > > 6.22: > > > > > > Any tagging performed > > by the WTP MUST be directly applied to the packets receive from the > > station, as well as the CAPWAP tunnel, if the packets are > > tunneled to the AC. > > > > The comment above about 'C' bit and DSCP Tag applies here as well... I think this comment is now handled above. > > > > > Well, some new WTPs might decide *not* to support WEP anymore -- > > perhaps not yet, but five year from now..? (But if support of WEP is > > required, the document should say so) > > > > Understood, but IEEE 802.11-2007 still requires the AP support it. > > If I'm reading IEEE 802.11-2007, Section A.4.4.1 correctly, it seems supporting WEP is optional...? Yes, I see PC2 as optional, but all of the sub-elements are being mandatory. I suppose I should read this as those sub-elements are required only if WEP was implemented. We could fix this problem by allocated another bit in section 8.1, alongside TKIP and AES. Note that this would reduce the total number of bits available for the whole protocol, unless we do something to address issue 172. PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/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 Aug 14 10:48:09 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C3FC3A6940 for ; Thu, 14 Aug 2008 10:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9hWFZIHqJw8 for ; Thu, 14 Aug 2008 10:48:08 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 085E53A6868 for ; Thu, 14 Aug 2008 10:48:08 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DC84D1C40FE1 for ; Thu, 14 Aug 2008 10:48:12 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id D64304401DD for ; Thu, 14 Aug 2008 10:48:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id BF91E3610023 for ; Thu, 14 Aug 2008 10:48:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id BA8223610011 for ; Thu, 14 Aug 2008 10:47:59 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 14 Aug 2008 10:47:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,210,1217808000"; d="scan'208";a="65616611" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 14 Aug 2008 17:46:45 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m7EHkiEg028742; Thu, 14 Aug 2008 10:46:44 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m7EHki6B027690; Thu, 14 Aug 2008 17:46:44 GMT 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.1830); Thu, 14 Aug 2008 10:46:44 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Aug 2008 10:46:43 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206459CFA@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A206393CCC@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Recap of current pending issues Thread-Index: Acjz9xoEqCcXlGoTT6y9r7yIArdLFwDULppAAbsS+0A= References: <4FF84B0BC277FF45AA27FE969DD956A2063304F7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A206393CCC@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 14 Aug 2008 17:46:44.0659 (UTC) FILETIME=[B7922830:01C8FE35] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Pasi.Eronen@nokia.com Subject: Re: [Capwap] Recap of current pending issues X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com All, We are now a little over a week past the IETF Last Call, and some progress has been made, so I wanted to provide an update on the latest issues. As you can see below, if there are no comments on any of the issues below, I will publish the new text on 8/18, which will include all of the issues identified through the IETF Last Call. This draft will be ready to move to the IESG for publication. ISSUES WAITING FOR PASI's REVIEW Issue 159 (Question on CAPWAP control protocol). I have provided some updated text to address Pasi's issues. I am waiting for his review. Issue 166 (Various IANA Issues). Pasi had comments on my new IANA text, and identified some real problems which I believe are now all addressed. I am waiting to hear from him on the latest. Issue 168 (DTLS and Retransmissions). I believe we are closed on this. Scott has proposed new text, and I am waiting to hear from Pasi if he is comfortable with the new text. Issue 171 (Pasi nits on binding spec). We are now in the fourth round trip, and I believe we are nearing the end. Waiting for Pasi to review the latest. ISSUES WAITING FOR WG FEEDBACK. Issue 106 (WaitJoin may be unnecessary). Yes, this is an old one, but in fixing 173 I realized that we never should have removed the WaitJoin timer, but instead cleaned it up. This fix re-introduces the timer, but it is enabled/disabled differently from the WaitDTLS timer. I am waiting for WG feedback on this proposed change, and will close by 8/18 if no comments are sent. Issue 158 (Allocation of WBIDs). There is no clear agreement on this issue. The current spec requires a Standards Action to allocate a WBID, but it doesn't look like EPCGlobal plans on submitting their protocol to the IETF. So we either agree to keep the document as it (although we did agree to remove 802.16), or change the IANA action from "Standards Action" to something else, such as perhaps "Designated Expert". I have made the proposal to change to Expert Review and waiting for feedback. Will close on 8/18 if no additional objections are received. Issue 169 (What to do with QoS tags exceeding maximum). Another one where we have a potential interoperability issue, and we need to agree on what behavior the WTP will take if it receives a packet whose QoS marking violates the configured policy. I have proposed that the document will require the WTP to down-tag, as dropping the packet will create unpleasant troubleshooting issues for customers. I will close on 8/18 if no additional objections are received. Issue 172 (How is the WTP Descriptor's Encryption Capabilities defined?). This is a particularly thorny issue that can cause us to break backward interoperability, or worse, severely limit the scope of the protocol. I have provided a solution that is really the optimal one, but it breaks interoperability with -10 and -11. I am waiting for WG comments and will close on 8/18 if no additional objections are received. Issue 173 (Inconsistency in enabling DTLSWait timer). The text was inconsistent in how it was making use of the WaitDTLS timer. Specifically, there were two state transitions that referenced the timer, when it would have been stopped already before reaching that transition. I have already sent text and will close by 8/18 if no additional comments are received. Issue 175 (Retransmission clarification required). The text that specifies how control messages are retransmitted needs some clarification, specifically around the text that deals with congestion control. I have proposed a change, and will close by 8/18 if no additional comments are received. PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 14 13:30:22 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 007D43A6953 for ; Thu, 14 Aug 2008 13:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.667 X-Spam-Level: X-Spam-Status: No, score=-102.667 tagged_above=-999 required=5 tests=[AWL=0.932, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqCdIWVsmh7H for ; Thu, 14 Aug 2008 13:30:21 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id EB6CA3A6856 for ; Thu, 14 Aug 2008 13:30:20 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C2AA31C40FAB for ; Thu, 14 Aug 2008 13:30:15 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id C4E394401C7 for ; Thu, 14 Aug 2008 13:30:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id B41A4362800C for ; Thu, 14 Aug 2008 13:30:09 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 346673628004 for ; Thu, 14 Aug 2008 13:30:08 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (64.170.98.32 whitelisted by list.dnswl.org 9.2) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 14 Aug 2008 13:30:07 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 0) id BCF5C3A6949; Thu, 14 Aug 2008 13:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080814203001.BCF5C3A6949@core3.amsl.com> Date: Thu, 14 Aug 2008 13:30:01 -0700 (PDT) Cc: capwap@frascone.com Subject: [Capwap] I-D ACTION:draft-ietf-capwap-threat-analysis-03.txt X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Control And Provisioning of Wireless Access Points Working Group of the IETF. Title : CAPWAP Threat Analysis for IEEE 802.11 Deployments Author(s) : S. Kelly, C. Clancy Filename : draft-ietf-capwap-threat-analysis-03.txt Pages : 34 Date : 2008-8-14 Early Wireless Local Area Network (WLAN) deployments feature a "fat" Access Point (AP) which serves as a stand-alone interface between the wired and wireless network segments. However, this model raises scaling, mobility, and manageability issues, and the Control and Provisioning for Wireless Access Points (CAPWAP) protocol is meant to address these issues. CAPWAP effectively splits the fat AP functionality into two network elements, and the communication channel between these components may traverse potentially hostile hops. This document analyzes the security exposure resulting from the introduction of CAPWAP, and summarizes the associated security considerations for IEEE 802.11-based CAPWAP implementations and deployments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-capwap-threat-analysis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-capwap-threat-analysis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-8-14132627.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --NextPart-- From 67srw@sirius.com Sat Aug 16 08:11:27 2008 Return-Path: <67srw@sirius.com> X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71A643A6B5F for ; Sat, 16 Aug 2008 08:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.123 X-Spam-Level: X-Spam-Status: No, score=-20.123 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FB_CONSOL_YOUR=1.995, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_MONEYTERMS=0.681, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNWb4bh9epFg for ; Sat, 16 Aug 2008 08:11:26 -0700 (PDT) Received: from X230.D-IP08.lipetsk.ru (X230.D-IP08.lipetsk.ru [195.34.255.230]) by core3.amsl.com (Postfix) with ESMTP id 1BB623A6969 for ; Sat, 16 Aug 2008 08:11:26 -0700 (PDT) Message-ID: <000901c8ffb2$06a19e37$2fdb3396@pbxwgi> From: "dougy liew" <67srw@sirius.com> To: Subject: oxygen debt Date: Sat, 16 Aug 2008 13:23:41 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Do Not consolidate your debt Eliminate it! Legally ELIMINATE your creditT card and other unsecured debt * WITHOUT ever making another payment to your creditors * WITHOUT it affecting your credit long-term * WITHOUT confrontation Visit www.preclea.com This IS NOT: * Bankruptcy * Consolidation * Or refinancing of any kind Visit here www.preclea.com to learn how * Must have a minimum of $10K in combined household unsecured debt to apply. * Must be a US resident. From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Aug 18 12:02:50 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD4EA28C1D1 for ; Mon, 18 Aug 2008 12:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.603 X-Spam-Level: X-Spam-Status: No, score=-4.603 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_00=-2.599, FUZZY_CPILL=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfCZ9g3RUwAV for ; Mon, 18 Aug 2008 12:02:49 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 913F528C1E4 for ; Mon, 18 Aug 2008 12:02:39 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C81BE1C40F4B for ; Mon, 18 Aug 2008 12:02:46 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id A4ED444011A for ; Mon, 18 Aug 2008 12:02:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 498BA34AC0DB for ; Mon, 18 Aug 2008 12:02:30 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4AFA334AC0E9 for ; Mon, 18 Aug 2008 12:02:26 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.122.230 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 18 Aug 2008 12:02:21 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7IJ1jaO007019; Mon, 18 Aug 2008 22:01:45 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 22:01:44 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 22:01:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Aug 2008 22:01:45 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720161CBD0@vaebe104.NOE.Nokia.com> In-Reply-To: <6F22142CC0DEBE478C659612F9CFCA5001C9325D@aruba-mx2.arubanetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 168: DTLS and Retransmissions Thread-Index: Acjz2WCdWj/4NEiBRna0IkK5PBovgQAIF04AATj3hCABJ5M2wAACo49wAPcO2xA= References: <4FF84B0BC277FF45AA27FE969DD956A20632FD71@xmb-sjc-235.amer.cisco.com> <4892D971.1010303@ltsnet.net> <4FF84B0BC277FF45AA27FE969DD956A206330514@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C62AA@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064598E3@xmb-sjc-235.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001C9325D@aruba-mx2.arubanetworks.com> From: To: , , X-OriginalArrivalTime: 18 Aug 2008 19:01:44.0761 (UTC) FILETIME=[DB7E3A90:01C90164] X-Nokia-AV: Clean Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Scott and Pat, This text still assumes that the WTP is responsible for retransmitting the DTLS handshake messages (based on timer) if it doesn't receive anything from the AC. That's not totally correct. Pat's proposed text did get this right; but I agree that talking explicitly about DTLS *handshake* messages (instead of just DTLS messages) would be clearer. Here's another attempt: If the AC or WTP does not respond to any DTLS handshake messages sent by its peer, the DTLS specification calls for the message to be retransmited. Note that during the handshake, when both the AC and the WTP are expecting additional handshake messages, they both retransmit if an expected message has not been received (note that retransmissions for CAPWAP Control messages work differently: all CAPWAP Control messages are either requests or responses, and the peer who sent the request is responsible for retransmissions). Best regards, Pasi > -----Original Message----- > From: ext Scott Kelly [mailto:skelly@arubanetworks.com] > Sent: 14 August, 2008 00:00 > To: Pat Calhoun (pacalhou); Eronen Pasi (Nokia-NRC/Helsinki); > clancy@ltsnet.net > Cc: capwap@frascone.com > Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions > > Sorry, I've been out of circulation for a while and am just > catching up. > > > Pasi's point is that handshake messages are an exception to the > current text, as DTLS will re-transmit these on its own. Rather than > stripping out the existing text (which is informative and helpful > for implementers and people troubleshooting issues), I think it > might be better to update it to reflect Pasi's point. > > How about this: > > 2.4.3. DTLS Error Handling > > If the AC does not respond to any DTLS handshake messages sent by > the WTP, the DTLS specification calls for the WTP to retransmit > these messages according to the current value of the exponential > back-off timer. If the WaitDTLS timer expires, CAPWAP will issue > the DTLSAbortSession command, causing DTLS to terminate the > handshake and remove any allocated session context. Note that > DTLS MAY send a single TLS Alert message to the AC to indicate > session termination. > > If the WTP does not respond to any DTLS handshake messages sent > by the AC, the CAPWAP protocol allows for three possibilities, > listed below. Note that DTLS MAY send a single TLS Alert message > to the AC to indicate session termination. > > o The message was lost in transit; in this case, the DTLS > implementation > on the WTP will retransmit its last outstanding > handshake message, > since it did not receive a reply. > > > > --Scott > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Wednesday, August 13, 2008 12:40 PM > > To: Pasi.Eronen@nokia.com; clancy@ltsnet.net; Scott Kelly > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions > > > > Ok, well I'm still looking to Charles and Scott to weigh in, but how > > about we replace the following text: > > > > > > 2.4.3. DTLS Error Handling > > > > If the AC does not respond to any DTLS messages sent by > > the WTP, the > > DTLS specification calls for the WTP to retransmit these > messages. > > If the WaitDTLS timer expires, CAPWAP will issue the > > DTLSAbortSession > > command, causing DTLS to terminate the handshake and remove any > > allocated session context. Note that DTLS MAY send a single TLS > > Alert message to the AC to indicate session termination. > > > > If the WTP does not respond to any DTLS messages sent by > > the AC, the > > CAPWAP protocol allows for three possibilities, listed > below. Note > > that DTLS MAY send a single TLS Alert message to the AC > to indicate > > session termination. > > > > o The message was lost in transit; in this case, the > WTP will re- > > transmit its last outstanding message, since it did not > > receive a > > reply. > > > > o The WTP sent a DTLS Alert, which was lost in transit; in this > > case, the AC's WaitDTLS timer will expire, and the > > session will be > > terminated. > > > > o Communication with the WTP has completely failed; in > this case, > > the AC's WaitDTLS timer will expire, and the session will be > > terminated. > > > > > > With: > > > > > > 2.4.3. DTLS Error Handling > > > > If the AC or WTP does not respond to any DTLS messages > sent by its > > peer, the DTLS specification calls for the message to be > > retransmited. If the WaitDTLS timer expires, CAPWAP > will issue the > > DTLSAbortSession command, causing DTLS to terminate the > > handshake and > > remove any allocated session context. Note that DTLS MAY send a > > single DTLS Alert message to the AC to indicate session > > termination. > > > > > > PatC > > -----Original Message----- > > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > > Sent: Thursday, August 07, 2008 3:42 PM > > To: Pat Calhoun (pacalhou); clancy@ltsnet.net > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions > > > > Section 2.4.3 assumes that only the WTP retransmits DTLS > > messages if it > > doesn't get a reply (and AC retransmits a reply only when it gets a > > retransmitted request from the WTP). > > > > That's not the case: both parties retransmit if the handshake > > isn't done > > yet. For example, the AC will also keep retransmitting > > ServerHello (and > > Certificate/ServerKeyExchange/ServerHelloDone) > > if it doesn't receive a reply (Certificate/ClientKeyExchange/etc.) > > from the WTP. > > > > Best regards, > > Pasi > > > > > -----Original Message----- > > > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > > Sent: 01 August, 2008 20:12 > > > To: Charles Clancy > > > Cc: capwap@frascone.com; Eronen Pasi (Nokia-NRC/Helsinki) > > > Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions > > > > > > Got it - waiting for Pasi on 2.4.3. > > > > > > PatC > > > > > > -----Original Message----- > > > From: Charles Clancy [mailto:clancy@ltsnet.net] > > > Sent: Friday, August 01, 2008 2:38 AM > > > To: Pat Calhoun (pacalhou) > > > Cc: capwap@frascone.com; Pasi.Eronen@nokia.com > > > Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions > > > > > > Suggested text changes to address the comments: > > > > > > Replace this 2.4.1 text: > > > > > > DTLS, as specified, provides its own retransmit timers with an > > > exponential back-off. However, DTLS will never terminate the > > > handshake due to non-responsiveness; instead, DTLS will > > continue > > > to > > > increase its back-off timer period. Hence, timing out > > incomplete > > > DTLS handshakes is entirely the responsibility of the CAPWAP > > > module. > > > > > > with this text: > > > > > > DTLS, as specified, provides its own retransmit timers with an > > > exponential back-off. [RFC4347] does not specify how long > > > retransmissions should continue. Consequently, timing out > > > incomplete > > > DTLS handshakes is entirely the responsibility of the CAPWAP > > > module. > > > > > > I'm not sure what needs to be addressed in 2.4.3. Pasi -- > > can you be > > > more specific? > > > > > > -- > > > Dr. Charles Clancy www.ltsnet.net/~clancy > > > Senior Researcher, Laboratory for Telecommunications Sciences > > > > > > > > > Pat Calhoun (pacalhou) wrote: > > > > Pasi's comment was: > > > > > > > > Section 2.4.1: "DTLS will never terminate the > handshake due to > > > > non-responsiveness; instead, DTLS will continue to > > > > increase its back-off timer period" While RFC 4347 > > > doesn't specify > > > > how > > > > long you should continue retransmitting, the > > > > intent certainly was not to continue indefinitely. > > > > > > > > Section 2.4.3 text about DTLS retransmissions is slightly > > > inaccurate; > > > > DTLS handshake isn't strictly request/response, > > > > and both parties (not just the DTLS client) retransmit > > based on > > > > timers > > > > (in some situations). > > > > > > > > It is unclear to me as to whether these are simply > > observations, or > > > > request for change. That said, I would like either Charles > > > or Scott to > > > > > > > reply. > > > > > > > > PatC > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/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 Aug 18 12:10:51 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7044028C1CC for ; Mon, 18 Aug 2008 12:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.563 X-Spam-Level: X-Spam-Status: No, score=-4.563 tagged_above=-999 required=5 tests=[AWL=-0.964, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tguVKi02T0AH for ; Mon, 18 Aug 2008 12:10:47 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 65FC628C1D7 for ; Mon, 18 Aug 2008 12:10:47 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E23C51C41012 for ; Mon, 18 Aug 2008 12:10:54 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 40C17440126 for ; Mon, 18 Aug 2008 12:10:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 31C37361001E for ; Mon, 18 Aug 2008 12:10:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 866793610023 for ; Mon, 18 Aug 2008 12:10:47 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.105.134 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 18 Aug 2008 12:10:47 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7IJ9P4x022389; Mon, 18 Aug 2008 14:10:18 -0500 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 22:09:51 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 22:09:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Aug 2008 22:09:41 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720161CBD7@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A206459987@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 158: Allocation of WBIDs Thread-Index: AcjxWPPBckiC/dIYR2+hBkqFhpAT4wACFMvQAEz5BoACvg95oAD18uPA References: <4FF84B0BC277FF45AA27FE969DD956A2062CB02E@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB72013BA8AA@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20632FD58@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A206459987@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 18 Aug 2008 19:09:39.0673 (UTC) FILETIME=[F6900C90:01C90165] X-Nokia-AV: Clean Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 158: Allocation of WBIDs X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Not an objection, but note the following text in RFC 5226: "The required documentation and review criteria for use by the Designated Expert should be provided when defining the registry. (In particular, the WBID field is only 5 bits, so it's not an infinite supply -- especially if new 802.11xx features may require new WBIDs, as was suggested in discussion around issue 171.) Best regards, Pasi > -----Original Message----- > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: 14 August, 2008 00:43 > To: Pat Calhoun (pacalhou); Eronen Pasi (Nokia-NRC/Helsinki); > margaret@thingmagic.com > Cc: capwap@frascone.com > Subject: RE: [Capwap] Issue 158: Allocation of WBIDs > > Folks, in order to move this one along, I would recommend that we > change the current IANA considerations from Standards Action to > Expert Review. This would alleviate many of the issues brought up > for both the WBID, the message element and the EPCGlobal WBID > allocation. > > Objections? > > PatC > > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Wednesday, July 30, 2008 3:42 PM > To: Pasi.Eronen@nokia.com; margaret@thingmagic.com > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 158: Allocation of WBIDs > > Correct, Pasi. The current IANA classification requires a Standards > track RFC for assignment of WBIDs (and every other namespace in the > document). I suspect that if EPCGlobal is using their own Enterprise > Number for control message types, then it is less of an > issue. However, > the message element types are still global, and therefore > unless you are > using the vendor specific message element, you would need an RFC. > > So what I'm hearing is remove 802.16, and keep 802.11 and > EPCGlobal. We > just need to work out the details of the IANA classification. > > PatC > > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Tuesday, July 29, 2008 2:59 AM > To: margaret@thingmagic.com; Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 158: Allocation of WBIDs > > > Ok -- but if the intent is to allow CAPWAP bindings (and > possibly other > types of CAPWAP specifications) to be developed outside IETF Standards > Track, then the IANA instructions need to be something else than > "Standards Action". > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Margaret Wasserman [mailto:margaret@thingmagic.com] > > Sent: 29 July, 2008 11:55 > > To: Pat Calhoun > > Cc: capwap@frascone.com; Eronen Pasi (Nokia-NRC/Helsinki) > > Subject: Re: [Capwap] Issue 158: Allocation of WBIDs > > > > > > > > Frankly, I don't care much whether we adopt this proposed > > change. The > > > IEEE 802.11 binding specification does not include the > WBID value, > > > so a change would be required for that specification. The bigger > > change, I > > > suspect, is on the EPCGlobal spec. Of particular note, the > > CAPWAP spec > > > currently requires a Standards Action to allocate one of these > > > numbers, and since the RFID CAPWAP specification is being > published > > > by EPCGlobal, and not the IETF, I'm not sure how they could get a > > > number assigned. > > > Margaret, you are closer to this than I am, so do you have any > > > recommendations? > > > > (Wearing my EPCglobal hat) > > > > The EPCglobal Discovery Configuration and Initialization (DCI) > > specification defines a CAPWAP binding for RFID readers. > It is very > > nearly complete after ~1-1/2 years of work. EPCglobal requires > > interoperability testing before they will ratify a > standard, and that > > testing was completed last week. Final ratification of the > EPCglobal > > standard is now blocked on getting an RFC number for CAPWAP. > > EPCglobal doesn't have any plans to publish DCI as an IETF > standards > > track document. > > > > The work in EPCglobal was done based on the CAPWAP WG's > agreement to > > assign an binding ID for that purpose in the CAPWAP spec. While I > > agree that further binding IDs need to be defined in their > bindings, I > > > think it would be pretty late to change the agreement with > EPCglobal > > now. > > > > > Finally, removing the IEEE 802.16 from the list is not a problem, > > > and I agree that if there is ever a specification that > defines the > > > use of CAPWAP for 802.16, then the number would be > assigned at that > > > time. > > > > That would be fine with me, as the 802.16 binding doesn't exist, > > AFAIK. > > > > Margaret > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Aug 18 12:30:22 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28BDB3A6D7F for ; Mon, 18 Aug 2008 12:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.226 X-Spam-Level: X-Spam-Status: No, score=-4.226 tagged_above=-999 required=5 tests=[AWL=-1.227, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yk7jru2tGcoq for ; Mon, 18 Aug 2008 12:30:20 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id E5BEE28C1C3 for ; Mon, 18 Aug 2008 12:30:20 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0F3EB1C40F64 for ; Mon, 18 Aug 2008 12:30:20 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id C92384400C3 for ; Mon, 18 Aug 2008 12:30:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 96988361001E for ; Mon, 18 Aug 2008 12:30:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id AAF72361000C for ; Mon, 18 Aug 2008 12:30:10 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.122.230 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 18 Aug 2008 12:30:10 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7IJTf0a000616; Mon, 18 Aug 2008 22:30:04 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 22:29:59 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 22:29:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Aug 2008 22:29:52 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720161CBE8@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2064598B4@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Last call comments for capwap-protocol-binding-ieee80211-07 Thread-Index: AcjxWvvYp8NTYNntQ6KnjwjYAMoZswBPfGhwAY62tJAABD6gUAIgXFOg References: <1696498986EFEC4D9153717DA325CB72013BA889@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20632FDC3@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C62A7@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064598B4@xmb-sjc-235.amer.cisco.com> From: To: X-OriginalArrivalTime: 18 Aug 2008 19:29:55.0462 (UTC) FILETIME=[CB3ABA60:01C90168] X-Nokia-AV: Clean Cc: capwap@frascone.com Subject: Re: [Capwap] Last call comments for capwap-protocol-binding-ieee80211-07 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun wrote: > > > > 802.11 header has 4 different addresses, all of which can be > > > > different. When doing split MAC with 802.3 frames, the 802.3 > > > > frame > > > > contains only two of the addresses; the "Radio MAC Address" > > > > field in CAPWAP header contains the third -- but what about the > > > > fourth one? > > > > > The CAPWAP WG only supports 802.11-2007, and does not > > > support ad-hoc > > > mode (client-client). The very fact that we are providing an > > > alternative way to deploy 802.11 infrastructure means that do not > > > need > > > to support ad hoc mode ;-) > > > > I wasn't thinking about ad-hoc mode, but rather a STA sending a > > packet to an AP where the 802.3 source address would be different > > from the transmitting STA address. Is this possible? (Perhaps a > > "wireless Ethernet bridge", which connects to PC via wired > > Ethernet, but looks like STA to the AP? Although I'm not quite > > sure how the address fields really look in this situation...) > > Yes, you are correct that bridges work this way, but this is not a > use case we are trying to address in this working group. An access > point uses the IEEE 802.11 primitives for populating its learning > table (e.g., association request), while a bridge needs to use other > means (e.g., spanning tree). Trying to add wireless bridges to this > specification would not only expand the scope of the WG and > protocol, but would require lots more work. Large bridges are indeed different, but small "wireless bridges" are marketed for e.g. connecting a printer with wired Ethernet jack to office WLAN. Does this mean if the office WLAN switches to CAPWAP-based access points, and uses split MAC with 802.3 frames, those would stop working? (I don't think there's a need to expand the scope of the WG -- accurately documenting what parts of 802.11 don't 100% work with CAPWAP is IMHO quite sufficient.) > > > > The document should have some more text about how the WTP > > > > processes > > > > IEEE 802.11 IEs it receives from the AC. Section 6.6 > > > > talks about > > > > copying them to Beacon/Probe Response messages, but it > > > > seems that in > > > > some cases, the WTP also does some local processing. (I was > > > > sort of > > > > expecting a list of all IEs, and description of expected WTP > > > > processing (possibly none) for them.) > > > > > There are two mode of operation: > > > 1. Split MAC. In this case, the WTP needs to make sure that the > > > beacons have the proper information. Other than that,the > > > AC handles > > > all of the IEs in the manner described in the 802.11-2007 > > > standard. > > > > This is contradicted by text in e.g. Section 6.15, which requires > > the WTP to process (beyond copying to beacons) the IE received > > from AC even in Split MAC mode. > > OK, fair enough. That is one exception, but that one is > described in the spec. The spec even includes: > > > 2.2.1. Split MAC > [...] > > o The WTP generates the IEEE 802.11 Beacon frames, using > information > provided to it through the IEEE 802.11 Add WLAN (see > Section 6.1) > message element, including the RSNIE, which indicates support of > 802.1X and AES-CCMP. > Yes, but the spec isn't very clear on how the RSN IE exactly is processed by the WTP (the IE has number of different fields). > > Also, it seems that some of the IEs sent are not even included in > > beacons; e.g. Section 6.1 says the AC MUST send the Power > > Capability IE to the WTP -- but reading 802.11, I can't seem to > > find any place the AP would actually send this IE (it's sent by > > the STA). So what does the WTP do with it? > > OK, that should have been Power Constraint, not Power > Capability. Thanks for finding that one. Ok, that clarifies this part... > > > 2. Local MAC. In this case, the 802.11 management packets are > > > processed in the WTP, as described 2.2.2. In this case, the WTP > > > handles the IEs in the manner described in the > > > 802.11-2007 standard. > > > > Right, 802.11-2007 specifies how the WTP processes IEs received from > > the STA. But it doesn't specify how to process IEs received from AC > > (obviously, since the concept of AC doesn't exist). > > Actually, re-reading the spec, I don't see where it dictates that > the WTP needs to process IEs. It does mention that the WTP needs to > look at the Result-Code in the (re-)Association Response. It also > does mention that the AC MAY send a Disassocation Request to the > station, through the WTP, and that the WTP should take the > Disassocation Request as an indication that service for the station > is to be terminated. > > Otherwise, there are no IE processing requirements. Again, except for the RSN IE, whose processing is mentioned, but not described in detail. Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 18 13:09:53 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A17D3A6852 for ; Mon, 18 Aug 2008 13:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.48 X-Spam-Level: X-Spam-Status: No, score=-4.48 tagged_above=-999 required=5 tests=[AWL=-0.881, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IL5Xp9OCDEKH for ; Mon, 18 Aug 2008 13:09:52 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 365683A6AE3 for ; Mon, 18 Aug 2008 13:09:52 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A9955439FB2 for ; Mon, 18 Aug 2008 13:09:59 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 284D044011F for ; Mon, 18 Aug 2008 13:09:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 18C3734AC00A for ; Mon, 18 Aug 2008 13:09:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2C01B34AC014 for ; Mon, 18 Aug 2008 13:09:50 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.122.230 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 18 Aug 2008 13:09:49 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7IK9cEm007218; Mon, 18 Aug 2008 23:09:44 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 23:09:38 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 23:09:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Aug 2008 23:09:34 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720161CC1B@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A206459CDF@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 171: Pasi nits on binding spec Thread-Index: AcjzL5wHOa8wpdqYQUmSlvTmZmTg1QFnnI4QAAUEOaAAGNrSwAEJI2JQADKYLFAAzSR4AA== References: <4FF84B0BC277FF45AA27FE969DD956A20633000B@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB72014C629F@vaebe104.NOE.Nokia.com><4FF84B0BC277FF45AA27FE969DD956A2063E6823@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB720150BDF9@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20645989D@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A206459CDF@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 18 Aug 2008 20:09:36.0057 (UTC) FILETIME=[562CB290:01C9016E] X-Nokia-AV: Clean Subject: Re: [Capwap] Issue 171: Pasi nits on binding spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun wrote: > > I can't find any mention of "WMM Information Element" in IEEE > > 802.11-2007 -- I assumed it's some extension that not everyone > implements? > > Yup - my bad. Now include a reference to the WMM web page on > www.wi-fi.org. So the current binding isn't just IEEE Std 802.11-2007, but 802.11-2007 plus some Wi-Fi Alliance spec? (That OK with me, but really needs to be said in the introduction section.) > > BTW, how are you planning to update these rules without breaking > > backwards compatibility? > > There are a couple of ways, but the most obvious one would be to have > the next binding use a new Wireless Binding Identifier (WBID). With a 5-bit WBID field, and lots of activity in the 802.11xy/16xy space, this could mean running out of WBIDs... > > In this case, it seems both "Update Station QoS" and "WTP Quality of > > Service" message elements apply to same packets -- how do > > they interact? > > I have added addition verbage to make this clearer: > > > 6.20. IEEE 802.11 Update Station QoS > > The IEEE 802.11 Update Station QoS message element is used to > change the Quality of Service policy on the WTP for a given > station. The QoS tags included in this message element are to be > applied to packets received at the WTP from the station indicated > through the MAC Address field. This message element overrides > the default values provided through the IEEE 802.11 WTP Quality > of Service message element (see Section 6.22. Any tagging > performed by the WTP MUST be directly applied to the packets > receive from the station, as well as the CAPWAP tunnel, if the > packets are tunneled to the AC. I think the tagging text still needs some details. Is the intent something like this? 1. If doing split MAC with native frame tunnel mode (instead of 802.3): replace the TID subfield of the packet with the "802.1p Tag" value (except if 'C' bit in IEEE 802.11 Station Session Key message element is set) 2. If doing local MAC: if the WTP adds an 802.1Q header for VLAN use (based on VLAN Name in the Add Station message element), place the "802.1p Tag" value in the 802.1Q header. 3. If doing split MAC: if the WTP adds an 802.1Q header for VLAN use (based on e.g. some local configuration), place the "802.1p Tag" value in the 802.1Q header. 4. If the packet received from the STA is an IPv4 or IPv6 packet, replace the DSCP field in the IP header with the "DSCP Tag" value (except if 'C' bit is set) 5. For split MAC, place the "DSCP Tag" value in the IP header added by the WTP for CAPWAP Data message. Note that here step 1 seems unnecessary -- replacing the TID before the AC sees it doesn't seem to add value -- and step 4 is very likely to raise questions in IESG review (as it overwrites the DSCP tagging done by the STA). (But perhaps I understood this wrong, and some other processing was intended?) > > [...] > > 6.22. IEEE 802.11 WTP Quality of Service > > The IEEE 802.11 WTP Quality of Service message element > value is sent > by the AC to the WTP to communicate quality of service > configuration > information. The QoS tag included in this message element are the > default QoS values to be applied to packets received by > the WTP from > stations on a particular radio. Any tagging performed by the WTP > MUST be directly applied to the packets receive from the > station, as > well as the CAPWAP tunnel, if the packets are tunneled to the AC. > Same ambiguity here; perhaps instead of repeating the detail, a pointer to 6.20 woul be sufficient. > > I'm also slightly surprised to see the WTP modifying the contents > > of IP packets here -- I thought it was acting as Layer 2 device > > for user plane traffic (not making any assumptions about the Layer > > 3 protocol carried in 802.3 frames). At the very least, the text > > should probably say the DSCP Tag applies only to packets with > > certain values in the 802.3 Type field. > > OK, I can modify the text to specifically read: > > DSCP Tag: The 6 bit DSCP label to use if packets are > eligible to be DSCP tagged (see [RFC2474]). > IMHO it would be clearer to say "if the packet received from the STA is an IPv4 or IPv6 packet" (if that's what's meant by "eligible to be DSCP Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 18 14:49:29 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E055A3A68F1 for ; Mon, 18 Aug 2008 14:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gwgx09WQy+su for ; Mon, 18 Aug 2008 14:49:28 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 90A9F3A68D2 for ; Mon, 18 Aug 2008 14:49:28 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 33F6E17519AC for ; Mon, 18 Aug 2008 14:49:21 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 38582440123 for ; Mon, 18 Aug 2008 14:49:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 279D734AC0B7 for ; Mon, 18 Aug 2008 14:49:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id EE07934AC0B2 for ; Mon, 18 Aug 2008 14:49:11 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 18 Aug 2008 14:49:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,230,1217808000"; d="scan'208";a="141700701" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 18 Aug 2008 21:49:07 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7ILn7dL020056; Mon, 18 Aug 2008 14:49:07 -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.13.8/8.13.8) with ESMTP id m7ILn71p029702; Mon, 18 Aug 2008 21:49:07 GMT 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.1830); Mon, 18 Aug 2008 14:49:07 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Aug 2008 14:49:06 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2064B776A@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB720161CBD7@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 158: Allocation of WBIDs Thread-Index: AcjxWPPBckiC/dIYR2+hBkqFhpAT4wACFMvQAEz5BoACvg95oAD18uPAAAWrPfA= References: <4FF84B0BC277FF45AA27FE969DD956A2062CB02E@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB72013BA8AA@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20632FD58@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A206459987@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720161CBD7@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 18 Aug 2008 21:49:07.0527 (UTC) FILETIME=[3D72B570:01C9017C] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 158: Allocation of WBIDs X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Yes, I agree we need to provide some guidance. I would recommend the following text added to the end of section 15. Note that I have crafted the wording very carefully because unlike other standards, the CAPWAP protocol will be used by other SDOs, who have policies that do not allow for the public sharing of their documents. The IEEE is one such example where some standards are available for free, but others are not. EPCGlobal and the WiFi Alliance does not make their documents available to non-members. 15. IANA Considerations [...] For registration requests where an Expert Review is required, a Designated Expert should be consulted, which is appointed by the responsible IESG area director. The intention is that any allocation will be accompanied by a published RFC, but given that other SDOs may want to create standards built on top of CAPWAP, a document the Designated Expert can review is also acceptable. IANA should allow for allocation of values prior to documents being approved for publication, so the Designated Expert can approve allocations once it seems clear that publication will occur. The Designated expert will post a request to the CAPWAP WG mailing list (or a successor designated by the Area Director) for comment and review. Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request and publish a notice of the decision to the CAPWAP WG mailing list or its successor, as well as informing IANA. A denial notice must be justified by an explanation, and in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable should be provided. PatC -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Monday, August 18, 2008 12:10 PM To: Pat Calhoun (pacalhou); margaret@thingmagic.com Cc: capwap@frascone.com Subject: RE: [Capwap] Issue 158: Allocation of WBIDs Not an objection, but note the following text in RFC 5226: "The required documentation and review criteria for use by the Designated Expert should be provided when defining the registry. (In particular, the WBID field is only 5 bits, so it's not an infinite supply -- especially if new 802.11xx features may require new WBIDs, as was suggested in discussion around issue 171.) Best regards, Pasi > -----Original Message----- > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: 14 August, 2008 00:43 > To: Pat Calhoun (pacalhou); Eronen Pasi (Nokia-NRC/Helsinki); > margaret@thingmagic.com > Cc: capwap@frascone.com > Subject: RE: [Capwap] Issue 158: Allocation of WBIDs > > Folks, in order to move this one along, I would recommend that we > change the current IANA considerations from Standards Action to Expert > Review. This would alleviate many of the issues brought up for both > the WBID, the message element and the EPCGlobal WBID allocation. > > Objections? > > PatC > > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Wednesday, July 30, 2008 3:42 PM > To: Pasi.Eronen@nokia.com; margaret@thingmagic.com > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 158: Allocation of WBIDs > > Correct, Pasi. The current IANA classification requires a Standards > track RFC for assignment of WBIDs (and every other namespace in the > document). I suspect that if EPCGlobal is using their own Enterprise > Number for control message types, then it is less of an issue. > However, the message element types are still global, and therefore > unless you are using the vendor specific message element, you would > need an RFC. > > So what I'm hearing is remove 802.16, and keep 802.11 and EPCGlobal. > We just need to work out the details of the IANA classification. > > PatC > > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Tuesday, July 29, 2008 2:59 AM > To: margaret@thingmagic.com; Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 158: Allocation of WBIDs > > > Ok -- but if the intent is to allow CAPWAP bindings (and possibly > other types of CAPWAP specifications) to be developed outside IETF > Standards Track, then the IANA instructions need to be something else > than "Standards Action". > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Margaret Wasserman [mailto:margaret@thingmagic.com] > > Sent: 29 July, 2008 11:55 > > To: Pat Calhoun > > Cc: capwap@frascone.com; Eronen Pasi (Nokia-NRC/Helsinki) > > Subject: Re: [Capwap] Issue 158: Allocation of WBIDs > > > > > > > > Frankly, I don't care much whether we adopt this proposed > > change. The > > > IEEE 802.11 binding specification does not include the > WBID value, > > > so a change would be required for that specification. The bigger > > change, I > > > suspect, is on the EPCGlobal spec. Of particular note, the > > CAPWAP spec > > > currently requires a Standards Action to allocate one of these > > > numbers, and since the RFID CAPWAP specification is being > published > > > by EPCGlobal, and not the IETF, I'm not sure how they could get a > > > number assigned. > > > Margaret, you are closer to this than I am, so do you have any > > > recommendations? > > > > (Wearing my EPCglobal hat) > > > > The EPCglobal Discovery Configuration and Initialization (DCI) > > specification defines a CAPWAP binding for RFID readers. > It is very > > nearly complete after ~1-1/2 years of work. EPCglobal requires > > interoperability testing before they will ratify a > standard, and that > > testing was completed last week. Final ratification of the > EPCglobal > > standard is now blocked on getting an RFC number for CAPWAP. > > EPCglobal doesn't have any plans to publish DCI as an IETF > standards > > track document. > > > > The work in EPCglobal was done based on the CAPWAP WG's > agreement to > > assign an binding ID for that purpose in the CAPWAP spec. While I > > agree that further binding IDs need to be defined in their > bindings, I > > > think it would be pretty late to change the agreement with > EPCglobal > > now. > > > > > Finally, removing the IEEE 802.16 from the list is not a problem, > > > and I agree that if there is ever a specification that > defines the > > > use of CAPWAP for 802.16, then the number would be > assigned at that > > > time. > > > > That would be fine with me, as the 802.16 binding doesn't exist, > > AFAIK. > > > > Margaret > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Aug 19 01:55:45 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94EAE3A67D1 for ; Tue, 19 Aug 2008 01:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.471 X-Spam-Level: X-Spam-Status: No, score=-4.471 tagged_above=-999 required=5 tests=[AWL=-0.872, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwT40Jo5K7lm for ; Tue, 19 Aug 2008 01:55:44 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 127C03A6818 for ; Tue, 19 Aug 2008 01:55:44 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1B9F6430E8B for ; Tue, 19 Aug 2008 01:54:54 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 2F54C440128 for ; Tue, 19 Aug 2008 01:54:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0516A34AC024 for ; Tue, 19 Aug 2008 01:54:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0A3D134AC020 for ; Tue, 19 Aug 2008 01:54:46 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.105.134 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 19 Aug 2008 01:54:45 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7J8sdnv029799; Tue, 19 Aug 2008 03:54:40 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 11:54:26 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 11:54:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 11:54:25 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720161CEB2@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2064B776A@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 158: Allocation of WBIDs Thread-Index: AcjxWPPBckiC/dIYR2+hBkqFhpAT4wACFMvQAEz5BoACvg95oAD18uPAAAWrPfAAFxvmgA== References: <4FF84B0BC277FF45AA27FE969DD956A2062CB02E@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB72013BA8AA@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20632FD58@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A206459987@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720161CBD7@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064B776A@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 19 Aug 2008 08:54:26.0031 (UTC) FILETIME=[2EBB07F0:01C901D9] X-Nokia-AV: Clean Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 158: Allocation of WBIDs X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Looks good, but it still doesn't provide much guidance about what kinds of requests should be approved. If a request comes from a group calling itself an "SDO", and a reasonably well-written technical specification is available, should it be granted? RFC 5226 says that "presumption should be that a code point should be granted, unless there is a compelling reason to the contrary", but then continues to list scarcity of code points as one reason to change this. At least some bit fields and WBIDs look like a very scarce resource to me (and BTW, if there wasn't the concern about backward compatibility, I'd recommend changing WBIDs to 16 bits, and enlarging some other fields, too). Best regards, Pasi > -----Original Message----- > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: 19 August, 2008 00:49 > To: Eronen Pasi (Nokia-NRC/Helsinki); margaret@thingmagic.com > Cc: capwap@frascone.com > Subject: RE: [Capwap] Issue 158: Allocation of WBIDs > > Yes, I agree we need to provide some guidance. > > I would recommend the following text added to the end of section 15. > Note that I have crafted the wording very carefully because > unlike other > standards, the CAPWAP protocol will be used by other SDOs, who have > policies that do not allow for the public sharing of their documents. > The IEEE is one such example where some standards are available for > free, but others are not. EPCGlobal and the WiFi Alliance > does not make > their documents available to non-members. > > > 15. IANA Considerations > [...] > For registration requests where an Expert Review is required, a > Designated Expert should be consulted, which is appointed by the > responsible IESG area director. The intention is that any > allocation > will be accompanied by a published RFC, but given that > other SDOs may > want to create standards built on top of CAPWAP, a document the > Designated Expert can review is also acceptable. IANA should allow > for allocation of values prior to documents being approved for > publication, so the Designated Expert can approve > allocations once it > seems clear that publication will occur. The Designated > expert will > post a request to the CAPWAP WG mailing list (or a successor > designated by the Area Director) for comment and review. Before a > period of 30 days has passed, the Designated Expert will either > approve or deny the registration request and publish a > notice of the > decision to the CAPWAP WG mailing list or its successor, as well as > informing IANA. A denial notice must be justified by an > explanation, > and in the cases where it is possible, concrete suggestions on how > the request can be modified so as to become acceptable should be > provided. > > > PatC > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Monday, August 18, 2008 12:10 PM > To: Pat Calhoun (pacalhou); margaret@thingmagic.com > Cc: capwap@frascone.com > Subject: RE: [Capwap] Issue 158: Allocation of WBIDs > > Not an objection, but note the following text in RFC 5226: > > "The required documentation and review criteria for use by the > Designated Expert should be provided when defining the registry. > > (In particular, the WBID field is only 5 bits, so it's not an infinite > supply -- especially if new 802.11xx features may require new > WBIDs, as > was suggested in discussion around issue 171.) > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: 14 August, 2008 00:43 > > To: Pat Calhoun (pacalhou); Eronen Pasi (Nokia-NRC/Helsinki); > > margaret@thingmagic.com > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Issue 158: Allocation of WBIDs > > > > Folks, in order to move this one along, I would recommend that we > > change the current IANA considerations from Standards > Action to Expert > > > Review. This would alleviate many of the issues brought up > for both > > the WBID, the message element and the EPCGlobal WBID allocation. > > > > Objections? > > > > PatC > > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) > > Sent: Wednesday, July 30, 2008 3:42 PM > > To: Pasi.Eronen@nokia.com; margaret@thingmagic.com > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 158: Allocation of WBIDs > > > > Correct, Pasi. The current IANA classification requires a Standards > > track RFC for assignment of WBIDs (and every other namespace in the > > document). I suspect that if EPCGlobal is using their own > Enterprise > > Number for control message types, then it is less of an issue. > > However, the message element types are still global, and therefore > > unless you are using the vendor specific message element, you would > > need an RFC. > > > > So what I'm hearing is remove 802.16, and keep 802.11 and > EPCGlobal. > > We just need to work out the details of the IANA classification. > > > > PatC > > > > -----Original Message----- > > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > > Sent: Tuesday, July 29, 2008 2:59 AM > > To: margaret@thingmagic.com; Pat Calhoun (pacalhou) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 158: Allocation of WBIDs > > > > > > Ok -- but if the intent is to allow CAPWAP bindings (and possibly > > other types of CAPWAP specifications) to be developed outside IETF > > Standards Track, then the IANA instructions need to be > something else > > than "Standards Action". > > > > Best regards, > > Pasi > > > > > -----Original Message----- > > > From: ext Margaret Wasserman [mailto:margaret@thingmagic.com] > > > Sent: 29 July, 2008 11:55 > > > To: Pat Calhoun > > > Cc: capwap@frascone.com; Eronen Pasi (Nokia-NRC/Helsinki) > > > Subject: Re: [Capwap] Issue 158: Allocation of WBIDs > > > > > > > > > > > Frankly, I don't care much whether we adopt this proposed > > > change. The > > > > IEEE 802.11 binding specification does not include the > > WBID value, > > > > so a change would be required for that specification. The bigger > > > change, I > > > > suspect, is on the EPCGlobal spec. Of particular note, the > > > CAPWAP spec > > > > currently requires a Standards Action to allocate one of these > > > > numbers, and since the RFID CAPWAP specification is being > > published > > > > by EPCGlobal, and not the IETF, I'm not sure how they > could get a > > > > number assigned. > > > > Margaret, you are closer to this than I am, so do you have any > > > > recommendations? > > > > > > (Wearing my EPCglobal hat) > > > > > > The EPCglobal Discovery Configuration and Initialization (DCI) > > > specification defines a CAPWAP binding for RFID readers. > > It is very > > > nearly complete after ~1-1/2 years of work. EPCglobal requires > > > interoperability testing before they will ratify a > > standard, and that > > > testing was completed last week. Final ratification of the > > EPCglobal > > > standard is now blocked on getting an RFC number for CAPWAP. > > > EPCglobal doesn't have any plans to publish DCI as an IETF > > standards > > > track document. > > > > > > The work in EPCglobal was done based on the CAPWAP WG's > > agreement to > > > assign an binding ID for that purpose in the CAPWAP spec. > While I > > > agree that further binding IDs need to be defined in their > > bindings, I > > > > > think it would be pretty late to change the agreement with > > EPCglobal > > > now. > > > > > > > Finally, removing the IEEE 802.16 from the list is not > a problem, > > > > and I agree that if there is ever a specification that > > defines the > > > > use of CAPWAP for 802.16, then the number would be > > assigned at that > > > > time. > > > > > > That would be fine with me, as the 802.16 binding doesn't exist, > > > AFAIK. > > > > > > Margaret > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Aug 19 02:30:48 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 051F03A69FB for ; Tue, 19 Aug 2008 02:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.442 X-Spam-Level: X-Spam-Status: No, score=-4.442 tagged_above=-999 required=5 tests=[AWL=-0.843, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96NewTNLLYsw for ; Tue, 19 Aug 2008 02:30:46 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id E62333A69CF for ; Tue, 19 Aug 2008 02:30:46 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7C8BD4318E6 for ; Tue, 19 Aug 2008 02:30:27 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 5A780440128 for ; Tue, 19 Aug 2008 02:30:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id F40B834AC049 for ; Tue, 19 Aug 2008 02:30:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id BB83834AC03F for ; Tue, 19 Aug 2008 02:30:15 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.122.230 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 19 Aug 2008 02:30:15 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7J9Tmwp008098; Tue, 19 Aug 2008 12:30:09 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 12:30:05 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 12:30:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 12:30:03 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720161CF0C@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2064598F1@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Recap of current pending issues Thread-Index: Acjz9xoEqCcXlGoTT6y9r7yIArdLFwDULppAAGVprtABKASH0AEXEvfA References: <4FF84B0BC277FF45AA27FE969DD956A2063304F7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A206393CCC@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C62AB@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064598F1@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 19 Aug 2008 09:30:00.0176 (UTC) FILETIME=[26C7B700:01C901DE] X-Nokia-AV: Clean Subject: Re: [Capwap] Recap of current pending issues X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun wrote: >> The answer (you can't have multiple outstanding requests) really >> needs to be in the spec. Also, the spec needs some more text about >> how the receiver processes them -- e.g. does the receiver maintain >> "last seen sequence number" counter, and silently drop (without >> replying) requests older than this? > > > I believe some of this was already covered, but I have added a new > sentence to the end of the first paragraph. I am including some > additional language that does address some of your concern that was > already in the spec: > > > 4.5.3. Retransmissions > > The CAPWAP control protocol operates as a reliable transport. > For each Request message, a Response message is defined, which is > used to acknowledge receipt of the Request message. In addition, > the control header Sequence Number field is used to pair the > Request and Response messages (see Section 4.5.1). This > Request/Response pair, combined with the Sequence Number, implies > that both the WTP and the AC can only have a single request > outstanding at any given time. Hmm... it doesn't really *imply* it. For example, IKEv2 has almost identical approach -- request/response pairs, sequence number, same way of doing retransmissions -- but does allow multiple outstanding requests (in some circumstances). Also, the definition of the Sequence Number field (4.5.1.2) says that "counter is monotonically incremented, ensuring that no two pending Request messages have the same Sequence Number" -- this sentence makes sense only if there can be more than one pending request. > Response messages are not explicitly acknowledged, therefore if a > Response message is not received, the original Request message is > retransmitted. Implementations MAY cache Response messages to > respond to a retransmitted Request messages with minimal local > processing. It isn't quite clear what the alternative to this "MAY" (what should an implementation that doesn't cache the Response message do). The most obvious answer would be to "process the message as usual and generate a reply", but unfortunately, that doesn't seem to work for all messages (for example, if the WTP processes retransmissions of Image Data Requests as normal requests, it seems the resulting image would be wrong). I'd suggest just making caching the Response message a MUST -- this would be the simplest solution, both specification-wise and implementation-wise. (A possible alternative might involve keeping a "Last Received Sequence Number" field, and specifying how to process the messages and generate a correct reply without really processing the message. Or making all Request messages idempotent. But those seem complex.) > Retransmitted Request messages MUST NOT be altered > by the sender. The sender MUST assume that the original Request > message was processed, but that the Response message was lost. I doubt any implementation would actually follow this "MUST assume". (E.g. if the AC is sending Image Data Requests, does it make sense to assume the WTP really received it, and move to the next image data block? Or if the Station Configuration Request isn't acknowledged, would the AC assume that station is now configured OK?) Also, the state machine says that if you reach the MaxRetransmit count without receiving a response, you move to DTLS Teardown state. In theory, you could abandon a Request for other reason that reaching the MaxRetransmit count (perhaps you changed your mind, and didn't want to do it anyway). But then you can't know whether the recipient received and processed it, leaving things is slightly indeterminate state. > Any alterations to the original Request message MUST have a new > Sequence Number, and be treated as a new Request message by the > receiver. Here's a suggestion based on my comments above: 4.5.3. Retransmissions The CAPWAP control protocol operates as a reliable transport. For each Request message, a Response message is defined, which is used to acknowledge receipt of the Request message. In addition, the control header Sequence Number field is used to pair the Request and Response messages (see Section 4.5.1). Response messages are not explicitly acknowledged, therefore if a Response message is not received, the original Request message is retransmitted. Implementations MUST keep track of the Sequence Number of the last received Request message, and MUST cache the corresponding Response message. If a retransmission with the same Sequence Number is received, the cached Response message MUST be retransmitted without re-processing the Request. If an older Request message (with smaller Sequence Number modulo 32) is received, it MUST be ignored. A newer Request message (with larger Sequence Number modulo 32) is processed as usual. Both the WTP and the AC can only have a single request outstanding at any given time. Retransmitted Request messages MUST NOT be altered by the sender. If the sender stops retransmitting a Request message before reaching MaxRetransmit retransmissions (which leads to transition to DTLS Teardown, as described in Section 2.3.1), it cannot know whether the recipient received and processed the Request or not. In most situations, the sender SHOULD NOT do this, and instead continue retransmitting until a Response message is received, or transition to DTLS Teardown occurs. However, if the sender does decide to continue the connection with a new or modified Request message, the new message MUST have a new Sequence Number, and be treated as a new Request message by the receiver. Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 19 02:42:53 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86C383A67E2 for ; Tue, 19 Aug 2008 02:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.415 X-Spam-Level: X-Spam-Status: No, score=-4.415 tagged_above=-999 required=5 tests=[AWL=-0.816, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaOFFaZavnKh for ; Tue, 19 Aug 2008 02:42:52 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id A24A23A6882 for ; Tue, 19 Aug 2008 02:42:52 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 86A05432016 for ; Tue, 19 Aug 2008 02:43:00 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 410AB440129 for ; Tue, 19 Aug 2008 02:42:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 14EFC34AC036 for ; Tue, 19 Aug 2008 02:42:55 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 663CD34AC02C for ; Tue, 19 Aug 2008 02:42:52 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.105.134 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 19 Aug 2008 02:42:52 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7J9g3FI012899; Tue, 19 Aug 2008 04:42:50 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 12:42:47 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 12:42:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 12:42:38 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720161CF38@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2064598C7@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 166: Various IANA Issues Thread-Index: AcjyfwiGWFFYbM34RwGLIXgw/+Uu9wGXDdqQASeRViABGTLZsA== References: <4FF84B0BC277FF45AA27FE969DD956A20632FC22@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C62A8@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064598C7@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 19 Aug 2008 09:42:33.0432 (UTC) FILETIME=[E7C17580:01C901DF] X-Nokia-AV: Clean Subject: Re: [Capwap] Issue 166: Various IANA Issues X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun wrote: > > > 15.10. AC Information Type > > > > > > The Information Type field in the AC Descriptor message element > > > (see Section 4.6.1) is used to represent information about the > > > AC. The namespace is 16 bits (0-65535), where the value of zero > > > (0) is reserved and must not be assigned. The values four (4) > > > and five (5) are allocated in this specification, and can be > > > found in Section 4.6.1. This namespace is managed by IANA and > > > assignments require a Standards Action. IANA will create the AC > > > Information Type registry, whose format is: > > > > > > AC Information Type Type Value Reference > > > > Is the intent to have something similar as for CAPWAP Message > > Types (IANA manages registry for Enterprise Number 0; other > > Enterprise Numbers are not controlled via IANA?) > > > > Or is the AC Information Type independent of the AC Information > > Vendor Identifier? (in that case, I'd expect vendors would want to > > include vendor-specific information, and Standards Action perhaps > > isn't the optimal policy.) > > > > Currently, any vendor (or SDO) can define their own message elements > through the vendor specific message element. This message element > allows the vendor (or SDO) to include their Enterprise Code, and > they can manage their own message element namespace. This didn't really answer my question. Which of the following is meant by this section and Section 4.6.1? - The AC Descriptor message element MUST always contain exactly one Sub-Element with "AC Information Vendor Identifier"=0/"AC Information Type"=4, exactly one Sub-Element with Vendor=0/Type=5, MAY contain other Sub-Elements. (In this case, saying that the contents are "vendor specific" is a bit strange, since the message doesn't tell who the vendor is. Perhaps "printable UTF-8 string intended for the administator" or something was intended?) - The AC Descriptor message element MUST always contain exactly one Sub-Element with "AC Information Vendor Identifier"=SOMEV/ "AC Information Type"=4, exactly one Sub-Element with Vendor=SOMEV/ Type=5, and MAY contain other Sub-Elements. (BTW -- this same question seems to apply to WTP Board Data message element as well.) Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 19 02:47:10 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED1283A6A03 for ; Tue, 19 Aug 2008 02:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.39 X-Spam-Level: X-Spam-Status: No, score=-4.39 tagged_above=-999 required=5 tests=[AWL=-0.791, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1h3eQnKHq4Zp for ; Tue, 19 Aug 2008 02:47:08 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id D65C83A696F for ; Tue, 19 Aug 2008 02:47:08 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4A289432262 for ; Tue, 19 Aug 2008 02:46:50 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 44DF8440129 for ; Tue, 19 Aug 2008 02:46:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 1E1FC34AC031 for ; Tue, 19 Aug 2008 02:46:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 186C534AC036 for ; Tue, 19 Aug 2008 02:46:41 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.122.233 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 19 Aug 2008 02:46:40 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7J9kMdI024934; Tue, 19 Aug 2008 12:46:29 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 12:46:15 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 12:46:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 12:46:13 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720161CF43@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A206459CFA@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Recap of current pending issues Thread-Index: Acjz9xoEqCcXlGoTT6y9r7yIArdLFwDULppAAbsS+0AA6va/wA== References: <4FF84B0BC277FF45AA27FE969DD956A2063304F7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A206393CCC@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A206459CFA@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 19 Aug 2008 09:46:07.0293 (UTC) FILETIME=[673A0ED0:01C901E0] X-Nokia-AV: Clean Subject: Re: [Capwap] Recap of current pending issues X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun wrote: > All, > > We are now a little over a week past the IETF Last Call, and some > progress has been made, so I wanted to provide an update on the > latest issues. As you can see below, if there are no comments on any > of the issues below, I will publish the new text on 8/18, which will > include all of the issues identified through the IETF Last > Call. This draft will be ready to move to the IESG for publication. > > ISSUES WAITING FOR PASI's REVIEW > > Issue 159 (Question on CAPWAP control protocol). I have provided some > updated text to address Pasi's issues. I am waiting for his review. I replied earlier today, suggesting some text. > Issue 166 (Various IANA Issues). Pasi had comments on my new IANA > text, and identified some real problems which I believe are now all > addressed. I am waiting to hear from him on the latest. Also, replied earlier today -- there's still one item left that needs clarification one way or another. > Issue 168 (DTLS and Retransmissions). I believe we are closed on > this. Scott has proposed new text, and I am waiting to hear from > Pasi if he is comfortable with the new text. Based on emails yesterday, it seemed we converged on text. > Issue 171 (Pasi nits on binding spec). We are now in the fourth round > trip, and I believe we are nearing the end. Waiting for Pasi to review > the latest. Yes, replied yesterday -- some clarifications are IMHO still needed. Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 19 07:55:49 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBEA33A6B90 for ; Tue, 19 Aug 2008 07:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FUZZY_CPILL=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ho7zf+K5PkyA for ; Tue, 19 Aug 2008 07:55:48 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 09D763A6BC5 for ; Tue, 19 Aug 2008 07:55:44 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E10901C40FCA for ; Tue, 19 Aug 2008 07:55:10 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 7E60B44012C for ; Tue, 19 Aug 2008 07:55:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 360843628054 for ; Tue, 19 Aug 2008 07:54:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 9561934AC18D for ; Tue, 19 Aug 2008 07:25:59 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 19 Aug 2008 07:25:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,235,1217808000"; d="scan'208";a="142223772" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 19 Aug 2008 14:25:59 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7JEPxHj025149; Tue, 19 Aug 2008 07:25:59 -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.13.8/8.13.8) with ESMTP id m7JEPxhV013462; Tue, 19 Aug 2008 14:25:59 GMT 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.1830); Tue, 19 Aug 2008 07:25:59 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 07:25:58 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2064B7950@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB720161CBD0@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 168: DTLS and Retransmissions Thread-Index: Acjz2WCdWj/4NEiBRna0IkK5PBovgQAIF04AATj3hCABJ5M2wAACo49wAPcO2xAAKSbtEA== References: <4FF84B0BC277FF45AA27FE969DD956A20632FD71@xmb-sjc-235.amer.cisco.com> <4892D971.1010303@ltsnet.net> <4FF84B0BC277FF45AA27FE969DD956A206330514@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C62AA@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064598E3@xmb-sjc-235.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001C9325D@aruba-mx2.arubanetworks.com> <1696498986EFEC4D9153717DA325CB720161CBD0@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , , X-OriginalArrivalTime: 19 Aug 2008 14:25:59.0009 (UTC) FILETIME=[7FDE9510:01C90207] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com So just to be clear, your request is to replace the first paragraph only. The resulting section would read as follows: 2.4.3. DTLS Error Handling If the AC or WTP does not respond to any DTLS handshake messages sent by its peer, the DTLS specification calls for the message to be retransmited. Note that during the handshake, when both the AC and the WTP are expecting additional handshake messages, they both retransmit if an expected message has not been received (note that retransmissions for CAPWAP Control messages work differently: all CAPWAP Control messages are either requests or responses, and the peer who sent the request is responsible for retransmissions). If the WTP does not respond to any DTLS handshake messages sent by the AC, the CAPWAP protocol allows for three possibilities, listed below. Note that DTLS MAY send a single TLS Alert message to the AC to indicate session termination. o The message was lost in transit; in this case, the DTLS implementation on the WTP will retransmit its last outstanding handshake message, since it did not receive a reply. o The WTP sent a DTLS Alert, which was lost in transit; in this case, the AC's WaitDTLS timer will expire, and the session will be terminated. o Communication with the WTP has completely failed; in this case, the AC's WaitDTLS timer will expire, and the session will be terminated. The DTLS specification provides for retransmission of unacknowledged requests. If retransmissions remain unacknowledged, the WaitDTLS timer will eventually expire, at which time the CAPWAP component will terminate the session. If a cookie fails to validate, this could represent a WTP error, or it could represent a DoS attack. Hence, AC resource utilization SHOULD be minimized. The AC MAY log a message indicating the failure, and SHOULD treat the message as though no cookie were present. Since DTLS handshake messages are potentially larger than the maximum record size, DTLS supports fragmenting of handshake messages across multiple records. There are several potential causes of re-assembly errors, including overlapping and/or lost fragments. The DTLS component MUST send a DTLSReassemblyFailure notification to the CAPWAP component. Whether precise information is given along with notification is an implementation issue, and hence is beyond the scope of this document. Upon receipt of such an error, the CAPWAP component SHOULD log an appropriate error message. Whether processing continues or the DTLS session is terminated is implementation dependent. DTLS decapsulation errors consist of three types: decryption errors, authentication errors, and malformed DTLS record headers. Since DTLS authenticates the data prior to encapsulation, if decryption fails, it is difficult to detect this without first attempting to authenticate the packet. If authentication fails, a decryption error is also likely, but not guaranteed. Rather than attempt to derive (and require the implementation of) algorithms for detecting decryption failures, decryption failures are reported as authentication failures. The DTLS component MUST provide a DTLSDecapFailure notification to the CAPWAP component when such errors occur. If a malformed DTLS record header is detected, the packets SHOULD be silently discarded, and the receiver MAY log an error message. There is currently only one encapsulation error defined: MTU exceeded. As part of DTLS session establishment, the CAPWAP component informs the DTLS component of the MTU size. This may be dynamically modified at any time when the CAPWAP component sends the DTLSMtuUpdate command to the DTLS component (see Section 2.3.2.1). The value provided to the DTLS stack is the result of the MTU Discovery process, which is described in Section 3.5. The DTLS component returns this notification to the CAPWAP component whenever a transmission request will result in a packet which exceeds the MTU. PatC -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Monday, August 18, 2008 12:02 PM To: skelly@arubanetworks.com; Pat Calhoun (pacalhou); clancy@ltsnet.net Cc: capwap@frascone.com Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions Scott and Pat, This text still assumes that the WTP is responsible for retransmitting the DTLS handshake messages (based on timer) if it doesn't receive anything from the AC. That's not totally correct. Pat's proposed text did get this right; but I agree that talking explicitly about DTLS *handshake* messages (instead of just DTLS messages) would be clearer. Here's another attempt: If the AC or WTP does not respond to any DTLS handshake messages sent by its peer, the DTLS specification calls for the message to be retransmited. Note that during the handshake, when both the AC and the WTP are expecting additional handshake messages, they both retransmit if an expected message has not been received (note that retransmissions for CAPWAP Control messages work differently: all CAPWAP Control messages are either requests or responses, and the peer who sent the request is responsible for retransmissions). Best regards, Pasi > -----Original Message----- > From: ext Scott Kelly [mailto:skelly@arubanetworks.com] > Sent: 14 August, 2008 00:00 > To: Pat Calhoun (pacalhou); Eronen Pasi (Nokia-NRC/Helsinki); > clancy@ltsnet.net > Cc: capwap@frascone.com > Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions > > Sorry, I've been out of circulation for a while and am just catching > up. > > > Pasi's point is that handshake messages are an exception to the > current text, as DTLS will re-transmit these on its own. Rather than > stripping out the existing text (which is informative and helpful for > implementers and people troubleshooting issues), I think it might be > better to update it to reflect Pasi's point. > > How about this: > > 2.4.3. DTLS Error Handling > > If the AC does not respond to any DTLS handshake messages sent by > the WTP, the DTLS specification calls for the WTP to retransmit > these messages according to the current value of the exponential > back-off timer. If the WaitDTLS timer expires, CAPWAP will issue > the DTLSAbortSession command, causing DTLS to terminate the > handshake and remove any allocated session context. Note that > DTLS MAY send a single TLS Alert message to the AC to indicate > session termination. > > If the WTP does not respond to any DTLS handshake messages sent > by the AC, the CAPWAP protocol allows for three possibilities, > listed below. Note that DTLS MAY send a single TLS Alert message > to the AC to indicate session termination. > > o The message was lost in transit; in this case, the DTLS > implementation > on the WTP will retransmit its last outstanding > handshake message, > since it did not receive a reply. > > > > --Scott > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Wednesday, August 13, 2008 12:40 PM > > To: Pasi.Eronen@nokia.com; clancy@ltsnet.net; Scott Kelly > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions > > > > Ok, well I'm still looking to Charles and Scott to weigh in, but how > > about we replace the following text: > > > > > > 2.4.3. DTLS Error Handling > > > > If the AC does not respond to any DTLS messages sent by the WTP, > > the > > DTLS specification calls for the WTP to retransmit these > messages. > > If the WaitDTLS timer expires, CAPWAP will issue the > > DTLSAbortSession > > command, causing DTLS to terminate the handshake and remove any > > allocated session context. Note that DTLS MAY send a single TLS > > Alert message to the AC to indicate session termination. > > > > If the WTP does not respond to any DTLS messages sent by the AC, > > the > > CAPWAP protocol allows for three possibilities, listed > below. Note > > that DTLS MAY send a single TLS Alert message to the AC > to indicate > > session termination. > > > > o The message was lost in transit; in this case, the > WTP will re- > > transmit its last outstanding message, since it did not > > receive a > > reply. > > > > o The WTP sent a DTLS Alert, which was lost in transit; in this > > case, the AC's WaitDTLS timer will expire, and the session > > will be > > terminated. > > > > o Communication with the WTP has completely failed; in > this case, > > the AC's WaitDTLS timer will expire, and the session will be > > terminated. > > > > > > With: > > > > > > 2.4.3. DTLS Error Handling > > > > If the AC or WTP does not respond to any DTLS messages > sent by its > > peer, the DTLS specification calls for the message to be > > retransmited. If the WaitDTLS timer expires, CAPWAP > will issue the > > DTLSAbortSession command, causing DTLS to terminate the handshake > > and > > remove any allocated session context. Note that DTLS MAY send a > > single DTLS Alert message to the AC to indicate session > > termination. > > > > > > PatC > > -----Original Message----- > > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > > Sent: Thursday, August 07, 2008 3:42 PM > > To: Pat Calhoun (pacalhou); clancy@ltsnet.net > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions > > > > Section 2.4.3 assumes that only the WTP retransmits DTLS messages if > > it doesn't get a reply (and AC retransmits a reply only when it gets > > a retransmitted request from the WTP). > > > > That's not the case: both parties retransmit if the handshake isn't > > done yet. For example, the AC will also keep retransmitting > > ServerHello (and > > Certificate/ServerKeyExchange/ServerHelloDone) > > if it doesn't receive a reply (Certificate/ClientKeyExchange/etc.) > > from the WTP. > > > > Best regards, > > Pasi > > > > > -----Original Message----- > > > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > > Sent: 01 August, 2008 20:12 > > > To: Charles Clancy > > > Cc: capwap@frascone.com; Eronen Pasi (Nokia-NRC/Helsinki) > > > Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions > > > > > > Got it - waiting for Pasi on 2.4.3. > > > > > > PatC > > > > > > -----Original Message----- > > > From: Charles Clancy [mailto:clancy@ltsnet.net] > > > Sent: Friday, August 01, 2008 2:38 AM > > > To: Pat Calhoun (pacalhou) > > > Cc: capwap@frascone.com; Pasi.Eronen@nokia.com > > > Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions > > > > > > Suggested text changes to address the comments: > > > > > > Replace this 2.4.1 text: > > > > > > DTLS, as specified, provides its own retransmit timers with an > > > exponential back-off. However, DTLS will never terminate the > > > handshake due to non-responsiveness; instead, DTLS will > > continue > > > to > > > increase its back-off timer period. Hence, timing out > > incomplete > > > DTLS handshakes is entirely the responsibility of the CAPWAP > > > module. > > > > > > with this text: > > > > > > DTLS, as specified, provides its own retransmit timers with an > > > exponential back-off. [RFC4347] does not specify how long > > > retransmissions should continue. Consequently, timing out > > > incomplete > > > DTLS handshakes is entirely the responsibility of the CAPWAP > > > module. > > > > > > I'm not sure what needs to be addressed in 2.4.3. Pasi -- > > can you be > > > more specific? > > > > > > -- > > > Dr. Charles Clancy www.ltsnet.net/~clancy > > > Senior Researcher, Laboratory for Telecommunications Sciences > > > > > > > > > Pat Calhoun (pacalhou) wrote: > > > > Pasi's comment was: > > > > > > > > Section 2.4.1: "DTLS will never terminate the > handshake due to > > > > non-responsiveness; instead, DTLS will continue to > > > > increase its back-off timer period" While RFC 4347 > > > doesn't specify > > > > how > > > > long you should continue retransmitting, the > > > > intent certainly was not to continue indefinitely. > > > > > > > > Section 2.4.3 text about DTLS retransmissions is slightly > > > inaccurate; > > > > DTLS handshake isn't strictly request/response, > > > > and both parties (not just the DTLS client) retransmit > > based on > > > > timers > > > > (in some situations). > > > > > > > > It is unclear to me as to whether these are simply > > observations, or > > > > request for change. That said, I would like either Charles > > > or Scott to > > > > > > > reply. > > > > > > > > PatC > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/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 Aug 19 08:03:08 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8941F3A6B85 for ; Tue, 19 Aug 2008 08:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKpaCrxghPxb for ; Tue, 19 Aug 2008 08:03:04 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id C52683A69B6 for ; Tue, 19 Aug 2008 08:02:06 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1EDAB1750206 for ; Tue, 19 Aug 2008 08:01:26 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id F2EED440134 for ; Tue, 19 Aug 2008 08:01:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id BDD1234AC16B for ; Tue, 19 Aug 2008 08:01:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E2DA9361036A for ; Tue, 19 Aug 2008 07:52:55 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 19 Aug 2008 07:52:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,235,1217808000"; d="scan'208";a="142242973" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 19 Aug 2008 14:52:55 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7JEqte7009474; Tue, 19 Aug 2008 07:52:55 -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.13.8/8.13.8) with ESMTP id m7JEqtro019308; Tue, 19 Aug 2008 14:52:55 GMT 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.1830); Tue, 19 Aug 2008 07:52:50 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 07:52:49 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2064B7976@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB720161CBE8@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Last call comments for capwap-protocol-binding-ieee80211-07 Thread-Index: AcjxWvvYp8NTYNntQ6KnjwjYAMoZswBPfGhwAY62tJAABD6gUAIgXFOgACiskVA= References: <1696498986EFEC4D9153717DA325CB72013BA889@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20632FDC3@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C62A7@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064598B4@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720161CBE8@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 19 Aug 2008 14:52:50.0311 (UTC) FILETIME=[4047C170:01C9020B] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] Last call comments for capwap-protocol-binding-ieee80211-07 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com > > > I wasn't thinking about ad-hoc mode, but rather a STA sending a > > > packet to an AP where the 802.3 source address would be different > > > from the transmitting STA address. Is this possible? (Perhaps a > > > "wireless Ethernet bridge", which connects to PC via wired Ethernet, > > > but looks like STA to the AP? Although I'm not quite sure how the > > > address fields really look in this situation...) > > > > Yes, you are correct that bridges work this way, but this is not a use > > case we are trying to address in this working group. An access point > > uses the IEEE 802.11 primitives for populating its learning table > > (e.g., association request), while a bridge needs to use other means > > (e.g., spanning tree). Trying to add wireless bridges to this > > specification would not only expand the scope of the WG and protocol, > > but would require lots more work. > > Large bridges are indeed different, but small "wireless bridges" are marketed for e.g. connecting a printer with wired Ethernet jack to office WLAN. > > Does this mean if the office WLAN switches to CAPWAP-based access points, and uses split MAC with 802.3 frames, those would stop working? > > (I don't think there's a need to expand the scope of the WG -- accurately documenting what parts of 802.11 don't 100% work with CAPWAP is IMHO quite sufficient.) The size of the bridge is actually irrelevant. The use of the four address frame format is the question. I would point you to the IEEE 802.11-2007 specification, section 7.1.3.1.3, which specifically states: To DS = 1, From DS = 1 A data frame using the four-address format. This standard does not define procedures for using this combination of field values. So to that end, I am proposing a modification to the last paragraph of the introduction section: 1. Introduction [...] Note that this binding only supports the IEEE 802.11-2007 specification. Of note, this binding does not support the ad-hoc network mode defined in the IEEE 802.11-2007 standard. This specification also does not cover the use of data frames with the four-address format, commonly referred to as Wireless Bridges, whose use is not specified in the IEEE 802.11-2007 standard. New protocol specifications published outside of this document (e.g., IEEE 802.11n, IEEE 802.11r) are therefore not supported through this binding, and must be addressed either through a separate CAPWAP binding, or an update to this binding. > > > This is contradicted by text in e.g. Section 6.15, which requires > > > the WTP to process (beyond copying to beacons) the IE received from > > > AC even in Split MAC mode. > > > > OK, fair enough. That is one exception, but that one is described in > > the spec. The spec even includes: > > > > > > 2.2.1. Split MAC > > [...] > > > > o The WTP generates the IEEE 802.11 Beacon frames, using > > information > > provided to it through the IEEE 802.11 Add WLAN (see > > Section 6.1) > > message element, including the RSNIE, which indicates support of > > 802.1X and AES-CCMP. > > > > Yes, but the spec isn't very clear on how the RSN IE exactly is processed by the WTP (the IE has number of different fields). The WTP does not need to perform any processing of the RSN IE. The IE is included in the Beacon and Probe Responses as-is by the WTP. Any cryptographic policies are sent by the AC either through the Add Station or the Session Key message elements. So in order to provide more clarity, I propose adding the first sentence in the last paragraph of the following text: 6.1. IEEE 802.11 Add WLAN [...] Power Constraint information element EDCA Parameter Set information element QoS Capability information element WPA information element [WPA] RSN information element WMM information element [WMM] These IEEE 802.11 information elements are stored by the WTP and included in any Probe Responses and Beacons generated, as specified in the IEEE 802.11 standard [IEEE.802-11.2007]. If present, the RSN information element is sent with the IEEE 802.11 Add WLAN message element to instruct the WTP on the usage of the Key field. > > Actually, re-reading the spec, I don't see where it dictates that the > > WTP needs to process IEs. It does mention that the WTP needs to look > > at the Result-Code in the (re-)Association Response. It also does > > mention that the AC MAY send a Disassocation Request to the station, > > through the WTP, and that the WTP should take the Disassocation > > Request as an indication that service for the station is to be > > terminated. > > > > Otherwise, there are no IE processing requirements. > > Again, except for the RSN IE, whose processing is mentioned, but not described in detail. I believe this is now covered above. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 19 08:21:05 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68BD33A67B4 for ; Tue, 19 Aug 2008 08:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCoptnpkQuqo for ; Tue, 19 Aug 2008 08:21:03 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id DB3503A67A3 for ; Tue, 19 Aug 2008 08:21:03 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4315918435EE for ; Tue, 19 Aug 2008 08:20:10 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id EC166440129 for ; Tue, 19 Aug 2008 08:19:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2659A36102A7 for ; Tue, 19 Aug 2008 08:19:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id ACAA634AC167 for ; Tue, 19 Aug 2008 07:22:12 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 19 Aug 2008 07:22:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,235,1217808000"; d="scan'208";a="142221556" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 19 Aug 2008 14:22:08 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7JEM8NG018385; Tue, 19 Aug 2008 07:22:08 -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.13.8/8.13.8) with ESMTP id m7JEM8TE020668; Tue, 19 Aug 2008 14:22:08 GMT 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.1830); Tue, 19 Aug 2008 07:22:07 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 07:22:06 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2064B794C@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB720161CEB2@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 158: Allocation of WBIDs Thread-Index: AcjxWPPBckiC/dIYR2+hBkqFhpAT4wACFMvQAEz5BoACvg95oAD18uPAAAWrPfAAFxvmgAALhLlQ References: <4FF84B0BC277FF45AA27FE969DD956A2062CB02E@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB72013BA8AA@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20632FD58@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A206459987@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720161CBD7@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064B776A@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720161CEB2@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 19 Aug 2008 14:22:07.0030 (UTC) FILETIME=[F5996560:01C90206] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 158: Allocation of WBIDs X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com I think the problem is that it is unclear exactly what kind of requests we can expect in the future. The text at least calls for a designated expert, who understands the scarcity issues, and requires him to post the request to the CAPWAP mailing list. This seems to me to provide the proper set of checks and balances to only assign numbers when the request is valid. The problem with the term SDO is that there are many pseudo-SDOs out there. For instance, EPCGlobal is not an SDO. They are a marketing organization who just happen to dabble in the creation of protocols from time to time. Same with WiFi Alliance. So using a hard term like SDO would like who can/cannot allocate numbers, and IMHO, would stiffle innovation. So I do believe that the current guidance offers as good a recommendation to IANA as any. It does not restrict anyone from asking, but at the same time, it requires that some trusted entity that is well versed in the protocol limitations and challenges is engaged in allocation requests. PatC -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Tuesday, August 19, 2008 1:54 AM To: Pat Calhoun (pacalhou); margaret@thingmagic.com Cc: capwap@frascone.com Subject: RE: [Capwap] Issue 158: Allocation of WBIDs Looks good, but it still doesn't provide much guidance about what kinds of requests should be approved. If a request comes from a group calling itself an "SDO", and a reasonably well-written technical specification is available, should it be granted? RFC 5226 says that "presumption should be that a code point should be granted, unless there is a compelling reason to the contrary", but then continues to list scarcity of code points as one reason to change this. At least some bit fields and WBIDs look like a very scarce resource to me (and BTW, if there wasn't the concern about backward compatibility, I'd recommend changing WBIDs to 16 bits, and enlarging some other fields, too). Best regards, Pasi > -----Original Message----- > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: 19 August, 2008 00:49 > To: Eronen Pasi (Nokia-NRC/Helsinki); margaret@thingmagic.com > Cc: capwap@frascone.com > Subject: RE: [Capwap] Issue 158: Allocation of WBIDs > > Yes, I agree we need to provide some guidance. > > I would recommend the following text added to the end of section 15. > Note that I have crafted the wording very carefully because unlike > other standards, the CAPWAP protocol will be used by other SDOs, who > have policies that do not allow for the public sharing of their > documents. > The IEEE is one such example where some standards are available for > free, but others are not. EPCGlobal and the WiFi Alliance does not > make their documents available to non-members. > > > 15. IANA Considerations > [...] > For registration requests where an Expert Review is required, a > Designated Expert should be consulted, which is appointed by the > responsible IESG area director. The intention is that any > allocation > will be accompanied by a published RFC, but given that > other SDOs may > want to create standards built on top of CAPWAP, a document the > Designated Expert can review is also acceptable. IANA should allow > for allocation of values prior to documents being approved for > publication, so the Designated Expert can approve > allocations once it > seems clear that publication will occur. The Designated > expert will > post a request to the CAPWAP WG mailing list (or a successor > designated by the Area Director) for comment and review. Before a > period of 30 days has passed, the Designated Expert will either > approve or deny the registration request and publish a notice of > the > decision to the CAPWAP WG mailing list or its successor, as well as > informing IANA. A denial notice must be justified by an > explanation, > and in the cases where it is possible, concrete suggestions on how > the request can be modified so as to become acceptable should be > provided. > > > PatC > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Monday, August 18, 2008 12:10 PM > To: Pat Calhoun (pacalhou); margaret@thingmagic.com > Cc: capwap@frascone.com > Subject: RE: [Capwap] Issue 158: Allocation of WBIDs > > Not an objection, but note the following text in RFC 5226: > > "The required documentation and review criteria for use by the > Designated Expert should be provided when defining the registry. > > (In particular, the WBID field is only 5 bits, so it's not an infinite > supply -- especially if new 802.11xx features may require new WBIDs, > as was suggested in discussion around issue 171.) > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: 14 August, 2008 00:43 > > To: Pat Calhoun (pacalhou); Eronen Pasi (Nokia-NRC/Helsinki); > > margaret@thingmagic.com > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Issue 158: Allocation of WBIDs > > > > Folks, in order to move this one along, I would recommend that we > > change the current IANA considerations from Standards > Action to Expert > > > Review. This would alleviate many of the issues brought up > for both > > the WBID, the message element and the EPCGlobal WBID allocation. > > > > Objections? > > > > PatC > > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) > > Sent: Wednesday, July 30, 2008 3:42 PM > > To: Pasi.Eronen@nokia.com; margaret@thingmagic.com > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 158: Allocation of WBIDs > > > > Correct, Pasi. The current IANA classification requires a Standards > > track RFC for assignment of WBIDs (and every other namespace in the > > document). I suspect that if EPCGlobal is using their own > Enterprise > > Number for control message types, then it is less of an issue. > > However, the message element types are still global, and therefore > > unless you are using the vendor specific message element, you would > > need an RFC. > > > > So what I'm hearing is remove 802.16, and keep 802.11 and > EPCGlobal. > > We just need to work out the details of the IANA classification. > > > > PatC > > > > -----Original Message----- > > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > > Sent: Tuesday, July 29, 2008 2:59 AM > > To: margaret@thingmagic.com; Pat Calhoun (pacalhou) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 158: Allocation of WBIDs > > > > > > Ok -- but if the intent is to allow CAPWAP bindings (and possibly > > other types of CAPWAP specifications) to be developed outside IETF > > Standards Track, then the IANA instructions need to be > something else > > than "Standards Action". > > > > Best regards, > > Pasi > > > > > -----Original Message----- > > > From: ext Margaret Wasserman [mailto:margaret@thingmagic.com] > > > Sent: 29 July, 2008 11:55 > > > To: Pat Calhoun > > > Cc: capwap@frascone.com; Eronen Pasi (Nokia-NRC/Helsinki) > > > Subject: Re: [Capwap] Issue 158: Allocation of WBIDs > > > > > > > > > > > Frankly, I don't care much whether we adopt this proposed > > > change. The > > > > IEEE 802.11 binding specification does not include the > > WBID value, > > > > so a change would be required for that specification. The bigger > > > change, I > > > > suspect, is on the EPCGlobal spec. Of particular note, the > > > CAPWAP spec > > > > currently requires a Standards Action to allocate one of these > > > > numbers, and since the RFID CAPWAP specification is being > > published > > > > by EPCGlobal, and not the IETF, I'm not sure how they > could get a > > > > number assigned. > > > > Margaret, you are closer to this than I am, so do you have any > > > > recommendations? > > > > > > (Wearing my EPCglobal hat) > > > > > > The EPCglobal Discovery Configuration and Initialization (DCI) > > > specification defines a CAPWAP binding for RFID readers. > > It is very > > > nearly complete after ~1-1/2 years of work. EPCglobal requires > > > interoperability testing before they will ratify a > > standard, and that > > > testing was completed last week. Final ratification of the > > EPCglobal > > > standard is now blocked on getting an RFC number for CAPWAP. > > > EPCglobal doesn't have any plans to publish DCI as an IETF > > standards > > > track document. > > > > > > The work in EPCglobal was done based on the CAPWAP WG's > > agreement to > > > assign an binding ID for that purpose in the CAPWAP spec. > While I > > > agree that further binding IDs need to be defined in their > > bindings, I > > > > > think it would be pretty late to change the agreement with > > EPCglobal > > > now. > > > > > > > Finally, removing the IEEE 802.16 from the list is not > a problem, > > > > and I agree that if there is ever a specification that > > defines the > > > > use of CAPWAP for 802.16, then the number would be > > assigned at that > > > > time. > > > > > > That would be fine with me, as the 802.16 binding doesn't exist, > > > AFAIK. > > > > > > Margaret > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Aug 19 08:57:24 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25A0B3A68B1 for ; Tue, 19 Aug 2008 08:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMHKGskYS+ii for ; Tue, 19 Aug 2008 08:57:22 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id B99823A6876 for ; Tue, 19 Aug 2008 08:57:22 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 38C361C40F71 for ; Tue, 19 Aug 2008 08:57:17 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id D50A5440134 for ; Tue, 19 Aug 2008 08:57:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id C3321361010C for ; Tue, 19 Aug 2008 08:57:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D9DC3361011F for ; Tue, 19 Aug 2008 08:53:14 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 19 Aug 2008 08:52:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,236,1217808000"; d="scan'208";a="142295818" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 19 Aug 2008 15:52:31 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7JFqV4I016584; Tue, 19 Aug 2008 08:52:31 -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.13.8/8.13.8) with ESMTP id m7JFqV05011017; Tue, 19 Aug 2008 15:52:31 GMT 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.1830); Tue, 19 Aug 2008 08:52:31 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 08:52:30 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2064B7A0E@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB720161CC1B@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 171: Pasi nits on binding spec Thread-Index: AcjzL5wHOa8wpdqYQUmSlvTmZmTg1QFnnI4QAAUEOaAAGNrSwAEJI2JQADKYLFAAzSR4AAAow9ZA References: <4FF84B0BC277FF45AA27FE969DD956A20633000B@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB72014C629F@vaebe104.NOE.Nokia.com><4FF84B0BC277FF45AA27FE969DD956A2063E6823@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB720150BDF9@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20645989D@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A206459CDF@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720161CC1B@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 19 Aug 2008 15:52:31.0122 (UTC) FILETIME=[969C2720:01C90213] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Capwap] Issue 171: Pasi nits on binding spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com > > > I can't find any mention of "WMM Information Element" in IEEE > > > 802.11-2007 -- I assumed it's some extension that not everyone > > implements? > > > > Yup - my bad. Now include a reference to the WMM web page on > > www.wi-fi.org. > > So the current binding isn't just IEEE Std 802.11-2007, but > 802.11-2007 plus some Wi-Fi Alliance spec? (That OK with me, but really needs to be said in the introduction section.) OK, then I have added the following paragraph to the introduction: 1. Introduction [...] In order to address immediate market needs for standards still being developed by the IEEE 802.11 standards body, the WiFi Alliance created interim pseudo-standards specifications. Two such specifications are widely used in the industry, namely the WiFi Protect Access [WPA] and the WiFi MultiMedia [WMM] specifications. Given their widespread adoption, this CAPWAP binding supports the use of these two specifications. > > > In this case, it seems both "Update Station QoS" and "WTP Quality of > > > Service" message elements apply to same packets -- how do they > > > interact? > > > > I have added addition verbage to make this clearer: > > > > > > 6.20. IEEE 802.11 Update Station QoS > > > > The IEEE 802.11 Update Station QoS message element is used to > > change the Quality of Service policy on the WTP for a given > > station. The QoS tags included in this message element are to be > > applied to packets received at the WTP from the station indicated > > through the MAC Address field. This message element overrides > > the default values provided through the IEEE 802.11 WTP Quality > > of Service message element (see Section 6.22. Any tagging > > performed by the WTP MUST be directly applied to the packets > > receive from the station, as well as the CAPWAP tunnel, if the > > packets are tunneled to the AC. > > I think the tagging text still needs some details. Is the intent something like this? > > 1. If doing split MAC with native frame tunnel mode (instead of 802.3): > replace the TID subfield of the packet with the "802.1p Tag" value > (except if 'C' bit in IEEE 802.11 Station Session Key message > element is set) > 2. If doing local MAC: if the WTP adds an 802.1Q header for VLAN use > (based on VLAN Name in the Add Station message element), place > the "802.1p Tag" value in the 802.1Q header. > 3. If doing split MAC: if the WTP adds an 802.1Q header for VLAN > use (based on e.g. some local configuration), place the > "802.1p Tag" value in the 802.1Q header. > 4. If the packet received from the STA is an IPv4 or IPv6 packet, > replace the DSCP field in the IP header with the "DSCP Tag" > value (except if 'C' bit is set) > 5. For split MAC, place the "DSCP Tag" value in the IP header > added by the WTP for CAPWAP Data message. > > Note that here step 1 seems unnecessary -- replacing the TID before the AC sees it doesn't seem to add value -- and step 4 is very likely to raise questions in IESG review (as it overwrites the DSCP tagging done by the STA). > > (But perhaps I understood this wrong, and some other processing was intended?) OK - clearly we need to provide more clarity, so I have created a new section 2.6, which I include below. I believe that you have read the rules properly, and I have tried to be explict below about the treatment of QoS at the WTP. I am unsure why the IESG would have issues with option 4, because whether we like it or not, enterprise networks do not necessarily trust DSCP markings from endpoints. We can be blind about this, and simply leave out the text and allow manufacturers do what they do today (which is allow for remarking), if you believe this would be more acceptable to the IESG. But like it or not, we can't change reality. 2.6. Quality of Service The CAPWAP IEEE 802.11 binding specification provides procedures to allow for the WTP to enforce Quality of Service. This section will detail the actual procedures for both Split and Local MAC. When the WLAN is created on the WTP, a default Quality of Service policy through the IEEE 802.11 WTP Quality of Service message element (see Section 6.22). This default policy will cause the WTP to use the default QoS values for any station associated with the WLAN in question. The AC MAY also override the policy for a given station, by sending the IEEE 802.11 Update Station QoS message element (see Section 6.20). Both message elements provide an "802.1p Tag", which is used by the WTP by adding an 802.1Q header (see [IEEE.802-1Q.2005]) with the priority field set according to the policy provided. Regardless of whether Split or Local MAC is used, the 802.1Q header processing is identical. Both message elements also provide a "DSCP Tag", which is used by the WTP to use in the DSCP field of bot the IPv4 and IPv6 headers (see [RFC2474]). When the WTP operates in a Split MAC mode, the DSCP markings are used in the CAPWAP data plane tunnel's IP header. For both Split and Local MAC, the DSCP value SHOULD be used as a default policy by the WTP to override any markings received by the station in its IPv4 or IPv6 packets. Note that the use of WMM (see [WMM]) allows the station to request special QoS treatment for a given flow. > > > > [...] > > > > 6.22. IEEE 802.11 WTP Quality of Service > > > > The IEEE 802.11 WTP Quality of Service message element value is > > sent > > by the AC to the WTP to communicate quality of service > > configuration > > information. The QoS tag included in this message element are the > > default QoS values to be applied to packets received by the WTP > > from > > stations on a particular radio. Any tagging performed by the WTP > > MUST be directly applied to the packets receive from the station, > > as > > well as the CAPWAP tunnel, if the packets are tunneled to the AC. > > > > Same ambiguity here; perhaps instead of repeating the detail, a pointer to 6.20 woul be sufficient. I prefer to include a reference to the new section 2.6 in both 6.20 and 6.22. > > > I'm also slightly surprised to see the WTP modifying the contents of > > > IP packets here -- I thought it was acting as Layer 2 device for > > > user plane traffic (not making any assumptions about the Layer > > > 3 protocol carried in 802.3 frames). At the very least, the text > > > should probably say the DSCP Tag applies only to packets with > > > certain values in the 802.3 Type field. > > > > OK, I can modify the text to specifically read: > > > > DSCP Tag: The 6 bit DSCP label to use if packets are > > eligible to be DSCP tagged (see [RFC2474]). > > > > IMHO it would be clearer to say "if the packet received from the STA is an IPv4 or IPv6 packet" (if that's what's meant by "eligible to be DSCP OK, so I have modified the text to: DSCP Tag: The 6 bit DSCP label to use if packets are eligible to be DSCP tagged, specifically an IPv4 or IPv6 packet (see [RFC2474]). PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 19 13:05:53 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67023A6982 for ; Tue, 19 Aug 2008 13:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.387 X-Spam-Level: X-Spam-Status: No, score=-4.387 tagged_above=-999 required=5 tests=[AWL=-0.788, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7K+AahtjefHj for ; Tue, 19 Aug 2008 13:05:52 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 4E72C3A6841 for ; Tue, 19 Aug 2008 13:05:52 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6D51E43A313 for ; Tue, 19 Aug 2008 13:05:20 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id B5122440144 for ; Tue, 19 Aug 2008 13:05:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 7EF213618088 for ; Tue, 19 Aug 2008 13:05:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id C2DC03610076 for ; Tue, 19 Aug 2008 12:56:08 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.105.134 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 19 Aug 2008 12:56:08 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7JJsROd013912; Tue, 19 Aug 2008 14:55:23 -0500 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 22:55:13 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 22:55:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 22:55:07 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720161D3DF@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2064B7A0E@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 171: Pasi nits on binding spec Thread-Index: AcjzL5wHOa8wpdqYQUmSlvTmZmTg1QFnnI4QAAUEOaAAGNrSwAEJI2JQADKYLFAAzSR4AAAow9ZAAAhYyBA= References: <4FF84B0BC277FF45AA27FE969DD956A20633000B@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB72014C629F@vaebe104.NOE.Nokia.com><4FF84B0BC277FF45AA27FE969DD956A2063E6823@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB720150BDF9@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20645989D@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A206459CDF@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720161CC1B@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064B7A0E@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 19 Aug 2008 19:55:13.0273 (UTC) FILETIME=[7E540E90:01C90235] X-Nokia-AV: Clean Subject: Re: [Capwap] Issue 171: Pasi nits on binding spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun wrote: > > So the current binding isn't just IEEE Std 802.11-2007, but > > 802.11-2007 plus some Wi-Fi Alliance spec? (That OK with me, but > really needs to be said in the introduction section.) > > OK, then I have added the following paragraph to the introduction: > > > 1. Introduction > [...] > In order to address immediate market needs for standards > still being > developed by the IEEE 802.11 standards body, the WiFi Alliance > created interim pseudo-standards specifications. Two such > specifications are widely used in the industry, namely the WiFi > Protect Access [WPA] and the WiFi MultiMedia [WMM] specifications. > Given their widespread adoption, this CAPWAP binding > supports the use > of these two specifications. > "Requires" instead of "supports", right? (Since it's mandatory to include the WPA and WMM information elements in the IEEE 802.11 Add WLAN message element.) > > I think the tagging text still needs some details. Is the intent > > something like this? > > > > 1. If doing split MAC with native frame tunnel mode (instead of > > 802.3): > > replace the TID subfield of the packet with the "802.1p > > Tag" value > > (except if 'C' bit in IEEE 802.11 Station Session Key message > > element is set) > > 2. If doing local MAC: if the WTP adds an 802.1Q header for VLAN use > > (based on VLAN Name in the Add Station message element), place > > the "802.1p Tag" value in the 802.1Q header. > > 3. If doing split MAC: if the WTP adds an 802.1Q header for VLAN > > use (based on e.g. some local configuration), place the > > "802.1p Tag" value in the 802.1Q header. > > 4. If the packet received from the STA is an IPv4 or IPv6 packet, > > replace the DSCP field in the IP header with the "DSCP Tag" > > value (except if 'C' bit is set) > > 5. For split MAC, place the "DSCP Tag" value in the IP header > > added by the WTP for CAPWAP Data message. > > > > Note that here step 1 seems unnecessary -- replacing the TID before > > the AC sees it doesn't seem to add value -- and step 4 is > > very likely to > > raise questions in IESG review (as it overwrites the DSCP tagging done > > by the STA). > > > > (But perhaps I understood this wrong, and some other processing was > > intended?) > > OK - clearly we need to provide more clarity, so I have created a > new section 2.6, which I include below. I believe that you have read > the rules properly, and I have tried to be explict below about the > treatment of QoS at the WTP. I am unsure why the IESG would have > issues with option 4, because whether we like it or not, enterprise > networks do not necessarily trust DSCP markings from endpoints. We > can be blind about this, and simply leave out the text and allow > manufacturers do what they do today (which is allow for remarking), > if you believe this would be more acceptable to the IESG. But like > it or not, we can't change reality. I'm not disagreeing that replacing the DSCP tag can be useful in some circumstances -- but it might be useful to allow *not* replacing it, while still tagging the IP header added by the WTP. > > 2.6. Quality of Service > > The CAPWAP IEEE 802.11 binding specification provides procedures to > allow for the WTP to enforce Quality of Service. This section will > detail the actual procedures for both Split and Local MAC. > > When the WLAN is created on the WTP, a default Quality of Service > policy through the IEEE 802.11 WTP Quality of Service > message element > (see Section 6.22). This default policy will cause the WTP to use > the default QoS values for any station associated with the WLAN in > question. The AC MAY also override the policy for a given station, > by sending the IEEE 802.11 Update Station QoS message element (see > Section 6.20). The "WTP QoS" message element allows different 802.1p Tags and DSCP Tags for e.g. Voice and Background traffic; the "Update Station QoS" element doesn't. Is this mismatch intentional? Does the latter override all the QoS profiles? The "WTP QoS" message element also has a bit field saying whether to do 802.1p tagging, DSCP tagging, or both (or neither). The "Update Station QoS" element doesn't have such bit field -- how does this work? (Is e.g. the bit field for "WTP QoS" message element used -- meaning that the DSCP field in "Update Station QoS" is ignored if the DSCP bit wasn't set in "WTP QoS", or something else?) > Both message elements provide an "802.1p Tag", which is used by the > WTP by adding an 802.1Q header (see [IEEE.802-1Q.2005]) with the > priority field set according to the policy provided. Regardless of > whether Split or Local MAC is used, the 802.1Q header processing is > identical. Does the WTP always add the 802.1Q header when doing Local MAC? (Even when bridging traffic to an untagged port?) For Split MAC, it obviously does not always add an 802.1Q header (the IP packets to the AC could be sent over any interface, not just those in 802.* family), so the processing needs some clarification. But if it's e.g. wired Ethernet, is the WTP *required* to add an 802.1Q header with this value? (the WTP is working as an ordinary host, not bridge, on this interface...) (My lack of knowledge about 802.1Q is probably showing -- but I think the spec needs to be clear here what's the required behavior, and what's just advice.) > Both message elements also provide a "DSCP Tag", which is used by > the WTP to use in the DSCP field of bot the IPv4 and IPv6 headers > (see [RFC2474]). When the WTP operates in a Split MAC mode, the > DSCP markings are used in the CAPWAP data plane tunnel's IP > header. For both Split and Local MAC, the DSCP value SHOULD be > used as a default policy by the WTP to override any markings > received by the station in its IPv4 or IPv6 packets. Note that > the use of WMM (see [WMM]) allows the station to request special > QoS treatment for a given flow. I don't know much about WMM, but "SHOULD" sounds a bit problematic here -- probably the AC should tell the WTP what to do? (In some deployments, DSCP Tags set by the hosts might be meaningful and sufficiently trustworthy, so the AC administrator should be able to decide whether they're overwritten or not, right?) Also, I'm not sure I understand the "be used as a default policy... to override". Something like "is used to override" would be clear, but "default policy" is probably referring to some WMM feature related to DSCP tagging? (Also, the text should say this doesn't apply when the 'C' bit in IEEE 802.11 Station Session Key message element is set). Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 19 13:15:12 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54B553A68AA for ; Tue, 19 Aug 2008 13:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.365 X-Spam-Level: X-Spam-Status: No, score=-4.365 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sxqf5jBTvjv9 for ; Tue, 19 Aug 2008 13:15:11 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 76FDF3A66B4 for ; Tue, 19 Aug 2008 13:15:11 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AE74F1C41002 for ; Tue, 19 Aug 2008 13:13:54 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id EA06844014E for ; Tue, 19 Aug 2008 13:13:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id C58EA3610080 for ; Tue, 19 Aug 2008 13:13:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D3B7D3648043 for ; Tue, 19 Aug 2008 13:11:03 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.122.230 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 19 Aug 2008 13:11:03 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7JKAJsC011202; Tue, 19 Aug 2008 23:10:27 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 23:10:13 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 23:10:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 23:10:07 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720161D3E8@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2064B7950@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 168: DTLS and Retransmissions Thread-Index: Acjz2WCdWj/4NEiBRna0IkK5PBovgQAIF04AATj3hCABJ5M2wAACo49wAPcO2xAAKSbtEAALkv2w References: <4FF84B0BC277FF45AA27FE969DD956A20632FD71@xmb-sjc-235.amer.cisco.com> <4892D971.1010303@ltsnet.net> <4FF84B0BC277FF45AA27FE969DD956A206330514@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C62AA@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064598E3@xmb-sjc-235.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001C9325D@aruba-mx2.arubanetworks.com> <1696498986EFEC4D9153717DA325CB720161CBD0@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064B7950@xmb-sjc-235.amer.cisco.com> From: To: , , X-OriginalArrivalTime: 19 Aug 2008 20:10:07.0412 (UTC) FILETIME=[9346D740:01C90237] X-Nokia-AV: Clean Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun wrote: > So just to be clear, your request is to replace the first paragraph > only. The resulting section would read as follows: No, the 2nd paragraph, the three bullets, and the paragraph following the bullets also need work... but much of the text is really redundant with the new 1st paragraph, so this could be shortened (while fixing the incorrect parts at the same time) -- see below. > > 2.4.3. DTLS Error Handling > > If the AC or WTP does not respond to any DTLS handshake messages > sent by its peer, the DTLS specification calls for the message to > be retransmited. Note that during the handshake, when both the > AC and the WTP are expecting additional handshake messages, they > both retransmit if an expected message has not been received > (note that retransmissions for CAPWAP Control messages work > differently: all CAPWAP Control messages are either requests or > responses, and the peer who sent the request is responsible for > retransmissions). > > If the WTP does not respond to any DTLS handshake messages sent > by the AC, the CAPWAP protocol allows for three possibilities, > listed below. Note that DTLS MAY send a single TLS Alert message > to the AC to indicate session termination. > > o The message was lost in transit; in this case, the DTLS > implementation on the WTP will retransmit its last outstanding > handshake message, since it did not receive a reply. > > o The WTP sent a DTLS Alert, which was lost in transit; in this > case, the AC's WaitDTLS timer will expire, and the > session will be > terminated. > > o Communication with the WTP has completely failed; in this case, > the AC's WaitDTLS timer will expire, and the session will be > terminated. > > The DTLS specification provides for retransmission of > unacknowledged > requests. If retransmissions remain unacknowledged, the WaitDTLS > timer will eventually expire, at which time the CAPWAP > component will > terminate the session. Probably everything from the 2nd paragraph to here could be summarized something like this: If the WTP or the AC does not receive an expected DTLS handshake message despite of retransmissions, the WaitDTLS timer will eventually expire, and the session will be terminated. This can happen if communication between the peers has completely failed, or if one of the peers sent a DTLS Alert message which was lost in transit (DTLS does not retransmit Alert messages). Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 19 13:42:18 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E40DB3A6839 for ; Tue, 19 Aug 2008 13:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.343 X-Spam-Level: X-Spam-Status: No, score=-4.343 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfJs7kYgMTul for ; Tue, 19 Aug 2008 13:42:17 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id D602D3A6767 for ; Tue, 19 Aug 2008 13:42:17 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DBF9C1751987 for ; Tue, 19 Aug 2008 13:41:29 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 6D768440150 for ; Tue, 19 Aug 2008 13:41:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 52FD534AC034 for ; Tue, 19 Aug 2008 13:41:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 016B234AC020 for ; Tue, 19 Aug 2008 13:41:11 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.105.134 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 19 Aug 2008 13:41:10 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7JKeMFs020652; Tue, 19 Aug 2008 15:40:42 -0500 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 23:40:37 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Aug 2008 23:40:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 23:40:32 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720161D3FA@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2064B7976@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Last call comments for capwap-protocol-binding-ieee80211-07 Thread-Index: AcjxWvvYp8NTYNntQ6KnjwjYAMoZswBPfGhwAY62tJAABD6gUAIgXFOgACiskVAADAKicA== References: <1696498986EFEC4D9153717DA325CB72013BA889@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20632FDC3@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C62A7@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064598B4@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720161CBE8@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064B7976@xmb-sjc-235.amer.cisco.com> From: To: X-OriginalArrivalTime: 19 Aug 2008 20:40:33.0248 (UTC) FILETIME=[D38F4E00:01C9023B] X-Nokia-AV: Clean Cc: capwap@frascone.com Subject: Re: [Capwap] Last call comments for capwap-protocol-binding-ieee80211-07 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun wrote: > > > > This is contradicted by text in e.g. Section 6.15, > > > > which requires > > > > the WTP to process (beyond copying to beacons) the IE received > > > > from > > > > AC even in Split MAC mode. > > > > > > OK, fair enough. That is one exception, but that one is > > > described in > > > > the spec. The spec even includes: > > > > > > > > > 2.2.1. Split MAC > > > [...] > > > > > > o The WTP generates the IEEE 802.11 Beacon frames, using > > > information > > > provided to it through the IEEE 802.11 Add WLAN (see > > > Section 6.1) > > > message element, including the RSNIE, which > > > indicates support of 802.1X and AES-CCMP. > > > > > > > Yes, but the spec isn't very clear on how the RSN IE exactly is > processed by the WTP (the IE has number of different fields). > > The WTP does not need to perform any processing of the RSN IE. The > IE is included in the Beacon and Probe Responses as-is by the > WTP. Any cryptographic policies are sent by the AC either through > the Add Station or the Session Key message elements. By "processing", I meant the WTP has to parse the contents of the RSN IE, find some field(s) inside it, and use those value(s) for something. Both Sections 6.1 and 6.15 say the WTP does this; I'd like to see more details for "some field(s)" and "something". (Presumably, other IEs are just stored and copied to Beacons and Probe Responses -- the WTP doesn't need to parse them. Is this correct?). > So in order to provide more clarity, I propose adding the first > sentence in the last paragraph of the following text: > > > 6.1. IEEE 802.11 Add WLAN > [...] > Power Constraint information element > > EDCA Parameter Set information element > > QoS Capability information element > > WPA information element [WPA] > > RSN information element > > WMM information element [WMM] > > These IEEE 802.11 information elements are stored by the WTP and > included in any Probe Responses and Beacons generated, as specified > in the IEEE 802.11 standard [IEEE.802-11.2007]. If > present, the RSN > information element is sent with the IEEE 802.11 Add WLAN message > element to instruct the WTP on the usage of the Key field. > As I wrote above, I don't think "instruct" is enough here, or in Section 6.15. Which fields are used, and how? (As an example of ambiguity, the RSN IE can list multiple pairwise cipher suites. If both TKIP and CCMP are listed in the RSN IE, what does the WTP do? The IEEE 802.11 Station Session Key message element could -- and perhaps should -- contain a "Cipher Suite" field, but currently, it doesn't.) Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 19 14:42:29 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58BFF3A63D2 for ; Tue, 19 Aug 2008 14:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FUZZY_CPILL=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSKM7zboSQm4 for ; Tue, 19 Aug 2008 14:42:28 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 1BC883A67E7 for ; Tue, 19 Aug 2008 14:42:28 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 97F7A1C40F66 for ; Tue, 19 Aug 2008 14:42:10 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id D7783440152 for ; Tue, 19 Aug 2008 14:42:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id BEB8F3610008 for ; Tue, 19 Aug 2008 14:42:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id B2D2734AC054 for ; Tue, 19 Aug 2008 14:41:59 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 19 Aug 2008 14:41:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,237,1217808000"; d="scan'208";a="76634737" Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-2.cisco.com with ESMTP; 19 Aug 2008 21:41:59 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id m7JLfxjg024448; Tue, 19 Aug 2008 14:41:59 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7JLfx65001751; Tue, 19 Aug 2008 21:41:59 GMT 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.1830); Tue, 19 Aug 2008 14:41:59 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 14:41:58 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2064B7CC1@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB720161D3E8@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 168: DTLS and Retransmissions Thread-Index: Acjz2WCdWj/4NEiBRna0IkK5PBovgQAIF04AATj3hCABJ5M2wAACo49wAPcO2xAAKSbtEAALkv2wAAOwzdA= References: <4FF84B0BC277FF45AA27FE969DD956A20632FD71@xmb-sjc-235.amer.cisco.com> <4892D971.1010303@ltsnet.net> <4FF84B0BC277FF45AA27FE969DD956A206330514@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C62AA@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064598E3@xmb-sjc-235.amer.cisco.com> <6F22142CC0DEBE478C659612F9CFCA5001C9325D@aruba-mx2.arubanetworks.com> <1696498986EFEC4D9153717DA325CB720161CBD0@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064B7950@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720161D3E8@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , , X-OriginalArrivalTime: 19 Aug 2008 21:41:59.0077 (UTC) FILETIME=[687C2D50:01C90244] Authentication-Results: sj-dkim-5; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Scott/Charles, are we good with this? Can I close this issue with the recommended text below? PatC -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Tuesday, August 19, 2008 1:10 PM To: Pat Calhoun (pacalhou); skelly@arubanetworks.com; clancy@ltsnet.net Cc: capwap@frascone.com Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions Pat Calhoun wrote: > So just to be clear, your request is to replace the first paragraph > only. The resulting section would read as follows: No, the 2nd paragraph, the three bullets, and the paragraph following the bullets also need work... but much of the text is really redundant with the new 1st paragraph, so this could be shortened (while fixing the incorrect parts at the same time) -- see below. > > 2.4.3. DTLS Error Handling > > If the AC or WTP does not respond to any DTLS handshake messages > sent by its peer, the DTLS specification calls for the message to > be retransmited. Note that during the handshake, when both the > AC and the WTP are expecting additional handshake messages, they > both retransmit if an expected message has not been received > (note that retransmissions for CAPWAP Control messages work > differently: all CAPWAP Control messages are either requests or > responses, and the peer who sent the request is responsible for > retransmissions). > > If the WTP does not respond to any DTLS handshake messages sent > by the AC, the CAPWAP protocol allows for three possibilities, > listed below. Note that DTLS MAY send a single TLS Alert message > to the AC to indicate session termination. > > o The message was lost in transit; in this case, the DTLS > implementation on the WTP will retransmit its last outstanding > handshake message, since it did not receive a reply. > > o The WTP sent a DTLS Alert, which was lost in transit; in this > case, the AC's WaitDTLS timer will expire, and the > session will be > terminated. > > o Communication with the WTP has completely failed; in this case, > the AC's WaitDTLS timer will expire, and the session will be > terminated. > > The DTLS specification provides for retransmission of > unacknowledged > requests. If retransmissions remain unacknowledged, the WaitDTLS > timer will eventually expire, at which time the CAPWAP > component will > terminate the session. Probably everything from the 2nd paragraph to here could be summarized something like this: If the WTP or the AC does not receive an expected DTLS handshake message despite of retransmissions, the WaitDTLS timer will eventually expire, and the session will be terminated. This can happen if communication between the peers has completely failed, or if one of the peers sent a DTLS Alert message which was lost in transit (DTLS does not retransmit Alert messages). Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 19 15:31:23 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1FB23A69B3 for ; Tue, 19 Aug 2008 15:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7zN6clchqC2 for ; Tue, 19 Aug 2008 15:31:22 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 377BA3A687D for ; Tue, 19 Aug 2008 15:31:22 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2DD9D1C40FA9 for ; Tue, 19 Aug 2008 15:23:12 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id EF57B44014C for ; Tue, 19 Aug 2008 15:23:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id DB22B3610031 for ; Tue, 19 Aug 2008 15:23:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 9D1CA361002B for ; Tue, 19 Aug 2008 15:23:00 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 19 Aug 2008 15:23:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,237,1217808000"; d="scan'208";a="142521672" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 19 Aug 2008 22:23:00 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m7JMN07e026050; Tue, 19 Aug 2008 15:23:00 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7JMN0cg004573; Tue, 19 Aug 2008 22:23:00 GMT 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.1830); Tue, 19 Aug 2008 15:23:00 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 15:22:59 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2064B7D1F@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB720161CF0C@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Recap of current pending issues Thread-Index: Acjz9xoEqCcXlGoTT6y9r7yIArdLFwDULppAAGVprtABKASH0AEXEvfAABwI+PA= References: <4FF84B0BC277FF45AA27FE969DD956A2063304F7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A206393CCC@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C62AB@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064598F1@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720161CF0C@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 19 Aug 2008 22:23:00.0146 (UTC) FILETIME=[23658120:01C9024A] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Capwap] Recap of current pending issues X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thanks Pasi, that was very useful. You did not cover all of the cases in the existing section, so I presume you were only providing text to cover the issues you had. With this assumption in mind, the new section looks like: 4.5.3. Retransmissions The CAPWAP control protocol operates as a reliable transport. For each Request message, a Response message is defined, which is used to acknowledge receipt of the Request message. In addition, the control header Sequence Number field is used to pair the Request and Response messages (see Section 4.5.1). Response messages are not explicitly acknowledged, therefore if a Response message is not received, the original Request message is retransmitted. Implementations MUST keep track of the Sequence Number of the last received Request message, and MUST cache the corresponding Response message. If a retransmission with the same Sequence Number is received, the cached Response message MUST be retransmitted without re-processing the Request. If an older Request message (with smaller Sequence Number modulo 32) is received, it MUST be ignored. A newer Request message (with larger Sequence Number modulo 32) is processed as usual. Both the WTP and the AC can only have a single request outstanding at any given time. Retransmitted Request messages MUST NOT be altered by the sender. After transmitting a Request message, the RetransmitInterval (see Section 4.7) timer and MaxRetransmit (see Section 4.8) variable are used to determine if the original Request message needs to be retransmitted. The RetransmitInterval timer is used the first time the Request is retransmitted. The timer is then doubled every subsequent time the same Request message is retransmitted, up to MaxRetransmit but no more than half the EchoInterval timer (see Section 4.7.7). Response messages are not subject to these timers. If the sender stops retransmitting a Request message before reaching MaxRetransmit retransmissions (which leads to transition to DTLS Teardown, as described in Section 2.3.1), it cannot know whether the recipient received and processed the Request or not. In most situations, the sender SHOULD NOT do this, and instead continue retransmitting until a Response message is received, or transition to DTLS Teardown occurs. However, if the sender does decide to continue the connection with a new or modified Request message, the new message MUST have a new Sequence Number, and be treated as a new Request message by the receiver. When a Request message is retransmitted, it MUST be re-encrypted via the DTLS stack. If the peer had received the Request message, and the corresponding Response message was lost, it is necessary to ensure that retransmitted Request messages are not identified as replays by the DTLS stack. Similarly, any cached Response messages that are retransmitted as a result of receiving a retransmitted Request message MUST be re-encrypted via DTLS. Duplicate Response messages, identified by the Sequence Number field in the CAPWAP control message header, SHOULD be discarded upon receipt. PatC -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Tuesday, August 19, 2008 2:30 AM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: Recap of current pending issues Pat Calhoun wrote: >> The answer (you can't have multiple outstanding requests) really >> needs to be in the spec. Also, the spec needs some more text about >> how the receiver processes them -- e.g. does the receiver maintain >> "last seen sequence number" counter, and silently drop (without >> replying) requests older than this? > > > I believe some of this was already covered, but I have added a new > sentence to the end of the first paragraph. I am including some > additional language that does address some of your concern that was > already in the spec: > > > 4.5.3. Retransmissions > > The CAPWAP control protocol operates as a reliable transport. > For each Request message, a Response message is defined, which is > used to acknowledge receipt of the Request message. In addition, > the control header Sequence Number field is used to pair the > Request and Response messages (see Section 4.5.1). This > Request/Response pair, combined with the Sequence Number, implies > that both the WTP and the AC can only have a single request > outstanding at any given time. Hmm... it doesn't really *imply* it. For example, IKEv2 has almost identical approach -- request/response pairs, sequence number, same way of doing retransmissions -- but does allow multiple outstanding requests (in some circumstances). Also, the definition of the Sequence Number field (4.5.1.2) says that "counter is monotonically incremented, ensuring that no two pending Request messages have the same Sequence Number" -- this sentence makes sense only if there can be more than one pending request. > Response messages are not explicitly acknowledged, therefore if a > Response message is not received, the original Request message is > retransmitted. Implementations MAY cache Response messages to > respond to a retransmitted Request messages with minimal local > processing. It isn't quite clear what the alternative to this "MAY" (what should an implementation that doesn't cache the Response message do). The most obvious answer would be to "process the message as usual and generate a reply", but unfortunately, that doesn't seem to work for all messages (for example, if the WTP processes retransmissions of Image Data Requests as normal requests, it seems the resulting image would be wrong). I'd suggest just making caching the Response message a MUST -- this would be the simplest solution, both specification-wise and implementation-wise. (A possible alternative might involve keeping a "Last Received Sequence Number" field, and specifying how to process the messages and generate a correct reply without really processing the message. Or making all Request messages idempotent. But those seem complex.) > Retransmitted Request messages MUST NOT be altered > by the sender. The sender MUST assume that the original Request > message was processed, but that the Response message was lost. I doubt any implementation would actually follow this "MUST assume". (E.g. if the AC is sending Image Data Requests, does it make sense to assume the WTP really received it, and move to the next image data block? Or if the Station Configuration Request isn't acknowledged, would the AC assume that station is now configured OK?) Also, the state machine says that if you reach the MaxRetransmit count without receiving a response, you move to DTLS Teardown state. In theory, you could abandon a Request for other reason that reaching the MaxRetransmit count (perhaps you changed your mind, and didn't want to do it anyway). But then you can't know whether the recipient received and processed it, leaving things is slightly indeterminate state. > Any alterations to the original Request message MUST have a new > Sequence Number, and be treated as a new Request message by the > receiver. Here's a suggestion based on my comments above: 4.5.3. Retransmissions The CAPWAP control protocol operates as a reliable transport. For each Request message, a Response message is defined, which is used to acknowledge receipt of the Request message. In addition, the control header Sequence Number field is used to pair the Request and Response messages (see Section 4.5.1). Response messages are not explicitly acknowledged, therefore if a Response message is not received, the original Request message is retransmitted. Implementations MUST keep track of the Sequence Number of the last received Request message, and MUST cache the corresponding Response message. If a retransmission with the same Sequence Number is received, the cached Response message MUST be retransmitted without re-processing the Request. If an older Request message (with smaller Sequence Number modulo 32) is received, it MUST be ignored. A newer Request message (with larger Sequence Number modulo 32) is processed as usual. Both the WTP and the AC can only have a single request outstanding at any given time. Retransmitted Request messages MUST NOT be altered by the sender. If the sender stops retransmitting a Request message before reaching MaxRetransmit retransmissions (which leads to transition to DTLS Teardown, as described in Section 2.3.1), it cannot know whether the recipient received and processed the Request or not. In most situations, the sender SHOULD NOT do this, and instead continue retransmitting until a Response message is received, or transition to DTLS Teardown occurs. However, if the sender does decide to continue the connection with a new or modified Request message, the new message MUST have a new Sequence Number, and be treated as a new Request message by the receiver. Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 19 15:34:43 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1C4B3A6AA6 for ; Tue, 19 Aug 2008 15:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oHj2cWwIdDp for ; Tue, 19 Aug 2008 15:34:42 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id BCEE63A6B17 for ; Tue, 19 Aug 2008 15:34:42 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EEFBE1C40FC6 for ; Tue, 19 Aug 2008 15:34:50 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id DB34C44014C for ; Tue, 19 Aug 2008 15:34:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id C6934361004A for ; Tue, 19 Aug 2008 15:34:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id EF714361002B for ; Tue, 19 Aug 2008 15:34:43 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 19 Aug 2008 15:34:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,237,1217808000"; d="scan'208";a="142525956" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 19 Aug 2008 22:34:43 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m7JMYhoL001400; Tue, 19 Aug 2008 15:34:43 -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.13.8/8.13.8) with ESMTP id m7JMYh62009250; Tue, 19 Aug 2008 22:34:43 GMT 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.1830); Tue, 19 Aug 2008 15:34:43 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 15:34:43 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2064B7D35@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB720161CF38@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 166: Various IANA Issues Thread-Index: AcjyfwiGWFFYbM34RwGLIXgw/+Uu9wGXDdqQASeRViABGTLZsAAbO8hQ References: <4FF84B0BC277FF45AA27FE969DD956A20632FC22@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C62A8@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064598C7@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720161CF38@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 19 Aug 2008 22:34:43.0619 (UTC) FILETIME=[C6B2F730:01C9024B] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Capwap] Issue 166: Various IANA Issues X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com > > Currently, any vendor (or SDO) can define their own message elements > > through the vendor specific message element. This message element > > allows the vendor (or SDO) to include their Enterprise Code, and they > > can manage their own message element namespace. > > This didn't really answer my question. > > Which of the following is meant by this section and Section 4.6.1? > > - The AC Descriptor message element MUST always contain exactly one > Sub-Element with "AC Information Vendor Identifier"=0/"AC Information > Type"=4, exactly one Sub-Element with Vendor=0/Type=5, > MAY contain other Sub-Elements. > > (In this case, saying that the contents are "vendor specific" > is a bit strange, since the message doesn't tell who the > vendor is. Perhaps "printable UTF-8 string intended for the > administator" or something was intended?) > > - The AC Descriptor message element MUST always contain exactly > one Sub-Element with "AC Information Vendor Identifier"=SOMEV/ > "AC Information Type"=4, exactly one Sub-Element with Vendor=SOMEV/ > Type=5, and MAY contain other Sub-Elements. > > (BTW -- this same question seems to apply to WTP Board Data message element as well.) My apologies - I completely misunderstood the original comment. I see now what you are asking. I have modified the text to: 15.10. AC Information Type The Information Type field in the AC Descriptor message element (see Section 4.6.1) is used to represent information about the AC. The namespace is 16 bits (0-65535), where the value of zero (0) is reserved and must not be assigned. This field, combined with the AC Information Vendor ID, allows vendors to use a private namespace. This specification defines the AC Information Type namespace when the AC Information Vendor ID is set to zero (0), for which the values four (4) and five (5) are allocated in this specification, and can be found in Section 4.6.1. This namespace is managed by IANA and assignments require a Expert Review. IANA will create the AC Information Type registry, whose format is: AC Information Type Type Value Reference 15.20. WTP Board Data Type The Board Data Type field in the WTP Board Data message element (see Section 4.6.39) is used to represent information about the WTP hardware. The namespace is 16 bits (0-65535). This field, combined with the Vendor ID field, allows vendors to use a private namespace. This specification defines the WTP Board Data Type namespace when the Vendor ID field is set to zero (0), for which the values zero (0) through four (4) are allocated in this specification, and can be found in Section 4.6.39. This namespace is managed by IANA and assignments require a Expert Review. IANA will create the WTP Board Data Type registry, whose format is: WTP Board Data Type Type Value Reference Makes sense? PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 19 17:04:09 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F157328C221 for ; Tue, 19 Aug 2008 17:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Takk2KfWOR6m for ; Tue, 19 Aug 2008 17:04:07 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id E47203A6BED for ; Tue, 19 Aug 2008 17:04:07 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 292FB1C40F44 for ; Tue, 19 Aug 2008 16:53:51 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 901D744013D for ; Tue, 19 Aug 2008 16:53:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 803483610008 for ; Tue, 19 Aug 2008 16:53:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8E81B3610042 for ; Tue, 19 Aug 2008 16:53:37 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 19 Aug 2008 16:53:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,238,1217808000"; d="scan'208";a="142563780" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 19 Aug 2008 23:53:34 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m7JNrYNr010339; Tue, 19 Aug 2008 16:53:34 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m7JNrYtr028170; Tue, 19 Aug 2008 23:53:34 GMT 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.1830); Tue, 19 Aug 2008 16:53:33 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 16:53:31 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2064B7DD9@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB720161D3DF@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 171: Pasi nits on binding spec Thread-Index: AcjzL5wHOa8wpdqYQUmSlvTmZmTg1QFnnI4QAAUEOaAAGNrSwAEJI2JQADKYLFAAzSR4AAAow9ZAAAhYyBAACIiHYA== References: <4FF84B0BC277FF45AA27FE969DD956A20633000B@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB72014C629F@vaebe104.NOE.Nokia.com><4FF84B0BC277FF45AA27FE969DD956A2063E6823@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB720150BDF9@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20645989D@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A206459CDF@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720161CC1B@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064B7A0E@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720161D3DF@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 19 Aug 2008 23:53:33.0726 (UTC) FILETIME=[CA1003E0:01C90256] Authentication-Results: sj-dkim-4; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Capwap] Issue 171: Pasi nits on binding spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com > > OK, then I have added the following paragraph to the introduction: > > > > > > 1. Introduction > > [...] > > In order to address immediate market needs for standards > > still being > > developed by the IEEE 802.11 standards body, the WiFi Alliance > > created interim pseudo-standards specifications. Two such > > specifications are widely used in the industry, namely the WiFi > > Protect Access [WPA] and the WiFi MultiMedia [WMM] specifications. > > Given their widespread adoption, this CAPWAP binding > > supports the use > > of these two specifications. > > > > "Requires" instead of "supports", right? (Since it's mandatory to include the WPA and WMM information elements in the IEEE 802.11 Add WLAN message element.) Correct - made the change. Thanks! > > > I think the tagging text still needs some details. Is the intent > > > something like this? > > > > > > 1. If doing split MAC with native frame tunnel mode (instead of > > > 802.3): > > > replace the TID subfield of the packet with the "802.1p > > > Tag" value > > > (except if 'C' bit in IEEE 802.11 Station Session Key message > > > element is set) > > > 2. If doing local MAC: if the WTP adds an 802.1Q header for VLAN use > > > (based on VLAN Name in the Add Station message element), place > > > the "802.1p Tag" value in the 802.1Q header. > > > 3. If doing split MAC: if the WTP adds an 802.1Q header for VLAN > > > use (based on e.g. some local configuration), place the > > > "802.1p Tag" value in the 802.1Q header. > > > 4. If the packet received from the STA is an IPv4 or IPv6 packet, > > > replace the DSCP field in the IP header with the "DSCP Tag" > > > value (except if 'C' bit is set) > > > 5. For split MAC, place the "DSCP Tag" value in the IP header > > > added by the WTP for CAPWAP Data message. > > > > > > Note that here step 1 seems unnecessary -- replacing the TID before > > > the AC sees it doesn't seem to add value -- and step 4 is very > > > likely to raise questions in IESG review (as it overwrites the DSCP > > > tagging done by the STA). > > > > > > (But perhaps I understood this wrong, and some other processing was > > > intended?) > > > > OK - clearly we need to provide more clarity, so I have created a new > > section 2.6, which I include below. I believe that you have read the > > rules properly, and I have tried to be explict below about the > > treatment of QoS at the WTP. I am unsure why the IESG would have > > issues with option 4, because whether we like it or not, enterprise > > networks do not necessarily trust DSCP markings from endpoints. We can > > be blind about this, and simply leave out the text and allow > > manufacturers do what they do today (which is allow for remarking), if > > you believe this would be more acceptable to the IESG. But like it or > > not, we can't change reality. > > I'm not disagreeing that replacing the DSCP tag can be useful in some circumstances -- but it might be useful to allow *not* replacing it, while still tagging the IP header added by the WTP. > > > > > 2.6. Quality of Service > > > > The CAPWAP IEEE 802.11 binding specification provides procedures to > > allow for the WTP to enforce Quality of Service. This section will > > detail the actual procedures for both Split and Local MAC. > > > > When the WLAN is created on the WTP, a default Quality of Service > > policy through the IEEE 802.11 WTP Quality of Service > > message element > > (see Section 6.22). This default policy will cause the WTP to use > > the default QoS values for any station associated with the WLAN in > > question. The AC MAY also override the policy for a given station, > > by sending the IEEE 802.11 Update Station QoS message element (see > > Section 6.20). > > The "WTP QoS" message element allows different 802.1p Tags and DSCP Tags for e.g. Voice and Background traffic; the "Update Station QoS" > element doesn't. Is this mismatch intentional? Does the latter override all the QoS profiles? > > The "WTP QoS" message element also has a bit field saying whether to do 802.1p tagging, DSCP tagging, or both (or neither). The "Update Station QoS" element doesn't have such bit field -- how does this work? (Is e.g. the bit field for "WTP QoS" message element used -- meaning that the DSCP field in "Update Station QoS" is ignored if the DSCP bit wasn't set in "WTP QoS", or something else?) > > > Both message elements provide an "802.1p Tag", which is used by the > > WTP by adding an 802.1Q header (see [IEEE.802-1Q.2005]) with the > > priority field set according to the policy provided. Regardless of > > whether Split or Local MAC is used, the 802.1Q header processing is > > identical. > > Does the WTP always add the 802.1Q header when doing Local MAC? > (Even when bridging traffic to an untagged port?) > > For Split MAC, it obviously does not always add an 802.1Q header (the IP packets to the AC could be sent over any interface, not just those in 802.* family), so the processing needs some clarification. > But if it's e.g. wired Ethernet, is the WTP *required* to add an 802.1Q header with this value? (the WTP is working as an ordinary host, not bridge, on this interface...) > > (My lack of knowledge about 802.1Q is probably showing -- but I think the spec needs to be clear here what's the required behavior, and what's just advice.) > > > Both message elements also provide a "DSCP Tag", which is used by > > the WTP to use in the DSCP field of bot the IPv4 and IPv6 headers > > (see [RFC2474]). When the WTP operates in a Split MAC mode, the > > DSCP markings are used in the CAPWAP data plane tunnel's IP > > header. For both Split and Local MAC, the DSCP value SHOULD be > > used as a default policy by the WTP to override any markings > > received by the station in its IPv4 or IPv6 packets. Note that > > the use of WMM (see [WMM]) allows the station to request special > > QoS treatment for a given flow. > > I don't know much about WMM, but "SHOULD" sounds a bit problematic here -- probably the AC should tell the WTP what to do? (In some deployments, DSCP Tags set by the hosts might be meaningful and sufficiently trustworthy, so the AC administrator should be able to decide whether they're overwritten or not, right?) > > Also, I'm not sure I understand the "be used as a default policy... to override". Something like "is used to override" would be clear, but "default policy" is probably referring to some WMM feature related to DSCP tagging? > > (Also, the text should say this doesn't apply when the 'C' bit in IEEE > 802.11 Station Session Key message element is set). OK, so you have raised many very valid points, and instead of addressing them one by one, I will simply include the updated text. I believe that there are now changes to section 2.6 that will address your specific concerns, and it also includes clarity across the use of WMM. I am also going better judgement here and breaking backward interoperability because you raised a valid point that having a single tag for the station is not sufficient given that the WTP policy has one per QoS class. So I have modified the per station policy message element to include all four. Finally, I have introduced a new bit in the WTP policy which simply states that the station's marking is to be trusted, which means that the WTP is not to remark any packets received. The new text reads: 2.6. Quality of Service The CAPWAP IEEE 802.11 binding specification provides procedures to allow for the WTP to enforce Quality of Service. This section will detail the actual procedures for both Split and Local MAC. When the WLAN is created on the WTP, a default Quality of Service policy through the IEEE 802.11 WTP Quality of Service message element (see Section 6.22). This default policy will cause the WTP to use the default QoS values for any station associated with the WLAN in question. The AC MAY also override the policy for a given station, by sending the IEEE 802.11 Update Station QoS message element (see Section 6.20). The IEEE 802.11 WTP Quality of Service message element's Tag Packet field indicates how the packets are to be tagged; either via 802.1Q or DSCP. When an IEEE 802.11 Update Station QoS message element is received, while the specific "802.1p Tag" or DSCP values may change for a given station, the original policy of whether 802.1p or DSCP is to be used continues to be enforced by the WTP. Both message elements provide an "802.1p Tag", which is used by the WTP by adding an 802.1Q header (see [IEEE.802-1Q.2005]) with the priority field set according to the policy provided. Note this tagging is only valid for interface that support 802.1p. Regardless of whether Split or Local MAC is used, the 802.1Q header processing is identical. Both message elements also provide a "DSCP Tag", which is used by the WTP to use in the DSCP field of bot the IPv4 and IPv6 headers (see [RFC2474]). When the WTP operates in a Split MAC mode, the DSCP markings are used in the CAPWAP data plane tunnel's IP header. For both Split and Local MAC, if the 'T' bit in the IEEE 802.11 WTP Quality of Service message element's Tag Packet field is not set, the WTP MUST re-mark the DSCP field of any IPv4 or IPv6 packets based either on the default policy, known through the IEEE 802.11 WTP Quality of Service message element, or a station specific policy, known through the IEEE 802.11 Update Station QoS message element. If the 'T' bit in the IEEE 802.11 WTP Quality of Service message element's Tag Packet field is set, the WTP MUST trust the marking sent by the station. Note that in Split MAC mode, the WTP cannot re- mark the DSCP field of the station's IPv4 or IPv6 packets if encryption is performed at the AC (see Section 6.15). Note additional per flow QoS policies MAY exist if the station had requested special QoS treatment through the TSPEC information element found in the IEEE 802.11-2007's QoS Action Frame. Note that stations MAY also use the WiFi Alliance's WMM specification instead to request QoS treatment for a flow (see [WMM]). This requires the WTP to observe the Status Code in the IEEE 802.11-2007 and WMM QoS Action ADDTS responses from the AC, and provide the services requested in the TSPEC information element. Similarly, the WTP MUST observe the Reason Code information element in the IEEE 802.11-2007 and WMM QoS Action DELTS responses from the AC by removing the policy associated with the TSPEC. [...] 6.20. IEEE 802.11 Update Station QoS The IEEE 802.11 Update Station QoS message element is used to change the Quality of Service policy on the WTP for a given station. The QoS tags included in this message element are to be applied to packets received at the WTP from the station indicated through the MAC Address field. This message element overrides the default values provided through the IEEE 802.11 WTP Quality of Service message element (see Section 6.22. Any tagging performed by the WTP MUST be directly applied to the packets receive from the station, as well as the CAPWAP tunnel, if the packets are tunneled to the AC. See Section 2.6 for more information. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | QoS Sub-Element... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1043 for IEEE 802.11 Update Station QoS Length: 8 Radio ID: The Radio Identifier, typically refers to some interface index on the WTP MAC Address: The station's MAC Address. QoS Sub-Element: The IEEE 802.11 WTP Quality of Service message element contains four QoS sub-elements, one for every QoS profile. The order of the QoS profiles are Voice, Video, Best Effort and Background. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved|8021p|RSV| DSCP Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved: All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. 8021p: The three bit 802.1p priority value to use if packets are to be IEEE 802.1p tagged. RSV: All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. DSCP Tag: The 6 bit DSCP label to use if packets are eligible to be DSCP tagged, specifically an IPv4 or IPv6 packet (see [RFC2474]). [...] 6.22. IEEE 802.11 WTP Quality of Service The IEEE 802.11 WTP Quality of Service message element value is sent by the AC to the WTP to communicate quality of service configuration information. The QoS tag included in this message element are the default QoS values to be applied to packets received by the WTP from stations on a particular radio. Any tagging performed by the WTP MUST be directly applied to the packets receive from the station, as well as the CAPWAP tunnel, if the packets are tunneled to the AC. See Section 2.6 for more information. 0 1 2 3 0 1 2 3 4 5 6 7 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 | Tag Packets | QoS Sub-Element ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1045 for IEEE 802.11 WTP Quality of Service Length: 34 Radio ID: The Radio Identifier, typically refers to some interface index on the WTP Tag Packet: A bit field indicating whether CAPWAP packets should be tagged for QoS purposes. The field has the following format: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Reservd|T|D|P|U| +-+-+-+-+-+-+-+-+ Reserved: A set of reserved bits for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. T: When set, this indicates that any QoS markings on packets received from stations are to be trusted and honored. D: When set, this indicates that the CAPWAP packets should be tagged for QoS purposes using DSCP. P: When set, this indicates that the CAPWAP packets should be tagged for QoS purposes using 802.1p. U: When set, this indicates that the CAPWAP packets should be untagged. When set, both the D and P bits MUST NOT be set. QoS Sub-Element: The IEEE 802.11 WTP Quality of Service message element contains four QoS sub-elements, one for every QoS profile. The order of the QoS profiles are Voice, Video, Best Effort and Background. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Queue Depth | CWMin | CWMax | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CWMax | AIFS | Reserved|8021p|RSV| DSCP Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Queue Depth: The number of packets that can be on the specific QoS transmit queue at any given time. CWMin: The Contention Window minimum (CWmin) value for the QoS transmit queue. The value of this field comes from the IEEE 802.11 dot11EDCATableCWMin MIB element (see [IEEE.802-11.2007]). CWMax: The Contention Window maximum (CWmax) value for the QoS transmit queue. The value of this field comes from the IEEE 802.11 dot11EDCATableCWMax MIB element (see [IEEE.802-11.2007]). AIFS: The Arbitration Inter Frame Spacing (AIFS) to use for the QoS transmit queue. The value of this field comes from the IEEE 802.11 dot11EDCATableAIFSN MIB element (see [IEEE.802-11.2007]). Reserved: All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. 8021p: The three bit 802.1p priority value to use if packets are to be IEEE 802.1p tagged. RSV: All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. DSCP Tag: The 6 bit DSCP label to use if packets are eligible to be DSCP tagged, specifically an IPv4 or IPv6 packet (see [RFC2474]). My apologies for the multiple round trips, but I have to admit understanding your issues is really helping improve the quality of the specification, so I appreciate the time you are putting into this. Does the above address your comments? PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 19 18:55:02 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 689A43A6817 for ; Tue, 19 Aug 2008 18:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVbfzzq5BKUJ for ; Tue, 19 Aug 2008 18:55:00 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 7BAE83A67FA for ; Tue, 19 Aug 2008 18:55:00 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 05DBF1C40FD5 for ; Tue, 19 Aug 2008 18:53:33 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 5927A44015B for ; Tue, 19 Aug 2008 18:53:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4312D34AC05C for ; Tue, 19 Aug 2008 18:53:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 5C07534AC05B for ; Tue, 19 Aug 2008 18:53:25 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 19 Aug 2008 18:53:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,238,1217808000"; d="scan'208";a="142625087" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 20 Aug 2008 01:53:21 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m7K1rLxt009071; Tue, 19 Aug 2008 18:53:21 -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.13.8/8.13.8) with ESMTP id m7K1rKkT013417; Wed, 20 Aug 2008 01:53:21 GMT 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.1830); Tue, 19 Aug 2008 18:50:29 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 18:50:28 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20650D9B9@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB720161D3FA@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Last call comments forcapwap-protocol-binding-ieee80211-07 Thread-Index: AcjxWvvYp8NTYNntQ6KnjwjYAMoZswBPfGhwAY62tJAABD6gUAIgXFOgACiskVAADAKicAALPkSA References: <1696498986EFEC4D9153717DA325CB72013BA889@vaebe104.NOE.Nokia.com><4FF84B0BC277FF45AA27FE969DD956A20632FDC3@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB72014C62A7@vaebe104.NOE.Nokia.com><4FF84B0BC277FF45AA27FE969DD956A2064598B4@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB720161CBE8@vaebe104.NOE.Nokia.com><4FF84B0BC277FF45AA27FE969DD956A2064B7976@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720161D3FA@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 20 Aug 2008 01:50:29.0793 (UTC) FILETIME=[1FF6E110:01C90267] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] Last call comments forcapwap-protocol-binding-ieee80211-07 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com > > > > > > > > 2.2.1. Split MAC > > > > [...] > > > > > > > > o The WTP generates the IEEE 802.11 Beacon frames, using > > > > information > > > > provided to it through the IEEE 802.11 Add WLAN (see > > > > Section 6.1) > > > > message element, including the RSNIE, which > > > > indicates support of 802.1X and AES-CCMP. > > > > > > > > > > Yes, but the spec isn't very clear on how the RSN IE exactly is > > processed by the WTP (the IE has number of different fields). > > > > The WTP does not need to perform any processing of the RSN IE. The IE > > is included in the Beacon and Probe Responses as-is by the WTP. Any > > cryptographic policies are sent by the AC either through the Add > > Station or the Session Key message elements. > > By "processing", I meant the WTP has to parse the contents of the RSN IE, find some field(s) inside it, and use those value(s) for something. > Both Sections 6.1 and 6.15 say the WTP does this; I'd like to see more details for "some field(s)" and "something". > > (Presumably, other IEs are just stored and copied to Beacons and Probe Responses -- the WTP doesn't need to parse them. Is this correct?). I think you are asking two separate questions. In terms of what processing needs to happen when the WLAN is created, which requires that many IEs are sent, including RSN, the answer is none. The WTP only includes them in the Beacons and Probe Responses. > > So in order to provide more clarity, I propose adding the first > > sentence in the last paragraph of the following text: > > > > > > 6.1. IEEE 802.11 Add WLAN > > [...] > > Power Constraint information element > > > > EDCA Parameter Set information element > > > > QoS Capability information element > > > > WPA information element [WPA] > > > > RSN information element > > > > WMM information element [WMM] > > > > These IEEE 802.11 information elements are stored by the WTP and > > included in any Probe Responses and Beacons generated, as specified > > in the IEEE 802.11 standard [IEEE.802-11.2007]. If > > present, the RSN > > information element is sent with the IEEE 802.11 Add WLAN message > > element to instruct the WTP on the usage of the Key field. > > > > As I wrote above, I don't think "instruct" is enough here, or in Section 6.15. Which fields are used, and how? > > (As an example of ambiguity, the RSN IE can list multiple pairwise cipher suites. If both TKIP and CCMP are listed in the RSN IE, what does the WTP do? The IEEE 802.11 Station Session Key message element could -- and perhaps should -- contain a "Cipher Suite" > field, but currently, it doesn't.) OK, now in terms of Section 6.15, there is some processing required. Sorry, I thought you were talking about the beacons/probes, not this section. In the IEEE standard, the AP can advertise multiple cipher suites in the Beacon and Probe Responses, but it confirms the cipher to use in message three of the 4-Way Key Handshake. So I have modified the text in section 6.15 to be specific about the cipher and AKM fields. So the new text reads: 6.15. IEEE 802.11 Station Session Key [...] The RSN information element MUST sent along with the IEEE 802.11 Station Session Key in order to instruct the WTP on the usage of the Key field. The WTP MUST observe the AKM field of the RSN information element in order to identify the authentication protocol to be enforced with the station. If cryptographic services are provided at the WTP, the WTP MUST observe the algorithm dictated in the Pairwise Cipher Suite field of the RSN information element sent by the AC. The RSN Information Element included here is the one sent by the AC in the third message of the 4-Way Key Handshake, which specifies which cipher is to be applied to provide encryption and decryption services with the station. The RSN Information Element is used to communicate any supported algorithm, including WEP, TKIP and AES-CCMP. In the case of static WEP keys, the RSN Information Element is still used to indicate the cryptographic algorithm even though no key exchange occurred. Does this address your comment? PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 20 05:26:22 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 125023A6811 for ; Wed, 20 Aug 2008 05:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.374 X-Spam-Level: X-Spam-Status: No, score=-4.374 tagged_above=-999 required=5 tests=[AWL=-0.775, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fv-DMuu+kAB6 for ; Wed, 20 Aug 2008 05:26:21 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 11F4D3A68C0 for ; Wed, 20 Aug 2008 05:26:21 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7D1E943315F for ; Wed, 20 Aug 2008 05:25:35 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 4E9D3440157 for ; Wed, 20 Aug 2008 05:25:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 383A634AC105 for ; Wed, 20 Aug 2008 05:25:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2C0B234AC08A for ; Wed, 20 Aug 2008 05:25:20 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.122.233 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 20 Aug 2008 05:25:19 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7KCP8Pq019465; Wed, 20 Aug 2008 15:25:13 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 15:25:11 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 15:25:04 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Aug 2008 15:25:03 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720161D958@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2064B7D35@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 166: Various IANA Issues Thread-Index: AcjyfwiGWFFYbM34RwGLIXgw/+Uu9wGXDdqQASeRViABGTLZsAAbO8hQABzifMA= References: <4FF84B0BC277FF45AA27FE969DD956A20632FC22@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C62A8@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064598C7@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720161CF38@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064B7D35@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 20 Aug 2008 12:25:04.0779 (UTC) FILETIME=[C66CADB0:01C902BF] X-Nokia-AV: Clean Subject: Re: [Capwap] Issue 166: Various IANA Issues X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun wrote: > My apologies - I completely misunderstood the original comment. I see > now what you are asking. I have modified the text to: > > > 15.10. AC Information Type > > The Information Type field in the AC Descriptor message > element (see > Section 4.6.1) is used to represent information about the AC. The > namespace is 16 bits (0-65535), where the value of zero (0) is > reserved and must not be assigned. This field, combined > with the AC > Information Vendor ID, allows vendors to use a private namespace. > This specification defines the AC Information Type > namespace when the > AC Information Vendor ID is set to zero (0), for which the values > four (4) and five (5) are allocated in this specification, > and can be > found in Section 4.6.1. This namespace is managed by IANA and > assignments require a Expert Review. IANA will create the AC > Information Type registry, whose format is: > > AC Information Type Type Value Reference This makes sense. Couple of words should be added to Section 4.6.1 as well, explicitly saying that 4/5 are with vendor ID 0. > 15.20. WTP Board Data Type > > The Board Data Type field in the WTP Board Data message > element (see > Section 4.6.39) is used to represent information about the WTP > hardware. The namespace is 16 bits (0-65535). This > field, combined > with the Vendor ID field, allows vendors to use a private > namespace. > This specification defines the WTP Board Data Type > namespace when the > Vendor ID field is set to zero (0), for which the values zero (0) > through four (4) are allocated in this specification, and can be > found in Section 4.6.39. This namespace is managed by IANA and > assignments require a Expert Review. IANA will create the > WTP Board > Data Type registry, whose format is: > > WTP Board Data Type Type Value Reference > > > Makes sense? Again, saying in 4.6.40 that the values 0..4 are with Vendor ID 0 would clarify the situation a lot. However, there's one difference here: in WTP Board Data, the Vendor Identifier is listed only once (it's not repeated for every WTP Board Data Type field). So if an implementation would send both (Vendor ID=0, Type=1) and (Vendor ID=123, Type=456), would it send two WTP Board Data message elements? (In this case, Section 4.6.40 should say more than one can be sent, and Sections 5.1, 5.3, and 6.1 should say "WTP Board Data message element(s)" instead of just "WTP Board Data"). Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 20 05:27:50 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCF293A68C0 for ; Wed, 20 Aug 2008 05:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.355 X-Spam-Level: X-Spam-Status: No, score=-4.355 tagged_above=-999 required=5 tests=[AWL=-0.756, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d30EL1taHidT for ; Wed, 20 Aug 2008 05:27:49 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 7DFB23A6811 for ; Wed, 20 Aug 2008 05:27:49 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3407F433D57 for ; Wed, 20 Aug 2008 05:27:22 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 098AF44015E for ; Wed, 20 Aug 2008 05:27:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id CBC5434AC051 for ; Wed, 20 Aug 2008 05:27:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8F16734AC00B for ; Wed, 20 Aug 2008 05:27:15 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.122.230 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 20 Aug 2008 05:27:15 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7KCQwMp016521; Wed, 20 Aug 2008 15:27:11 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 15:26:51 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 15:26:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Aug 2008 15:26:45 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720161D95E@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2064B7D1F@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Recap of current pending issues Thread-Index: Acjz9xoEqCcXlGoTT6y9r7yIArdLFwDULppAAGVprtABKASH0AEXEvfAABwI+PAAHYApQA== References: <4FF84B0BC277FF45AA27FE969DD956A2063304F7@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A206393CCC@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C62AB@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064598F1@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720161CF0C@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064B7D1F@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 20 Aug 2008 12:26:46.0299 (UTC) FILETIME=[02EF66B0:01C902C0] X-Nokia-AV: Clean Subject: Re: [Capwap] Recap of current pending issues X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Looks good -- thanks! Best regards, Pasi > -----Original Message----- > From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: 20 August, 2008 01:23 > To: Eronen Pasi (Nokia-NRC/Helsinki); capwap@frascone.com > Subject: RE: Recap of current pending issues > > Thanks Pasi, that was very useful. You did not cover all of > the cases in > the existing section, so I presume you were only providing > text to cover > the issues you had. With this assumption in mind, the new > section looks > like: > > > 4.5.3. Retransmissions > > The CAPWAP control protocol operates as a reliable transport. For > each Request message, a Response message is defined, which > is used to > acknowledge receipt of the Request message. In addition, > the control > header Sequence Number field is used to pair the Request > and Response > messages (see Section 4.5.1). > > Response messages are not explicitly acknowledged, therefore if a > Response message is not received, the original Request message is > retransmitted. > > Implementations MUST keep track of the Sequence Number of the last > received Request message, and MUST cache the corresponding Response > message. If a retransmission with the same Sequence Number is > received, the cached Response message MUST be retransmitted without > re-processing the Request. If an older Request message > (with smaller > Sequence Number modulo 32) is received, it MUST be > ignored. A newer > Request message (with larger Sequence Number modulo 32) is > processed > as usual. > > Both the WTP and the AC can only have a single request > outstanding at > any given time. Retransmitted Request messages MUST NOT be altered > by the sender. > > After transmitting a Request message, the RetransmitInterval (see > Section 4.7) timer and MaxRetransmit (see Section 4.8) variable are > used to determine if the original Request message needs to be > retransmitted. The RetransmitInterval timer is used the first time > the Request is retransmitted. The timer is then doubled every > subsequent time the same Request message is retransmitted, up to > MaxRetransmit but no more than half the EchoInterval timer (see > Section 4.7.7). Response messages are not subject to these timers. > > If the sender stops retransmitting a Request message > before reaching > MaxRetransmit retransmissions (which leads to transition to DTLS > Teardown, as described in Section 2.3.1), it cannot know > whether the > recipient received and processed the Request or not. In most > situations, the sender SHOULD NOT do this, and instead continue > retransmitting until a Response message is received, or > transition to > DTLS Teardown occurs. However, if the sender does decide > to continue > the connection with a new or modified Request message, the new > message MUST have a new Sequence Number, and be treated as a new > Request message by the receiver. > > When a Request message is retransmitted, it MUST be > re-encrypted via > the DTLS stack. If the peer had received the Request message, and > the corresponding Response message was lost, it is necessary to > ensure that retransmitted Request messages are not identified as > replays by the DTLS stack. Similarly, any cached Response messages > that are retransmitted as a result of receiving a retransmitted > Request message MUST be re-encrypted via DTLS. > > Duplicate Response messages, identified by the Sequence > Number field > in the CAPWAP control message header, SHOULD be discarded upon > receipt. > > > PatC > > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Tuesday, August 19, 2008 2:30 AM > To: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: RE: Recap of current pending issues > > Pat Calhoun wrote: > >> The answer (you can't have multiple outstanding requests) really > >> needs to be in the spec. Also, the spec needs some more text about > >> how the receiver processes them -- e.g. does the receiver maintain > >> "last seen sequence number" counter, and silently drop (without > >> replying) requests older than this? > > > > > > I believe some of this was already covered, but I have added a new > > sentence to the end of the first paragraph. I am including some > > additional language that does address some of your concern that was > > already in the spec: > > > > > > 4.5.3. Retransmissions > > > > The CAPWAP control protocol operates as a reliable transport. > > For each Request message, a Response message is defined, which is > > used to acknowledge receipt of the Request message. In addition, > > the control header Sequence Number field is used to pair the > > Request and Response messages (see Section 4.5.1). This > > Request/Response pair, combined with the Sequence Number, implies > > that both the WTP and the AC can only have a single request > > outstanding at any given time. > > Hmm... it doesn't really *imply* it. For example, IKEv2 has almost > identical approach -- request/response pairs, sequence > number, same way > of doing retransmissions -- but does allow multiple > outstanding requests > (in some circumstances). > > Also, the definition of the Sequence Number field (4.5.1.2) says that > "counter is monotonically incremented, ensuring that no two pending > Request messages have the same Sequence Number" -- this sentence makes > sense only if there can be more than one pending request. > > > Response messages are not explicitly acknowledged, therefore if a > > Response message is not received, the original Request message is > > retransmitted. Implementations MAY cache Response messages to > > respond to a retransmitted Request messages with minimal local > > processing. > > It isn't quite clear what the alternative to this "MAY" (what > should an > implementation that doesn't cache the Response message do). > > The most obvious answer would be to "process the message as usual and > generate a reply", but unfortunately, that doesn't seem to > work for all > messages (for example, if the WTP processes retransmissions of Image > Data Requests as normal requests, it seems the resulting > image would be > wrong). > > I'd suggest just making caching the Response message a MUST -- this > would be the simplest solution, both specification-wise and > implementation-wise. (A possible alternative might involve keeping a > "Last Received Sequence Number" field, and specifying how to > process the > messages and generate a correct reply without really processing the > message. Or making all Request messages idempotent. But those seem > complex.) > > > Retransmitted Request messages MUST NOT be altered > > by the sender. The sender MUST assume that the original Request > > message was processed, but that the Response message was lost. > > I doubt any implementation would actually follow this "MUST assume". > > (E.g. if the AC is sending Image Data Requests, does it make sense to > assume the WTP really received it, and move to the next image data > block? Or if the Station Configuration Request isn't acknowledged, > would the AC assume that station is now configured OK?) > > Also, the state machine says that if you reach the MaxRetransmit count > without receiving a response, you move to DTLS Teardown state. > > In theory, you could abandon a Request for other reason that reaching > the MaxRetransmit count (perhaps you changed your mind, and > didn't want > to do it anyway). But then you can't know whether the > recipient received > and processed it, leaving things is slightly indeterminate state. > > > Any alterations to the original Request message MUST have a new > > Sequence Number, and be treated as a new Request message by the > > receiver. > > Here's a suggestion based on my comments above: > > 4.5.3. Retransmissions > > The CAPWAP control protocol operates as a reliable transport. For > each Request message, a Response message is defined, which is used > to acknowledge receipt of the Request message. In addition, the > control header Sequence Number field is used to pair the Request > and Response messages (see Section 4.5.1). > > Response messages are not explicitly acknowledged, therefore if a > Response message is not received, the original Request message is > retransmitted. > > Implementations MUST keep track of the Sequence Number of the last > received Request message, and MUST cache the corresponding Response > message. If a retransmission with the same Sequence Number is > received, the cached Response message MUST be retransmitted without > re-processing the Request. If an older Request message (with > smaller Sequence Number modulo 32) is received, it MUST be > ignored. A newer Request message (with larger Sequence Number > modulo 32) is processed as usual. > > Both the WTP and the AC can only have a single request outstanding > at any given time. Retransmitted Request messages MUST NOT be > altered by the sender. > > If the sender stops retransmitting a Request message before > reaching MaxRetransmit retransmissions (which leads to transition > to DTLS Teardown, as described in Section 2.3.1), it cannot know > whether the recipient received and processed the Request or not. > In most situations, the sender SHOULD NOT do this, and instead > continue retransmitting until a Response message is received, > or transition to DTLS Teardown occurs. However, if the > sender does decide to continue the connection with a new or > modified Request message, the new message MUST have a new Sequence > Number, and be treated as a new Request message by the receiver. > > Best regards, > Pasi > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 20 06:18:27 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2767D3A68C3 for ; Wed, 20 Aug 2008 06:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1W6s82uA+PZb for ; Wed, 20 Aug 2008 06:18:26 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 0232E3A6B89 for ; Wed, 20 Aug 2008 06:18:26 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5B30B1C40F9C for ; Wed, 20 Aug 2008 06:17:28 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 7CE5A44015E for ; Wed, 20 Aug 2008 06:17:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 560FD34AC046 for ; Wed, 20 Aug 2008 06:17:21 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id AFA6434AC012 for ; Wed, 20 Aug 2008 06:17:19 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 20 Aug 2008 06:17:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,239,1217808000"; d="scan'208";a="76831525" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 20 Aug 2008 13:17:12 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m7KDH9VD032543; Wed, 20 Aug 2008 06:17:09 -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.13.8/8.13.8) with ESMTP id m7KDH9DW012068; Wed, 20 Aug 2008 13:17:09 GMT 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.1830); Wed, 20 Aug 2008 06:17:09 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Aug 2008 06:17:09 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20650DA47@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB720161D958@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 166: Various IANA Issues Thread-Index: AcjyfwiGWFFYbM34RwGLIXgw/+Uu9wGXDdqQASeRViABGTLZsAAbO8hQABzifMAAAUqW0A== References: <4FF84B0BC277FF45AA27FE969DD956A20632FC22@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72014C62A8@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064598C7@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720161CF38@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064B7D35@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720161D958@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 20 Aug 2008 13:17:09.0491 (UTC) FILETIME=[0CE5E430:01C902C7] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Capwap] Issue 166: Various IANA Issues X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com > This makes sense. Couple of words should be added to Section 4.6.1 as well, explicitly saying that 4/5 are with vendor > ID 0. Yes, here is the new text: 4.6.1. AC Descriptor [...] AC Information Type: Vendor specific encoding of AC information. The following enumerated values are supported. Both the Hardware and Software Version sub-elements MUST be included in the AC Descriptor message element. The values listed below are used in conjunction with the AC Information Vendor Identifier field, whose value MUST be set to zero (0). 4 - Hardware Version: The AC's hardware version number. 5 - Software Version: The AC's Software (firmware) version number. > Again, saying in 4.6.40 that the values 0..4 are with Vendor ID 0 would clarify the situation a lot. Yes, I have made the necessary change. The text now reads: 4.6.40. WTP Descriptor [...] Descriptor Type: The Descriptor Type field identifies the data being encoded. The CAPWAP protocol defines the following values, and each of these types identify whether their presence is mandatory or optional. The values listed below are used in conjunction with the Descriptor Vendor Identifier field, whose value MUST be set to zero (0). 0 - Hardware Version: The WTP hardware version number MUST be present. 1 - Active Software Version: The WTP running software version number MUST be present. 2 - Boot Version: The WTP boot loader version number MUST be present. 3 - Other Software Version: The WTP non-running software (firmware) version number MAY be present. This type is used to communicate alternate software versions that are available on the WTP's non-volatile storage. 15.21. WTP Descriptor Type The Descriptor Type field in the WTP Descriptor message element (see Section 4.6.40) is used to represent information about the WTP software. The namespace is 16 bits (0-65535). This field, combined with the Descriptor Vendor ID, allows vendors to use a private namespace. This specification defines the WTP Descriptor Type namespace when the Descriptor Vendor ID is set to zero (0), for which the values zero (0) through three (3) are allocated in this specification, and can be found in Section 4.6.40. This namespace is managed by IANA and assignments require a Expert Review. IANA will create the WTP Board Data Type registry, whose format is: > > However, there's one difference here: in WTP Board Data, the Vendor Identifier is listed only once (it's not repeated > for every WTP Board Data Type field). So if an implementation would send both (Vendor ID=0, Type=1) and (Vendor ID=123, > Type=456), would it send two WTP Board Data message elements? > > (In this case, Section 4.6.40 should say more than one can be sent, and Sections 5.1, 5.3, and 6.1 should say "WTP > Board Data message element(s)" instead of just "WTP Board Data"). I need to apologize profusely. I *just* realized the original intent, and the reason why the Vendor ID was called out separately. The WTP Board Data Types are not used in conjunction with the Vendor ID. The Vendor ID is used to identify the HW manufacturer, while the data types are used consistently across all implementations. This requires going back to the original IANA considerations text, but also a small tweak to the WTP Board Data Vendor ID field descriptor: 4.6.39. WTP Board Data [...] Vendor Identifier: A 32-bit value containing the IANA assigned "SMI Network Management Private Enterprise Codes", identifying the WTP hardware manufacturer. 15.20. WTP Board Data Type The Board Data Type field in the WTP Board Data message element (see Section 4.6.39) is used to represent information about the WTP hardware. The namespace is 16 bits (0-65535). The WTP Board Data Type values zero (0) through four (4) are allocated in this specification, and can be found in Section 4.6.39. This namespace is managed by IANA and assignments require a Expert Review. IANA will create the WTP Board Data Type registry, whose format is: PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 21 01:07:50 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18E528C142 for ; Thu, 21 Aug 2008 01:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.365 X-Spam-Level: X-Spam-Status: No, score=-4.365 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieXU4E7tH6PP for ; Thu, 21 Aug 2008 01:07:49 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 67D013A69C3 for ; Thu, 21 Aug 2008 01:07:49 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EB889430A87 for ; Thu, 21 Aug 2008 01:07:20 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id B35D644018B for ; Thu, 21 Aug 2008 01:07:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id A106E34AC0C3 for ; Thu, 21 Aug 2008 01:07:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 05A3434AC06B for ; Thu, 21 Aug 2008 01:07:14 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (192.100.122.230 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 21 Aug 2008 01:07:13 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7L86s7Y026993; Thu, 21 Aug 2008 11:06:58 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Aug 2008 11:06:55 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Aug 2008 11:06:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Aug 2008 11:06:46 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720168E553@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20650D9B9@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Last call comments forcapwap-protocol-binding-ieee80211-07 Thread-Index: AcjxWvvYp8NTYNntQ6KnjwjYAMoZswBPfGhwAY62tJAABD6gUAIgXFOgACiskVAADAKicAALPkSAAD+NazA= References: <1696498986EFEC4D9153717DA325CB72013BA889@vaebe104.NOE.Nokia.com><4FF84B0BC277FF45AA27FE969DD956A20632FDC3@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB72014C62A7@vaebe104.NOE.Nokia.com><4FF84B0BC277FF45AA27FE969DD956A2064598B4@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB720161CBE8@vaebe104.NOE.Nokia.com><4FF84B0BC277FF45AA27FE969DD956A2064B7976@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720161D3FA@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20650D9B9@xmb-sjc-235.amer.cisco.com> From: To: X-OriginalArrivalTime: 21 Aug 2008 08:06:46.0761 (UTC) FILETIME=[DB4C8D90:01C90364] X-Nokia-AV: Clean Cc: capwap@frascone.com Subject: Re: [Capwap] Last call comments forcapwap-protocol-binding-ieee80211-07 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun wrote: > > By "processing", I meant the WTP has to parse the contents of the > > RSN IE, find some field(s) inside it, and use those value(s) for > > something. Both Sections 6.1 and 6.15 say the WTP does this; I'd > > like to see more details for "some field(s)" and "something". > > > > (Presumably, other IEs are just stored and copied to Beacons and > > Probe Responses -- the WTP doesn't need to parse them. Is this > > correct?). > > I think you are asking two separate questions. In terms of what > processing needs to happen when the WLAN is created, which requires > that many IEs are sent, including RSN, the answer is none. The WTP > only includes them in the Beacons and Probe Responses. It seems the WTP has to parse the RSN IE to find out at least the Group Cipher suite, no? > > (As an example of ambiguity, the RSN IE can list multiple pairwise > > cipher suites. If both TKIP and CCMP are listed in the RSN IE, > > what does the WTP do? The IEEE 802.11 Station Session Key message > > element could -- and perhaps should -- contain a "Cipher Suite" > > field, but currently, it doesn't.) > > OK, now in terms of Section 6.15, there is some processing required. > Sorry, I thought you were talking about the beacons/probes, not this > section. In the IEEE standard, the AP can advertise multiple cipher > suites in the Beacon and Probe Responses, but it confirms the cipher > to use in message three of the 4-Way Key Handshake. So I have > modified the text in section 6.15 to be specific about the cipher > and AKM fields. So the new text reads: > > > 6.15. IEEE 802.11 Station Session Key > [...] > > The RSN information element MUST sent along with the IEEE 802.11 > Station Session Key in order to instruct the WTP on the usage of > the Key field. The WTP MUST observe the AKM field of the RSN > information element in order to identify the authentication > protocol to be enforced with the station. > > If cryptographic services are provided at the WTP, the WTP MUST > observe the algorithm dictated in the Pairwise Cipher Suite field > of the RSN information element sent by the AC. The RSN > Information Element included here is the one sent by the AC in > the third message of the 4-Way Key Handshake, which specifies > which cipher is to be applied to provide encryption and > decryption services with the station. The RSN Information > Element is used to communicate any supported algorithm, including > WEP, TKIP and AES-CCMP. In the case of static WEP keys, the RSN > Information Element is still used to indicate the cryptographic > algorithm even though no key exchange occurred. > > > > Does this address your comment? Yes, this looks clear enough. Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 21 07:03:13 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BA733A6AF4 for ; Thu, 21 Aug 2008 07:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyWqLwzJef8B for ; Thu, 21 Aug 2008 07:03:12 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id A8C763A684A for ; Thu, 21 Aug 2008 07:03:12 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5180C1C40F80 for ; Thu, 21 Aug 2008 07:02:03 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 7EFA744019F for ; Thu, 21 Aug 2008 07:01:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 6826F34AC117 for ; Thu, 21 Aug 2008 07:01:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id A11D034AC10C for ; Thu, 21 Aug 2008 07:01:56 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from pass-seymour.com (marussyr001.pass-seymour.com [12.33.96.185]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 21 Aug 2008 07:01:56 -0700 (PDT) Received: from ([172.16.5.211]) by Marussyr001.pass-seymour.com with ESMTP id 5202449.45963263; Thu, 21 Aug 2008 09:54:22 -0400 From: mike.hines@ortronics.com To: capwap@frascone.com Message-ID: Date: Thu, 21 Aug 2008 10:01:33 -0400 X-MIMETrack: Serialize by Router on US-SYR-HUB-01/SRV/GRPLEG(Release 6.5.6|March 06, 2007) at 08/21/2008 10:01:34 AM MIME-Version: 1.0 Subject: [Capwap] Mike Hines/PSL/US is out of the office. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com I will be out of the office starting 08/20/2008 and will not return until 09/08/2008. In my absence, feel free to leave an e-mail or contact Rudy Montgelas at (860) 405-2969 / rudolph.montgelas@ortronics.com for immediate assistance. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 21 09:38:10 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043DD3A6914 for ; Thu, 21 Aug 2008 09:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FUZZY_CPILL=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9jSe2iQGTju for ; Thu, 21 Aug 2008 09:38:09 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 064263A6780 for ; Thu, 21 Aug 2008 09:38:08 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 71CBB1C40F75 for ; Thu, 21 Aug 2008 09:24:38 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 5ECE04401A5 for ; Thu, 21 Aug 2008 09:24:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3F9C834AC164 for ; Thu, 21 Aug 2008 09:24:32 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 6E62B34AC152 for ; Thu, 21 Aug 2008 09:23:51 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low); Accepted (Neutral) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 21 Aug 2008 09:23:51 -0700 (PDT) Received: from [209.86.224.46] (helo=elwamui-royal.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KWCwu-0005DZ-Pp; Thu, 21 Aug 2008 12:23:48 -0400 Received: from 216.31.249.246 by webmail.atl.earthlink.net with HTTP; Thu, 21 Aug 2008 12:23:48 -0400 Message-ID: <26417781.1219335828729.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Date: Thu, 21 Aug 2008 09:23:48 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "Pat Calhoun (pacalhou)" , Pasi.Eronen@nokia.com, clancy@ltsnet.net Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7b7f19f0d9c038d9aa007fff1e6bcba7ab7a3ff6e8ee9b875c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.46 Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com okay with me. -----Original Message----- >From: "Pat Calhoun (pacalhou)" >Sent: Aug 19, 2008 2:41 PM >To: Pasi.Eronen@nokia.com, skelly@arubanetworks.com, clancy@ltsnet.net >Cc: capwap@frascone.com >Subject: Re: [Capwap] Issue 168: DTLS and Retransmissions > >Scott/Charles, are we good with this? Can I close this issue with the >recommended text below? > >PatC > >-----Original Message----- >From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] >Sent: Tuesday, August 19, 2008 1:10 PM >To: Pat Calhoun (pacalhou); skelly@arubanetworks.com; clancy@ltsnet.net >Cc: capwap@frascone.com >Subject: RE: [Capwap] Issue 168: DTLS and Retransmissions > >Pat Calhoun wrote: > >> So just to be clear, your request is to replace the first paragraph >> only. The resulting section would read as follows: > >No, the 2nd paragraph, the three bullets, and the paragraph following >the bullets also need work... but much of the text is really redundant >with the new 1st paragraph, so this could be shortened (while fixing the >incorrect parts at the same time) -- see below. > >> >> 2.4.3. DTLS Error Handling >> >> If the AC or WTP does not respond to any DTLS handshake messages >> sent by its peer, the DTLS specification calls for the message to >> be retransmited. Note that during the handshake, when both the >> AC and the WTP are expecting additional handshake messages, they >> both retransmit if an expected message has not been received >> (note that retransmissions for CAPWAP Control messages work >> differently: all CAPWAP Control messages are either requests or >> responses, and the peer who sent the request is responsible for >> retransmissions). >> >> If the WTP does not respond to any DTLS handshake messages sent >> by the AC, the CAPWAP protocol allows for three possibilities, >> listed below. Note that DTLS MAY send a single TLS Alert message >> to the AC to indicate session termination. >> >> o The message was lost in transit; in this case, the DTLS >> implementation on the WTP will retransmit its last outstanding >> handshake message, since it did not receive a reply. >> >> o The WTP sent a DTLS Alert, which was lost in transit; in this >> case, the AC's WaitDTLS timer will expire, and the >> session will be >> terminated. >> >> o Communication with the WTP has completely failed; in this case, >> the AC's WaitDTLS timer will expire, and the session will be >> terminated. >> >> The DTLS specification provides for retransmission of >> unacknowledged >> requests. If retransmissions remain unacknowledged, the WaitDTLS >> timer will eventually expire, at which time the CAPWAP >> component will >> terminate the session. > >Probably everything from the 2nd paragraph to here could be summarized >something like this: > > If the WTP or the AC does not receive an expected DTLS handshake > message despite of retransmissions, the WaitDTLS timer will > eventually expire, and the session will be terminated. This can > happen if communication between the peers has completely failed, or > if one of the peers sent a DTLS Alert message which was lost in > transit (DTLS does not retransmit Alert messages). > >Best regards, >Pasi >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/capwap > >Archives: http://lists.frascone.com/pipermail/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 Aug 21 11:41:24 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3CDD3A6AB8 for ; Thu, 21 Aug 2008 11:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3S2UL+XoQ+ff for ; Thu, 21 Aug 2008 11:41:23 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 91B1E3A68FF for ; Thu, 21 Aug 2008 11:41:23 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D96D143B629 for ; Thu, 21 Aug 2008 11:40:40 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 3D39444002B for ; Thu, 21 Aug 2008 11:40:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 21B4734AC16B for ; Thu, 21 Aug 2008 11:40:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 38AEB3688006 for ; Thu, 21 Aug 2008 11:39:23 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted (171.68.10.87 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 21 Aug 2008 11:39:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,246,1217808000"; d="scan'208";a="42717406" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 21 Aug 2008 18:39:14 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m7LIdEGU011265; Thu, 21 Aug 2008 11:39:14 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m7LIdEhH027459; Thu, 21 Aug 2008 18:39:14 GMT 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.1830); Thu, 21 Aug 2008 11:39:14 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Aug 2008 11:39:13 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20650E1D3@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB720168E553@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Last call comments forcapwap-protocol-binding-ieee80211-07 Thread-Index: AcjxWvvYp8NTYNntQ6KnjwjYAMoZswBPfGhwAY62tJAABD6gUAIgXFOgACiskVAADAKicAALPkSAAD+NazAAFjaDgA== References: <1696498986EFEC4D9153717DA325CB72013BA889@vaebe104.NOE.Nokia.com><4FF84B0BC277FF45AA27FE969DD956A20632FDC3@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB72014C62A7@vaebe104.NOE.Nokia.com><4FF84B0BC277FF45AA27FE969DD956A2064598B4@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB720161CBE8@vaebe104.NOE.Nokia.com><4FF84B0BC277FF45AA27FE969DD956A2064B7976@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720161D3FA@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20650D9B9@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720168E553@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 21 Aug 2008 18:39:14.0463 (UTC) FILETIME=[35E45AF0:01C903BD] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: capwap@frascone.com Subject: Re: [Capwap] Last call comments forcapwap-protocol-binding-ieee80211-07 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com > > > By "processing", I meant the WTP has to parse the contents of the > > > RSN IE, find some field(s) inside it, and use those value(s) for > > > something. Both Sections 6.1 and 6.15 say the WTP does this; I'd > > > like to see more details for "some field(s)" and "something". > > > > > > (Presumably, other IEs are just stored and copied to Beacons and > > > Probe Responses -- the WTP doesn't need to parse them. Is this > > > correct?). > > > > I think you are asking two separate questions. In terms of what > > processing needs to happen when the WLAN is created, which requires > > that many IEs are sent, including RSN, the answer is none. The WTP > > only includes them in the Beacons and Probe Responses. > > It seems the WTP has to parse the RSN IE to find out at least the Group Cipher suite, no? Got it. Here is the new text: 6.1. IEEE 802.11 Add WLAN [...] If cryptographic services are provided at the WTP, the WTP MUST observe the algorithm dictated in the Group Cipher Suite field of the RSN information element sent by the AC. The RSN Information Element is used to communicate any supported algorithm, including WEP, TKIP and AES-CCMP. In the case of static WEP keys, the RSN Information Element is still used to indicate the cryptographic algorithm even though no key exchange occurred. The same text was added to section 6.21 (IEEE 802.11 Update WLAN). PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 25 03:18:36 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F7053A689E for ; Mon, 25 Aug 2008 03:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUvuju4yA4HB for ; Mon, 25 Aug 2008 03:18:34 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id CDACA3A6B4C for ; Mon, 25 Aug 2008 03:18:34 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 632881C40FCE for ; Mon, 25 Aug 2008 03:17:55 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 83FBF4401C9 for ; Mon, 25 Aug 2008 03:17:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 6F41634AC04D for ; Mon, 25 Aug 2008 03:17:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4A3D134AC01D for ; Mon, 25 Aug 2008 03:17:48 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted TTSSA (192.100.122.233 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 25 Aug 2008 03:17:47 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7PAHXQ3025446; Mon, 25 Aug 2008 13:17:42 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Aug 2008 13:17:31 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Aug 2008 13:16:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Aug 2008 13:16:15 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72016F99FF@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2064B7DD9@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 171: Pasi nits on binding spec Thread-Index: AcjzL5wHOa8wpdqYQUmSlvTmZmTg1QFnnI4QAAUEOaAAGNrSwAEJI2JQADKYLFAAzSR4AAAow9ZAAAhYyBAACIiHYAER2Hqw References: <4FF84B0BC277FF45AA27FE969DD956A20633000B@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB72014C629F@vaebe104.NOE.Nokia.com><4FF84B0BC277FF45AA27FE969DD956A2063E6823@xmb-sjc-235.amer.cisco.com><1696498986EFEC4D9153717DA325CB720150BDF9@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A20645989D@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A206459CDF@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720161CC1B@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064B7A0E@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720161D3DF@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A2064B7DD9@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 25 Aug 2008 10:16:54.0193 (UTC) FILETIME=[B28B2210:01C9069B] X-Nokia-AV: Clean Subject: Re: [Capwap] Issue 171: Pasi nits on binding spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun wrote: > OK, so you have raised many very valid points, and instead of > addressing them one by one, I will simply include the updated > text. I believe that there are now changes to section 2.6 that will > address your specific concerns, and it also includes clarity across > the use of WMM. I am also going better judgement here and breaking > backward interoperability because you raised a valid point that > having a single tag for the station is not sufficient given that the > WTP policy has one per QoS class. So I have modified the per station > policy message element to include all four. Finally, I have > introduced a new bit in the WTP policy which simply states that the > station's marking is to be trusted, which means that the WTP is not > to remark any packets received. > > The new text reads: > > > 2.6. Quality of Service > > The CAPWAP IEEE 802.11 binding specification provides procedures to > allow for the WTP to enforce Quality of Service. This section will > detail the actual procedures for both Split and Local MAC. > > When the WLAN is created on the WTP, a default Quality of Service > policy through the IEEE 802.11 WTP Quality of Service message > element (see Section 6.22). This default policy will cause the > WTP to use the default QoS values for any station associated with > the WLAN in question. The AC MAY also override the policy for a > given station, by sending the IEEE 802.11 Update Station QoS > message element (see Section 6.20). > > The IEEE 802.11 WTP Quality of Service message element's Tag > Packet field indicates how the packets are to be tagged; either > via 802.1Q or DSCP. When an IEEE 802.11 Update Station QoS > message element is received, while the specific "802.1p Tag" or > DSCP values may change for a given station, the original policy > of whether 802.1p or DSCP is to be used continues to be enforced > by the WTP. > > Both message elements provide an "802.1p Tag", which is used by > the WTP by adding an 802.1Q header (see [IEEE.802-1Q.2005]) with > the priority field set according to the policy provided. Note > this tagging is only valid for interface that support 802.1p. > Regardless of whether Split or Local MAC is used, the 802.1Q > header processing is identical. > > Both message elements also provide a "DSCP Tag", which is used by > the WTP to use in the DSCP field of bot the IPv4 and IPv6 headers > (see [RFC2474]). When the WTP operates in a Split MAC mode, the > DSCP markings are used in the CAPWAP data plane tunnel's IP > header. For both Split and Local MAC, if the 'T' bit in the IEEE > 802.11 WTP Quality of Service message element's Tag Packet field > is not set, the WTP MUST re-mark the DSCP field of any IPv4 or > IPv6 packets based either on the default policy, known through > the IEEE 802.11 WTP Quality of Service message element, or a > station specific policy, known through the IEEE 802.11 Update > Station QoS message element. If the 'T' bit in the IEEE 802.11 > WTP Quality of Service message element's Tag Packet field is set, > the WTP MUST trust the marking sent by the station. Note that in > Split MAC mode, the WTP cannot re-mark the DSCP field of the > station's IPv4 or IPv6 packets if encryption is performed at the > AC (see Section 6.15). I'm not sure "WTP MUST trust" is best possible phrasing; in this case, the WTP doesn't use the value for anything, so it doesn't really "trust" it (any more than it "trusts", say, the destination IP address field). If it would copy the inner DSCP Tag to CAPWAP data plane tunnel's IP header, then "trust" might be appropriate... but I case this wasn't intended? So the intended logic would be: D=1 and T=1: mark data plane tunnel's IP header (with DSCP value from this message element, not from inner IP header); don't change the inner IP header sent by STA. D=1 and T=0: mark data plane tunnel's IP header (with DSCP value from this message element, not from inner IP header); also replace the DSCP field in the inner IP header with this value (if it's IPv4/IPv6, and encryption isn't done in WTP) D=0 and T=0: use default DSCP value for data plane tunnel's IP header; don't touch the inner IP header. D=0 and T=1: use default DSCP value for data plane tunnel's IP header; don't touch the inner IP header Or are the D/T bits supposed to be orthogonal, so the last case would replace the DSCP field in the inner header? (BTW -- this discussion about DSCP reminded me that the spec doesn't say anything about the ECN bits...) > Note additional per flow QoS policies MAY exist if the station > had requested special QoS treatment through the TSPEC information > element found in the IEEE 802.11-2007's QoS Action Frame. This "MAY" seems to describe a logical possibility, not an optional feature, so it probably should be lowercase "may" (or perhaps "can"). > Note that stations MAY also use the WiFi Alliance's WMM > specification instead to request QoS treatment for a flow (see > [WMM]). This requires the WTP to observe the Status Code in the > IEEE 802.11-2007 and WMM QoS Action ADDTS responses from the AC, > and provide the services requested in the TSPEC information > element. Similarly, the WTP MUST observe the Reason Code > information element in the IEEE 802.11-2007 and WMM QoS Action > DELTS responses from the AC by removing the policy associated > with the TSPEC. > > [...] > 6.20. IEEE 802.11 Update Station QoS > > The IEEE 802.11 Update Station QoS message element is used > to change > the Quality of Service policy on the WTP for a given station. The > QoS tags included in this message element are to be applied to > packets received at the WTP from the station indicated through the > MAC Address field. This message element overrides the > default values > provided through the IEEE 802.11 WTP Quality of Service message > element (see Section 6.22. Any tagging performed by the > WTP MUST be > directly applied to the packets receive from the station, > as well as > the CAPWAP tunnel, if the packets are tunneled to the AC. See > Section 2.6 for more information. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 > 8 9 0 1 2 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Radio ID | MAC Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MAC Address | QoS Sub-Element... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type: 1043 for IEEE 802.11 Update Station QoS > > Length: 8 > > Radio ID: The Radio Identifier, typically refers to some > interface > index on the WTP > > MAC Address: The station's MAC Address. > > QoS Sub-Element: The IEEE 802.11 WTP Quality of Service message > element contains four QoS sub-elements, one for every > QoS profile. > The order of the QoS profiles are Voice, Video, Best Effort and > Background. > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved|8021p|RSV| DSCP Tag | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Reserved: All implementations complying with this > protocol MUST > set to zero any bits that are reserved in the version of the > protocol supported by that implementation. Receivers MUST > ignore all bits not defined for the version of the protocol > they support. > > 8021p: The three bit 802.1p priority value to use if > packets are > to be IEEE 802.1p tagged. Perhaps add "This field is used only if the 'P' bit in the WTP Quality of Service message element was set; otherwise, its contents MUST be ignored."? > RSV: All implementations complying with this protocol MUST set > to zero any bits that are reserved in the version of the > protocol supported by that implementation. Receivers MUST > ignore all bits not defined for the version of the protocol > they support. > > DSCP Tag: The 6 bit DSCP label to use if packets are > eligible to > be DSCP tagged, specifically an IPv4 or IPv6 packet (see > [RFC2474]). Perhaps add "This field is used only if the 'D' bit in the WTP Quality of Service message element was set; otherwise, its contents MUST be ignored."? > [...] > 6.22. IEEE 802.11 WTP Quality of Service > > The IEEE 802.11 WTP Quality of Service message element value is > sent by the AC to the WTP to communicate quality of service > configuration information. The QoS tag included in this message > element are the default QoS values to be applied to packets > received by the WTP from stations on a particular radio. Any > tagging performed by the WTP MUST be directly applied to the > packets receive from the station, as well as the CAPWAP tunnel, > if the packets are tunneled to the AC. See Section 2.6 for more > information. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 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 | Tag Packets | QoS Sub-Element ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type: 1045 for IEEE 802.11 WTP Quality of Service > > Length: 34 > > Radio ID: The Radio Identifier, typically refers to some > interface > index on the WTP > > Tag Packet: A bit field indicating whether CAPWAP > packets should be > tagged for QoS purposes. The field has the following format: > > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |Reservd|T|D|P|U| > +-+-+-+-+-+-+-+-+ > > Reserved: A set of reserved bits for future use. All > implementations complying with this protocol MUST set to zero > any bits that are reserved in the version of the protocol > supported by that implementation. Receivers MUST ignore all > bits not defined for the version of the protocol > they support. > > T: When set, this indicates that any QoS markings on packets > received from stations are to be trusted and honored. As I commented above, "trusted and honored" describes perhaps the intent, but I'm not sure what, exactly, an implementation would do here. IMHO this would be best phrased as talking about processing specific header fields (adding header with value X; copying value from one place to another; replacing an existing value). > D: When set, this indicates that the CAPWAP packets should be > tagged for QoS purposes using DSCP. > > P: When set, this indicates that the CAPWAP packets should be > tagged for QoS purposes using 802.1p. > > U: When set, this indicates that the CAPWAP packets should be > untagged. When set, both the D and P bits MUST NOT be set. > > QoS Sub-Element: The IEEE 802.11 WTP Quality of Service message > element contains four QoS sub-elements, one for every > QoS profile. > The order of the QoS profiles are Voice, Video, Best Effort and > Background. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Queue Depth | CWMin | CWMax | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | CWMax | AIFS | Reserved|8021p|RSV| DSCP Tag | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Queue Depth: The number of packets that can be on the specific > QoS transmit queue at any given time. > > CWMin: The Contention Window minimum (CWmin) value for the QoS > transmit queue. The value of this field comes from the IEEE > 802.11 dot11EDCATableCWMin MIB element (see > [IEEE.802-11.2007]). > > CWMax: The Contention Window maximum (CWmax) value for the QoS > transmit queue. The value of this field comes from the IEEE > 802.11 dot11EDCATableCWMax MIB element (see > [IEEE.802-11.2007]). > > AIFS: The Arbitration Inter Frame Spacing (AIFS) to > use for the > QoS transmit queue. The value of this field comes from the > IEEE 802.11 dot11EDCATableAIFSN MIB element (see > [IEEE.802-11.2007]). > > Reserved: All implementations complying with this > protocol MUST > set to zero any bits that are reserved in the version of the > protocol supported by that implementation. Receivers MUST > ignore all bits not defined for the version of the protocol > they support. > > 8021p: The three bit 802.1p priority value to use if > packets are > to be IEEE 802.1p tagged. Perhaps add "This field is used only if the 'P' bit is set; otherwise, its contents MUST be ignored"? > > RSV: All implementations complying with this protocol MUST set > to zero any bits that are reserved in the version of the > protocol supported by that implementation. Receivers MUST > ignore all bits not defined for the version of the protocol > they support. > > DSCP Tag: The 6 bit DSCP label to use if packets are > eligible to > be DSCP tagged, specifically an IPv4 or IPv6 packet (see > [RFC2474]). Perhaps add "This field is used only if the 'D' bit is set; otherwise, its contents MUST be ignored"? > > > My apologies for the multiple round trips, but I have to admit > understanding your issues is really helping improve the quality of the > specification, so I appreciate the time you are putting into this. > > Does the above address your comments? Almost there:) Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 25 14:01:15 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F10013A6BD4 for ; Mon, 25 Aug 2008 14:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr+koPrE-NJU for ; Mon, 25 Aug 2008 14:01:13 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id C12A13A6BD0 for ; Mon, 25 Aug 2008 14:01:13 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 07E5F1C40F40 for ; Mon, 25 Aug 2008 14:00:30 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 6737F440202 for ; Mon, 25 Aug 2008 14:00:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 54ED734AC094 for ; Mon, 25 Aug 2008 14:00:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id AC5BF34AC06A for ; Mon, 25 Aug 2008 14:00:20 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted TTSSA (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 25 Aug 2008 14:00:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,266,1217808000"; d="scan'208,217";a="146171395" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 25 Aug 2008 20:59:28 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m7PKxSW5021118; Mon, 25 Aug 2008 13:59:28 -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.13.8/8.13.8) with ESMTP id m7PKxRAs011718; Mon, 25 Aug 2008 20:59:28 GMT 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.1830); Mon, 25 Aug 2008 13:59:26 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Aug 2008 13:59:09 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20658317E@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 171: Pasi nits on binding spec Thread-Index: AckG9WXqGxShcga1RZiZREGQsN/Bbw== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 25 Aug 2008 20:59:26.0156 (UTC) FILETIME=[754DD8C0:01C906F5] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 171: Pasi nits on binding spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============0868081179==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============0868081179== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C906F5.7516563A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C906F5.7516563A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pasi, =20 You had the following comment: =20 > I'm not sure "WTP MUST trust" is best possible phrasing; in this case, > the WTP doesn't use the value for anything, so it doesn't really > "trust" it (any more than it "trusts", say, the destination IP address > field). >=20 > If it would copy the inner DSCP Tag to CAPWAP data plane tunnel's IP > header, then "trust" might be appropriate... but I case this wasn't > intended? So the intended logic would be: >=20 > D=3D1 and T=3D1: mark data plane tunnel's IP header (with DSCP value > from this message element, not from inner IP header); don't change > the inner IP header sent by STA. > D=3D1 and T=3D0: mark data plane tunnel's IP header (with DSCP value > from this message element, not from inner IP header); also replace > the DSCP field in the inner IP header with this value (if it's > IPv4/IPv6, and encryption isn't done in WTP) > D=3D0 and T=3D0: use default DSCP value for data plane tunnel's IP > header; don't touch the inner IP header. > D=3D0 and T=3D1: use default DSCP value for data plane tunnel's IP=20 > header; don't touch the inner IP header >=20 > Or are the D/T bits supposed to be orthogonal, so the last > case would replace the DSCP field in the inner header? and =20 > > T: When set, this indicates that any QoS markings on packets > > received from stations are to be trusted and honored. >=20 > As I commented above, "trusted and honored" describes perhaps the > intent, but I'm not sure what, exactly, an implementation would do > here. IMHO this would be best phrased as talking about processing > specific header fields (adding header with value X; copying value > from one place to another; replacing an existing value). OK, this is a valid comment, so I have accepted all of your proposed = text changes and modified the following text to address the issues you = have raised =20 2.6. CAPWAP Data Channel QoS Behavior The CAPWAP IEEE 802.11 binding specification provides procedures to allow for the WTP to enforce Quality of Service on IEEE 802.11 Data Frames and MAC Management messages. =20 2.6.1. IEEE 802.11 Data Frames When the WLAN is created on the WTP, a default Quality of Service policy is established through the IEEE 802.11 WTP Quality of Service message element (see Section 6.22). This default policy will cause the WTP to use the default QoS values for any station associated with the WLAN in question. The AC MAY also override the policy for a given station, by sending the IEEE 802.11 Update Station QoS message element (see Section 6.20), known as a station specific QoS policy. =20 Beyond the default, and per station QoS policy, the IEEE 802.11 protocol also allows a station to request special QoS treatment for a specific flow through the TSPEC information elements found in the IEEE 802.11-2007's QoS Action Frame. Alternatively, stations MAY also use the WiFi Alliance's WMM specification instead to request QoS treatment for a flow (see [WMM]). This requires the WTP to observe the Status Code in the IEEE 802.11-2007 and WMM QoS Action ADDTS responses from the AC, and provide the services requested in the TSPEC information element. Similarly, the WTP MUST observe the Reason Code information element in the IEEE 802.11-2007 and WMM QoS Action DELTS responses from the AC by removing the policy associated with the TSPEC. =20 The IEEE 802.11 WTP Quality of Service message element's Tagging Policy field indicates how the packets are to be tagged, via the 'P' bit (802.1Q), 'D' bit (DSCP) and the 'U' bit (do not tag). The Tagging Policy also includes the 'T' bit, which is used to inform the WTP to not modify any markings set by the station. The expected behavior of these bits is specified below. When an IEEE 802.11 Update Station QoS message element is received, while the specific "802.1p Tag" or DSCP values may change for a given station, the original Tagging Policy (the use of the 'T', 'D', 'P' and 'U' bits) remains the same. =20 2.6.1.1. 802.1p Support The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station QoS message elements provide an "802.1p Tag", which is used by the WTP by adding an 802.1Q header (see [IEEE.802-1Q.2005]) with the priority field set according to the policy provided. Note this tagging is only valid for interfaces that support 802.1p. The actual treatment is identical in both Split and Local MAC mode, except that the former requires the 802.1Q header to be added to the station's packet vs. the outer packet header. The following options are possible: =20 P=3D1, T=3D0: The WTP marks the priority field in the 802.1Q = header, which is added to the station's packet or outer packet header, to either the default, or the station specific DSCP policy. P=3D1, T=3D1: The WTP marks the priority field in the 802.1Q = header, which is added to the station's packet or outer packet header, to the value found in User Priority field of the QoS Control field of the IEEE 802.11 header. If the QoS Control field is not present in the IEEE 802.11 header, then the packet is handled as defined in the above option. =20 P=3D0, T=3D0: The WTP sets the priority field in the 802.1Q header = to zero (0), if present. This bit combination MUST NOT be set if the 'U' bit is not set. =20 P=3D0, T=3D1: This is an invalid bit combination. =20 Note that if the 'U' bit was set, then the WTP MUST NOT set the 802.1Q header's priority field. Note that in this case, the 'P', 'D' and 'T' bits MUST NOT be set. =20 2.6.1.2. DSCP Support The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station QoS message elements also provide a "DSCP Tag", which is used by the WTP when the 'D' bit is set to mark the DSCP field of both the IPv4 and IPv6 headers (see [RFC2474]). Unlike 802.1p, the WTP can mark either the inner packet (the original packet received by the station), or the outer packet's IP header. If the 'D' bit is not set, the WTP MUST NOT mark either the inner or outer packet's IP header's DSCP field. =20 Assuming the 'D' bit is set, the treatment of the packet differs based on whether the WTP is operating in a Split or Local MAC mode. For Local MAC mode, the WTP does not tunnel packets to the AC, and there is therefore no outer packet to mark. In this case, there are three possible mode of operations: =20 D=3D1, T=3D0: The WTP re-marks the DSCP field in the station's = packet to either the default, or the station specific DSCP policy. =20 D=3D1, T=3D1: The WTP does not modify the DSCP field in the = station's packets. =20 D=3D0, T=3D0: The WTP sets the DSCP field in the station's packet = to zero (0). This bit combination MUST NOT be set if the 'U' bit is not set. =20 D=3D0, T=3D1: This is an invalid bit combination. =20 For Split MAC mode, the WTP needs to contend with both the inner packet (the station's original packet), as well as the tunnel header (added by the WTP). In this mode of operation, there are two options: =20 D=3D1, T=3D0: The WTP marks the outer header's DSCP field based on either the default or the station specific DSCP policy. Similarly, the WTP also re-marks the inner packet header's DSCP field to the same DSCP value. If encryption services are provided by the AC (see Section 6.15), the WTP does not modify the inner packet. =20 D=3D1, T=3D1: The WTP marks the outer header's DSCP field based on = the value set in the inner packet header's DSCP field. Further the WTP does not modify the inner packet header's DSCP field. This option is invalid if the AC is providing encryption services, since the inner packet would be encrypted, and therefore not modifyable by the WTP. If this option is set while the AC is providing encryption services, the WTP must provide the services defined in the "D=3D1, T=3D0" option. =20 D=3D0, T=3D0: The WTP sets the DSCP field of the inner and outer = packet header to zero (0). If encryption services are provided by the AC, the WTP MUST NOT modify the inner packet header's DSCP field. This bit combination MUST NOT be set if the 'U' bit is not set. =20 D=3D0, T=3D1: This is an invalid bit combination. =20 Note that if the 'U' bit was set, then the WTP MUST ensure that neither the outer or inner packet header's DSCP field is set. Note that in this case, the 'P', 'D' and 'T' bits MUST NOT be set. =20 2.6.2. IEEE 802.11 MAC Management Messages =20 It is recommended that IEEE 802.11 MAC Management frames be sent by both the AC and the WTP with appropriate Quality of Service values, listed below, to ensure that congestion in the network minimizes occurrences of packet loss. Note that the Tagging Policy used is specified by the AC in the IEEE 802.11 WTP Quality of Service message element (see Section 6.22), except that in this case the 'T' bit is not observed. [...] 6.22. IEEE 802.11 WTP Quality of Service [...] Tagging Policy: A bit field indicating how the WTP is to mark packets for QoS purposes. The required WTP behavior is defined in Section 2.6.1. The field has the following format: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Reservd|T|D|P|U| +-+-+-+-+-+-+-+-+ Reserved: A set of reserved bits for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. T: When set, this indicates that the WTP MUST NOT modify any QoS markings on packets received from stations. D: When set, this indicates that the WTP is to use DSCP to provide Quality of Service. P: When set, this indicates that the WTP is to use 802.1p to provide Quality of Service. U: When set, this indicates that the CAPWAP packets should be untagged. When set, the 'T', 'D' and 'P' bits MUST NOT be set. If any other bits are set, the WTP will follow the behavior specified by the 'U' bit. Let me know if this addresses all of your concerns. Thanks again, PatC ------_=_NextPart_001_01C906F5.7516563A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
Hi = Pasi,
=0A=
 
=0A=
You had the following = comment:
=0A=
 
=0A=
> I'm not sure "WTP MUST = trust" is best possible phrasing; in this case,
> the WTP doesn't = use the value for anything, so it doesn't really
> "trust" it (any = more than it "trusts", say, the destination IP address
> = field).
>
> If it would copy the inner DSCP Tag to CAPWAP = data plane tunnel's IP
> header, then "trust" might be = appropriate... but I case this wasn't
> intended? So the intended = logic would be:
>
> D=3D1 and T=3D1: mark data plane = tunnel's IP header (with DSCP value
>   from this = message element, not from inner IP header); don't = change
>   the inner IP header sent by STA.
> = D=3D1 and T=3D0: mark data plane tunnel's IP header (with DSCP = value
>   from this message element, not from inner IP = header); also replace
>   the DSCP field in the inner IP = header with this value (if it's
>   IPv4/IPv6, and = encryption isn't done in WTP)
> D=3D0 and T=3D0: use default DSCP = value for data plane tunnel's IP
>   header; don't touch = the inner IP header.
> D=3D0 and T=3D1: use default DSCP value for = data plane tunnel's IP
>  header; don't touch the inner IP = header
>
> Or are the D/T bits supposed to be orthogonal, = so the last
> case would replace the DSCP field in the inner = header?
=0A=
and
=0A=
 
=0A=
> = >       T:   When set, this = indicates that any QoS markings on packets
> = >          received from = stations are to be trusted and honored.
>
> As I commented = above, "trusted and honored" describes perhaps the
> intent, but = I'm not sure what, exactly, an implementation would do
> here. = IMHO this would be best phrased as talking about processing
> = specific header fields (adding header with value X; copying = value
> from one place to another; replacing an existing = value).
=0A=
OK, this is a valid comment, so = I have accepted all of your proposed text changes and modified the = following text to address the issues you have raised
=0A=
 
=0A=
<modified = text>
=0A=
2.6.  CAPWAP Data Channel = QoS Behavior
=0A=
   The CAPWAP IEEE = 802.11 binding specification provides procedures to
   = allow for the WTP to enforce Quality of Service on IEEE 802.11 = Data
   Frames and MAC Management messages.
=0A=
 
=0A=
2.6.1.  IEEE 802.11 Data = Frames
=0A=
   When the WLAN is = created on the WTP, a default Quality of Service
   policy = is established through the IEEE 802.11 WTP Quality of = Service
   message element (see Section 6.22).  This = default policy will cause
=0A=
   the WTP to use the = default QoS values for any station associated with
   the = WLAN in question.  The AC MAY also override the policy for = a
   given station, by sending the IEEE 802.11 Update = Station QoS message
   element (see Section 6.20), known as = a station specific QoS policy.
=0A=
 
=0A=
   Beyond the = default, and per station QoS policy, the IEEE 802.11
   = protocol also allows a station to request special QoS treatment for = a
   specific flow through the TSPEC information elements = found in the
   IEEE 802.11-2007's QoS Action Frame.  = Alternatively, stations MAY
   also use the WiFi Alliance's = WMM specification instead to request QoS
   treatment for a = flow (see [WMM]).  This requires the WTP to observe
   = the Status Code in the IEEE 802.11-2007 and WMM QoS Action = ADDTS
   responses from the AC, and provide the services = requested in the
   TSPEC information element.  = Similarly, the WTP MUST observe the
   Reason Code = information element in the IEEE 802.11-2007 and WMM QoS
   = Action DELTS responses from the AC by removing the policy = associated
   with the TSPEC.
=0A=
 
=0A=
   The IEEE 802.11 = WTP Quality of Service message element's Tagging
   Policy = field indicates how the packets are to be tagged, via the = 'P'
   bit (802.1Q), 'D' bit (DSCP) and the 'U' bit (do not = tag).  The
   Tagging Policy also includes the 'T' = bit, which is used to inform the
   WTP to not modify any = markings set by the station.  The expected
   behavior = of these bits is specified below.  When an IEEE = 802.11
   Update Station QoS message element is received, = while the specific
   "802.1p Tag" or DSCP values may = change for a given station, the
   original Tagging Policy = (the use of the 'T', 'D', 'P' and 'U' bits)
   remains the = same.
=0A=
 
=0A=
2.6.1.1.  802.1p = Support
=0A=
   The IEEE 802.11 = WTP Quality of Service and IEEE 802.11 Update Station
   = QoS message elements provide an "802.1p Tag", which is used by = the
   WTP by adding an 802.1Q header (see = [IEEE.802-1Q.2005]) with the
   priority field set = according to the policy provided.  Note this
   = tagging is only valid for interfaces that support 802.1p.  The = actual
   treatment is identical in both Split and Local = MAC mode, except that
   the former requires the 802.1Q = header to be added to the station's
   packet vs. the outer = packet header.  The following options are
   = possible:
=0A=
 
=0A=
   P=3D1, = T=3D0:   The WTP marks the priority field in the 802.1Q = header,
      which is added to the = station's packet or outer packet header, = to
      either the default, or the station = specific DSCP policy.
=0A=

   P=3D1, = T=3D1:   The WTP marks the priority field in the 802.1Q = header,
      which is added to the = station's packet or outer packet header, = to
      the value found in User Priority = field of the QoS Control field of
      the = IEEE 802.11 header.  If the QoS Control field is not = present
      in the IEEE 802.11 header, = then the packet is handled as defined
      = in the above option.
=0A=
 
=0A=
   P=3D0, = T=3D0:   The WTP sets the priority field in the 802.1Q header = to
      zero (0), if present.  This = bit combination MUST NOT be set if the
      = 'U' bit is not set.
=0A=
 
=0A=
   P=3D0, = T=3D1:   This is an invalid bit combination.
=0A=
 
=0A=
   Note that if the = 'U' bit was set, then the WTP MUST NOT set the
   802.1Q = header's priority field.  Note that in this case, the 'P', = 'D'
   and 'T' bits MUST NOT be set.
=0A=
 
=0A=
2.6.1.2.  DSCP = Support
=0A=
   The IEEE 802.11 = WTP Quality of Service and IEEE 802.11 Update Station
   = QoS message elements also provide a "DSCP Tag", which is used by = the
   WTP when the 'D' bit is set to mark the DSCP field = of both the IPv4
   and IPv6 headers (see [RFC2474]).  = Unlike 802.1p, the WTP can mark
   either the inner packet = (the original packet received by the
   station), or the = outer packet's IP header.  If the 'D' bit is not
   = set, the WTP MUST NOT mark either the inner or outer packet's = IP
   header's DSCP field.
=0A=
 
=0A=
   Assuming the 'D' = bit is set, the treatment of the packet differs
   based on = whether the WTP is operating in a Split or Local MAC = mode.
   For Local MAC mode, the WTP does not tunnel = packets to the AC, and
   there is therefore no outer = packet to mark.  In this case, there are
   three = possible mode of operations:
=0A=
 
=0A=
   D=3D1, = T=3D0:   The WTP re-marks the DSCP field in the station's = packet
      to either the default, or the = station specific DSCP policy.
=0A=
 
=0A=
   D=3D1, = T=3D1:   The WTP does not modify the DSCP field in the = station's
      packets.
=0A=
 
=0A=
   D=3D0, = T=3D0:   The WTP sets the DSCP field in the station's packet = to
      zero (0).  This bit = combination MUST NOT be set if the 'U' bit = is
      not set.
=0A=
 
=0A=
   D=3D0, = T=3D1:   This is an invalid bit combination.
=0A=
 
=0A=
   For Split MAC = mode, the WTP needs to contend with both the inner
   = packet (the station's original packet), as well as the tunnel = header
=0A=
   (added by the = WTP).  In this mode of operation, there are two
   = options:
=0A=
 
=0A=
   D=3D1, = T=3D0:   The WTP marks the outer header's DSCP field based = on
      either the default or the station = specific DSCP policy.
      Similarly, the = WTP also re-marks the inner packet header's = DSCP
      field to the same DSCP = value.  If encryption services are = provided
      by the AC (see Section 6.15), = the WTP does not modify the inner
      = packet.
=0A=
 
=0A=
   D=3D1, = T=3D1:   The WTP marks the outer header's DSCP field based on = the
      value set in the inner packet = header's DSCP field.  Further the
      = WTP does not modify the inner packet header's DSCP field.  = This
      option is invalid if the AC is = providing encryption services,
      since = the inner packet would be encrypted, and therefore = not
      modifyable by the WTP.  If = this option is set while the AC is
      = providing encryption services, the WTP must provide the = services
      defined in the "D=3D1, T=3D0" = option.
=0A=
 
=0A=
   D=3D0, = T=3D0:   The WTP sets the DSCP field of the inner and outer = packet
      header to zero (0).  If = encryption services are provided by = the
      AC, the WTP MUST NOT modify the = inner packet header's DSCP field.
      This = bit combination MUST NOT be set if the 'U' bit is not set.
=0A=
 
=0A=
   D=3D0, = T=3D1:   This is an invalid bit combination.
=0A=
 
=0A=
   Note that if the = 'U' bit was set, then the WTP MUST ensure that
   neither = the outer or inner packet header's DSCP field is set.  = Note
   that in this case, the 'P', 'D' and 'T' bits MUST = NOT be set.
=0A=
 
=0A=
2.6.2.  IEEE 802.11 MAC = Management Messages
=0A=
 
=0A=
   It is recommended = that IEEE 802.11 MAC Management frames be sent by
   both = the AC and the WTP with appropriate Quality of Service = values,
   listed below, to ensure that congestion in the = network minimizes
   occurrences of packet loss.  Note = that the Tagging Policy used is
   specified by the AC in = the IEEE 802.11 WTP Quality of Service message
   element = (see Section 6.22), except that in this case the 'T' bit = is
   not observed.
[...]
=0A=

6.22.  IEEE 802.11 WTP = Quality of Service

=0A=

[...]
   Tagging = Policy:   A bit field indicating how the WTP is to = mark
      packets for QoS purposes.  = The required WTP behavior is defined = in
      Section 2.6.1.  The field has = the following format:

=0A=

         0 1 2 3 4 5 6 = 7
        = +-+-+-+-+-+-+-+-+
        = |Reservd|T|D|P|U|
        = +-+-+-+-+-+-+-+-+

=0A=

      = Reserved:  A set of reserved bits for future use.  = All
         implementations = complying with this protocol MUST set to = zero
         any bits that = are reserved in the version of the = protocol
         supported = by that implementation.  Receivers MUST ignore = all
         bits not defined = for the version of the protocol they support.

=0A=

      T:   When set, this = indicates that the WTP MUST NOT modify any = QoS
         markings on = packets received from stations.

=0A=

      D:   When set, this = indicates that the WTP is to use DSCP = to
         provide Quality = of Service.

=0A=

      P:   When set, this = indicates that the WTP is to use 802.1p = to
         provide Quality = of Service.

=0A=

      U:   When set, this = indicates that the CAPWAP packets should = be
         untagged.  = When set, the 'T', 'D' and 'P' bits MUST NOT be = set.
         If any other = bits are set, the WTP will follow the = behavior
         specified = by the 'U' bit.
</modified text>

=0A=

Let me know if this addresses all = of your concerns.

=0A=

Thanks again,

=0A=

PatC

=0A=

------_=_NextPart_001_01C906F5.7516563A-- --===============0868081179== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0868081179==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Aug 25 14:53:15 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D64353A6877 for ; Mon, 25 Aug 2008 14:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHTuMQW+ac4j for ; Mon, 25 Aug 2008 14:53:13 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 7F08228C0DF for ; Mon, 25 Aug 2008 14:53:13 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E9C62439FCD for ; Mon, 25 Aug 2008 14:52:37 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id CD33D440022 for ; Mon, 25 Aug 2008 14:52:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id BC26E34AC13C for ; Mon, 25 Aug 2008 14:52:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8C56634AC033 for ; Mon, 25 Aug 2008 14:52:22 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted TTSSA (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 25 Aug 2008 14:52:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,266,1217808000"; d="scan'208,217";a="146207309" Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-6.cisco.com with ESMTP; 25 Aug 2008 21:52:22 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id m7PLqMOV012222; Mon, 25 Aug 2008 14:52:22 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m7PLqK7g016531; Mon, 25 Aug 2008 21:52:21 GMT 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.1830); Mon, 25 Aug 2008 14:52:20 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Aug 2008 14:47:58 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206583182@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 171: Pasi nits on binding spec Thread-Index: AckG9WXqGxShcga1RZiZREGQsN/BbwABtdcv References: <4FF84B0BC277FF45AA27FE969DD956A20658317E@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 25 Aug 2008 21:52:20.0948 (UTC) FILETIME=[D9A0A940:01C906FC] Authentication-Results: sj-dkim-6; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); Cc: Pasi.Eronen@nokia.com Subject: Re: [Capwap] Issue 171: Pasi nits on binding spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 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="===============1854944646==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============1854944646== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C906FC.D9515654" This is a multi-part message in MIME format. ------_=_NextPart_001_01C906FC.D9515654 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I forgot to addess one more of your comments: =20 > (BTW -- this discussion about DSCP reminded me that the spec doesn't > say anything about the ECN bits...) =20 That was in fact intentional. The LWAPP and CAPWAP specs never got into = specifying how the ECN bits are to be used. I would recommend that we = leave the use of ECN for a subsequent version of the protocol. At this = point we can either continue to be silent about it, or simply add a = statement at the end of section 2.6.1.2 to the effect of: =20 The CAPWAP protocol does not make use of ECN [RFC3168], therefore the = ECN bits in the DSCP field MUST be set to zero (Not-ECT). =20 PatC ________________________________ From: Pat Calhoun (pacalhou) Sent: Mon 8/25/2008 1:59 PM To: capwap@frascone.com Cc: Pasi.Eronen@nokia.com Subject: [Capwap] Issue 171: Pasi nits on binding spec Hi Pasi, =20 You had the following comment: =20 > I'm not sure "WTP MUST trust" is best possible phrasing; in this case, > the WTP doesn't use the value for anything, so it doesn't really > "trust" it (any more than it "trusts", say, the destination IP address > field). >=20 > If it would copy the inner DSCP Tag to CAPWAP data plane tunnel's IP > header, then "trust" might be appropriate... but I case this wasn't > intended? So the intended logic would be: >=20 > D=3D1 and T=3D1: mark data plane tunnel's IP header (with DSCP value > from this message element, not from inner IP header); don't change > the inner IP header sent by STA. > D=3D1 and T=3D0: mark data plane tunnel's IP header (with DSCP value > from this message element, not from inner IP header); also replace > the DSCP field in the inner IP header with this value (if it's > IPv4/IPv6, and encryption isn't done in WTP) > D=3D0 and T=3D0: use default DSCP value for data plane tunnel's IP > header; don't touch the inner IP header. > D=3D0 and T=3D1: use default DSCP value for data plane tunnel's IP=20 > header; don't touch the inner IP header >=20 > Or are the D/T bits supposed to be orthogonal, so the last > case would replace the DSCP field in the inner header? and =20 > > T: When set, this indicates that any QoS markings on packets > > received from stations are to be trusted and honored. >=20 > As I commented above, "trusted and honored" describes perhaps the > intent, but I'm not sure what, exactly, an implementation would do > here. IMHO this would be best phrased as talking about processing > specific header fields (adding header with value X; copying value > from one place to another; replacing an existing value). OK, this is a valid comment, so I have accepted all of your proposed = text changes and modified the following text to address the issues you = have raised =20 2.6. CAPWAP Data Channel QoS Behavior The CAPWAP IEEE 802.11 binding specification provides procedures to allow for the WTP to enforce Quality of Service on IEEE 802.11 Data Frames and MAC Management messages. =20 2.6.1. IEEE 802.11 Data Frames When the WLAN is created on the WTP, a default Quality of Service policy is established through the IEEE 802.11 WTP Quality of Service message element (see Section 6.22). This default policy will cause the WTP to use the default QoS values for any station associated with the WLAN in question. The AC MAY also override the policy for a given station, by sending the IEEE 802.11 Update Station QoS message element (see Section 6.20), known as a station specific QoS policy. =20 Beyond the default, and per station QoS policy, the IEEE 802.11 protocol also allows a station to request special QoS treatment for a specific flow through the TSPEC information elements found in the IEEE 802.11-2007's QoS Action Frame. Alternatively, stations MAY also use the WiFi Alliance's WMM specification instead to request QoS treatment for a flow (see [WMM]). This requires the WTP to observe the Status Code in the IEEE 802.11-2007 and WMM QoS Action ADDTS responses from the AC, and provide the services requested in the TSPEC information element. Similarly, the WTP MUST observe the Reason Code information element in the IEEE 802.11-2007 and WMM QoS Action DELTS responses from the AC by removing the policy associated with the TSPEC. =20 The IEEE 802.11 WTP Quality of Service message element's Tagging Policy field indicates how the packets are to be tagged, via the 'P' bit (802.1Q), 'D' bit (DSCP) and the 'U' bit (do not tag). The Tagging Policy also includes the 'T' bit, which is used to inform the WTP to not modify any markings set by the station. The expected behavior of these bits is specified below. When an IEEE 802.11 Update Station QoS message element is received, while the specific "802.1p Tag" or DSCP values may change for a given station, the original Tagging Policy (the use of the 'T', 'D', 'P' and 'U' bits) remains the same. =20 2.6.1.1. 802.1p Support The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station QoS message elements provide an "802.1p Tag", which is used by the WTP by adding an 802.1Q header (see [IEEE.802-1Q.2005]) with the priority field set according to the policy provided. Note this tagging is only valid for interfaces that support 802.1p. The actual treatment is identical in both Split and Local MAC mode, except that the former requires the 802.1Q header to be added to the station's packet vs. the outer packet header. The following options are possible: =20 P=3D1, T=3D0: The WTP marks the priority field in the 802.1Q = header, which is added to the station's packet or outer packet header, to either the default, or the station specific DSCP policy. P=3D1, T=3D1: The WTP marks the priority field in the 802.1Q = header, which is added to the station's packet or outer packet header, to the value found in User Priority field of the QoS Control field of the IEEE 802.11 header. If the QoS Control field is not present in the IEEE 802.11 header, then the packet is handled as defined in the above option. =20 P=3D0, T=3D0: The WTP sets the priority field in the 802.1Q header = to zero (0), if present. This bit combination MUST NOT be set if the 'U' bit is not set. =20 P=3D0, T=3D1: This is an invalid bit combination. =20 Note that if the 'U' bit was set, then the WTP MUST NOT set the 802.1Q header's priority field. Note that in this case, the 'P', 'D' and 'T' bits MUST NOT be set. =20 2.6.1.2. DSCP Support The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station QoS message elements also provide a "DSCP Tag", which is used by the WTP when the 'D' bit is set to mark the DSCP field of both the IPv4 and IPv6 headers (see [RFC2474]). Unlike 802.1p, the WTP can mark either the inner packet (the original packet received by the station), or the outer packet's IP header. If the 'D' bit is not set, the WTP MUST NOT mark either the inner or outer packet's IP header's DSCP field. =20 Assuming the 'D' bit is set, the treatment of the packet differs based on whether the WTP is operating in a Split or Local MAC mode. For Local MAC mode, the WTP does not tunnel packets to the AC, and there is therefore no outer packet to mark. In this case, there are three possible mode of operations: =20 D=3D1, T=3D0: The WTP re-marks the DSCP field in the station's = packet to either the default, or the station specific DSCP policy. =20 D=3D1, T=3D1: The WTP does not modify the DSCP field in the = station's packets. =20 D=3D0, T=3D0: The WTP sets the DSCP field in the station's packet = to zero (0). This bit combination MUST NOT be set if the 'U' bit is not set. =20 D=3D0, T=3D1: This is an invalid bit combination. =20 For Split MAC mode, the WTP needs to contend with both the inner packet (the station's original packet), as well as the tunnel header (added by the WTP). In this mode of operation, there are two options: =20 D=3D1, T=3D0: The WTP marks the outer header's DSCP field based on either the default or the station specific DSCP policy. Similarly, the WTP also re-marks the inner packet header's DSCP field to the same DSCP value. If encryption services are provided by the AC (see Section 6.15), the WTP does not modify the inner packet. =20 D=3D1, T=3D1: The WTP marks the outer header's DSCP field based on = the value set in the inner packet header's DSCP field. Further the WTP does not modify the inner packet header's DSCP field. This option is invalid if the AC is providing encryption services, since the inner packet would be encrypted, and therefore not modifyable by the WTP. If this option is set while the AC is providing encryption services, the WTP must provide the services defined in the "D=3D1, T=3D0" option. =20 D=3D0, T=3D0: The WTP sets the DSCP field of the inner and outer = packet header to zero (0). If encryption services are provided by the AC, the WTP MUST NOT modify the inner packet header's DSCP field. This bit combination MUST NOT be set if the 'U' bit is not set. =20 D=3D0, T=3D1: This is an invalid bit combination. =20 Note that if the 'U' bit was set, then the WTP MUST ensure that neither the outer or inner packet header's DSCP field is set. Note that in this case, the 'P', 'D' and 'T' bits MUST NOT be set. =20 2.6.2. IEEE 802.11 MAC Management Messages =20 It is recommended that IEEE 802.11 MAC Management frames be sent by both the AC and the WTP with appropriate Quality of Service values, listed below, to ensure that congestion in the network minimizes occurrences of packet loss. Note that the Tagging Policy used is specified by the AC in the IEEE 802.11 WTP Quality of Service message element (see Section 6.22), except that in this case the 'T' bit is not observed. [...] 6.22. IEEE 802.11 WTP Quality of Service [...] Tagging Policy: A bit field indicating how the WTP is to mark packets for QoS purposes. The required WTP behavior is defined in Section 2.6.1. The field has the following format: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Reservd|T|D|P|U| +-+-+-+-+-+-+-+-+ Reserved: A set of reserved bits for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. T: When set, this indicates that the WTP MUST NOT modify any QoS markings on packets received from stations. D: When set, this indicates that the WTP is to use DSCP to provide Quality of Service. P: When set, this indicates that the WTP is to use 802.1p to provide Quality of Service. U: When set, this indicates that the CAPWAP packets should be untagged. When set, the 'T', 'D' and 'P' bits MUST NOT be set. If any other bits are set, the WTP will follow the behavior specified by the 'U' bit. Let me know if this addresses all of your concerns. Thanks again, PatC ------_=_NextPart_001_01C906FC.D9515654 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
I = forgot to addess one more of your comments:
=0A=
 
=0A=
> (BTW -- this = discussion about DSCP reminded me that the spec doesn't
> say = anything about the ECN bits...)
=0A=
 
=0A=
That was in fact = intentional. The LWAPP and CAPWAP specs never got into specifying how = the ECN bits are to be used. I would recommend that we leave the use of = ECN for a subsequent version of the protocol. At this point we can = either continue to be silent about it, or simply add a statement at the = end of section 2.6.1.2 to the effect of:
=0A=
 
=0A=
<possible = text>
=0A=
The CAPWAP protocol = does not make use of ECN [RFC3168], therefore the ECN bits in the DSCP = field MUST be set to zero (Not-ECT).
=0A=
</possible = text>
=0A=
 
=0A=
PatC
=0A=
=0A=
=0A=
=0A=
From: Pat Calhoun = (pacalhou)
Sent: Mon 8/25/2008 1:59 PM
To: = capwap@frascone.com
Cc: = Pasi.Eronen@nokia.com
Subject: [Capwap] Issue 171: Pasi nits = on binding spec

=0A=
=0A=
Hi = Pasi,
=0A=
 
=0A=
You had the following = comment:
=0A=
 
=0A=
> I'm not sure "WTP MUST = trust" is best possible phrasing; in this case,
> the WTP doesn't = use the value for anything, so it doesn't really
> "trust" it (any = more than it "trusts", say, the destination IP address
> = field).
>
> If it would copy the inner DSCP Tag to CAPWAP = data plane tunnel's IP
> header, then "trust" might be = appropriate... but I case this wasn't
> intended? So the intended = logic would be:
>
> D=3D1 and T=3D1: mark data plane = tunnel's IP header (with DSCP value
>   from this = message element, not from inner IP header); don't = change
>   the inner IP header sent by STA.
> = D=3D1 and T=3D0: mark data plane tunnel's IP header (with DSCP = value
>   from this message element, not from inner IP = header); also replace
>   the DSCP field in the inner IP = header with this value (if it's
>   IPv4/IPv6, and = encryption isn't done in WTP)
> D=3D0 and T=3D0: use default DSCP = value for data plane tunnel's IP
>   header; don't touch = the inner IP header.
> D=3D0 and T=3D1: use default DSCP value for = data plane tunnel's IP
>  header; don't touch the inner IP = header
>
> Or are the D/T bits supposed to be orthogonal, = so the last
> case would replace the DSCP field in the inner = header?
=0A=
and
=0A=
 
=0A=
> = >       T:   When set, this = indicates that any QoS markings on packets
> = >          received from = stations are to be trusted and honored.
>
> As I commented = above, "trusted and honored" describes perhaps the
> intent, but = I'm not sure what, exactly, an implementation would do
> here. = IMHO this would be best phrased as talking about processing
> = specific header fields (adding header with value X; copying = value
> from one place to another; replacing an existing = value).
=0A=
OK, this is a valid comment, so = I have accepted all of your proposed text changes and modified the = following text to address the issues you have raised
=0A=
 
=0A=
<modified = text>
=0A=
2.6.  CAPWAP Data Channel = QoS Behavior
=0A=
   The CAPWAP IEEE = 802.11 binding specification provides procedures to
   = allow for the WTP to enforce Quality of Service on IEEE 802.11 = Data
   Frames and MAC Management messages.
=0A=
 
=0A=
2.6.1.  IEEE 802.11 Data = Frames
=0A=
   When the WLAN is = created on the WTP, a default Quality of Service
   policy = is established through the IEEE 802.11 WTP Quality of = Service
   message element (see Section 6.22).  This = default policy will cause
=0A=
   the WTP to use the = default QoS values for any station associated with
   the = WLAN in question.  The AC MAY also override the policy for = a
   given station, by sending the IEEE 802.11 Update = Station QoS message
   element (see Section 6.20), known as = a station specific QoS policy.
=0A=
 
=0A=
   Beyond the = default, and per station QoS policy, the IEEE 802.11
   = protocol also allows a station to request special QoS treatment for = a
   specific flow through the TSPEC information elements = found in the
   IEEE 802.11-2007's QoS Action Frame.  = Alternatively, stations MAY
   also use the WiFi Alliance's = WMM specification instead to request QoS
   treatment for a = flow (see [WMM]).  This requires the WTP to observe
   = the Status Code in the IEEE 802.11-2007 and WMM QoS Action = ADDTS
   responses from the AC, and provide the services = requested in the
   TSPEC information element.  = Similarly, the WTP MUST observe the
   Reason Code = information element in the IEEE 802.11-2007 and WMM QoS
   = Action DELTS responses from the AC by removing the policy = associated
   with the TSPEC.
=0A=
 
=0A=
   The IEEE 802.11 = WTP Quality of Service message element's Tagging
   Policy = field indicates how the packets are to be tagged, via the = 'P'
   bit (802.1Q), 'D' bit (DSCP) and the 'U' bit (do not = tag).  The
   Tagging Policy also includes the 'T' = bit, which is used to inform the
   WTP to not modify any = markings set by the station.  The expected
   behavior = of these bits is specified below.  When an IEEE = 802.11
   Update Station QoS message element is received, = while the specific
   "802.1p Tag" or DSCP values may = change for a given station, the
   original Tagging Policy = (the use of the 'T', 'D', 'P' and 'U' bits)
   remains the = same.
=0A=
 
=0A=
2.6.1.1.  802.1p = Support
=0A=
   The IEEE 802.11 = WTP Quality of Service and IEEE 802.11 Update Station
   = QoS message elements provide an "802.1p Tag", which is used by = the
   WTP by adding an 802.1Q header (see = [IEEE.802-1Q.2005]) with the
   priority field set = according to the policy provided.  Note this
   = tagging is only valid for interfaces that support 802.1p.  The = actual
   treatment is identical in both Split and Local = MAC mode, except that
   the former requires the 802.1Q = header to be added to the station's
   packet vs. the outer = packet header.  The following options are
   = possible:
=0A=
 
=0A=
   P=3D1, = T=3D0:   The WTP marks the priority field in the 802.1Q = header,
      which is added to the = station's packet or outer packet header, = to
      either the default, or the station = specific DSCP policy.
=0A=

   P=3D1, = T=3D1:   The WTP marks the priority field in the 802.1Q = header,
      which is added to the = station's packet or outer packet header, = to
      the value found in User Priority = field of the QoS Control field of
      the = IEEE 802.11 header.  If the QoS Control field is not = present
      in the IEEE 802.11 header, = then the packet is handled as defined
      = in the above option.
=0A=
 
=0A=
   P=3D0, = T=3D0:   The WTP sets the priority field in the 802.1Q header = to
      zero (0), if present.  This = bit combination MUST NOT be set if the
      = 'U' bit is not set.
=0A=
 
=0A=
   P=3D0, = T=3D1:   This is an invalid bit combination.
=0A=
 
=0A=
   Note that if the = 'U' bit was set, then the WTP MUST NOT set the
   802.1Q = header's priority field.  Note that in this case, the 'P', = 'D'
   and 'T' bits MUST NOT be set.
=0A=
 
=0A=
2.6.1.2.  DSCP = Support
=0A=
   The IEEE 802.11 = WTP Quality of Service and IEEE 802.11 Update Station
   = QoS message elements also provide a "DSCP Tag", which is used by = the
   WTP when the 'D' bit is set to mark the DSCP field = of both the IPv4
   and IPv6 headers (see [RFC2474]).  = Unlike 802.1p, the WTP can mark
   either the inner packet = (the original packet received by the
   station), or the = outer packet's IP header.  If the 'D' bit is not
   = set, the WTP MUST NOT mark either the inner or outer packet's = IP
   header's DSCP field.
=0A=
 
=0A=
   Assuming the 'D' = bit is set, the treatment of the packet differs
   based on = whether the WTP is operating in a Split or Local MAC = mode.
   For Local MAC mode, the WTP does not tunnel = packets to the AC, and
   there is therefore no outer = packet to mark.  In this case, there are
   three = possible mode of operations:
=0A=
 
=0A=
   D=3D1, = T=3D0:   The WTP re-marks the DSCP field in the station's = packet
      to either the default, or the = station specific DSCP policy.
=0A=
 
=0A=
   D=3D1, = T=3D1:   The WTP does not modify the DSCP field in the = station's
      packets.
=0A=
 
=0A=
   D=3D0, = T=3D0:   The WTP sets the DSCP field in the station's packet = to
      zero (0).  This bit = combination MUST NOT be set if the 'U' bit = is
      not set.
=0A=
 
=0A=
   D=3D0, = T=3D1:   This is an invalid bit combination.
=0A=
 
=0A=
   For Split MAC = mode, the WTP needs to contend with both the inner
   = packet (the station's original packet), as well as the tunnel = header
=0A=
   (added by the = WTP).  In this mode of operation, there are two
   = options:
=0A=
 
=0A=
   D=3D1, = T=3D0:   The WTP marks the outer header's DSCP field based = on
      either the default or the station = specific DSCP policy.
      Similarly, the = WTP also re-marks the inner packet header's = DSCP
      field to the same DSCP = value.  If encryption services are = provided
      by the AC (see Section 6.15), = the WTP does not modify the inner
      = packet.
=0A=
 
=0A=
   D=3D1, = T=3D1:   The WTP marks the outer header's DSCP field based on = the
      value set in the inner packet = header's DSCP field.  Further the
      = WTP does not modify the inner packet header's DSCP field.  = This
      option is invalid if the AC is = providing encryption services,
      since = the inner packet would be encrypted, and therefore = not
      modifyable by the WTP.  If = this option is set while the AC is
      = providing encryption services, the WTP must provide the = services
      defined in the "D=3D1, T=3D0" = option.
=0A=
 
=0A=
   D=3D0, = T=3D0:   The WTP sets the DSCP field of the inner and outer = packet
      header to zero (0).  If = encryption services are provided by = the
      AC, the WTP MUST NOT modify the = inner packet header's DSCP field.
      This = bit combination MUST NOT be set if the 'U' bit is not set.
=0A=
 
=0A=
   D=3D0, = T=3D1:   This is an invalid bit combination.
=0A=
 
=0A=
   Note that if the = 'U' bit was set, then the WTP MUST ensure that
   neither = the outer or inner packet header's DSCP field is set.  = Note
   that in this case, the 'P', 'D' and 'T' bits MUST = NOT be set.
=0A=
 
=0A=
2.6.2.  IEEE 802.11 MAC = Management Messages
=0A=
 
=0A=
   It is recommended = that IEEE 802.11 MAC Management frames be sent by
   both = the AC and the WTP with appropriate Quality of Service = values,
   listed below, to ensure that congestion in the = network minimizes
   occurrences of packet loss.  Note = that the Tagging Policy used is
   specified by the AC in = the IEEE 802.11 WTP Quality of Service message
   element = (see Section 6.22), except that in this case the 'T' bit = is
   not observed.
[...]
=0A=

6.22.  IEEE 802.11 WTP = Quality of Service

=0A=

[...]
   Tagging = Policy:   A bit field indicating how the WTP is to = mark
      packets for QoS purposes.  = The required WTP behavior is defined = in
      Section 2.6.1.  The field has = the following format:

=0A=

         0 1 2 3 4 5 6 = 7
        = +-+-+-+-+-+-+-+-+
        = |Reservd|T|D|P|U|
        = +-+-+-+-+-+-+-+-+

=0A=

      = Reserved:  A set of reserved bits for future use.  = All
         implementations = complying with this protocol MUST set to = zero
         any bits that = are reserved in the version of the = protocol
         supported = by that implementation.  Receivers MUST ignore = all
         bits not defined = for the version of the protocol they support.

=0A=

      T:   When set, this = indicates that the WTP MUST NOT modify any = QoS
         markings on = packets received from stations.

=0A=

      D:   When set, this = indicates that the WTP is to use DSCP = to
         provide Quality = of Service.

=0A=

      P:   When set, this = indicates that the WTP is to use 802.1p = to
         provide Quality = of Service.

=0A=

      U:   When set, this = indicates that the CAPWAP packets should = be
         untagged.  = When set, the 'T', 'D' and 'P' bits MUST NOT be = set.
         If any other = bits are set, the WTP will follow the = behavior
         specified = by the 'U' bit.
</modified text>

=0A=

Let me know if this addresses all = of your concerns.

=0A=

Thanks again,

=0A=

PatC

=0A=

------_=_NextPart_001_01C906FC.D9515654-- --===============1854944646== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1854944646==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Aug 26 00:20:23 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAC7D3A682F for ; Tue, 26 Aug 2008 00:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18raZUE3DrwA for ; Tue, 26 Aug 2008 00:20:22 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id E7E343A6843 for ; Tue, 26 Aug 2008 00:20:22 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 90051430545 for ; Tue, 26 Aug 2008 00:20:24 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id D44DD44020F for ; Tue, 26 Aug 2008 00:20:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id B91623610055 for ; Tue, 26 Aug 2008 00:20:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 79A54361004A for ; Tue, 26 Aug 2008 00:20:13 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted TTSSA (192.100.122.233 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 26 Aug 2008 00:20:11 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7Q7JjBD016135; Tue, 26 Aug 2008 10:19:58 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Aug 2008 10:19:51 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Aug 2008 10:19:50 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Aug 2008 10:19:47 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72016FA015@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A206583182@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 171: Pasi nits on binding spec Thread-Index: AckG9WXqGxShcga1RZiZREGQsN/BbwABtdcvABOVkcA= References: <4FF84B0BC277FF45AA27FE969DD956A20658317E@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A206583182@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 26 Aug 2008 07:19:50.0545 (UTC) FILETIME=[20C4D810:01C9074C] X-Nokia-AV: Clean Subject: Re: [Capwap] Issue 171: Pasi nits on binding spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun wrote: > > I forgot to addess one more of your comments: > > > (BTW -- this discussion about DSCP reminded me that the spec doesn't > > say anything about the ECN bits...) > > That was in fact intentional. The LWAPP and CAPWAP specs never got > into specifying how the ECN bits are to be used. I would recommend > that we leave the use of ECN for a subsequent version of the > protocol. At this point we can either continue to be silent about > it, or simply add a statement at the end of section 2.6.1.2 to the > effect of: > > > The CAPWAP protocol does not make use of ECN [RFC3168], therefore the > ECN bits in the DSCP field MUST be set to zero (Not-ECT). > How to construct the outer IP header for tunneled data packets (when doing Split MAC) is an important detail for any spec doing tunneling, so I don't think being silent about it would be a good choice. RFC 3168 does have discussion (in Section 9) of various ways of doing ECN with tunnels. I think what you're proposing would be the "limited-functionality" option (ECN is preserved in the inner header, but disabled in the outer header). I don't have enough expertise in ECN to really know which of the options would be the best... (BTW, the text should be specific that only the ECN bits in the *outer* header are set to zero -- the ECN bits in the inner header are not modified even if the DSCP tag is modified. And the ECN bits are not really *in* the DSCP field, but next to it.) Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 26 10:07:56 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBACC28C1E1 for ; Tue, 26 Aug 2008 10:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1DcA86rUu9V for ; Tue, 26 Aug 2008 10:07:55 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id DD7DA28C1DE for ; Tue, 26 Aug 2008 10:07:55 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8E9ED433D96 for ; Tue, 26 Aug 2008 10:07:54 -0700 (PDT) Received: from hgblob.mail.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 2AEB244021A for ; Tue, 26 Aug 2008 10:07:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4719934AC0A6 for ; Tue, 26 Aug 2008 10:07:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 458A634AC147 for ; Tue, 26 Aug 2008 10:06:40 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted TTSSA (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 26 Aug 2008 10:06:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,271,1217808000"; d="scan'208";a="69638498" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 26 Aug 2008 17:06:32 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7QH6Wbj014429; Tue, 26 Aug 2008 10:06: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.13.8/8.13.8) with ESMTP id m7QH6W8G027558; Tue, 26 Aug 2008 17:06:32 GMT 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.1830); Tue, 26 Aug 2008 10:06:32 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Aug 2008 10:06:21 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206578F4D@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB72016FA015@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 171: Pasi nits on binding spec Thread-Index: AckG9WXqGxShcga1RZiZREGQsN/BbwABtdcvABOVkcAAFKRoQA== References: <4FF84B0BC277FF45AA27FE969DD956A20658317E@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A206583182@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72016FA015@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 26 Aug 2008 17:06:32.0456 (UTC) FILETIME=[16BE3080:01C9079E] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Capwap] Issue 171: Pasi nits on binding spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com OK - thanks for the pointer. In that case, I would propose the following text: 2.6.1.2. DSCP Support [...] The DSCP field also includes the Explicit Congestion Notification (ECN) bits. When packets received from stations are encapsulated by the WTP, the ECN bits are set to zero (0) in the outer header. The WTP does not modify the ECN bits in the original station's packet header. This mode of operation is detailed as the "limited functionality option" in [RFC3168]. If this is OK with you, are you comfortable with the rest of the text at this point? I'd like to know if I can close out the remaining issues. These are: 171 - This issue 161 - IANA Issues. I had responded to your comments about the vendor ID, etc. I think we are done, but need confirmation 158 - Allocation of WBID. You had commented that we need to provide some guidance to IANA when dealing with a Designated Expert request. I had provided some text. I think we are done here as well, but need confirmation. ??? - RSN Handling at WTP. You had asked me to add some additional language to help provide guidance on how the WTP deals with the RSN information element. I believe this is closed, but need confirmation. PatC -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Tuesday, August 26, 2008 12:20 AM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Issue 171: Pasi nits on binding spec Pat Calhoun wrote: > > I forgot to addess one more of your comments: > > > (BTW -- this discussion about DSCP reminded me that the spec doesn't > > say anything about the ECN bits...) > > That was in fact intentional. The LWAPP and CAPWAP specs never got > into specifying how the ECN bits are to be used. I would recommend > that we leave the use of ECN for a subsequent version of the protocol. > At this point we can either continue to be silent about it, or simply > add a statement at the end of section 2.6.1.2 to the effect of: > > > The CAPWAP protocol does not make use of ECN [RFC3168], therefore the > ECN bits in the DSCP field MUST be set to zero (Not-ECT). > How to construct the outer IP header for tunneled data packets (when doing Split MAC) is an important detail for any spec doing tunneling, so I don't think being silent about it would be a good choice. RFC 3168 does have discussion (in Section 9) of various ways of doing ECN with tunnels. I think what you're proposing would be the "limited-functionality" option (ECN is preserved in the inner header, but disabled in the outer header). I don't have enough expertise in ECN to really know which of the options would be the best... (BTW, the text should be specific that only the ECN bits in the *outer* header are set to zero -- the ECN bits in the inner header are not modified even if the DSCP tag is modified. And the ECN bits are not really *in* the DSCP field, but next to it.) Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From nedehtrt_1985@fedex.com Tue Aug 26 15:45:03 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A9DE3A6A81 for ; Tue, 26 Aug 2008 15:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DATE_IN_FUTURE_24_48=3.196, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVy9+ZA1XrDk for ; Tue, 26 Aug 2008 15:45:01 -0700 (PDT) Received: from 180-169-222-85.adsl.verat.net (180-169-222-85.adsl.verat.net [85.222.169.180]) by core3.amsl.com (Postfix) with ESMTP id 88EF33A6894 for ; Tue, 26 Aug 2008 15:44:56 -0700 (PDT) Message-ID: <000e01c90896$b99758b0$b4a9de55@desktop> From: "Carlysle Bautista" To: capwap-archive@lists.ietf.org Subject: Larger is better Date: Thu, 28 Aug 2008 00:46:20 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000A_01C908A7.7D2028B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 ----------=_NextPart_000_000A_01C908A7.7D2028B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you stretch her inside, she gets wetter and wetter faster. = http://www.needdome.com/ ----------=_NextPart_000_000A_01C908A7.7D2028B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If you stretch her inside, she gets = wetter and=20 wetter faster. http://www.needdome.com// ----------=_NextPart_000_000A_01C908A7.7D2028B0-- From Reinhart-ndavagen@fedex.com Tue Aug 26 15:46:14 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5927628C188 for ; Tue, 26 Aug 2008 15:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DATE_IN_FUTURE_24_48=3.196, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uu3P+NCdj1I8 for ; Tue, 26 Aug 2008 15:46:13 -0700 (PDT) Received: from 180-169-222-85.adsl.verat.net (180-169-222-85.adsl.verat.net [85.222.169.180]) by core3.amsl.com (Postfix) with ESMTP id 5F4633A68C6 for ; Tue, 26 Aug 2008 15:46:09 -0700 (PDT) Message-ID: <000f01c90896$e4973080$b4a9de55@desktop> From: "Reinhart formosa" To: capwap-archive@ietf.org Subject: Pop these for increase mass Date: Thu, 28 Aug 2008 00:47:33 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000B_01C908A7.A8200080" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 ----------=_NextPart_000_000B_01C908A7.A8200080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Last chance to get your hands on the incredible growth formula EVERYBODY = has been talking about. http://www.lighthuge.com/ ----------=_NextPart_000_000B_01C908A7.A8200080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Last chance to get your hands on the = incredible=20 growth formula EVERYBODY has been talking about. http://www.lighthuge.com//<= /DIV> ----------=_NextPart_000_000B_01C908A7.A8200080-- From namunah_1997@fedex.com Tue Aug 26 15:47:47 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0A43A6894 for ; Tue, 26 Aug 2008 15:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DATE_IN_FUTURE_24_48=3.196, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eg2wWSIlZqmc for ; Tue, 26 Aug 2008 15:47:47 -0700 (PDT) Received: from 180-169-222-85.adsl.verat.net (180-169-222-85.adsl.verat.net [85.222.169.180]) by core3.amsl.com (Postfix) with ESMTP id 2542E28C188 for ; Tue, 26 Aug 2008 15:47:41 -0700 (PDT) Message-ID: <001001c90897$1ba19cf0$b4a9de55@desktop> From: "Ashlee vertz" To: capwap-archive@megatron.ietf.org Subject: Grow your manhood today Date: Thu, 28 Aug 2008 00:49:05 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000C_01C908A7.DF2A6CF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 ----------=_NextPart_000_000C_01C908A7.DF2A6CF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You deserve a larger size, and so does your woman. = http://www.shinecome.com/ ----------=_NextPart_000_000C_01C908A7.DF2A6CF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
You deserve a larger size, and so does = your woman.=20 http://www.shinecome.com//<= /DIV> ----------=_NextPart_000_000C_01C908A7.DF2A6CF0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Aug 28 04:46:35 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4D0A3A68FD for ; Thu, 28 Aug 2008 04:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.268 X-Spam-Level: X-Spam-Status: No, score=-4.268 tagged_above=-999 required=5 tests=[AWL=-0.669, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQfb6QLyrepL for ; Thu, 28 Aug 2008 04:46:27 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 60B713A6BC2 for ; Thu, 28 Aug 2008 04:46:12 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 868B0430D9D for ; Thu, 28 Aug 2008 04:45:24 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 18D5B440230 for ; Thu, 28 Aug 2008 04:45:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 08C8719EBE8 for ; Thu, 28 Aug 2008 04:45:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 50E4619EBE6 for ; Thu, 28 Aug 2008 04:45:17 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted TTSSA (192.100.122.230 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by mx3.tigertech.net (Postfix) with ESMTP for ; Thu, 28 Aug 2008 04:45:17 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7SBj8OD031633; Thu, 28 Aug 2008 14:45:11 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Aug 2008 14:44:55 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Aug 2008 14:44:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Aug 2008 14:44:57 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720179FDE7@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20658317E@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 171: Pasi nits on binding spec Thread-Index: AckG9WXqGxShcga1RZiZREGQsN/BbwCCgDrQ References: <4FF84B0BC277FF45AA27FE969DD956A20658317E@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 28 Aug 2008 11:44:55.0401 (UTC) FILETIME=[7DA0C590:01C90903] X-Nokia-AV: Clean Subject: Re: [Capwap] Issue 171: Pasi nits on binding spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun wrote: > OK, this is a valid comment, so I have accepted all of your proposed > text changes and modified the following text to address the issues > you have raised > > > 2.6. CAPWAP Data Channel QoS Behavior > The CAPWAP IEEE 802.11 binding specification provides procedures to > allow for the WTP to enforce Quality of Service on IEEE 802.11 Data > Frames and MAC Management messages. > > 2.6.1. IEEE 802.11 Data Frames > When the WLAN is created on the WTP, a default Quality of Service > policy is established through the IEEE 802.11 WTP Quality of Service > message element (see Section 6.22). This default policy will cause > the WTP to use the default QoS values for any station associated with > the WLAN in question. The AC MAY also override the policy for a > given station, by sending the IEEE 802.11 Update Station QoS message > element (see Section 6.20), known as a station specific QoS policy. > > Beyond the default, and per station QoS policy, the IEEE 802.11 > protocol also allows a station to request special QoS treatment for a > specific flow through the TSPEC information elements found in the > IEEE 802.11-2007's QoS Action Frame. Alternatively, stations MAY > also use the WiFi Alliance's WMM specification instead to request QoS > treatment for a flow (see [WMM]). This requires the WTP to observe > the Status Code in the IEEE 802.11-2007 and WMM QoS Action ADDTS > responses from the AC, and provide the services requested in the > TSPEC information element. Similarly, the WTP MUST observe the > Reason Code information element in the IEEE 802.11-2007 and WMM QoS > Action DELTS responses from the AC by removing the policy associated > with the TSPEC. Fine so far.. > The IEEE 802.11 WTP Quality of Service message element's Tagging > Policy field indicates how the packets are to be tagged, via the 'P' > bit (802.1Q), 'D' bit (DSCP) and the 'U' bit (do not tag). The > Tagging Policy also includes the 'T' bit, which is used to inform the > WTP to not modify any markings set by the station. The expected > behavior of these bits is specified below. When an IEEE 802.11 > Update Station QoS message element is received, while the specific > "802.1p Tag" or DSCP values may change for a given station, the > original Tagging Policy (the use of the 'T', 'D', 'P' and 'U' bits) > remains the same. I think the usage of bits need some further work. There isn't really such a thing as "untagged" DSCP packet; the field is always there (it can be tagged with value 000000, of course). Also, it'd be more logical if the 802.1p and DSCP bits were orthogonal (you could use either one of them, neither, or both -- ). For DSCP, there seem to be three valid options for the outer header (only in Split MAC case): "use system default" (the DSCP field is always there with some value), "use NNNNNN", (sent in the CAPWAP message element), or "copy from inner header" (if it's IPv4/IPv6, and encryption is not done in AC; otherwise, use system default, I guess), and two choices for the inner header (both Split and Local MAC): "don't touch", and "replace with NNNNNN" (if it's IPv4/IPv6, and encryption is not done in AC). Two of the six (3x2) combinations, two ("copy from inner header"+ "replace with NNNNNN", and "use system default"+"replace with NNNNNN") probably don't make sense/are not important, so we have four left, requiring two bits: 00 "use system default"+"don't touch" (what is meant by "untagged" now, I guess) 01 "use NNNNNN"+"don't touch" (not valid for local MAC) 10 "copy from inner header"+"don't touch" (not valid for local MAC) 11 "use NNNNNN"+"replace with NNNNNN" For 802.1p, I'm not quite sure what the options are. Can the packet received from the STA contain a 802.1Q header (I guess a packet received from a host over wired Ethernet could contain it)? If it does, is it guaranteed to be the same value as the User Priority field of the QoS Control field of the IEEE 802.11 header? The current text seems to suggest there'd be three combinations which make sense, needing two bits. So two for DSCP + two for 802.1p would be the same amount of bits as now. Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 28 04:51:34 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 561463A6BD1 for ; Thu, 28 Aug 2008 04:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.194 X-Spam-Level: X-Spam-Status: No, score=-4.194 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4Tp8abIVLjr for ; Thu, 28 Aug 2008 04:51:28 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id E31533A68D9 for ; Thu, 28 Aug 2008 04:51:28 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 361B6430C2F for ; Thu, 28 Aug 2008 04:51:32 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id CDCA2440230 for ; Thu, 28 Aug 2008 04:51:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id BF0CD19EC0E for ; Thu, 28 Aug 2008 04:51:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 349EF19EC0C for ; Thu, 28 Aug 2008 04:51:26 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted TTSSA (192.100.122.230 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by mx3.tigertech.net (Postfix) with ESMTP for ; Thu, 28 Aug 2008 04:51:25 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7SBp8X8004999; Thu, 28 Aug 2008 14:51:17 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Aug 2008 14:51:00 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Aug 2008 14:50:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Aug 2008 14:50:49 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720179FE01@vaebe104.NOE.Nokia.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A206578F4D@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 171: Pasi nits on binding spec Thread-Index: AckG9WXqGxShcga1RZiZREGQsN/BbwABtdcvABOVkcAAFKRoQABZmNnA References: <4FF84B0BC277FF45AA27FE969DD956A20658317E@xmb-sjc-235.amer.cisco.com> <4FF84B0BC277FF45AA27FE969DD956A206583182@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB72016FA015@vaebe104.NOE.Nokia.com> <4FF84B0BC277FF45AA27FE969DD956A206578F4D@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 28 Aug 2008 11:50:46.0636 (UTC) FILETIME=[4EFAFAC0:01C90904] X-Nokia-AV: Clean Subject: Re: [Capwap] Issue 171: Pasi nits on binding spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun wrote: > OK - thanks for the pointer. In that case, I would propose the > following text: > > > 2.6.1.2. DSCP Support > [...] > The DSCP field also includes the Explicit Congestion Notification > (ECN) bits. When packets received from stations are > encapsulated by > the WTP, the ECN bits are set to zero (0) in the outer header. The > WTP does not modify the ECN bits in the original station's packet > header. This mode of operation is detailed as the "limited > functionality option" in [RFC3168]. > The ECN bits are not *included* in the DSCP field (which is 6 bits); they're the 2 bits next to the DSCP field. Otherwise, works for me. > If this is OK with you, are you comfortable with the rest of the > text at this point? I'd like to know if I can close out the > remaining issues. These are: > > 171 - This issue Not quite yet... > 161 - IANA Issues. I had responded to your comments about the > vendor ID, etc. I think we are done, but need confirmation Looks OK. > 158 - Allocation of WBID. You had commented that we need to provide > some guidance to IANA when dealing with a Designated Expert > request. I had provided some text. I think we are done here as well, > but need confirmation. I'd be happier if the WBID field would be large enough not to make scarcity an issue.. but I guess the text you provided is OK, too. > ??? - RSN Handling at WTP. You had asked me to add some additional > language to help provide guidance on how the WTP deals with the RSN > information element. I believe this is closed, but need confirmation. I think the proposed text probably covers everything. Best regards, Pasi _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: 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 Aug 28 12:23:59 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C38573A697D for ; Thu, 28 Aug 2008 12:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.133 X-Spam-Level: X-Spam-Status: No, score=-3.133 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CNUI8Jgeo6q for ; Thu, 28 Aug 2008 12:23:58 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 4391D3A6937 for ; Thu, 28 Aug 2008 12:23:58 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 86EB44328D5 for ; Thu, 28 Aug 2008 12:24:01 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id B36A7440232 for ; Thu, 28 Aug 2008 12:23:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 99E6E34AC051 for ; Thu, 28 Aug 2008 12:23:55 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3345934AC063 for ; Thu, 28 Aug 2008 12:23:55 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low); Whitelisted TTSSA (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 28 Aug 2008 12:23:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,288,1217808000"; d="scan'208";a="70593882" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 28 Aug 2008 19:23:42 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7SJNgq9010436; Thu, 28 Aug 2008 12:23:42 -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.13.8/8.13.8) with ESMTP id m7SJNgbL004528; Thu, 28 Aug 2008 19:23:42 GMT 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.1830); Thu, 28 Aug 2008 12:23:42 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Aug 2008 12:23:49 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2065DECBC@xmb-sjc-235.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB720179FDE7@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 171: Pasi nits on binding spec Thread-Index: AckG9WXqGxShcga1RZiZREGQsN/BbwCCgDrQAAzABnA= References: <4FF84B0BC277FF45AA27FE969DD956A20658317E@xmb-sjc-235.amer.cisco.com> <1696498986EFEC4D9153717DA325CB720179FDE7@vaebe104.NOE.Nokia.com> From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 28 Aug 2008 19:23:42.0352 (UTC) FILETIME=[94F82900:01C90943] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Capwap] Issue 171: Pasi nits on binding spec X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com > > The IEEE 802.11 WTP Quality of Service message element's Tagging > > Policy field indicates how the packets are to be tagged, via the 'P' > > bit (802.1Q), 'D' bit (DSCP) and the 'U' bit (do not tag). The > > Tagging Policy also includes the 'T' bit, which is used to inform the > > WTP to not modify any markings set by the station. The expected > > behavior of these bits is specified below. When an IEEE 802.11 > > Update Station QoS message element is received, while the specific > > "802.1p Tag" or DSCP values may change for a given station, the > > original Tagging Policy (the use of the 'T', 'D', 'P' and 'U' bits) > > remains the same. > > > I think the usage of bits need some further work. > > There isn't really such a thing as "untagged" DSCP packet; the field is always there (it can be tagged with value 000000, of course). > Also, it'd be more logical if the 802.1p and DSCP bits were orthogonal (you could use either one of them, neither, or both -- ). OK, so I have changed "do not tag" to "set to zero", and added the last paragraph: 2.6.1. IEEE 802.11 Data Frames [...] The IEEE 802.11 WTP Quality of Service message element's Tagging Policy field indicates how the packets are to be tagged, via the 'P' bit (802.1Q), 'D' bit (DSCP) and the 'U' bit (set to zero). The Tagging Policy also includes the 'T' bit, which is used to inform the WTP to not modify any markings set by the station. The expected behavior of these bits is specified below. When an IEEE 802.11 Update Station QoS message element is received, while the specific "802.1p Tag" or DSCP values may change for a given station, the original Tagging Policy (the use of the 'T', 'D', 'P' and 'U' bits) remains the same. The use of DSCP and 802.1p are not mutually exclusive. An AC MAY request that a WTP use non, either, or both types of QoS mechanisms at the same time. The 'D' and 'P' bits are independent, while the 'T' bit behavior is common for both mechanisms. > For DSCP, there seem to be three valid options for the outer header (only in Split MAC case): "use system default" (the DSCP field is always there with some value), "use NNNNNN", (sent in the CAPWAP message element), or "copy from inner header" (if it's IPv4/IPv6, and encryption is not done in AC; otherwise, use system default, I guess), and two choices for the inner header (both Split and Local MAC): "don't touch", and "replace with NNNNNN" (if it's IPv4/IPv6, and encryption is not done in AC). > > Two of the six (3x2) combinations, two ("copy from inner header"+ "replace with NNNNNN", and "use system default"+"replace with NNNNNN") probably don't make sense/are not important, so we have four left, requiring two bits: > > 00 "use system default"+"don't touch" (what is meant by > "untagged" now, I guess) > 01 "use NNNNNN"+"don't touch" (not valid for local MAC) > 10 "copy from inner header"+"don't touch" (not valid for local MAC) > 11 "use NNNNNN"+"replace with NNNNNN" I'm not sure that I understand why the confusion exists. Let me break this down and see if I can understand where the issue is. First, let's tackle Local MAC (they are separate because the behavior is different): D=1, T=0: The WTP re-marks the DSCP field in the station's packet to either the default, or the station specific DSCP policy. This means the WTP changes the DSCP field to either the default, or the station policy. D=1, T=1: The WTP does not modify the DSCP field in the station's packets. The WTP leaves the DSCP field as-is D=0, T=0: The WTP sets the DSCP field in the station's packet to zero (0). This bit combination MUST NOT be set if the 'U' bit is not set. The WTP sets the DSCP field to zero (0) - meaning it overrides the field. This is basically the same as the 'U' option - meaning we could remove that option, but I was trying to minimize changes to the protocol. Now let's take a look at Split MAC: D=1, T=0: The WTP marks the outer header's DSCP field based on either the default or the station specific DSCP policy. Similarly, the WTP also re-marks the inner packet header's DSCP field to the same DSCP value. If encryption services are provided by the AC (see Section 6.15), the WTP does not modify the inner packet. Similar to the Local MAC, the WTP re-marks the DSCP field to the default, or station policy. Both the outer and inner packet is modified, depending upon whether encryption is done at the AC. D=1, T=1: The WTP marks the outer header's DSCP field based on the value set in the inner packet header's DSCP field. Further the WTP does not modify the inner packet header's DSCP field. This option is invalid if the AC is providing encryption services, since the inner packet would be encrypted, and therefore not readable by the WTP. If this option is set while the AC is providing encryption services, the WTP must provide the services defined in the "D=1, T=0" option. If encryption services are provided at the WTP, the outer DSCP field is set to the value found in the inner packet. If encryption is done at the AC, then this option is invalid, and the WTP is to use the "D=1, T=0" option instead. D=0, T=0: The WTP sets the DSCP field of the inner and outer packet header to zero (0). If encryption services are provided by the AC, the WTP MUST NOT modify the inner packet header's DSCP field. This bit combination MUST NOT be set if the 'U' bit is not set. Both the outer and inner DSCP fields are set to zero (0). > > For 802.1p, I'm not quite sure what the options are. Can the packet received from the STA contain a 802.1Q header (I guess a packet received from a host over wired Ethernet could contain it)? If it does, is it guaranteed to be the same value as the User Priority field of the QoS Control field of the IEEE 802.11 header? First, the 802.11 protocol does not permit an 802.1Q header to be sent over the air, so the WTP never sees the header. Instead, we rely on the QoS control field - it is the only thing the WTP will see (from a link layer priority field perspective). Second, just to make sure that we are clear about where the 802.1Q header is inserted, I have made a small change to the text. To make sure that this is clear, I have modified the first sentence and added the last two sentences to the end of the first paragraph: 2.6.1.1. 802.1p Support [...] The actual treatment is identical in both Split and Local MAC mode, except that the former requires the 802.1Q header to be added to the station's packet vs. the outer packet header. The IEEE 802.11 does not permit the station's packet to include an 802.1Q header. Instead, the QoS mechanisms defined in the IEEE 802.11 standard are used by stations to mark a packet's priority. and then we provide the actual behavior description for the bits, which for this case it is OK to include in a single block for both Split and Local MAC. The text reads: P=1, T=0: The WTP marks the priority field in the 802.1Q header, which is added to the station's packet (in a Local MAC mode) or outer packet header (in a Split MAC mode), to either the default, or the station specific 802.1p policy. So in this case we add an 802.1Q header, and set the priority field based on the default, or the user policy. P=1, T=1: The WTP marks the priority field in the 802.1Q header, which is added to the station's packet (in a Local MAC mode) or outer packet header (in a Split MAC mode), to the value found in User Priority field of the QoS Control field of the IEEE 802.11 header. If the QoS Control field is not present in the IEEE 802.11 header, then the packet is handled as defined in the above option. In this case, we copy the value of the User Priority field in the QoS Control field to the 802.1Q header. This is *similar* to the DSCP behavior, where we use a station set value. P=0, T=0: The WTP sets the priority field in the 802.1Q header to zero (0), if present. This bit combination MUST NOT be set if the 'U' bit is not set. If the header exists, then the value is set to zero (0). So the behavior for both DSCP *and* 802.1p is very similar in all cases, except we are dealing with different fields in the packet. Maybe if you could provide me more clarity on what above is causing the confusion, then I could clean that up. From the e-mail you sent, I wonder if you just read the first section, and didn't read the bit descriptions, which led to the confusion. > The current text seems to suggest there'd be three combinations which make sense, needing two bits. So two for DSCP + two for 802.1p would be the same amount of bits as now. There are three bits. The 'T' bit behavior is the same, regardless of whether DSCP or 802.1p was used. Then DSCP and 802.1p can be set separately - and in combination. PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap